hreflang richtig einsetzen: die vier Fehler, die still passieren

Seit dem 22. September 2022 ist der International-Targeting-Report abgeschaltet. Das war lange die zentrale Stelle für hreflang-Hinweise in der Search Console. Seitdem gibt es diese Rückmeldung nicht mehr. Die Auszeichnung selbst funktioniert weiter, die Fehlermeldung dazu nicht.

Das verändert die Aufgabe grundlegend. Früher konntest du einbauen und abwarten, ob sich ein Fehler meldet. Heute meldet sich nichts. Weder wenn es klappt noch wenn es nicht klappt.

Genau das macht hreflang zu einer besonderen Sorte technischer SEO. Ein kaputter Canonical fällt irgendwann in den Rankings auf und eine kaputte robots.txt zeigt sich früher oder später an der Indexierung, aber eine kaputte hreflang-Annotation hat kein eigenes Warnsignal. Die Seiten ranken weiter, wodurch Nutzer unter Umständen die falsche Sprachversion sehen.

Ich betreibe seo-kreativ.de zweisprachig und jeder Beitrag existiert sowohl auf Deutsch als auch auf Englisch. Für diesen Artikel habe ich meine eigene Auszeichnung mit curl geprüft statt sie vorauszusetzen. Ergebnis: drei von vier Prüfpunkten sauber und einer fehlt komplett. Die Befehle zum Nachmachen stehen weiter unten.

Dieser Text hält den Teil kurz, den du in jedem anderen Guide findest. Die Syntax steht kompakt in einem einzigen Abschnitt und der ganze Rest des Artikels handelt von einer einzigen Frage: Bewirkt sie überhaupt etwas?

Der Denkfehler, der mir am häufigsten begegnet: die Erwartung, damit Rankings zu gewinnen. Das leistet die Auszeichnung nicht. Sie beantwortet eine engere Frage: Wenn mehrere deiner Seiten denselben Inhalt in verschiedenen Sprachen tragen, welche davon zeigt Google einem bestimmten Nutzer?

Google beschreibt den Zweck in der offiziellen Dokumentation so: „Mithilfe von hreflang kannst du Google über Inhaltsvarianten informieren“. Informieren. Nicht anweisen. Diese Wortwahl zieht sich durch die gesamte Spezifikation und sie hat handfeste Konsequenzen für das Ergebnis, das du erwarten darfst.

John Mueller hat das im Mai 2025 an einem konkreten Fall deutlich gemacht. Ein SEO hatte belgisch-französische Seiten in französischen Suchergebnissen beobachtet und die Auszeichnung sah etwas ganz anderes vor. Search Engine Journal dokumentierte Muellers Antwort aus einem Bluesky-Post vom 12. Mai 2025: „hreflang doesn’t guarantee indexing, so it can also just be that not all variations are indexed.“ Was nicht im Index steht kann auch nicht ausgespielt werden. Wie Crawling und Indexierung bei Google zusammenhängen, habe ich in einem eigenen Beitrag aufgeschrieben.

Für sprachgleiche Varianten wird Mueller noch deutlicher: „if they are the same (eg fr-fr, fr-be), it’s common that one is chosen as canonical“. Zwei Seiten mit identischem französischem Text sind für Googles Systeme eben zwei Kopien und die hreflang-Auszeichnung ändert daran nichts. Das ist kein Bug. Das ist Konsolidierung.

Praktisch heißt das: hreflang repariert keinen schwachen Inhalt. Es sorgt dafür, dass der vorhandene Inhalt beim richtigen Publikum landet. Wer eine Seite hat, die auf Deutsch auf Position 30 steht, bekommt durch eine englische Fassung mit noch so sauberer Auszeichnung keine einzige Position mehr in den deutschen Ergebnissen.

Das Element ist ein link-Tag mit rel="alternate". Für eine deutsche und eine englische Fassung sieht das so aus:

