Das Attribut hreflang teilt Google mit, welche Sprach- oder Regionalversion einer Seite einer bestimmten Suchanfrage angezeigt werden soll. Schlecht umgesetzt, löst es fast nie einen sichtbaren Fehler aus: Die Seiten werden weiterhin indexiert, die Website funktioniert weiter, und genau das macht das Problem so schwer zu erkennen. Die eigentlichen Symptome, Traffic-Verlust bei einer Sprachversion, falsche Seite in den Suchergebnissen, zeigen sich oft erst Wochen nach dem Start einer mehrsprachigen Website.
Was hreflang wirklich tut, und was nicht
hreflang übersetzt nichts und leitet niemanden automatisch um. Es deklariert lediglich Beziehungen zwischen URLs: „Diese deutsche Seite hat ein englisches Äquivalent unter dieser Adresse, ein französisches unter jener.“ Google nutzt diese Information anschließend, um zu entscheiden, welche URL je nach Sprache und Suchstandort angezeigt wird. Ohne hreflang bleibt eine mehrsprachige Website zwar indexierbar, aber Google muss die richtige Version erraten, und liegt dabei bei stark frequentierten internationalen Seiten öfter falsch, als man denkt.
Die häufigsten Fehler
Die meisten hreflang-Probleme auf produktiven Websites lassen sich auf eine Handvoll wiederkehrender Ursachen zurückführen.
| Fehler | Beobachtetes Symptom | Typische Ursache | Korrektur |
|---|---|---|---|
| Nicht-reziproke Tags | Search Console meldet einen „Rückverweisfehler“ | Seite B verweist auf A, aber A verweist nicht zurück auf B | Tags paarweise generieren, niemals manuell Seite für Seite |
| Ungültiger Sprachcode | Google ignoriert das Tag ohne expliziten Fehler | Verwendung eines fehlerhaften Ländercodes allein („de-DE“ falsch gebildet) oder eines erfundenen Codes | ISO 639-1 für die Sprache, ISO 3166-1 für die Region, in dieser Reihenfolge |
| Fehlendes x-default | Falsche Version wird Suchenden außerhalb der abgedeckten Sprachen angezeigt | Keine Fallback-Seite deklariert | Ein hreflang="x-default"-Tag zur generischen Version oder Sprachauswahl hinzufügen |
| Nicht-kanonische URLs in hreflang | Konflikt zwischen Canonical- und hreflang-Tag | hreflang-URLs verweisen auf Versionen mit Parametern oder nicht-kanonische Seiten | Nur exakte, wie indexiert vorliegende kanonische URLs verwenden |
| Widerspruch zwischen Sitemap und HTML-Tags | Manche Seiten korrekt behandelt, andere nicht, ohne erkennbares Muster | Beide Mechanismen deklarieren unterschiedliche Beziehungen | Pro Website nur eine Implementierungsmethode wählen, nie beide gleichzeitig |
Google ignoriert falsch zugeordnete hreflang-Tags stillschweigend, ohne dass dies wochenlang in Search Console sichtbar wird.
Eine bestehende Website prüfen
Der Bericht „Internationale Ausrichtung“ in Search Console bleibt der zuverlässigste Ausgangspunkt: Er listet Rückverweisfehler auf, die bei einer Stichprobe von Seiten erkannt wurden. Er deckt jedoch nicht die gesamte Website ab, und seine Aktualisierungsverzögerung kann eine Woche überschreiten. Für eine vollständige Prüfung bleibt ein technischer Crawl (Screaming Frog, Sitebulb oder ein eigenes Skript) notwendig: Er prüft URL für URL, ob jede hreflang-Beziehung tatsächlich reziprok ist und die Sprachcodes gültig sind.
Diese Verzögerung bei der Erkennung hängt mit einem umfassenderen Steuerungsproblem zusammen: Ohne ein regelmäßiges Dashboard, das Indexierung und Performance nach Sprache gegenüberstellt, kann ein hreflang-Fehler monatelang unbemerkt bleiben. Ein nach Sprache segmentiertes GA4- und Search-Console-Dashboard einzurichten, erleichtert es, einen lokal begrenzten Traffic-Einbruch bei einer einzelnen Sprachversion zu erkennen, oft ein Zeichen für ein hreflang-Problem statt für einen generellen Sichtbarkeitsverlust.
hreflang korrekt umsetzen
Zwei Methoden stehen nebeneinander: <link>-Tags im <head> jeder Seite oder eine Deklaration in der XML-Sitemap. Letztere ist auf umfangreichen Websites vorzuziehen, da sie jede Seite schlank hält und die Beziehungen in einer einzigen, zu pflegenden Datei zentralisiert.
<!-- Im head der deutschen Seite -->
<link rel="alternate" hreflang="de" href="https://beispiel.de/de/hreflang-leitfaden/" />
<link rel="alternate" hreflang="en" href="https://beispiel.de/en/hreflang-guide/" />
<link rel="alternate" hreflang="fr" href="https://beispiel.de/fr/guide-hreflang/" />
<link rel="alternate" hreflang="es" href="https://beispiel.de/es/guia-hreflang/" />
<link rel="alternate" hreflang="x-default" href="https://beispiel.de/" />
<!-- Entsprechende Deklaration in der XML-Sitemap -->
<url>
<loc>https://beispiel.de/de/hreflang-leitfaden/</loc>
<xhtml:link rel="alternate" hreflang="en"
href="https://beispiel.de/en/hreflang-guide/" />
<xhtml:link rel="alternate" hreflang="fr"
href="https://beispiel.de/fr/guide-hreflang/" />
<xhtml:link rel="alternate" hreflang="x-default"
href="https://beispiel.de/" />
</url>
Jenseits von Search Console: weitere Kontrollwerkzeuge
Search Console allein reicht für eine regelmäßige Kontrolle nicht aus, bedingt durch Stichprobenumfang und Verarbeitungsverzögerung. Drei Arten von Werkzeugen decken das Wesentliche ab, was ein technisches Team braucht. Ein klassischer SEO-Crawler (Screaming Frog, Sitebulb) besitzt einen eigenen Reiter, der automatisch nicht-reziproke hreflang-Tags, ungültige Sprachcodes und Seiten ohne Selbstreferenz auflistet, über die gesamte Website hinweg statt nur stichprobenartig. Für Websites, die mehrmals täglich veröffentlichen, erkennt ein in die Continuous-Integration-Pipeline eingebundenes Prüfskript Regressionen vor der Veröffentlichung, statt erst Wochen später über Search Console. Schließlich bleibt das hreflang-Testwerkzeug von Merkle (technicalseo.com) eine Referenz, um eine Handvoll URLs manuell zu prüfen, ohne einen vollständigen Crawl zu benötigen.
Ein häufiges Szenario: eine Sprache nachträglich hinzufügen
Die meisten in Audits gefundenen hreflang-Fehler treten nicht beim Start einer mehrsprachigen Website auf, sondern beim nachträglichen Hinzufügen einer Sprache zu einer Website, die bereits zwei oder drei Sprachen umfasste. Das Muster wiederholt sich: Ein Team fügt einer französisch-englisch-spanischen Website Deutsch hinzu, aber das Skript oder die Konfiguration, die hreflang-Tags erzeugt, wurde nur für drei Sprachen konzipiert. Die neuen deutschen Seiten existieren und werden indexiert, tauchen aber in keinem hreflang-Tag der bestehenden Seiten auf, und ihre eigenen Tags verweisen auf URLs, die sie ihrerseits nicht zurückreferenzieren. Das Ergebnis ist ein Rückverweisfehler auf sämtlichen neuen Seiten, unsichtbar, bis jemand erneut ein vollständiges Audit durchführt.
Die Lösung ist weniger eine Frage des Werkzeugs als des Prozesses: Jede Sprachergänzung als Änderung des Datenschemas behandeln statt als isolierten Inhalt, und danach systematisch einen vollständigen Website-Crawl erneut ausführen, nicht nur auf den neuen Seiten.
Der Fall mehrsprachiger CMS
Bei WordPress erzeugen Mehrsprachigkeits-Plugins (Polylang, WPML) die hreflang-Tags in der Regel automatisch aus den in der Datenbank verknüpften Übersetzungen, was die meisten manuellen Fehler vermeidet. Das Risiko verlagert sich dann auf die Konfiguration: Eine nicht übersetzte Rubrik oder Kategorie kann die Verknüpfungskette unterbrechen, und einen Beitrag in einer Standardsprache erneut zu veröffentlichen, ohne den Übersetzungsmechanismus des Themes zu durchlaufen, erzeugt oft eine verwaiste Seite, auf die kein einziges hreflang-Tag verweist. Die Wahl des CMS und seiner mehrsprachigen Architektur sollte früh im Projekt getroffen werden; der Leitfaden zur CMS-Auswahl erläutert, was vor dem Hinzufügen einer Übersetzungsschicht zu einer bestehenden Website zu berücksichtigen ist.
Das Wichtigste in Kürze
hreflang verzeiht keine Ungenauigkeit: Ein verwaistes Tag oder ein falsch gebildeter Sprachcode verhindert sichtbar nichts, entzieht aber einem Teil des internationalen Publikums stillschweigend die richtige Version der Website. Eine regelmäßige Prüfung, eine einzige Implementierungsmethode pro Website (HTML oder Sitemap, nicht beides) und eine systematische Selbstreferenz decken die meisten in der Praxis auftretenden Fälle ab.
Bei fast jedem mehrsprachigen Audit, das auf meinem Schreibtisch landet, liegt das Problem nie an fehlendem Willen, sondern an einem Versäumnis beim Hinzufügen einer fünften Sprache zu einer Website, die mit zweien begonnen hat. Das Skript zur Tag-Generierung wurde nicht aktualisiert, und niemand bemerkt es, bevor der Traffic auf der neuen Version einbricht. Mein Reflex: hreflang wie Code behandeln, mit einem automatisierten Test, der die Reziprozität der Tags bei jedem Deployment prüft, statt wie ein Häkchen in einem Plugin. — Simon Janvier
Zum Weiterlesen: die offizielle Google-Dokumentation zu lokalisierten Versionen und hreflang.
