Canonical gesetzt, aber Google wählt eine andere Seite: 10 Ursachen

Du hast den Quelltext der Seite geöffnet, <link rel="canonical"> gefunden, und dein SEO-Plugin zeigt einen grünen Haken. In der Search Console steht unter den nicht indexierten Seiten aber die Zeile „Duplikat: Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt“ (Duplicate, Google chose different canonical than user). Du hast also die Hauptadresse benannt, und Google hat hingeschaut, nachgedacht und eine andere genommen.

Die erste Reaktion: „Google spinnt.“ Die zweite: „Ich brauche noch ein Plugin.“ Beides hilft nicht. Google schreibt klar, dass ein Canonical für die Suchmaschine „ein Hinweis, keine Regel“ ist (Google Search Central). Google gewichtet ihn zusammen mit den übrigen Signalen deiner Website, und wenn diese Signale sich widersprechen, entscheidet Google selbst.

Und eine Website sendet viele Signale: Sprachversionen, Katalogfilter, UTM-Parameter, Vorlagenseiten, JavaScript. Jedes davon kann Google leise etwas anderes sagen als dein Tag. Unten findest du zehn solche Ursachen und die Reihenfolge der Prüfung. Das durchgehende Beispiel ist erfunden: ein Onlineshop für Fahrräder und Ersatzteile mit Filtern und zwei Sprachversionen.

Wenn dieselbe Seite unter mehreren Adressen erreichbar ist, gruppiert Google sie und wählt eine aus, die in der Suche erscheint. Diese Adresse heißt kanonisch, der Vorgang selbst Kanonisierung. Die übrigen Adressen der Gruppe gelten als Duplikate: Google crawlt sie seltener und zeigt sie in den Ergebnissen meist nicht an (Google Search Central).

Die Kategorie Mountainbikes lebt schnell unter fünf Adressen:

https://bike-shop.example/ua/mtb/
https://bike-shop.example/ua/mtb
http://bike-shop.example/ua/mtb/
https://bike-shop.example/ua/mtb/?utm_source=facebook
https://bike-shop.example/ua/mtb/?orderby=price

Für Menschen ist das eine Seite, für die Suchmaschine sind es fünf URLs. Um die Hauptadresse anzugeben, setzt man im <head> diesen Tag:

<link rel="canonical" href="https://bike-shop.example/ua/mtb/" />