<link rel="alternate" href="https://example.com/seite/" hreflang="de" />
<link rel="alternate" href="https://example.com/en/page/" hreflang="en" />
<link rel="alternate" href="https://example.com/en/page/" hreflang="x-default" />

Der Codeaufbau ist in der Google-Dokumentation exakt festgelegt: „Der erste Code des hreflang-Attributs ist der Sprachcode (im Format ISO 639-1), gefolgt von einem optionalen zweiten Code als Regionscode (im Format ISO 3166-1 Alpha 2).“ Der Regionscode ist optional. Der Sprachcode ist es nicht.

Die Reihenfolge wird regelmäßig vertauscht. Korrekt ist de-AT mit der Sprache zuerst und der Region danach. AT-de ist ungültig. Was passiert dann? Die Dokumentation ist unmissverständlich: „Wenn du Codes verwendest, die für etwas anderes reserviert sind, wird dieser Teil der Annotation von der Google Suche ignoriert.“ Google ignoriert den betroffenen Teil der Annotation still.

Ein zweiter Klassiker betrifft Länder, die keine eigene Sprache sind. Es gibt kein hreflang="uk" für das Vereinigte Königreich, denn uk ist in ISO 639-1 der Sprachcode für Ukrainisch. Gemeint ist in diesen Fällen en-GB.

Für die Auslieferung nennt Google drei Möglichkeiten: „Es gibt drei Möglichkeiten, bei Google mehrere Sprach- oder Länderversionen einer Seite anzugeben: HTML, HTTP-Header, Sitemap“. Welche davon passt hängt weniger von SEO ab als von deinem Stack.

Ahrefs hat für seinen hreflang-Guide 374.756 Domains ausgewertet und kommt zu dem Ergebnis: „67% of the hreflang implementations had issues“. Einen Erhebungszeitraum nennt Ahrefs dazu nicht und die Zahl stammt vom Toolanbieter selbst, weshalb ich sie hier ausschließlich als Größenordnung verwende und nicht als belastbare Fehlerquote des Webs. Zwei von drei Implementierungen tragen mindestens ein Problem.

1. Der fehlende Rückverweis

Das ist die Regel, an der nach meiner Erfahrung die meisten scheitern, und sie ist zugleich die einzige Regel in Googles Dokumentation, die Gegenseitigkeit verlangt. Google formuliert sie so: „In jeder Sprachversion müssen die Version selbst und alle anderen Sprachversionen aufgelistet sein.“

Zwei Dinge stecken darin. Erstens muss jede Seite sich selbst auflisten und nicht nur ihre Geschwister. Zweitens muss die Verbindung in beide Richtungen bestehen. Was bei einem einseitigen Verweis passiert führt Google unter den häufigen Fehlern auf: „Wenn Seite X auf Seite Y verweist, muss Seite Y zurück auf Seite X verweisen. Falls dies nicht für alle Seiten mit hreflang-Attribut der Fall ist, werden die Attribute möglicherweise ignoriert oder nicht richtig interpretiert.“

An diesem Satz hängen zwei Einschränkungen, die gern überlesen werden. Erstens das Wort „möglicherweise“: Google sagt hier nicht zu, dass einseitige Annotationen immer ignoriert werden, sondern nur, dass du dich nicht darauf verlassen kannst. In der Praxis ist das der schlechtere Fall. Sporadische Fehler sind deutlich schwerer zu finden als dauerhafte.

Zweitens nennt Google zwei mögliche Folgen und nicht eine. Die Attribute können ignoriert werden, sie können aber auch „nicht richtig interpretiert“ werden. Das ist der unangenehmere Ausgang, denn eine ignorierte Annotation tut schlicht nichts, während eine falsch interpretierte etwas tut, das du nicht wolltest.

Die typische Ursache ist banal. Eine Sprachversion wird nachträglich angelegt und die bestehenden Seiten werden dabei nicht aktualisiert, sodass die neue Seite auf alle alten verweist und keine der alten die neue kennt.

