Canonical-URLs und Duplicate Content in Next.js, PL/EN/DE, hreflang, Trailing Slash (2026)

TL;DR

Ein Canonical sagt Google: „Das ist die bevorzugte URL für diesen Inhalt.“ Auf einer mehrsprachigen Unternehmenssite (PL/EN/DE) bekommt jedes Locale ein eigenes Self-Canonical, die polnische Seite zeigt nicht auf die englische URL. hreflang bedeutet „das ist eine Übersetzung“; Canonical bedeutet „das ist das Original unter technischen Duplikaten.“ Im Next.js App Router setzen Sie alternates.canonical + alternates.languages, ergänzen 301s für Trailing Slash/www und halten UTMs aus der indexierten URL. Unten: Duplikat-Map, Metadata-API-Code, hreflang↔Canonical-Konflikte und GSC-Checkliste.

Für wen

• Betreiber von pl/en/de-Sites mit Duplikat-Warnungen in GSC
• Next.js-Entwickler nach Migration oder URL-Umbau
• SEOs mit www vs. non-www, Slash vs. No-Slash, UTMs im Index
• Teams, deren Preview/ISR Extra-URLs erzeugt
• Firmen mit dem „selben Angebot“ unter drei Pfaden

Keyword (SEO)

canonical url nextjs, duplicate content pl en de, hreflang vs canonical, trailing slash seo, alternates.canonical app router, kanonische url 2026

Canonical vs. hreflang, unterschiedliche Jobs

Klassischer Fehler: polnisches Canonical auf Englisch „weil EN der Hauptmarkt ist.“ Google kann hreflang ignorieren und auf EN konsolidieren, PL verschwindet lokal.

Korrekt: Self-Canonical pro Locale + gegenseitiges hreflang (+ x-default).

Typische Duplikat-Quellen auf Service-Sites

1. www vs. non-www und http vs. https
2. Trailing Slash (/de/leistungen vs. /de/leistungen/)
3. Parameter (UTM, fbclid, Sortierung)
4. Locale-Fallback (Middleware liefert DE auf / und /de)
5. Alte URLs nach Redesign ohne 301
6. Blog-Paginierung / Tags mit Thin Content
7. Preview / Draft versehentlich indexiert
8. Gleicher CMS-Inhalt unter zwei Slugs

Case Studies in Branchly brauchen einen Slug pro Locale und ein stabiles Canonical in Metadata, keine zweite „Kampagnen-URL“.

Next.js App Router, Metadata API

import type { Metadata } from 'next';

const BASE = 'https://devstudioit.com';

const paths = {
  pl: '/pl/oferta',
  en: '/en/services',
  de: '/de/leistungen',
} as const;

export async function generateMetadata({
  params,
}: {
  params: Promise<{ locale: keyof typeof paths }>;
}): Promise<Metadata> {
  const { locale } = await params;
  const path = paths[locale];

  return {
    title: '…',
    description: '…',
    alternates: {
      canonical: `${BASE}${path}`,
      languages: {
        pl: `${BASE}${paths.pl}`,
        en: `${BASE}${paths.en}`,
        de: `${BASE}${paths.de}`,
        'x-default': `${BASE}${paths.en}`,
      },
    },
  };
}

x-default ist der Fallback für unerkannte Sprachen (oft EN oder Sprachwahl), nicht „wichtigster Markt“.

Blog, gemeinsamer Slug, Locale im Pfad

canonical: https://devstudioit.com/de/blog/{slug}
hreflang pl/en/de → /{locale}/blog/{slug}

Pfad-Präfixe statt ?lang=de als kanonisches Modell.

Trailing Slash, eine Konvention wählen

Next.js: trailingSlash: true | false in next.config.

Eine Politik auf DevStudioIT Cloud aligned mit Next-Config. Abweichung = Soft-Duplikate in GSC.

const nextConfig = {
  trailingSlash: false,
};

UTM und Tracking-Parameter

Landing-Canonical ohne UTMs. Tracking bleibt in GA4; der Index sieht die saubere URL.

Konflikte, die Google oft ignoriert

• Canonical A→B, während B zurück auf A zeigt (Schleife)
• hreflang auf noindex-URLs
• hreflang auf 404 / Redirect-Ketten
• Cross-Domain-Canonical ohne starken Grund
• HTML-Canonical X, Sitemap nur Y inkonsistent

Regel: Jede URL im hreflang-Cluster muss 200, indexierbar, self-canonical sein und volle Alternates haben.

Diagnose in Search Console

1. Page indexing → Duplikat / „Google chose different canonical“
2. URL Inspection → user-declared vs. Google-selected Canonical
3. Wenn Google abweicht: Self-Canonical stärken, Content angleichen, interne Links auf die bevorzugte URL zeigen

Interne Links verstärken das Canonical

Canonical ist ein Hinweis, Google gewichtet auch interne Links. Zeigen Nav, Blog und Footer auf /de/leistungen/, während das Canonical /de/leistungen sagt, senden Sie widersprüchliche Signale. Nach der Slash-Wahl:

• Navigation, Breadcrumbs und CTAs aktualisieren
• Sitemap neu generieren
• Ältere CMS-/Case-Study-URLs in Branchly bereinigen

Auf dem Hosting (DevStudioIT Cloud) den 301 möglichst nah am Edge halten, kürzere Ketten = saubererer Crawl.

Rollout-Checkliste

1. Eine Host-Politik (https + www/apex)
2. Eine Trailing-Slash-Politik + 301
3. Self-Canonical auf jeder öffentlichen Seite
4. Volles hreflang pl/en/de (+ x-default)
5. Keine UTMs im Canonical
6. Alte URLs → 301 auf neu
7. Staging noindex / eigene Domain
8. Sitemap nur Canonical-URLs
9. Nach Deploy: 5–10 Kernseiten inspizieren
10. Duplikat-Report 2–4 Wochen monitoren
11. Interne Links am Canonical ausrichten
12. Keine Canonical-Schleifen A↔B

FAQ

Ersetzt Canonical den 301?

Nein. 301 bewegt Nutzer und Link Equity auf HTTP-Ebene. Canonical ist ein Hinweis für Near-Duplicate-Indexierung.

Braucht jede Seite hreflang?

Nur wenn eine gleichwertige Übersetzung existiert. Eine nur-PL-Seite sollte keinen EN/DE-Cluster vortäuschen.

Was ist mit Blog-Paginierung?

Self-Canonical auf jeder paginierten Seite oder View-all-Strategie, eine wählen. Nicht jede Seite auf page=1 zeigen, wenn page=2 eigenen Wert hat.

Soll JSON-LD das Canonical wiederholen?

mainEntityOfPage / @id sollten dem Canonical entsprechen, Konsistenz hilft, Abweichung verwirrt.

CTA

Duplikate über PL/EN/DE, Slash-Chaos oder „Google chose a different canonical“?

• Canonical-/hreflang-Audit buchen, Metadata API, 301s, DevStudioIT Cloud