Es passiert immer wieder, dass Kunden an uns herantreten und Hilfe einfordern, weil sie gesehen haben, dass in der Google Search Console gemeldet wird, dass Google bestimmte Inhalte als Duplikat erkannt hat und diese “deindexiert” wurden.
Im jüngsten Fall ging es um eine .com-Domain, welche mit drei Foldern:
- /de/
- /ch/
- /at/
ausgestattet war und folglich für den DACH-Raum bestimmt ist. Hreflang war wie folgt implementiert:
<link rel="canonical" href="https：//www．beispiel．com/de/xyz">
<link rel="alternate" href="https：//www．beispiel．com/ch/xyz" hreflang="de-CH">
<link rel="alternate" href="https：//www．beispiel．com/de/xyz" hreflang="de-DE">
<link rel="alternate" href="https：//www．beispiel．com/at/xyz" hreflang="de-AT">
<link rel="alternate" href="https：//www．beispiel．com/de/xyz" hreflang="de">
<link rel="alternate"
href="https：//www．beispiel．com/de/" hreflang="x-default">
In unserem Fall würdes es reichen, wenn das Hreflang wie folgt aufgebaut ist:
<link rel="canonical" href="https：//www．wngmn．com/de/xyz">
<link rel="alternate" href="https：//www．wngmn．com/ch/xyz" hreflang="de-CH">
<link rel="alternate" href="https：//www．wngmn．de．com/at/xyz" hreflang="de-AT">
<link rel="alternate" href="https：//www．wngmn．com/de/xyz" hreflang="de">
Mit hreflang="de" haben wir eine Catch-all Variante, die alle deutschsprachigen User abholt, die nicht aus der Schweiz oder Österreich kommen. In dem Fall können wir auch auf hreflang="x-default verzichten.
“If you have several alternate URLs targeted at users with the same language but in different locales, it's a good idea to also provide a catchall URL for geographically unspecified users of that language. For example, if you have specific URLs for English speakers in Ireland (en-ie), Canada (en-ca), and Australia (en-au), provide a generic English (en) page for searchers in the US, UK, and all other English-speaking locations. It can be one of the specific pages, if you choose.”
Aufgefallen sind die URLs durch den Google Search Console Bericht “Duplikat – Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt”. Da alle drei Varianten inhaltlich exakt gleich sind, aber ein selbstreferenzierendes Canonical haben, tauchen in diesem Bericht natürlich häufig zwei von drei unserer URLs auf. Das hängt davon ab, welche Variante Google aufgrund der eingehenden Signale als Kanonisch ausgewählt hat. Für unseren Kunden war dies kritisch, da er Sorge hatte, dass seine URLs nicht indexiert sind. Diese Sorge ist auch absolut nachvollziehbar. Die URL Inspection sagt ja auch, die Seite ist nicht indexiert.
Hier ist es gar nicht so einfach zu erklären, dass wir genau dieses Szenario als SEOs bevorzugen, da Google alle URLs bekannt sind, aber die Signale auf eine, die kanonische Variante, vereint sind. Auch wenn diese URLs als “nicht-indexiert” im Bericht stehen, sind sie dem Index bekannt. Wir haben es als sekundäre URLs, die der Canonical-Gruppe zugeordnet sind, bezeichnet. Hreflang funktioniert und dass sie ranken, können wir aufgrund der Canonical-Consolidation in der GSC zwar nicht erkennen, aber leicht mit Sistrix visualisieren. Wir geben die unterschiedlichen URLs mit /de/, /at/ und /ch/ bei Sistrix ein und schalten die Länder durch. Nun sehen wir, dass die /de/ Rankings in DE rankt, die /at/ in AT und so weiter. Natürlich nur, wenn Hreflang funktioniert. Sollten wir auch Rankings der URLs auf anderen Märkten sehen, dann sollten wir auf Spurensuche gehen. In unserem Fall mussten wir das nicht.
Manchmal kam es dennoch vor, dass nur zwei URLs in einer Canonical-Gruppe waren, zum Beispiel /de/ und /at/, aber nicht /ch/. Das ist aus Performance-Sicht nicht perfekt, aber der User bekommt immer noch die richtigen URLs ausgespielt. Was meint, dass:
- Canonicals sind immer eine eins zu n-Beziehung: Google merkt sich einen Inhalt und viele URLs, die diesen Inhalt für Nutzer darstellen. Das von Google gewählte Canonical ist die bevorzugte URL dieses Inhalts.
- Hreflang ist immer eine eins zu eins Beziehung: Es sind immer zwei URLs, die sich gegenseitig für bestimmte Sprachen/Sprach-Land-Kombinationen referenzieren. Wenn Google eine URL ausspielen will, prüft es, ob es für Sprache (und Land) eine gültige Hreflang-Alternative gibt. Jede URL kann natürlich mehrere dieser eins zu eins Beziehungen für unterschiedliche Sprachen und Länder haben.
Sofern im Hreflang die /de/ und die /ch/ Variante jeweils miteinander verknüpft sind, wird dem User in CH vermutlich auch die /ch/-Variante ausgespielt, auch wenn ohne Hreflang die /de/-Variante ausgespielt werden würde, da sie die stärkeren Signale hat..
Würde das Hreflang nicht funktionieren, dann kann es passieren, dass die beiden Varianten in Konkurrenz stehen. Hier könnte es im schlimmsten Fall passieren, dass der User die "falsche" Variante ausgespielt bekommt. Es ist aber auch möglich, dass Google aufgrund von passender Länderzuordnung über Länder-Folder oder Top-Level-Domain trotzdem die korrekte Variante bevorzugt.
Kritisch wäre es, wenn das Hreflang nicht funktioniert und Google alle drei URLs in einer Canonical-Gruppe zusammenfasst. Dann wird tatsächlich nur noch eine Variante für alle Märkte ausgespielt und dies mit einer geringeren Performance, abgesehen vom Zielmarkt. Hier kommt es dann auf den Inhalt und die eingehenden Signale an. In so einem Fall sollte das Hreflang-Setup dringend korrigiert werden.
Lass Dich nicht verunsichern, wenn Deine URLs in diesem Bericht auftauchen. Wenn es Sprachversionen sind und Dein Hreflang funktioniert, ist alles fein. Das bescheinigt uns auch Martin Splitt noch mal in diesem Abschnitt seines Videos “How to Avoid Duplicate Content”. Viele andere Gründe, warum Google sich für ein anderes Canonical entscheidet, sind auch legitim, oder ein Hinweis auf Verbesserungspotenzial in der internen Verlinkung oder der inhaltlichen Differenzierung Deiner Inhalte. Wenn die Inhalte nicht zusammengehören, und das von Google gewählte Canonical wirklich nicht zu der URL passt, kann dieser Bericht auch ein wichtiger Hinweis auf Rendering- oder Crawling-Probleme sein.