Guide

Fünf Canonical-Konflikte, die Google für Sie entscheidet

Googles eigene Formulierung lautet: ein Hinweis, keine Regel. Das sind die fünf Stellen, an denen Ihre Signale sich widersprechen, und welches gewinnt.

Von WebDoctor-Redaktion·23. September 2026·5 Min. Lesezeit


Ein Canonical-Tag ist ein Hinweis, keine Regel. Genau so steht es auf Googles Seite zur Kanonisierung, und Google bestimmt die kanonische URL selbst: aus Weiterleitungen, Sitemap-Einträgen, der HTTPS-Präferenz und hreflang-Clustern, nicht nur aus Ihrem Tag. Widersprechen sich diese Signale, verliert Ihr Tag. Das sind die fünf Konflikte, die dazu führen.

Ist ein Canonical-Tag eine Anweisung oder ein Hinweis?

Ein Hinweis. Auf Googles Seite What is canonicalization heißt es, dass die Angabe einer kanonischen Präferenz ein Hinweis ist und keine Regel. Google fasst Seiten, die es als Duplikate liest, zu einem Cluster zusammen und markiert darin die Seite, die es als die vollständigste und nützlichste für Suchende einstuft. Ihr Tag ist ein Eingangswert dieser Entscheidung, und es steht in einer veröffentlichten Rangfolge.

SignalStärkeWas Google dazu sagt
WeiterleitungenStark, an erster Stelle genanntEin starkes Signal, dass das Ziel der Weiterleitung kanonisch werden soll
rel=canonical-AnnotationStark, an zweiter Stelle genanntEin starkes Signal, dass die angegebene URL kanonisch werden soll
Eintrag in der SitemapSchwachHilft den in einer Sitemap gelisteten URLs, kanonisch zu werden. Die Duplikate ermittelt Google trotzdem selbst
HTTPS vor HTTPSignal aus der Site-KonfigurationGoogle bevorzugt HTTPS-Seiten als kanonisch, außer bei widersprüchlichen Signalen
Zugehörigkeit zu einem hreflang-ClusterSignal aus der Site-KonfigurationGoogle bevorzugt URLs, die Teil eines hreflang-Clusters sind

Zwei Best Practices sollten Sie sich vor allen folgenden Konflikten notieren. Nutzen Sie robots.txt nicht zur Kanonisierung, denn Google kann per robots.txt gesperrte URLs trotzdem indexieren, dann eben ohne Inhalt. Und geben Sie für dieselbe Seite nicht über verschiedene Techniken verschiedene kanonische URLs an.

Darf ein Canonical auf eine Seite mit noindex, robots.txt-Sperre oder Weiterleitung zeigen?

Technisch ja, und jede dieser Varianten untergräbt das Tag. Google empfiehlt ausdrücklich nicht, noindex zur Auswahl eines Canonicals innerhalb einer Website einzusetzen, weil die Seite damit komplett aus der Suche fällt. rel=canonical nennt Google stattdessen als bevorzugte Lösung. Auf eine per robots.txt gesperrte URL zu zeigen, ist noch schlechter: Die noindex-Dokumentation sagt klar, dass ein Crawler, der eine Seite nicht abrufen kann, auch keine Regel darauf zu sehen bekommt.

Weiterleitungen sind der subtile Fall, denn sie stehen in Googles Rangfolge über den Canonical-Tags. Die Dokumentation führt genau einen Fall aus: Eine HTTPS-Seite, die Nutzer zu oder über HTTP weiterleitet oder ein Canonical auf die HTTP-Version trägt, wird als widersprüchliches Signal gelistet, und Weiterleitungen von HTTPS auf HTTP führen dazu, dass Google HTTP sehr stark bevorzugt. Weitere Fälle eines Canonicals auf eine weiterleitende URL behandelt die Doku nicht, prüfen Sie das Ziel also selbst mit unserem Redirect-Checker und richten Sie das Tag auf die URL, die 200 antwortet.

Was passiert, wenn Sitemap und Canonical-Tag sich widersprechen?

Diesen Fall benennt Google in den Best Practices direkt: Geben Sie nicht eine URL in der Sitemap an und für dieselbe Seite eine andere per rel=canonical. Der Sitemap-Eintrag ist das schwächere der beiden Signale, das Tag setzt sich also meist durch. Trotzdem gilt jede eingereichte URL als Vorschlag für ein Canonical, und Google muss weiterhin entscheiden, welche Seiten die Duplikate sind. Die Lösung ist unspektakulär: Erzeugen Sie die Sitemap aus derselben Quelle, die auch die Canonical-Tags schreibt, und prüfen Sie die Datei mit unserem Sitemap-Validator. Was überhaupt hineingehört, klärt unser Leitfaden zu den Sitemap-Best-Practices.

Kann rel=canonical mit hreflang kollidieren?

Häufig, und mehrsprachige Websites trifft es am härtesten. Googles Vorgabe: Geben Sie eine kanonische Seite in derselben Sprache an, oder die bestmögliche Ersatzsprache, wenn es für diese Sprache keine gibt. Zeigt das Canonical Ihrer deutschen Seite auf die englische URL, haben Sie Google gebeten, die deutsche fallen zu lassen.