2. Der Canonical, der dagegen arbeitet

hreflang und Canonical müssen dieselbe Geschichte erzählen. Jede Sprachversion braucht einen Canonical auf sich selbst. Zeigt die englische Seite per Canonical auf die deutsche, sagst du Google zwei widersprüchliche Dinge: „das sind gleichwertige Sprachvarianten“ und „das hier ist nur eine Kopie der deutschen Seite“.

Google löst diesen Widerspruch nicht zu deinen Gunsten. In der Regel gewinnt der Canonical und die englische Seite verschwindet aus dem Index. Damit ist die hreflang-Gruppe ohnehin unvollständig.

Ein Sonderfall erklärt, warum dieser Fehler oft unbemerkt bleibt: Bei sehr ähnlichen Sprachvarianten konsolidiert Google auch dann, wenn dein Canonical von der ersten bis zur letzten Seite völlig korrekt gesetzt ist. Mueller ordnet das ausdrücklich als Vermutung ein: „I suspect this is a ’same language‘ case where our systems just try to simplify things for sites.“

3. Ungültige oder erfundene Codes

Neben der bereits erwähnten Verwechslung von Sprach- und Regionscode gibt es eine zweite Kategorie: Codes, die als Regionscode nicht zur Verfügung stehen. en-EU ist in Projekten mit europaweiter Ausrichtung ausgesprochen beliebt und trotzdem untauglich. Google nennt genau diesen Fall in der Dokumentation: „Die Verwendung von EU, UN oder UK in hreflang-Annotationen hat beispielsweise keine Auswirkungen auf die Google Suche.“ Der Grund steht im Satz davor: „Es werden nur Sprachcodes unterstützt, die in ISO 639-1 aufgeführt sind, und Regionscodes, die in ISO 3166-1 Alpha 2 aufgeführt sind.“ EU und UK zählen dort nicht zu den regulären Ländercodes, sondern sind für andere Zwecke reserviert.

Der Effekt ist in beiden Fällen derselbe. Die betroffene Zeile fällt aus und der Rest der Gruppe bleibt bestehen, sodass du am Ende eine teilweise funktionierende Auszeichnung hast. Von außen sieht die genauso aus wie eine vollständig funktionierende.

4. Die Auszeichnung landet nicht dort, wo sie hingehört

Die Google-Dokumentation verlangt die HTML-Variante im Head-Bereich. Damit ist eine Platzierung im Body nicht spezifikationskonform, unabhängig davon, wie Google im Einzelfall damit umgeht.

Interessant wird es, weil du das im Quelltext nicht siehst. Ich habe das für Canonical- und robots-Tags in einem eigenen Beitrag ausführlicher untersucht: Ein einzelnes fehlplatziertes Script kann dafür sorgen, dass der Parser den Head früher beendet, als du denkst, und alles Nachfolgende rutscht in den Body. Für Canonical und robots ist belegt, dass Google Direktiven im Body nicht verarbeitet. Für hreflang kenne ich keine vergleichbar harte Aussage und würde mich deshalb auf gar nichts verlassen, sondern schlicht nachsehen wo die Tags im gerenderten DOM tatsächlich stehen.

Dieselbe Vorsicht gilt, wenn die Tags per JavaScript nachgeladen werden. Und ein trivialer, aber realer Fall: Wenn die Zielsprachversion über die robots.txt ausgesperrt ist, kann Google den Rückverweis nicht sehen. Die Gruppe bleibt unvollständig, obwohl im Markup alles korrekt steht.

Google definiert den Wert knapp: „Der reservierte Wert x-default wird verwendet, wenn keine andere Sprache oder Region mit der Browsereinstellung des Nutzers übereinstimmt.“

Das klingt nach einem Randfall und ist keiner. Nimm eine Site mit einer deutschen und einer englischen Fassung. Was passiert bei einem Nutzer mit spanischer Browsereinstellung? Ohne x-default überlässt du Google die Entscheidung darüber, welche der beiden Versionen ausgespielt wird. Mit x-default triffst du sie selbst.

