Was ist Hreflang? Definition, Code-Beispiel und häufige Fehler

Eine Website mit mehreren Sprachversionen steht vor einem Problem, das Suchmaschinen von sich aus nicht lösen können: Woher soll Google wissen, dass die deutsche, die spanische und die englische Version derselben Seite inhaltlich zusammengehören und sich nur in der Sprache unterscheiden? Ohne einen expliziten Hinweis behandelt eine Suchmaschine drei getrennte URLs als drei getrennte, möglicherweise sogar konkurrierende Seiten. Genau hier setzt hreflang an. Das Attribut verknüpft alle Sprachversionen einer Seite zu einer Gruppe und teilt gleichzeitig mit, welche Version für welche Sprache und optional welches Land gedacht ist.

Der Wert des hreflang-Attributs folgt einer festen Syntax: zuerst der Sprachcode nach ISO 639-1, zum Beispiel "de" für Deutsch oder "es" für Spanisch, optional gefolgt von einem Bindestrich und dem Ländercode nach ISO 3166-1 Alpha-2, etwa "de-AT" für deutschsprachige Nutzer in Österreich oder "es-MX" für Spanisch in Mexiko. Die Reihenfolge ist verbindlich: Sprache zuerst, Land danach, niemals umgekehrt. Ein Wert wie "AT-de" ist ungültig und wird ignoriert. Ergänzend gibt es den Sonderwert "x-default": Er markiert die Version, die ausgespielt wird, wenn keine der definierten Sprachversionen zur Spracheinstellung oder Region des Nutzers passt, meist die internationale oder englische Startseite.

Am häufigsten wird hreflang als Gruppe von Link-Tags im Head-Bereich jeder beteiligten Seite eingebunden. Die Gruppe muss auf jeder Sprachversion identisch sein: Jede Seite listet sich selbst und alle anderen Sprachversionen auf. So sieht ein vollständiger Block für einen Glossareintrag mit drei Sprachversionen plus x-default aus, am Beispiel eines Eintrags auf zds.es. Die Abbildung darunter zeigt den vollständigen Block für alle drei Sprachfassungen.

Dieser exakte Block, mit denselben vier hreflang-Zeilen und demselben Canonical-Tag, gehört in den Head jeder der drei beteiligten Seiten, nicht nur der spanischen. Nur die eigene Canonical-URL ändert sich von Seite zu Seite. Bei Websites mit sehr vielen Sprachversionen wird der Head-Bereich schnell unübersichtlich; dann bietet sich stattdessen die Angabe über die XML-Sitemap an, bei der jede URL ihre Alternativen über xhtml:link-Einträge referenziert. Für Nicht-HTML-Dokumente wie PDFs eignet sich der HTTP-Header Link mit rel="alternate", weil sich in ein PDF kein Head-Bereich einfügen lässt.

Für welchen der drei Wege man sich entscheidet, hängt vor allem von der Seitenzahl ab. Eine Website mit wenigen Dutzend mehrsprachigen Seiten kommt mit Link-Tags im Head problemlos aus, weil sich Fehler dort noch von Hand überprüfen lassen. Bei mehreren Hundert oder Tausend URLs pro Sprache wird die Sitemap-Variante deutlich wartbarer, weil sich die Zuordnung zentral aus einer Datenquelle generieren lässt, statt in jeder einzelnen Seitenvorlage gepflegt zu werden. Unabhängig vom gewählten Weg gilt dieselbe Regel: Die Gruppe muss vollständig und in sich konsistent sein, sonst ignoriert Google das gesamte Signal für die betroffenen URLs.

Hreflang und Canonical-Tag werden oft verwechselt, weil beide im selben Head-Bereich stehen und beide mit URLs arbeiten. Ihre Aufgaben sind aber grundverschieden. Der Canonical-Tag sagt: Von mehreren technisch ähnlichen oder identischen URLs ist dies die eine Version, die indexiert werden soll, etwa wenn dieselbe Seite über eine URL mit und ohne Tracking-Parameter erreichbar ist. Hreflang sagt dagegen: Diese Seiten sind bewusst unterschiedliche, eigenständige Sprachversionen desselben Inhalts, alle sollen indexiert werden, aber jeweils der passenden Zielgruppe angezeigt werden.