Zwei weitere Details von denselben Seiten. Eine rel=canonical-Annotation mit den Attributen hreflang, lang, media oder type wird für die Kanonisierung gar nicht verwendet, dafür ist rel=alternate da. Und die Cluster-Zugehörigkeit ist selbst ein Signal: Googles Beispiel sind eine de-de- und eine de-ch-Seite, die sich gegenseitig referenzieren und deshalb als Canonical bevorzugt werden, während die de-at-Seite außerhalb des Clusters bleibt. Die Annotationsfehler dahinter behandelt unser Hreflang-Leitfaden.

Braucht jede Seite ein selbstreferenzierendes Canonical?

Google empfiehlt es. In den Best Practices steht, dass die kanonische Seite selbst einen rel=canonical-Link auf sich tragen soll, ein sogenanntes selbstreferenzielles Canonical.

Richtig schiefgeht es bei Templates, die das Tag aus der aufgerufenen URL bauen. Kommt jemand mit einem Tracking-Parameter an, zeigt das Tag plötzlich auf die parametrisierte Variante, und jeder Anzeigenklick deklariert sein eigenes Canonical. Googles Beispiel für eine URL, die man lieber nicht in den Ergebnissen sähe, ist eine Produktseite mit gclid-Parameter. Zwei weitere Vorgaben von derselben Seite: absolute statt relative URLs verwenden, und niemals ein URL-Fragment als Canonical angeben, da Google Fragmente in der Regel nicht unterstützt.

Funktioniert ein Canonical-Tag außerhalb des head oder per JavaScript?

Außerhalb des head nicht. Google schreibt, dass das rel=canonical-Link-Element nur akzeptiert wird, wenn es im <head>-Bereich des HTML steht, und ergänzt, dass zumindest dieser head-Bereich valides HTML sein muss. Genau daran hängt es: Ein nicht geschlossenes Tag schiebt Ihr Canonical in den body, wo es nichts mehr zählt.

JavaScript wird unterstützt, aber nicht empfohlen. Die Seite zu den JavaScript-SEO-Grundlagen sagt, dass die Google-Suche ein per JavaScript eingefügtes Canonical beim Rendern aufnimmt. Die Seite zur Kanonisierung bittet Sie zugleich, die URL im HTML-Quelltext zu setzen und dafür zu sorgen, dass JavaScript sie nicht auf etwas anderes ändert. Geht das nicht, lassen Sie sie ganz aus dem Quelltext heraus und setzen sie ausschließlich per JavaScript. In jedem Fall gilt: genau eines ausliefern. Google warnt, dass widersprüchliche oder mehrfache rel=canonical-Tags zu unerwarteten Ergebnissen führen können.

Wie prüfen Sie, welches Canonical Google tatsächlich gewählt hat?

Die URL-Prüfung in der Search Console zeigt das von Google ausgewählte Canonical neben dem von Ihnen angegebenen. Googles Troubleshooting-Seite ergänzt etwas, das man vorher wissen sollte: Selbst nach der Korrektur der Inhalte kann Google Seiten bis zu zwei Wochen in einem Duplikat-Cluster halten, und sie lösen sich schneller heraus, wenn der Unterschied klar und deutlich ist. Nichts davon greift, wenn der Crawler die Seite gar nicht erreicht. Das sind fünf Minuten in Ihrer robots.txt.

Canonical-TagTechnisches SEO

Frequently asked questions

Folgt Google immer meinem Canonical-Tag?
Nein. Googles Dokumentation nennt eine kanonische Präferenz einen Hinweis und keine Regel. Google clustert die Seiten, die es als Duplikate liest, und markiert die vollständigste und nützlichste. Weiterleitungen, Sitemap-Einträge, HTTPS-Präferenz und hreflang-Cluster wiegen dabei mit.
Soll die kanonische Seite ein Canonical auf sich selbst setzen?
Ja. Googles Best Practices empfehlen einen rel=canonical-Link auf der kanonischen Seite selbst. Bauen Sie ihn aus einem gespeicherten Pfad statt aus der aufgerufenen URL, damit ein Tracking-Parameter das Tag nicht unbemerkt auf eine parametrisierte Kopie umschreibt.
Kann ich Duplicate Content über robots.txt regeln?
Nein. Google sagt klar, robots.txt nicht zur Kanonisierung zu nutzen, denn gesperrte URLs können trotzdem indexiert werden, dann ohne Inhalt. Bei einer gesperrten URL liest Google außerdem weder Canonical-Tag noch noindex, weil die Seite nie abgerufen wird.
Wo muss das Canonical-Tag stehen?
Im head. Google akzeptiert das rel=canonical-Link-Element nur, wenn es im head-Bereich des HTML steht, und verlangt, dass zumindest dieser Bereich valides HTML ist. Für Nicht-HTML-Dateien wie PDFs senden Sie das Canonical stattdessen als Link-HTTP-Header.
Wie lange dauert es, bis eine Canonical-Änderung wirkt?
Googles Troubleshooting-Hinweise nennen bis zu zwei Wochen, in denen Seiten auch nach behobenen Inhaltsproblemen in einem Duplikat-Cluster bleiben können. Je klarer der Unterschied, desto schneller lösen sie sich heraus. Prüfen Sie das Ergebnis mit der URL-Prüfung.

Jetzt prüfen

Weiterlesen