Der Wert ist kein Ersatz für eine Sprachauszeichnung. Er steht zusätzlich und zeigt meistens auf die englische Fassung oder auf eine Sprachauswahlseite. Eine automatische Weiterleitung ist damit ausdrücklich nicht gemeint und Google rät davon ab: „Vermeide eine automatische Weiterleitung der Nutzer von einer Sprachversion einer Website zu einer anderen Sprachversion der Website.“

Die Hilfeseite von Google ist an dieser Stelle sehr kurz: „The International Targeting report has been deprecated.“ Und direkt danach die Entwarnung: „Google will continue to support and use hreflang tags on your pages.“ Die Auszeichnung bleibt also relevant. Nur die Kontrollinstanz ist weg.

Angekündigt wurde das am 24. August 2022 über den Account von Google Search Central, und die Benachrichtigung in der Search Console nannte den 22. September 2022 als letzten Tag. Die Länderausrichtung saß im selben Report und wird ebenfalls nicht mehr unterstützt. Google begründet das damit, sie sei „determined to have little value for the ecosystem, and is no longer supported“.

Damit bleibt dieser Prüfpfad. Ich gehe ihn bei jedem Relaunch einmal komplett durch.

Schritt 1: Den ausgelieferten Head ansehen

Nicht im Browser, sondern in der Rohantwort des Servers. Ein Befehl genügt:

curl -s https://example.com/seite/ | grep -i 'rel="alternate"' | grep -i hreflang

Das zeigt dir, was tatsächlich ausgeliefert wird, ohne Browser-Interpretation. Der zweite Filter ist keine Kosmetik. Ein einfaches grep -i hreflang durchsucht das ganze Dokument und findet deshalb auch das hreflang-Attribut an einem Link im Fließtext. Mein eigener Sprachumschalter setzt genau das: ungefiltert liefern meine beiden Testseiten 21 und 22 Treffer, gefiltert bleiben jeweils zwei übrig, und nur diese zwei sind die Annotation (eigene Messung vom 3. August 2026). Ein Attribut an einem <a> im Body gehört zu keinem der drei Wege, die Googles Dokumentation nennt.

Für den HTTP-Header-Weg brauchst du eine Variante davon:

curl -sI https://example.com/seite/ | grep -i '^link:'

Schritt 2: Die Gegenrichtung prüfen

Das ist der Schritt, der nach meiner Erfahrung am häufigsten ausgelassen wird. Nimm die URL, auf die du gerade verwiesen hast, und prüfe ob sie zurückverweist. Bei zwei Sprachen sind das zwei Befehle. Bei fünf Sprachen sind es fünf und spätestens hier lohnt sich ein kleines Skript.

Das Kriterium ist einfach. Jede Seite der Gruppe muss dieselbe vollständige Liste ausliefern und sich dabei selbst mit aufführen. Unterscheiden sich die Listen, hast du deinen Fehler gefunden.

Schritt 3: Den gerenderten DOM gegenprüfen

Öffne das URL-Prüftool in der Search Console und lass dir das gerenderte HTML anzeigen. Hier siehst du, was nach der Verarbeitung durch den Renderer übrig bleibt und ob die Tags danach immer noch dort stehen, wo sie hingehören. Das ist einer der wenigen Schritte, für die die Search Console hier noch hilft, und er ersetzt den alten Report ausdrücklich nicht. Er zeigt dir den Zustand deiner Seite, nicht Googles Bewertung davon.

Schritt 4: Auf Auffälligkeiten in den Suchdaten achten

Ein indirektes, aber brauchbares Signal: Wenn die falsche Sprachversion für ein Land ausgespielt wird, siehst du das früher oder später im Leistungsbericht der Search Console. Filtere dort nach Land und sieh dir an, welche deiner Seiten in diesem Markt überhaupt Impressionen sammeln. Erscheint die deutsche URL systematisch in britischen Suchergebnissen, obwohl eine englische Fassung existiert, ist das ein Hinweis. Wie du solche Filter effizient baust, habe ich in der Sammlung RegEx-Kopiervorlagen für die Search Console zusammengestellt.

