Ein rel=canonical im head einer Seite benennt die bevorzugte URL einer Gruppe gleichartiger Adressen. Er muss absolut sein, auf eine indexierbare 200er-Seite zeigen und sich auf Standardseiten selbst referenzieren. Google wertet ihn als Hinweis, nicht als Befehl — die tatsächlich gewählte URL steht in der Search Console unter der von Google ausgewählten kanonischen URL.
Was macht das Canonical-Tag technisch genau?
Findet eine Suchmaschine mehrere URLs mit sehr ähnlichem Inhalt, bildet sie daraus eine Gruppe und bestimmt einen Repräsentanten. Dieser Repräsentant wird indexiert und in den Ergebnissen angezeigt; die übrigen Adressen der Gruppe geben ihre Signale an ihn ab. Das Canonical-Tag ist Ihr Vorschlag dafür, welche URL das sein soll.
Der Verweis gehört in den head-Bereich des HTML-Dokuments oder in den HTTP-Header. Im Body wird er ignoriert. Pro Seite darf es genau einen geben — zwei widersprüchliche Angaben führen dazu, dass beide verworfen werden und die Suchmaschine allein entscheidet.
Anders als eine Weiterleitung verändert der Verweis nichts an der Auslieferung. Die Adresse mit dem Canonical bleibt vollständig erreichbar, liefert weiterhin Status 200 und zeigt ihren Inhalt. Nur im Index tritt sie hinter die benannte Version zurück.
Neben dem Tag fließen weitere Signale in die Auswahl ein: interne Verlinkung, die URLs in der XML-Sitemap, Weiterleitungen, hreflang-Verweise und die Frage, welche Variante als sauberer erscheint. Widersprechen sich diese Signale, gewinnt selten das Canonical-Tag.
Wie sieht eine korrekte Implementierung aus?
Die Grundregel: Jede indexierbare Seite bekommt ein selbstreferenzierendes Canonical, das auf ihre eigene, bevorzugte URL zeigt. Das klingt überflüssig, verhindert aber, dass Varianten mit angehängten Parametern als eigenständige Seiten behandelt werden.
- Absolute URL inklusive Protokoll und Host, niemals ein relativer Pfad.
- Genau die Schreibweise, die Sie auch intern verlinken und in die Sitemap schreiben.
- Ziel liefert Status 200, ist nicht per robots.txt gesperrt und trägt kein noindex.
- Genau ein Canonical-Element pro Seite, ausgeliefert im HTML-head oder als HTTP-Header.
- Bei nicht-HTML-Dateien wie PDFs ausschließlich über den HTTP-Header Link mit rel=canonical.
Achten Sie besonders auf die Schreibweise am Ende der Adresse. Wenn Ihre Seiten mit abschließendem Schrägstrich ausgeliefert werden, muss auch der Canonical ihn tragen. Eine Abweichung an dieser Stelle erzeugt einen Verweis auf eine URL, die per Weiterleitung antwortet — ein stiller Fehler, der sich über ganze Vorlagen zieht.
Bei serverseitig gerenderten Seiten steht der Verweis fest im Quelltext. Bei Single-Page-Anwendungen muss er beim Rendern der jeweiligen Route erzeugt werden — ein Canonical, das erst nach dem Laden per JavaScript eingefügt oder verändert wird, kommt möglicherweise zu spät oder gar nicht an.
Canonical, 301, noindex oder robots.txt — welches Signal wann?
Die vier Werkzeuge lösen unterschiedliche Aufgaben und lassen sich nicht gegeneinander austauschen. Wer das verwechselt, produziert entweder Sichtbarkeitsverluste oder wundert sich, warum eine Seite hartnäckig im Index bleibt.
- Canonical: Der Inhalt existiert unter mehreren Adressen und alle sollen erreichbar bleiben.
- 301-Weiterleitung: Der Inhalt ist dauerhaft umgezogen und die alte Adresse soll verschwinden.
- noindex: Die Seite soll erreichbar bleiben, aber nicht in den Ergebnissen erscheinen.
- robots.txt: Der Abruf selbst soll unterbleiben — meist wegen Serverlast, nicht wegen des Index.
Ein verbreiteter Fehlgriff ist die Kombination aus robots.txt-Sperre und noindex. Was nicht abgerufen werden darf, kann auch nicht gelesen werden — das noindex bleibt unbemerkt, und die URL erscheint im schlimmsten Fall ohne Beschreibung trotzdem in den Ergebnissen.
Auch die Kombination aus Canonical und noindex auf derselben Seite ist widersprüchlich. Das eine sagt, diese Seite gehöre zu einer Gruppe und ihre Signale sollten weitergereicht werden; das andere sagt, sie solle verschwinden. Google verarbeitet solche Paare unvorhersehbar — entscheiden Sie sich für eine der beiden Aussagen.
Ebenso unpassend ist ein Canonical dort, wo eine 301 hingehört. Wenn eine Seite endgültig ersetzt wurde, führt der Canonical-Hinweis nur dazu, dass beide Adressen bestehen bleiben und Nutzer weiterhin auf der veralteten landen.
Welche Canonical-Fehler treten am häufigsten auf?
Aus unseren technischen Audits lässt sich eine recht stabile Rangliste ableiten. Fast alle Fälle entstehen nicht aus Unwissen, sondern aus Templates, die einmal falsch konfiguriert wurden und dann tausendfach ausgeliefert werden.
Canonical auf die Startseite
Ein Immobilienportal hatte in einem Template den Canonical-Verweis hart auf die Domain-Wurzel gesetzt. Die Folge: Rund 900 Objektseiten meldeten die Startseite als bevorzugte Version, und keine einzige Objektseite war auffindbar. Solche Fälle finden Sie, indem Sie im Crawl die Zahl der Seiten mit identischem Canonical-Ziel prüfen.
Ketten und Widersprüche
Zeigt Seite A auf B und B auf C, entsteht eine Kette. Suchmaschinen folgen ihr manchmal, oft aber nicht. Ähnlich problematisch: Eine URL steht in der Sitemap, verweist aber per Canonical auf eine andere — dann widersprechen sich Ihre eigenen Signale, und die Sitemap verliert an Glaubwürdigkeit.
- Canonical zeigt auf eine URL, die selbst per 301 weiterleitet.
- Canonical zeigt auf eine Seite mit noindex oder auf eine 404.
- Canonical widerspricht dem hreflang-Cluster: Die Sprachvariante verweist auf die Hauptsprache statt auf sich selbst.
- Canonical zeigt über Domaingrenzen hinweg, obwohl der Inhalt auf beiden Domains eigenständig ranken soll.
- Canonical wird erst per JavaScript nachträglich eingefügt oder überschrieben.
Der hreflang-Konflikt verdient besondere Aufmerksamkeit. Jede Sprachvariante muss sich selbst als kanonisch ausweisen. Verweist die österreichische Fassung per Canonical auf die deutsche, wird das gesamte hreflang-Bündel unwirksam, weil die verwiesene Seite gar nicht mehr als eigenständig gilt.
Wie behandle ich Parameter- und Tracking-URLs?
Kampagnen-Parameter, Sitzungskennungen und Affiliate-Kennungen erzeugen beliebig viele Varianten derselben Seite. Da sie in Newslettern, Anzeigen und auf fremden Seiten verlinkt werden, findet die Suchmaschine sie zuverlässig.
Das selbstreferenzierende Canonical auf der Basis-URL löst diesen Fall vollständig: Jede Parameter-Variante liefert dieselbe Seite aus, und diese benennt konsequent die parameterlose Adresse als bevorzugt. Wichtig ist, dass der Verweis serverseitig aus dem Pfad erzeugt wird und nicht die aufgerufene URL samt Parametern zurückspiegelt.
Bei Filtern liegt der Fall anders. Eine Filterkombination, nach der tatsächlich gesucht wird und die ein sinnvolles Ergebnis liefert, kann eine eigenständige Seite verdienen. Kombinationen aus vier Filtern mit drei Treffern dagegen nicht — diese gehören per Canonical gebündelt oder gar nicht erst verlinkt.
Ergänzend hilft die interne Verlinkung. Verlinken Sie ausschließlich die Basis-URLs, auch wenn Ihre Analyse-Werkzeuge Parameter anhängen möchten. Jeder interne Link auf eine Variante ist ein Signal, das Ihrem eigenen Canonical widerspricht.
Ein SaaS-Anbieter reduzierte auf diesem Weg rund 12.000 indexierbare Filtervarianten auf 40 kuratierte Übersichtsseiten. Die Zahl der täglich abgerufenen URLs sank deutlich, die verbliebenen Seiten wurden häufiger und schneller neu gecrawlt.
Wie prüfe ich, welche URL Google tatsächlich gewählt hat?
Die Search Console beantwortet das direkt. Geben Sie eine URL in die URL-Prüfung ein: Unter Indexierung erscheinen zwei Zeilen — die vom Nutzer angegebene kanonische URL, also Ihr Tag, und die von Google ausgewählte kanonische URL. Weichen beide voneinander ab, wurde Ihr Hinweis überstimmt.
Im Bericht zur Seitenindexierung finden Sie dieselbe Information in aggregierter Form. Die Kategorie Duplikat — Google hat eine andere Seite als kanonisch bestimmt sammelt genau die Fälle, in denen Ihre Angabe nicht übernommen wurde.
Das Canonical-Tag ist ein Vorschlag an die Suchmaschine, kein Schalter in ihrem Index.
Ergänzend lohnt ein Crawl mit aktivierter JavaScript-Ausführung im Vergleich zum reinen HTML-Abruf. Unterscheiden sich die gefundenen Canonical-Angaben zwischen beiden Durchläufen, wird der Verweis clientseitig manipuliert — ein Zustand, den Sie beheben sollten.
Was tun, wenn Google den Hinweis ignoriert?
Wird Ihr Canonical überstimmt, liegt das fast nie am Tag selbst, sondern an widersprüchlichen Signalen drumherum. Google folgt der Gesamtevidenz, und die entsteht aus internen Links, Sitemap-Einträgen, Weiterleitungen und der tatsächlichen Inhaltsähnlichkeit.
- Prüfen Sie, ob Ihre internen Links auf die kanonische Variante zeigen oder auf eine andere.
- Prüfen Sie, ob ausschließlich die kanonischen URLs in der XML-Sitemap stehen.
- Prüfen Sie, ob die Zielseite wirklich der reichhaltigere Inhalt ist — sonst wirkt der Hinweis unplausibel.
- Prüfen Sie, ob eine der Varianten über externe Links deutlich stärker adressiert wird.
Ein zusätzlicher Prüfpunkt sind die Weiterleitungen. Zeigt der Canonical auf eine Adresse, die ihrerseits per 301 antwortet, betrachtet Google die Angabe als unsauber und wählt häufig das Weiterleitungsziel oder die Ausgangsseite. Ein Canonical sollte immer auf die Endstation zeigen, nie auf eine Zwischenstufe.
Bleibt der Widerspruch bestehen, obwohl alle Signale stimmen, sind die Seiten für Google möglicherweise nicht ähnlich genug, um überhaupt eine Gruppe zu bilden. Dann ist die richtige Antwort keine technische Korrektur, sondern eine inhaltliche Entscheidung: zusammenlegen oder klarer abgrenzen.