Wichtige Details aus der Google-Dokumentation: Der Tag zählt nur im <head>, die Adresse darin muss absolut sein (mit https:// und Domain), und für PDFs und andere Nicht-HTML-Dateien lässt sich der Canonical als HTTP-Header übergeben (Google Search Central).

Nun zur Stärke der Signale. Google ordnet die Wege, eine kanonische Adresse anzugeben, selbst ein:

Die Signale verstärken sich gegenseitig. Wenn aber die Weiterleitung an einen Ort führt, der Tag an einen anderen und die Sitemap einen dritten nennt, löst Google den Streit selbst. Außerdem bevorzugt Google die HTTPS-Version gegenüber HTTP sowie Adressen, die zu gegenseitigen hreflang-Clustern gehören (Google Search Central).

Daher kommt die Verwirrung: Das Plugin prüft, ob der Tag existiert. Google prüft, ob die ganze Website dasselbe sagt.

1. Für Google sind die Seiten nicht ähnlich genug

Ein Canonical ergibt nur zwischen echten Duplikaten Sinn: Seiten mit gleichem oder sehr ähnlichem Hauptinhalt. Unterscheidet sich der Inhalt spürbar, kann Google zu dem Schluss kommen, dass es zwei eigenständige Seiten vor sich hat, und den Tag ignorieren.

Im Fahrradshop sieht die typische Situation so aus: Die Kategorie „Mountainbikes“ hat 120 Modelle, die Seite mit dem Filter „Marke Trek“ zeigt 14. Kopfbereich, Menü und Design sind gleich, also wirkt es für den Inhaber wie eine Variante derselben Seite. Aber Produktliste, Namen, Preise und Links sind andere. Für Google ist das bereits ein anderes Dokument, und ein Canonical von „Trek“ auf die allgemeine Kategorie sieht wie ein Fehler aus.

Was du tun kannst: Wenn Menschen wirklich nach „Trek Mountainbikes“ suchen, gib der Seite einen eigenen Canonical, eine eigene Überschrift und einen eigenen Text. Wenn nicht, sperre solche Adressen für das Crawling (Ursache 4), statt sie per Tag „zusammenzukleben“.

2. Interne Links sagen das eine, der Tag das andere

Ein Canonical funktioniert nicht losgelöst vom Rest der Website. Wenn der Tag auf /ua/mtb/ zeigt, das Hauptmenü aber auf /ua/mtb/?orderby=popular verlinkt, die Breadcrumbs auf /ua/mtb und die Sitemap die http://-Version enthält, sieht Google vier verschiedene Meinungen über eine Seite.

Am häufigsten passiert das nach einem Redesign, einer geänderten URL-Struktur oder einem Wechsel des SEO-Plugins: Der Tag wurde aktualisiert, die Links in Menü, Bannern und alten Artikeln sind aber geblieben, wie sie waren.

Was du tun kannst: Lass einen Crawler über die Website laufen (Screaming Frog, Sitebulb oder ähnliche Tools) und schau, auf welche Adressen die internen Links führen. Die Regel ist einfach: Alle Links innerhalb der Website führen auf die kanonische Adresse, ohne Parameter, mit demselben Schrägstrich am Ende und demselben Protokoll. Ist die Website vor Kurzem umgezogen, lohnt es sich außerdem, die Weiterleitungen von den alten auf die neuen Adressen abzugleichen.

3. Canonical streitet mit hreflang

Das ist auf mehrsprachigen Websites eine eigene große Fehlerkategorie. Ein typisches Szenario: Die ukrainische Seite hat einen Canonical auf die englische, weil „Englisch die Hauptversion ist“. Oder alle Sprachversionen setzen den Canonical auf die Standardversion.

Das Problem: Verschiedene Sprachen sind für Google keine Duplikate. Sprachversionen gelten nur dann als Duplikate, wenn der Hauptinhalt in derselben Sprache bleibt und nur Menü und Footer übersetzt sind (Google Search Central). Wenn hreflang sagt „das sind eigene Versionen für verschiedene Sprachen“ und der Canonical sagt „nein, die Hauptseite ist diese hier“, widersprechen sich die Signale, und ein Teil davon wird ignoriert.

Richtig ist dieses Schema:

• Jede Sprachversion hat einen Canonical auf sich selbst;
• hreflang listet in jeder Version alle Sprachversionen auf, einschließlich der Version selbst;
• die Verweise sind gegenseitig: Wenn Seite A auf B verweist, muss B auf A verweisen, sonst ignoriert Google diese Tags (Google Search Central).

So ist es auf unserer eigenen Website grandma.agency umgesetzt. Sie hat drei Sprachen: Ukrainisch mit dem Präfix /ua/, Englisch ohne Präfix (zugleich x-default) und Deutsch mit /de/. Das liefert die ukrainische Fassung eines unserer Artikel aus:

<link rel="canonical" href="https://grandma.agency/ua/blog/yak-pryskoryty-sajt-na-wordpress/">
<link rel="alternate" hreflang="en" href="https://grandma.agency/blog/how-to-speed-up-wordpress-site/">
<link rel="alternate" hreflang="uk" href="https://grandma.agency/ua/blog/yak-pryskoryty-sajt-na-wordpress/">
<link rel="alternate" hreflang="de" href="https://grandma.agency/de/blog/wordpress-website-schneller-machen/">
<link rel="alternate" hreflang="x-default" href="https://grandma.agency/blog/how-to-speed-up-wordpress-site/">

Der Canonical der ukrainischen Seite zeigt auf die ukrainische Seite, nicht auf die englische, obwohl die englische x-default ist. Du kannst das selbst prüfen: curl -s <Adresse> | grep -E 'canonical|hreflang'. Warum auch hreflang oft nicht greift, steht in unserem Schwesterartikel über hreflang.

4. Filter und URL-Parameter vervielfachen Adressen schneller, als du zählen kannst

Fünf Filter mit je zehn Werten, drei Sortieroptionen und Paginierung ergeben für einen Shop Tausende URL-Kombinationen. Zum Beispiel:

/ua/mtb/?brand=trek
/ua/mtb/?brand=trek&wheel=29
/ua/mtb/?wheel=29&brand=trek
/ua/mtb/?brand=trek&wheel=29&orderby=price&page=3

Die beiden mittleren Adressen zeigen dieselben Produkte, für den Crawler sind es aber verschiedene URLs. Früher ließ sich ein Teil davon in der Search Console mit dem Tool „URL-Parameter“ steuern, aber Google hat es schon 2022 abgeschaltet (Google Search Central Blog).

Was Google heute für die facettierte Navigation empfiehlt (Google Search Central):

• wenn Filteradressen in der Suche nicht gebraucht werden, ist es am zuverlässigsten, sie in der robots.txt für das Crawling zu sperren;
• ein Canonical vom Filter auf die allgemeine Kategorie kann das Crawling solcher Adressen mit der Zeit verringern, ist langfristig aber weniger wirksam als eine Sperre;
• die Reihenfolge der Filter in der URL einheitlich halten und doppelte Parameter vermeiden;
• für Kombinationen ganz ohne Produkte einen 404 zurückgeben, keine Weiterleitung auf die allgemeine Seite.

Extra zur Paginierung, denn hier ist der Fehler ein Klassiker: Die Katalogseiten 2, 3, 4 bekommen einen Canonical auf die erste Seite. Google bittet ausdrücklich, das nicht zu tun: Jede paginierte Seite hat einen eigenen Canonical, weil darauf andere Produkte stehen. Und die Tags rel="next" und rel="prev" nutzt Google nicht mehr (Google Search Central).

5. Die Seiten sind keine Kopien, aber sehr ähnlich

Das sind „weiche“ Duplikate: Seiten nach einer Vorlage, bei denen sich ein oder zwei Wörter ändern. „Fahrradlieferung nach Lwiw“, „Fahrradlieferung nach Dnipro“, „Fahrradlieferung nach Odesa“ mit identischem Text, in dem nur der Städtename ausgetauscht ist. Oder Seiten „Produkt + Farbe“, die sich in einer Zeile der technischen Daten unterscheiden.

Im Hauptinhalt sind sie fast gleich, also fasst Google sie zu einem Cluster zusammen und wählt selbst, welche es zeigt. Ein Canonical entscheidet hier nichts.

Google schreibt, dass Seiten schneller aus einem Cluster „herausgelöst“ werden, wenn der Unterschied zwischen ihnen klar und wesentlich ist, und dass die Neubewertung bis zu zwei Wochen dauern kann (Google Search Central). Für eine Stadtseite heißt das: echte Daten genau dieser Stadt, also Lieferzeiten, Adressen der Abholstellen, lokale Bedingungen. Gibt es diesen Unterschied nicht, ist es ehrlicher, bei einer Seite zu bleiben.

6. Der Canonical zeigt auf eine Seite, die selbst kaputt ist

Banal, aber sehr verbreitet. Der Tag zeigt auf eine Adresse, die:

• selbst weiterleitet;
• 404 oder 410 zurückgibt;
• per noindex gesperrt ist;
• in der robots.txt gesperrt ist;
• auf http:// liegt, obwohl die Website längst auf https:// läuft.

Für Google ist das ein Widerspruch: Du bittest darum, eine Seite als Hauptseite zu behandeln, die du selbst nicht in die Suche lässt oder die es nicht mehr gibt. In so einer Lage sucht Google einen anderen Kandidaten.

Extra zu noindex: Google rät davon ab, damit innerhalb einer Website die kanonische Seite festzulegen, denn noindex entfernt die Seite komplett aus der Suche. Ebenso wenig solltest du Duplikate in der robots.txt sperren in der Hoffnung, dass Google das Gewicht auf die Hauptseite überträgt: Eine gesperrte Adresse crawlt Google nicht, sieht darauf also weder Canonical noch Inhalt, kann die URL ohne Inhalt aber trotzdem indexieren (Google Search Central).

Solche „kaputten“ Canonicals sammeln sich nach Umzügen und gelöschten Produkten an: Die Modellseite wurde entfernt, aber die Farbvarianten zeigen immer noch darauf.

7. Die XML-Sitemap widerspricht dem Tag

Google sagt es direkt: Gib für eine Seite nicht auf verschiedenen Wegen verschiedene kanonische Adressen an, etwa eine in der Sitemap und eine andere in rel="canonical" (Google Search Central). Alle Adressen in der Sitemap versteht Google als Vorschläge für kanonische Seiten.

Wenn ein automatischer Generator Filter, Sortierungen, alte http://-URLs oder Seiten mit einem Canonical auf eine andere Adresse in die Sitemap gelegt hat, schlägst du Google selbst die falsche Variante vor.

Was du in der Sitemap prüfen solltest:

1. Jede Adresse liefert den Code 200, ohne Weiterleitungen.
2. Jede Adresse hat einen Canonical auf sich selbst.
3. Keine Parameter, UTM, Sortierungen, interne Suche.
4. Keine Seiten mit noindex.
5. Protokoll, Domain und Schrägstrich am Ende stimmen mit dem Canonical überein.

8. Der Canonical erscheint erst nach JavaScript

Auf Websites mit React oder Vue, in SPAs und Headless-Lösungen fügt oft erst JavaScript im Browser den Canonical-Tag ein oder ändert ihn. Google kann einen per JavaScript eingefügten Canonical beim Rendern erfassen, schreibt aber ausdrücklich, dass es diesen Weg nicht empfiehlt. Wenn es nicht anders geht, muss der Tag der einzige auf der Seite sein: Mehrere oder widersprüchliche Canonicals können zu unvorhersehbaren Ergebnissen führen. Und wenn der Canonical schon im HTML steht, sollte JavaScript ihn nicht ändern (Google Search Central).

Die typische Falle: Die Vorlage liefert HTML mit einem Canonical auf die Startseite, und ein Skript ersetzt ihn danach durch die richtige Adresse.

So prüfst du es: Vergleiche das ausgelieferte HTML (curl -s <Adresse> | grep canonical oder „Seitenquelltext anzeigen“ im Browser) mit dem, was Google nach dem Rendern sieht. Letzteres findest du in der Search Console im Tool zur URL-Prüfung über „Live-URL testen“ (Test live URL) und „Getestete Seite anzeigen“ (View tested page). Wenn es zwei Tags gibt oder sie sich unterscheiden, hast du das Problem gefunden.

9. Massenhaft generierte Seiten erzeugen Duplikat-Cluster

Hunderte Seiten „Leistung + Stadt“ oder „Produkt + Marke“ mit Texten aus einem KI-Modell sind formal einzigartig, Struktur und Fakten sind aber gleich. Das ist Ursache 5 im industriellen Maßstab: Google fasst sie zu Clustern zusammen, wählt selbst, welche es zeigt, und indexiert einen Teil gar nicht. Die Google-Richtlinien zu Spam beschreiben eigens das massenhafte Erstellen von Seiten, um Rankings zu manipulieren, ohne Nutzen für Menschen, und stellen klar, dass es egal ist, wie die Seiten entstehen, ob durch Menschen oder durch Automatisierung (Google Search Central).

Das Problem ist also nicht der KI-Text, sondern dass die Seiten nichts haben, worin sie sich unterscheiden. Vor der zweihundertsten Seite lohnt sich die Frage: Was steht auf dieser Seite, das auf den vorherigen fehlt?

10. Google hält einfach eine andere Seite für besser

Manchmal ist technisch alles sauber, und Google wählt trotzdem eine andere Adresse. Die Dokumentation gibt das offen zu: Selbst wenn du eine kanonische Seite ausdrücklich angibst, kann Google eine andere wählen, und Google empfiehlt zu prüfen, ob diese für Menschen vielleicht besser passt (Google Search Central).

Was den Tag laut Google-Dokumentation überstimmen kann:

• HTTPS. Google bevorzugt die HTTPS-Version, wenn es damit keine Probleme gibt. Ein ungültiges Zertifikat oder Weiterleitungen von HTTPS auf HTTP bringen Google aber dazu, sehr stark zu HTTP zu tendieren.
• hreflang-Cluster. Adressen, die zu gegenseitigen hreflang-Clustern gehören, bevorzugt Google.
• Fremde Kopien. Wenn dein Text auf einer anderen Website steht (Partner, Aggregator, Copy-and-paste), kann Google die fremde Adresse als kanonisch wählen. Bei Partnern rät Google, sich nicht auf den Canonical zu verlassen, sondern sie zu bitten, die Kopie von der Indexierung auszuschließen; für nicht genehmigte Kopien gibt es die DMCA-Beschwerde.
• Serverkonfiguration oder Hack. Manche Hosting-Fehler oder von Angreifern eingeschleuste Weiterleitungen und Canonicals führen dazu, dass eine Adresse auf einer anderen Domain kanonisch wird.

Alles Nötige findest du kostenlos in der Google Search Console.

Schritt 1. Bericht für die ganze Website. Öffne im linken Menü „Indexierung“ → „Seiten“ (Indexing → Pages). Unter dem Diagramm steht eine Tabelle mit den Gründen, warum Seiten nicht indexiert werden. Drei davon betreffen den Canonical:

Die Status sind in der Search Console-Hilfe zum Bericht „Seitenindexierung“ beschrieben. Die deutschen Bezeichnungen in der Oberfläche können im Wortlaut leicht abweichen, orientiere dich deshalb am Sinn oder stell die Sprache der Oberfläche auf Englisch um.

Schritt 2. Eine einzelne Adresse. Füge die URL in die Suchleiste oben in der Search Console ein, das ist das Tool zur URL-Prüfung (URL Inspection). Im Abschnitt zur Indexierung der Seite gibt es zwei Felder:

• „Vom Nutzer angegebene kanonische URL“ (User-declared canonical): das, was du angegeben hast;
• „Von Google ausgewählte kanonische URL“ (Google-selected canonical): das, was Google gewählt hat.

Stimmen sie nicht überein, hat Google deinen Canonical nicht übernommen. Zwei Details aus der Hilfe: Der von Google gewählte Wert kann dem Index um einige Stunden hinterherhinken, und der Live-Test („Live-URL testen“) zeigt nur den von dir angegebenen Canonical. Googles Wahl fällt bei der Indexierung, und der Test kann nicht vorhersagen, ob die geprüfte Version kanonisch wird.

Schritt 3. Nach der Korrektur. Klicke für die wichtigsten Seiten auf „Indexierung beantragen“ (Request indexing). Für diese Schaltfläche gibt es Kontingente, drück sie also nicht für Hunderte Adressen, und denk daran, dass sie keine Aufnahme in den Index garantiert. Google kann Seiten bis zu zwei Wochen in einem Duplikat-Cluster halten, prüf das Ergebnis also nicht am nächsten Morgen.

Was du gleich mit abgleichen solltest: Sitemap, interne Links, hreflang, robots.txt, Weiterleitungen, Parameter. Was du davon realistisch selbst prüfen kannst, haben wir im Artikel „SEO-Audit: was du selbst prüfen kannst und was du beauftragen solltest“ aufgeschrieben.

Probleme mit dem Canonical bleiben lange unbemerkt: Anfragen kommen weiter, und in der Suche steht derweil eine Filterseite statt der Kategorie. Deshalb lohnt es sich, den Bericht regelmäßig zu öffnen, nicht erst, wenn der Traffic schon eingebrochen ist.

Der Canonical ist längst kein Schalter „mach diese Seite zur Hauptseite“ mehr. Er ist einer der Hinweise, die Google zusammen mit Weiterleitungen, internen Links, Sitemap, hreflang, Protokoll und dem Inhalt der Seiten selbst gewichtet. Wenn alle dasselbe sagen, stimmt Google fast immer zu. Wenn sie streiten, entscheidet Google selbst.

Statt gegen den Tag zu kämpfen, such also, wer ihm widerspricht: ein Menü mit Parametern, eine Sitemap mit alten Adressen, eine Sprachversion mit Canonical auf eine andere Sprache, Seiten, die sich durch nichts unterscheiden. Das ist keine Arbeit an einer Zeile im <head>, sondern technische Ordnung auf der ganzen Website, und sie gehört zu unserer Suchmaschinenoptimierung. Wird die Website gerade erst gebaut, ist es günstiger, solche Dinge gleich bei der Entwicklung richtig anzulegen.

Wenn die Search Console Duplikate zeigt und unklar ist, woher sie kommen, schreib uns. Wir schauen, welche Signale mit deinem Canonical streiten, und sagen dir, was sich in den Einstellungen beheben lässt und wofür es einen Entwickler braucht.