Statt ein Beispiel zu konstruieren, prüfe ich meine eigene Seite. seo-kreativ.de läuft auf WordPress mit Polylang für die Sprachausspielung und Yoast für die Sitemaps. Deutsch liegt unter /blog/, Englisch unter /en/blog/.

Geprüft habe ich drei URL-Paare mit den Befehlen aus Schritt 1 und 2. Das kam dabei heraus:

Der letzte Punkt hat mich am meisten interessiert. Die von Yoast erzeugte post-sitemap.xml deklariert einen Namespace für Bilder und keinen für xhtml, kann hreflang-Annotationen also gar nicht tragen. Wer davon ausgeht, dass eine Sitemap das automatisch mitliefert, liegt hier falsch. Ein Blick in den Wurzelknoten der Datei genügt.

Das fehlende x-default ist der einzige Punkt, an dem meine Auszeichnung nicht vollständig ist. Ich lasse ihn bewusst offen, und die Begründung gehört dazu, weil sie zeigt, welchen Teil die Auszeichnung erledigt und welchen nicht.

Deutschsprachige Nutzer landen auf der deutschen Fassung. Das ist keine Cleverness von Google, sondern hreflang="de", das genau seine Aufgabe erfüllt. Der Abgleich läuft dabei über die Spracheinstellung und nicht über das Land des Nutzers: „Die Google Suche gibt das entsprechende Ergebnis für den Nutzer gemäß den Browsereinstellungen zurück.“ Ein deutschsprachiger Nutzer in Spanien bekommt also die deutsche Fassung, ein englischsprachiger in Österreich die englische. x-default käme in beiden Fällen gar nicht zum Zug, denn der Wert greift nur, „wenn keine andere Sprache oder Region mit der Browsereinstellung des Nutzers übereinstimmt“.

Offen bleibt damit genau eine Gruppe: Nutzer, deren Spracheinstellung weder Deutsch noch Englisch ist. Für die entscheidet ohne x-default Google, welche meiner beiden Fassungen erscheint, und wie es das entscheidet, steht in der Dokumentation nicht. Ich halte das Risiko für vertretbar, weil Englisch bei einem deutsch-englischen Paar ohnehin die Fassung wäre, die ich für diesen Fall wählen würde. Das ist eine Abwägung für meine Site und keine Empfehlung: Google empfiehlt den Wert ausdrücklich, nämlich „um die Fallback-Seite für Nutzer anzugeben, deren Spracheinstellungen mit keiner der lokalisierten Versionen deiner Website übereinstimmen“. Wer diese Entscheidung nicht Google überlassen will, setzt ihn.

Nach meiner Erfahrung ist das Muster bei fast jeder wirkungslosen Implementierung dasselbe. Die Syntax stimmt und die Codes stimmen und trotzdem passiert überhaupt nichts, weil irgendwo eine einzelne Seite der Gruppe nicht zurückverweist oder ein vergessener Canonical dagegen arbeitet. Beide Fehler siehst du nur, wenn du gezielt danach suchst.

Deshalb lohnt sich die Umkehrung der üblichen Reihenfolge. Bau die Auszeichnung ein und plane die Prüfung direkt als festen zweiten Termin ein. Nicht als optionalen Zusatz. Bei mir hat genau diese Prüfung gezeigt, dass x-default fehlt. Ob das so bleibt, ist danach eine Entscheidung. Vorher war es ein blinder Fleck.

Und wenn du nur einen einzigen Befehl aus diesem Artikel mitnimmst, dann den auf die Gegenrichtung. Die Hinrichtung prüfen nach meiner Erfahrung fast alle. Die Rückrichtung fast niemand.