Canonical-Tag richtig setzen — Duplikate konsolidieren ohne Index-Chaos
Sobald eine Seite über mehrere URLs erreichbar ist — mit und ohne Tracking-Parameter, mit www und ohne, http und https, sortiert und gefiltert — hat Google ein Problem: Welche Variante soll in den Index, und auf welche bündeln sich die Signale? Der Canonical-Tag ist deine Antwort darauf. Der Canonical-Tag im Überblick erklärt die Grundlagen; dieser Artikel geht in die Mechanik, die Fallstricke und die Abgrenzung zu den anderen Konsolidierungs-Signalen.
Was rel=canonical bewirkt
<link rel="canonical" href="https://example.com/produkt/"> im <head> sagt Google: Wenn du diese URL und andere für quasi gleichwertig hältst, nimm bitte diese als Vorzugs-URL (die kanonische) in den Index. Alle Ranking-Signale der Duplikate — Links, Relevanz, Crawl-Aufmerksamkeit — werden auf diese eine URL konsolidiert, statt sich über mehrere Varianten zu verteilen.
Wichtig: Der Canonical entfernt keine Seite und sperrt nichts. Er ist reine Index-Auswahl. Die Duplikate bleiben erreichbar, werden aber nicht eigenständig indexiert.
Self-Referencing Canonical als Default. Jede Seite sollte einen Canonical auf sich selbst setzen — auch ohne bekannte Duplikate. Das räumt Tracking-Parameter (utm_*, gclid, fbclid) und Crawler-Varianten direkt mit ab und ist Best Practice. Eine Seite ohne jeden Canonical überlässt die Auswahl komplett Google.
Methoden — und wie stark sie wirken
Google kennt mehrere Wege, eine kanonische URL zu signalisieren, mit unterschiedlicher Durchsetzungskraft:
- 301-Redirect — das stärkste Signal. Wenn eine Duplikat-URL gar nicht mehr eigenständig existieren soll, ist der dauerhafte Redirect das klarste Zeichen.
- rel=canonical (Link-Element oder HTTP-Header) — starkes Signal. Der HTTP-Header ist die Variante für Nicht-HTML-Dateien wie PDFs.
- Sitemap-Eintrag — schwaches Signal. Nur als unterstützender Hinweis, nie allein verlassen.
Diese Signale stapeln sich: Konsistent kombiniert wirken sie deutlich stärker. Pflicht in allen Fällen: absolute URLs im Canonical, keine relativen Pfade.
Der entscheidende Punkt: Canonical ist ein Hinweis, kein Befehl
Das ist die Eigenschaft, die die meisten Probleme erklärt. Google behandelt rel=canonical als Signal, nicht als Direktive. Sind die Signale widersprüchlich, kann Google eine andere URL als kanonisch wählen, als du angegeben hast. In der Search Console siehst du das als „Von Google ausgewählte kanonische URL”, die von deiner „vom Nutzer angegebenen” abweicht.
Typische Auslöser dafür:
- Die von dir gewünschte kanonische URL bekommt kaum interne Links, die Duplikate dagegen viele.
- Die Sitemap listet eine andere URL als der Canonical.
- Der Canonical zeigt auf eine Seite, die per Redirect oder Fehlercode antwortet.
Google folgt am Ende dem Gesamtbild, nicht einem einzelnen Tag. Konsistenz über alle Signale ist deshalb wichtiger als der Canonical allein.
Typische Fallstricke
Canonical auf eine noindex-Seite. Widersprüchlich: „Indexiere diese als kanonisch” plus „indexiere sie nicht”. Google muss raten und ignoriert oft beides. Canonical und noindex gehören nie auf dieselbe Ziel-URL.
Canonical-Ketten. A canonicalisiert auf B, B auf C. Jede Umleitungsstufe verwässert das Signal. Immer direkt auf die finale URL zeigen, die mit 200 OK antwortet.
Canonical auf 3xx/4xx. Zeigt der Canonical auf eine weitergeleitete oder fehlende URL, ist das Signal kaputt. Jede kanonische URL muss selbst 200 zurückgeben.
Parameter-URLs. Filter-, Sortier- und Tracking-Parameter erzeugen massenhaft Duplikate. Self-Canonical auf die parameterlose Basis-URL räumt das auf und schont das Crawl-Budget.
Pagination. Seite 2, 3, 4 dürfen nicht auf Seite 1 canonicalisieren — das streicht ihre Inhalte aus dem Index. Korrekt ist Self-Canonical pro Paginierungs-Seite.
Cross-Domain-Canonical. Google unterstützt Canonicals über Domain-Grenzen (etwa bei Syndication). Gefährlich wird es, wenn in Multi-Brand-Setups versehentlich auf eine fremde Domain canonicalisiert wird — dann rankt die eigene Marke nicht, weil Google die andere Domain indexiert.
Mobile/AMP. Bei separaten Mobile-URLs nutzt die Desktop-Seite rel=canonical auf sich selbst und rel=alternate mit Media-Attribut auf die Mobile-Variante; die Mobile-Seite canonicalisiert zurück auf Desktop. AMP folgt eigenen Canonical-Regeln aus der AMP-Doku.
Abgrenzung: Canonical vs. 301 vs. noindex vs. hreflang
Vier Signale, vier verschiedene Jobs. Sie werden ständig verwechselt:
| Signal | Was es sagt | Wann nutzen | |---|---|---| | rel=canonical | „Bündle die Index-Signale auf diese Vorzugs-URL.” Beide URLs bleiben erreichbar. | Echte oder Beinahe-Duplikate, die beide bestehen bleiben sollen (Parameter, Varianten). | | 301-Redirect | „Diese URL ist umgezogen, geh dauerhaft dorthin.” Das Original verschwindet. | URL soll wirklich ersetzt werden (Migration, Konsolidierung). | | noindex | „Indexiere diese Seite nicht.” Sie bleibt erreichbar, taucht aber nicht in der Suche auf. | Seite soll existieren, aber nicht ranken (interne Suche, Danke-Seiten). | | hreflang | „Das sind Sprach-/Regionsvarianten derselben Seite.” Keine Konsolidierung. | Mehrsprachige/regionale Versionen, siehe hreflang. |
Die häufigste Verwechslung: Sprachvarianten nicht per Canonical zusammenführen. DE-Seite canonicalisiert auf die DE-URL, EN auf die EN-URL — die Verbindung läuft über hreflang, nicht über Canonical. Wer DE auf EN canonicalisiert, löscht die deutsche Version faktisch aus dem Index.
Die Einbettung in die übrigen Head-Tags — Title, Description, Robots — steht im Meta-Tags-Artikel.
FAQ
Ist der Canonical-Tag ein Befehl an Google? Nein. Er ist ein Hinweis. Google kann bei widersprüchlichen Signalen eine andere URL als kanonisch wählen — sichtbar als „Von Google ausgewählte kanonische URL” in der Search Console. Konsistenz über alle Signale erhöht die Chance, dass Google deiner Angabe folgt.
Soll jede Seite einen Self-Canonical haben? Ja, das ist Best Practice. Ein Canonical auf sich selbst räumt Tracking-Parameter und Crawler-Varianten ab und macht die Index-Auswahl eindeutig — auch bei Seiten ohne bekannte Duplikate.
Was ist der Unterschied zwischen Canonical und 301? Der 301 leitet dauerhaft um, das Original verschwindet. Der Canonical lässt beide URLs erreichbar und bündelt nur die Index-Signale. 301 nutzt du, wenn eine URL wirklich ersetzt wird; Canonical, wenn beide Varianten bestehen bleiben sollen.
Darf ich Paginierungs-Seiten auf Seite 1 canonicalisieren? Nein. Das streicht die Inhalte von Seite 2, 3, 4 aus dem Index. Jede Paginierungs-Seite bekommt einen Self-Canonical auf sich selbst.
Kann ich Sprachvarianten per Canonical verbinden? Nein. Dafür ist hreflang da. Jede Sprachversion canonicalisiert auf sich selbst; die Verbindung der Sprachen läuft über hreflang. Ein Canonical von DE auf EN entfernt die deutsche Seite aus dem Index.
Entdecke mehr
Meta-Tags richtig nutzen — Title, Description, Canonical, Robots
Title, Description, Canonical, Robots-Meta — was Google wirklich nutzt, wo es umschreibt, und wie du die Tags so setzt, dass Klick und Indexierung stimmen.
Glossar301-Weiterleitung
Eine 301-Weiterleitung ist ein HTTP-Statuscode, der eine URL dauerhaft auf eine andere weiterleitet — der Standard für URL-Änderungen, Domain-Umzüge und Site-Migrationen.
LexikonTechnisches SEO — was Google wirklich crawlen, rendern und indexieren muss
Wie Crawl-Budget, Robots, Sitemap, JS-Rendering, Indexierung, Canonical und Core Web Vitals zusammenspielen — der vollständige Bogen für produktive Sites.