Das Zusammenspiel ist trotzdem zwingend. Jede Sprachversion braucht einen eigenen, auf sich selbst verweisenden Canonical-Tag. Verweist die deutsche Seite in ihrem Canonical-Tag auf die spanische Version, signalisiert das Google, dass nur die spanische Seite indexiert werden soll, und die gesamte hreflang-Gruppe wird de facto entwertet, weil eine der vermeintlich gleichwertigen Sprachversionen sich selbst als nicht kanonisch markiert. Ein häufiger, unauffälliger Fehler ist außerdem, dass die im hreflang-Attribut verwendete URL nicht exakt mit der im Canonical-Tag verwendeten URL übereinstimmt, etwa weil eine Version mit und die andere ohne abschließenden Schrägstrich geschrieben ist. Für Google sind das zwei verschiedene URLs, auch wenn sie im Browser zur selben Seite führen. Canonical und hreflang-Selbstverweis müssen zeichengenau identisch sein.

Der praktisch folgenreichste und zugleich am schwersten zu entdeckende Fehler bei hreflang betrifft Weiterleitungen. Ein hreflang-Verweis muss immer direkt auf die finale URL zeigen, die mit dem Statuscode 200 antwortet, niemals auf eine URL, die selbst eine Weiterleitung ist. Zeigt ein hreflang-Eintrag auf eine Zwischen-URL, die per 301 oder 302 auf eine andere Adresse umleitet, wertet Google diesen Verweis nicht als gültiges Sprachsignal.

Google dokumentiert in der offiziellen Search-Central-Referenz zu Redirects, wie Weiterleitungen aus Sicht der Indexierung funktionieren: Bei einer Weiterleitung führt Google intern zwei URLs, Quelle und Ziel, und konsolidiert die Signale auf eine kanonische URL, während die andere zur reinen "alternate name" wird, die selbst nicht mehr eigenständig für die Indexierung herangezogen wird (Quelle: developers.google.com/search/docs/crawling-indexing/301-redirects). Ein hreflang-Verweis, der auf die weiterleitende Quelle statt auf das Redirect-Ziel zeigt, referenziert damit keine indexierbare, kanonische Seite mehr. In der offiziellen hreflang-Dokumentation selbst verlangt Google zusätzlich ausdrücklich, dass jede Sprachversion sich selbst und alle anderen Versionen korrekt zurückverweist und mit einem passenden Canonical-Tag versehen ist (Quelle: developers.google.com/search/docs/specialty/international/localized-versions); eine URL, die selbst nur eine Weiterleitung ist, kann diese Anforderung an eine stabile, kanonische Zielseite nicht erfüllen. In der Kombination beider Dokumentationsseiten ist die Regel eindeutig geprüft: Jeder hreflang-Verweis muss auf die tatsächliche, mit 200 antwortende Endseite zeigen.

Dieser Fehler entsteht typischerweise nicht beim ersten Aufsetzen einer mehrsprachigen Seite, sondern erst später, nach einer URL-Struktur-Änderung. Wird zum Beispiel ein Glossar von /blog/glossar/begriff auf eine kürzere URL wie /begriff umgezogen und die alte Adresse per 301 auf die neue weitergeleitet, bleiben die hreflang-Verweise auf den anderen Sprachversionen oft unverändert stehen und zeigen weiter auf die inzwischen weitergeleitete alte Adresse. Die Seite selbst funktioniert für Besucher völlig normal, der Redirect greift ja, deshalb bleibt der Fehler oft monatelang unbemerkt. Erst ein Blick in die Search Console oder ein gezielter Crawl der hreflang-Ziel-URLs auf ihren tatsächlichen Statuscode deckt ihn auf.

