Zehn Hreflang-Fehler, die internationales SEO ruinieren
Zehn Fehler stecken hinter fast jedem kaputten Hreflang-Setup – und die meisten davon scheitern lautlos. So erkennen und beheben Sie jeden einzelnen.
Die meisten Hreflang-Probleme laufen auf zehn Fehler hinaus: fehlende Rückverweise, keine Selbstreferenz, ungültige Sprach- oder Regionscodes, relative URLs, Verweise auf nicht kanonische Seiten, ein fehlendes x-default, gemischte Implementierungswege, unvollständige Abdeckung, gesperrte Alternates und die Annahme, Hreflang behebe Duplicate Content. Jeder hat ein klares Symptom und eine konkrete Lösung.
Was Hreflang tatsächlich leistet
Hreflang sagt Suchmaschinen, welche Sprach- oder Regionsvariante einer Seite sie einem bestimmten Nutzer zeigen sollen. Es tauscht die URL im Ergebnis aus, mehr nicht. Ein Ranking-Boost ist es nicht. Eine Seite mit fehlerfreien Annotationen muss ihre Position weiterhin aus eigener Kraft verdienen.
Wie ein korrekter Hreflang-Satz aussieht
Drei Varianten – Englisch, Spanisch und ein Fallback –, notiert als Link-Elemente im Head jeder einzelnen dieser Seiten:
<link rel="alternate" hreflang="en" href="https://example.com/page/">
<link rel="alternate" hreflang="es" href="https://example.com/es/pagina/">
<link rel="alternate" hreflang="x-default" href="https://example.com/page/">Dieselbe Beziehung, ausgedrückt in einer XML-Sitemap, deren urlset den xhtml-Namespace deklarieren muss:
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/page/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/page/"/>
<xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/pagina/"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page/"/>
</url>
</urlset>Die spanische Seite trägt den identischen Satz. Diese Symmetrie ist der gesamte Mechanismus – und die meisten der folgenden Fehler sind Wege, sie zu zerstören.
1. Fehlende Rückverweise
Jede Hreflang-Beziehung ist wechselseitig. Wenn A auf B verweist, muss B auf A zurückverweisen, sonst gilt die Annotation als unbestätigt und wird ignoriert. Symptom: Die Varianten werden in den Ergebnissen nie getauscht, und die Search Console meldet fehlende Rückverweise. Lösung: Erzeugen Sie denselben vollständigen Satz für jede Seite der Gruppe statt einer einseitigen Liste.
2. Keine selbstreferenzierende Hreflang-Angabe
Jede Seite muss einen Hreflang-Eintrag für ihre eigene URL enthalten. Fehlt er, ist der Satz unvollständig, und Suchmaschinen verwerfen Sätze, die sie nicht abgleichen können. Lösung: Ergänzen Sie die Selbstreferenz, sodass eine dreisprachige Gruppe auf allen drei Seiten drei Einträge trägt.
3. Falsche Sprach- und Regionscodes
Der Sprachwert muss ein ISO-639-1-Code sein, die optionale Region ISO 3166-1 Alpha 2. Eine Region darf nie allein stehen. Drei Klassiker: en-UK statt en-GB, die Verwechslung von zh-CN (Chinesisch in China) mit zh-Hans (ein Schrift-Subtag, keine Region) und das Erfinden einer Sprache aus einem Land, etwa uk für Großbritannien, obwohl es Ukrainisch bedeutet. Ungültige Werte werden ohne Warnung verworfen.
4. Relative URLs
Hreflang-Werte müssen vollständig qualifizierte absolute URLs sein, inklusive Protokoll. Ein Wert wie /es/pagina/ ist ungültig, und der Eintrag wird übersprungen. Symptom: Annotationen, die in Ihrem Template richtig aussehen, aber nirgends registriert werden. Lösung: Geben Sie jedes Mal https://example.com/es/pagina/ aus – dieselbe Regel gilt für die loc-Werte in der Sitemap.
5. Verweise auf nicht kanonische, weiterleitende oder noindex-URLs
Hreflang und Canonical müssen übereinstimmen. Das Canonical jeder Seite zeigt auf sie selbst, und jeder Hreflang-Wert zeigt auf die kanonische URL einer anderen Variante. Eine URL zu annotieren, die weiterleitet, woandershin kanonisiert oder auf noindex steht, sendet widersprüchliche Anweisungen – und der Konflikt löst sich meist dadurch, dass Ihre Annotationen verworfen werden. Lösung: Stellen Sie sicher, dass jede URL der Gruppe Status 200 liefert, indexierbar und selbstkanonisch ist.
6. Fehlendes oder falsch genutztes x-default
x-default markiert den Fallback für Nutzer, deren Sprache Sie nicht abdecken: eine Sprachauswahl, eine globale Landingpage oder Ihre Hauptvariante. Symptom: Besucher aus nicht abgedeckten Regionen landen auf einer beliebigen Variante. Lösung: Benennen Sie einen echten Fallback und wiederholen Sie ihn in der gesamten Gruppe.
7. Implementierungswege mischen
Für Hreflang gibt es drei gültige Orte: HTML-Link-Elemente im Head, HTTP-Link-Header und xhtml:link-Annotationen in der XML-Sitemap. Jeder davon funktioniert. Ärger beginnt, wenn eine Website zwei davon halb umsetzt, sodass der Head zwei Sprachen listet und die Sitemap vier. Wählen Sie einen Weg und setzen Sie ihn vollständig um.
8. Nur die Startseite annotieren
Hreflang ist ein Signal auf Seitenebene, keine Einstellung auf Website-Ebene. Die Startseite auszuzeichnen bringt den 500 Produktseiten darunter nichts. Symptom: pro Markt die richtige Startseite, tiefere Seiten in der falschen Sprache. Lösung: Verknüpfen Sie jede Seite mit ihren echten Entsprechungen – und wo es keine gibt, lassen Sie diese Sprache lieber weg, statt auf eine ungefähre Entsprechung zu zeigen.
9. Die Alternate sperren, sodass sie nicht gecrawlt werden kann
Eine Beziehung gilt nur als bestätigt, wenn beide Seiten abrufbar sind. Einen Sprachordner in der robots.txt zu sperren oder ihn hinter Geo-Weiterleitungen zu verstecken, die Crawler abweisen, bricht die Prüfung der Rückverweise. Lösung: Halten Sie jede annotierte URL crawlbar und ohne Weiterleitung erreichbar.
10. Erwarten, dass Hreflang Duplicate Content behebt
Hreflang verwaltet regionale und sprachliche Varianten. Es dedupliziert keine nahezu identischen Seiten und ersetzt keine Canonical-Tags. Zwei fast identische englische Seiten, eine für die USA und eine für Australien, konkurrieren weiterhin miteinander; Hreflang sagt nur, für welchen Markt jede gedacht ist. Echte Duplikate brauchen Kanonisierung oder Zusammenlegung.
Welchen Implementierungsweg wählen?
| Methode | Am besten geeignet für | Wichtigster Nachteil |
|---|---|---|
| HTML-Link-Elemente im Head | HTML-Seiten, wenige Sprachen, Template-getriebene Websites | Das Markup wächst quadratisch mit der Zahl der Sprachen und wird bei jedem Seitenaufruf mitgeladen |
| HTTP-Link-Header | Nicht-HTML-Dateien wie PDFs, bei denen es keinen Head zu bearbeiten gibt | Im Quelltext unsichtbar, erfordert Server- oder CDN-Konfiguration, geht bei einer Migration leicht verloren |
| xhtml:link in der XML-Sitemap | Große Websites und viele Sprachen; hält das Seiten-Markup schlank | Schwerer stichprobenartig zu prüfen, und die Sitemap muss gültig und aktuell bleiben, sonst veraltet der gesamte Satz |
Der Sitemap-Weg skaliert am besten – und genau deshalb scheitert er lautlos: Ein fehlerhafter Namespace oder eine veraltete Datei reißt die Annotationen mit. Validieren Sie die Sitemap nach jeder Änderung am Generator, und teilen Sie große mehrsprachige Sätze mit einem Sitemap-Index auf.
So prüfen Sie, ob Hreflang funktioniert
Prüfen Sie in beide Richtungen. Rufen Sie Seite A ab, lesen Sie ihren Annotationssatz, rufen Sie dann jede darin genannte URL ab und bestätigen Sie, dass jede denselben Satz inklusive sich selbst listet. Der Quelltext deckt die HTML-Methode ab, die Response-Header die zweite und die Sitemap die dritte. Jede Asymmetrie ist der Fehler.
Wo die Search Console für Ihre Property ein Reporting zum internationalen Targeting bietet, listet sie Hreflang-Fehler wie fehlende Rückverweise und unbekannte Sprachcodes auf – der schnellste Weg, Probleme im großen Maßstab zu sehen. Sie hinkt Ihren Deployments hinterher, nehmen Sie sie also als Zweitmeinung. Für die darunterliegenden Crawl-Fehler behandelt der Guide zu Sitemap-Fehlern die Weiterleitungen, 404er und robots.txt-Sperren, die ganze Annotationssätze zu Fall bringen.