01 Was ist rel=canonical?
Ein Canonical-Tag ist ein HTML-Element, das Suchmaschinen mitteilt, welche Version einer URL die „Master-Version" ist, wenn mehrere URLs im Wesentlichen denselben Inhalt ausliefern. Es sieht so aus:
<link rel="canonical" href="https://example.com/products/blauer-widget" />Canonical-Tags lösen ein Problem, das Sie möglicherweise nicht bemerkt haben: Die meisten Websites erzeugen versehentlich Dutzende von URL-Varianten für dieselbe Seite — Query-Parameter, Tracking-Codes, Session-IDs, Sortierreihenfolgen, paginierte Ansichten. Ohne Canonicals konkurriert jede Variante gegen die anderen im Google-Index, und Ihre Ranking-Signale fragmentieren sich über alle Varianten.
02 Warum Canonical-Tags wichtig sind
Wenn Google denselben Inhalt unter mehreren URLs sieht, muss es eine zur Indexierung auswählen. Wenn Sie nicht angeben, welche kanonisch ist, rät Google — und die gewählte URL ist möglicherweise nicht die, die Sie wollen.
Der Canonical-Tag leistet drei Dinge auf einmal:
- Konsolidiert Ranking-Signale. Backlinks auf nicht-kanonische Varianten geben ihren Wert an die kanonische Version weiter.
- Verhindert Duplicate-Content-Verwässerung über Query-Parameter-Varianten.
- Teilt Google Ihre Präferenz mit, wenn mehrere URLs gültig sind (z.B.
/blog/beitragvs./blog/beitrag?ref=newsletter).
Eine wichtige Nuance: Ein Canonical-Tag ist ein Hinweis, keine Direktive. Google kann ihn ignorieren, wenn andere Signale stark auf eine andere URL als die richtige kanonische hinweisen. In der Praxis befolgt Google ihn meistens — aber verlassen Sie sich nicht auf Canonicals, um strukturelle Duplicate-Content-Probleme zu lösen.
03 Wann man Canonical verwendet
Fügen Sie in diesen Situationen einen Canonical-Tag hinzu:
- Selbstreferenzierendes Canonical auf jeder indexierbaren Seite. Ja, jede Seite sollte auf sich selbst canonicalen. Das schützt Sie vor versehentlichen URL-Parametern, auf die Google in der Wildnis stößt.
- Tracking-Parameter-Varianten:
?utm_source=newsletter-URLs canonicalen zur sauberen URL. - HTTP und HTTPS, www und non-www: Nicht-bevorzugte Versionen canonicalen zur bevorzugten (zusätzlich zu einem 301-Redirect).
- Paginierter Content: Seite 2, 3, 4… jede canonicalt zu sich selbst, nicht zurück zu Seite 1.
- Syndizierter Content: Wenn ein Partner Ihren Artikel republiziert, bitten Sie ihn, zurück zu Ihrer URL zu canonicalen.
- Produktvarianten: Wenn Sie ein Produkt in fünf Farben unter fünf URLs haben, canonicalen Sie die Varianten zur Haupt-Produktseite.
04 Wann man Canonical NICHT verwenden sollte
Canonical-Tags werden als Allheilmittel für Deduplizierung missbraucht. Das sind sie nicht. Verwenden Sie kein Canonical, wenn:
- Die Seiten sich wirklich unterscheiden. Zwei Produktseiten mit unterschiedlichem Content sollten nicht zu einer einzigen URL canonicalen — sie fallen beide aus dem Index.
- Sie eine Seite de-indexieren möchten. Verwenden Sie stattdessen ein
noindex-Meta-Tag. Canonical entfernt URLs nicht zuverlässig aus dem Index. - Sie Nutzer weiterleiten möchten. Verwenden Sie einen 301-Redirect. Canonicals leiten nicht um — sie sind nur ein Hinweis für die Indexierungspräferenz.
- Content paginiert und auf jeder Ebene bedeutsam ist (z.B. hat Blog-Seite 2 andere Beiträge als Seite 1). Canonicals zu Seite 1 kosten Sie indexierte Seiten.
05 Implementierung
Es gibt zwei gültige Wege, ein Canonical zu deklarieren:
1. HTML <link>-Tag (am häufigsten)
Im <head> platzieren:
<link rel="canonical" href="https://example.com/seite" />2. HTTP Link-Header (für Nicht-HTML-Ressourcen)
Für PDFs, Bilder oder andere Nicht-HTML-Assets nutzen Sie den HTTP-Header:
Link: <https://example.com/whitepaper.pdf>; rel="canonical"Verwenden Sie immer die absolute URL mit Schema (https://) und kanonischem Host. Relative URLs funktionieren technisch, verursachen aber subtile Fehler, wenn CDNs oder Staging-Umgebungen ins Spiel kommen.
06 Vier häufige Fehler
Das sind die Canonical-Bugs, die wir auf etwa der Hälfte aller auditierten Websites sehen.
Fehler 1: Paginierte Archive zu Seite 1 canonicalen
Jahrelang unterstützte Google rel="next"/rel="prev"-Paginierungssignale. Diese sind weg. Best Practice ist jetzt, dass jede paginierte Seite auf sich selbst canonicalt. Seite 2, 3, 4… alle auf Seite 1 zu zeigen, lässt Google die tieferen Seiten aus dem Index fallen — inklusive aller Inhalte.
Fehler 2: Mobile zu Desktop-URLs canonicalen (oder umgekehrt)
Wenn Sie separate m.example.com-URLs betreiben, sollte die mobile Version zu Desktop canonicalen, während Desktop rel="alternate" zurück zu Mobile verwendet. Die meisten Websites überspringen dies oder haben die Richtung falsch.
Fehler 3: Canonical zeigt auf einen Redirect oder eine 404-Seite
Das Canonical-Ziel muss einen 200-Status zurückgeben. Bei einem 301-Redirect muss Google diesen folgen, um das echte Canonical zu finden — das schwächt das Signal. Bei einer 404-Seite wird das Canonical stillschweigend ignoriert.
Fehler 4: Widersprüchliche Signale
Eine Seite, die zu einer URL canonicalt, intern aber unter einer anderen verlinkt wird, in einer dritten sitemap auftaucht und hreflang zu einer vierten hat, gibt Google fünf konkurrierende Signale. Es wählt seine eigene Antwort — die selten die gewünschte ist. Canonical, interne Links, Sitemaps und hreflang müssen übereinstimmen.
07 Wie man die Canonical-Konfiguration prüft
Ein sauberes Canonical-Audit umfasst vier Prüfungen:
- Hat jede indexierbare Seite einen Canonical-Tag? Seiten ohne Tag sind Googles Interpretation überlassen.
- Ist das Canonical selbstreferenziell? Bei den meisten Seiten sollte das Canonical gleich der eigenen URL sein.
- Gibt das Canonical-Ziel einen 200-Status zurück? Nicht 301, nicht 404 — 200.
- Stimmen Canonical, Sitemap und interne Links überein? Google sollte eine konsistente Canonical-Antwort aus allen Signalen erhalten.
Smart SEO Audit prüft alle vier automatisch und markiert Konflikte im Audit-Bericht.
? Häufige Fragen
Ist ein Canonical-Tag eine Anweisung oder ein Hinweis?
Es ist ein Hinweis, keine Anweisung. Google befolgt ihn meist, kann ihn aber ignorieren, wenn andere Signale stark für eine andere URL als Canonical sprechen. Verlassen Sie sich nicht auf Canonicals, um strukturelle Duplicate-Content-Probleme zu beheben — sie bündeln Signale und drücken eine Präferenz aus, erzwingen aber keine Indexierung.
Sollte jede Seite einen selbstreferenzierenden Canonical haben?
Ja. Jede indexierbare Seite sollte auf sich selbst kanonisieren. Das schützt vor zufälligen URL-Parametern, denen Google begegnet (Tracking-Codes, Session-IDs, Sortierungen), indem Sie mitteilen, welche saubere URL die Master-Version ist.
Kann ich mit einem Canonical eine Seite aus Google entfernen?
Nein. Canonical-Tags deindexieren nicht zuverlässig und leiten Nutzer nicht um. Nutzen Sie ein noindex-Meta-Tag, um eine Seite aus dem Index zu halten, und eine 301-Weiterleitung, um Nutzer (und Signale) zu einer anderen URL zu schicken. Canonical gibt nur einen Hinweis, welches Duplikat indexiert werden soll.
→ Verwandte Guides
Tiefer einsteigen — diese Guides behandeln verwandte Themen.