Neben dem Redirect-Fehler tauchen in der Praxis vor allem drei weitere Fehlerarten regelmäßig auf, alle drei explizit in Googles eigener Liste häufiger Fehler genannt.

Fehlende Rückverweise sind der häufigste Fehler überhaupt. Verweist die deutsche Seite per hreflang auf die englische, muss die englische Seite umgekehrt auch auf die deutsche verweisen, und beide müssen sich zusätzlich selbst referenzieren. Google formuliert das in der offiziellen Dokumentation unmissverständlich: Verweisen zwei Seiten nicht wechselseitig aufeinander, werden die Tags ignoriert. Ein einseitiger Verweis ist aus Sicht von Google kein gültiges hreflang-Signal, sondern wird schlicht übergangen.

Falsche Sprachcodes sind der zweite große Fehlerblock. Häufig wird versucht, nur einen Ländercode ohne Sprachcode anzugeben, etwa "DE" statt "de-DE" – das ist laut Google ungültig, ein Ländercode allein wird nicht akzeptiert. Ebenso häufig ist die vertauschte Reihenfolge, etwa "AT-de" statt "de-AT". Beides führt dazu, dass Google den betroffenen Eintrag ignoriert.

Ungültige Regionscodes sind der dritte Block: Manche Websites verwenden Codes, die zwar geläufig klingen, aber offiziell nicht zu ISO 3166-1 Alpha-2 gehören, etwa "EU" für Europa, "UN" für die Vereinten Nationen oder "UK" für das Vereinigte Königreich, korrekt wäre hier "GB". Solche reservierten oder nicht zugewiesenen Codes werden von Google nicht erkannt.

Ein vierter, seltener diskutierter Fehler betrifft blockierte oder ausgeschlossene Zielseiten: Zeigt ein hreflang-Verweis auf eine URL, die per robots.txt für Crawler gesperrt ist oder ein noindex-Tag trägt, kann Google diese Version nicht auswerten, selbst wenn sie mit Statuscode 200 antwortet. Aus Sicht der Suchmaschine ist eine gesperrte Seite kein gültiges Ziel für ein Sprachsignal, ähnlich wie bei einer Weiterleitung fehlt schlicht eine erreichbare, indexierbare Endseite.

• Jede Sprachversion referenziert sich selbst und alle anderen Sprachversionen, inklusive eines konsistenten x-default für nicht abgedeckte Sprachen oder Regionen.
• Die im hreflang-Attribut verwendete URL ist zeichengenau identisch mit der im Canonical-Tag der Zielseite, inklusive Schrägstrich am Ende und Groß-/Kleinschreibung.
• Jeder hreflang-Verweis zeigt auf eine URL, die direkt mit Statuscode 200 antwortet, nie auf eine Weiterleitung oder eine URL mit noindex.
• Nach jeder URL-Struktur-Änderung werden alle hreflang-Ziel-URLs erneut auf ihren tatsächlichen Statuscode geprüft, nicht nur die neue Struktur selbst.
• Sprachcodes folgen ISO 639-1, optionale Regionscodes folgen ISO 3166-1 Alpha-2, immer in der Reihenfolge Sprache vor Land.
• Bei vielen Sprachversionen wird die Angabe über die XML-Sitemap statt über einzelne Link-Tags im Head geprüft, das hält den Head-Bereich schlank und reduziert Tippfehler.

• Hreflang-Verweis zeigt auf eine URL, die selbst per 301 oder 302 weiterleitet, statt auf die finale Zielseite.
• Fehlende Rückverweise: Seite A verweist auf Seite B, aber B verweist nicht zurück auf A.
• Sprachcode und Ländercode vertauscht, zum Beispiel "AT-de" statt "de-AT".
• Ländercode ohne begleitenden Sprachcode angegeben, was Google nicht akzeptiert.
• Reservierte oder ungültige Regionscodes wie "EU", "UN" oder "UK" statt des korrekten Ländercodes.
• Hreflang-URL und Canonical-URL derselben Seite weichen minimal voneinander ab, etwa durch einen fehlenden oder zusätzlichen Schrägstrich.