Stolperfallen, die Ihr SEO ruinieren können

Hreflang-Fehler wirken harmlos, entscheiden aber darüber, ob Nutzer in Wien, Zürich und London die für sie gedachte Version Ihrer Website sehen – oder eine, die nicht zu Sprache, Währung und Markt passt. Falsche Sprach- oder Ländercodes, widersprüchliche Canonicals und fehlende Rückverweise führen dazu, dass Google Ihre Angaben ignoriert. Dieser Leitfaden zeigt, wie hreflang funktioniert, auf welchen Grundlagen einer mehrsprachigen Website es aufbaut, welche sieben Fehler am häufigsten vorkommen und wie Sie sie systematisch finden und beheben.

YellowFrog-Insight: „Internationales SEO scheitert selten an der Strategie – sondern an Details. Hreflang ist ein Zeilen-Feature, das ohne klare Zuständigkeiten schnell aus dem Takt gerät.“

Warum Hreflang entscheidend ist

Hreflang sorgt dafür, dass Google bei mehreren Sprach- oder Länderversionen auf die Version verlinkt, die zur Sprache und Region der suchenden Person passt.

Ein Nutzer aus München sucht nach Ihrem Produkt – und landet auf der US-englischen Version mit Dollarpreisen. Die Folge sind Absprünge und verlorene Anfragen. Google empfiehlt in seiner Dokumentation zu mehrsprachigen Websites ausdrücklich, hreflang-Angaben zu nutzen, damit die Suchergebnisse auf die richtige Sprachversion einer Seite verweisen. Besonders wichtig ist das, wenn sich Versionen stark ähneln: gleiche Templates, gleiche Sprache, nur andere Preise, Währungen oder Versandbedingungen – etwa bei Deutschland, Österreich und der Schweiz.

Hinzu kommt die Kanonisierung. Laut Google gelten lokalisierte Versionen nur dann als Duplikate, wenn der Hauptinhalt unübersetzt bleibt. Bei gleichsprachigen Länderversionen ist das oft der Fall – und Google bevorzugt für die Wahl der kanonischen URL Seiten, die Teil eines hreflang-Clusters sind. Saubere Angaben helfen also auch dabei, dass die richtige Länderversion im Index steht.

Was ist das Hreflang-Attribut?

Das hreflang-Attribut ist ein Wegweiser, der Google sagt: Diese URL ist für Deutschsprachige in Deutschland gedacht, jene für Englischsprachige in den USA.

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

Wichtig für die Praxis: Laut Google müssen die URLs vollständig angegeben werden, inklusive https://. Groß- und Kleinschreibung spielt beim Wert keine Rolle, üblich ist die Schreibweise de-DE mit Bindestrich. Reine Sprachcodes wie de oder en sind ausdrücklich erlaubt. Für Schriftvarianten lässt Google Angaben wie zh-Hant zu; die Grundlage dafür bildet der IETF-Standard für Sprach-Tags, RFC 5646.

Mehrsprachige Website: Grundlagen, auf denen hreflang aufbaut

Hreflang kann nur Versionen verbinden, die es als eigene, crawlbare URLs gibt – deshalb beginnt jede saubere Auszeichnung mit der Struktur der mehrsprachigen Website.

Google empfiehlt, für jede Sprachversion einer Seite eine eigene URL zu verwenden, statt die Sprache per Cookie oder Browsereinstellung zu wechseln. Für die URL-Struktur beschreibt Google vier Optionen:

Welche Struktur zu Ihrem Unternehmen passt, hängt von Märkten, Technik und Organisation ab – die Abwägung zwischen Subdomain und Verzeichnis beschreiben wir ausführlich im Leitfaden Subdomain vs. Unterverzeichnis. Unabhängig von der Struktur gelten vier Grundregeln aus der Google-Dokumentation:

• Sprache steckt im sichtbaren Inhalt: Google bestimmt die Sprache einer Seite anhand des sichtbaren Inhalts. Weder das HTML-Attribut lang noch hreflang noch die URL werden zur Spracherkennung genutzt.
• Keine automatische Weiterleitung nach vermuteter Sprache: Google rät davon ab, Nutzer automatisch auf eine Sprachversion umzuleiten, und davon, Inhalte anhand der IP-Adresse anzupassen. Der Googlebot crawlt meist von US-Adressen und sendet keinen Accept-Language-Header – automatische Umleitungen können also verhindern, dass Google alle Versionen sieht.
• Sprachwechsler mit echten Links: Google empfiehlt, auf jeder Seite Links zu den anderen Sprachversionen anzubieten, damit Nutzer selbst wechseln können.
• Vollständig übersetzen: Nur Navigation und Rahmentexte zu übersetzen, während der Hauptinhalt in einer anderen Sprache bleibt, nennt Google eine schlechte Nutzererfahrung. Und die Spam-Richtlinien zählen automatisierte Umwandlungen wie Übersetzen ohne Mehrwert zum Missbrauch skalierter Inhalte – maschinelle Übersetzungen sollten daher redaktionell geprüft werden.

Implementierungsvarianten

Google bietet drei gleichwertige Wege, Sprachversionen auszuzeichnen: im HTML-Head, im HTTP-Header und in der XML-Sitemap.

HTML-Head

<link rel="alternate" hreflang="de-DE" href="https://example.com/de/produkt-a/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/product-a/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

XML-Sitemap

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
 <url>
  <loc>https://example.com/de/produkt-a/</loc>
  <xhtml:link rel="alternate" hreflang="de-DE" href="https://example.com/de/produkt-a/"/>
  <xhtml:link rel="alternate" hreflang="en-US" href="https://example.com/us/product-a/"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/"/>
 </url>
</urlset>

Wie Sie Sitemaps aufbauen und in der Search Console einreichen, zeigt unser Leitfaden XML-Sitemap erstellen und einreichen.

HTTP-Header

Link: <https://example.com/de/broschuere.pdf>; rel="alternate"; hreflang="de-DE",
 <https://example.com/en/brochure.pdf>; rel="alternate"; hreflang="en-GB",
 <https://example.com/>; rel="alternate"; hreflang="x-default"

Faustregel aus unserer Praxis: Laut Google können Sie die Methoden kombinieren, gewinnen dadurch in der Suche aber nichts. Jede zusätzliche Methode ist eine weitere Quelle, die bei jeder Änderung synchron bleiben muss. Wählen Sie deshalb eine Methode pro Seitentyp und pflegen Sie sie vollständig.

7 typische Fehler im Überblick

Die sieben häufigsten Hreflang-Fehler betreffen Codes, Rückverweise, Canonicals, Vollständigkeit, Methodenmix, die Fallback-Version und nicht indexierbare Ziele.

Zu Fehler 2 ist die Google-Dokumentation eindeutig: Bei lokalisierten Seiten soll die kanonische Seite in derselben Sprache liegen oder in der bestmöglichen Ersatzsprache. Ein Canonical von der österreichischen auf die deutsche Version sagt Google, dass nur die deutsche Version indexiert werden soll – und widerspricht damit der hreflang-Angabe. Zu Fehler 7: Google rät ausdrücklich davon ab, HTTP-Versionen statt HTTPS in Sitemaps oder hreflang-Angaben aufzunehmen. Dass nur indexierbare Seiten mit Status 200 ins Set gehören, ist unsere Praxisregel – eine Seite mit noindex soll nicht in der Suche erscheinen und kann daher auch keine Sprachversion vertreten. Wie sich noindex, robots.txt und Canonical unterscheiden, erklärt unser Vergleich robots.txt, noindex und Canonical.

Tools & Prüfmethoden (inkl. XPath/Regex)

Hreflang prüfen Sie am zuverlässigsten mit einem Crawler, der alle Sprachversionen abruft, die Angaben extrahiert und Rückverweise automatisch abgleicht.

• Google Search Console: Den Bericht „Internationale Ausrichtung“ hat Google eingestellt; hreflang wird laut Search-Console-Hilfe aber weiterhin unterstützt. Nutzen Sie die URL-Prüfung, um für jede Sprachversion die vom Nutzer angegebene und die von Google gewählte kanonische URL zu vergleichen. Im Bericht zur Seitenindexierung sehen Sie, ob Länderversionen als Duplikate ausgeschlossen werden – wie Sie diesen Bericht lesen, zeigt unser Beitrag zum Indexierungsbericht der Search Console.
• Desktop-Crawler: Extrahieren Sie alle link[rel="alternate"]-Angaben und prüfen Sie Rückverweise, Statuscodes und Canonicals der Ziel-URLs.
• Manueller Check: Quelltext, HTTP-Header (etwa per curl -I) und Sitemaps stichprobenartig gegen die ISO-639-Codeliste abgleichen.

//link[@rel='alternate'][@hreflang]/@href
//link[@rel='alternate'][@hreflang]/@hreflang

^([a-z]{2}(-[a-z]{4})?(-[a-z]{2})?|x-default)$

Best Practices & Entscheidungsregeln

Gute Hreflang-Umsetzungen folgen wenigen, konsequent angewandten Regeln – Konsistenz ist wichtiger als jede einzelne Spezialoption.

• Vollständige Sets: Jede Version nennt sich selbst und alle anderen Versionen – immer dieselben.
• Canonical und hreflang im Einklang: Jede Version hat einen selbstreferenzierenden Canonical; Canonicals zeigen nie auf eine andere Sprache.
• Allgemeine plus regionale Versionen: Google empfiehlt für Sprachen mit mehreren Regionalversionen eine allgemeine Seite, etwa en für alle Englischsprachigen, zusätzlich zu en-GB oder en-AU.
• x-default für den Rest: Eine Fallback-Seite für Sprachen, die Sie nicht abdecken.
• Zuständigkeiten: Eine Person oder ein Team verantwortet das Sprach-Mapping; Releases mit neuen Sprachversionen laufen erst nach einem Crawler-Abgleich live.

Edge Cases (die oft vergessen werden)

Viele Hreflang-Probleme entstehen nicht auf Standardseiten, sondern in Sonderfällen, die im ersten Rollout niemand bedacht hat.

• PDFs und Downloads: Ohne HTML-Head bleibt nur der HTTP-Header – laut Google genau dafür gedacht.
• Länderdomains mit gleicher Sprache: hreflang funktioniert auch über Domains hinweg; laut Google müssen die alternativen URLs nicht auf derselben Domain liegen. Jede Domain behält ihren eigenen Canonical.
• Paginierte Listen und Filter: Nach unserer Praxisregel nur kanonische, indexierbare Seiten ins Set aufnehmen; Filter- und Sortier-URLs bleiben außen vor. Solche Template-Regeln setzen wir im Rahmen von Technical SEO direkt im System um.
• Währungen und Preise: Eigene URLs nur, wenn sich Inhalt oder Angebot tatsächlich unterscheiden und die Seite indexiert werden soll.
• JavaScript-Anwendungen: Liefern Sie die hreflang-Angaben im initialen HTML aus, damit sie nicht vom Rendering abhängen.
• Nicht passende Codes: es-419 für Lateinamerika wird laut Google nicht unterstützt; ebenso haben EU, UN und UK keine Wirkung.

Schritt-für-Schritt-Audit: der kompakte Prüfplan

Ein Hreflang-Audit folgt immer derselben Reihenfolge: erst Inventar, dann Codes, dann Rückverweise, dann Canonicals, dann Indexierung.

1. Inventar: Alle Sprach- und Ländervarianten tabellarisch erfassen – URL, Sprache, Region, Canonical, Methode.
2. Extraktion: Per Crawler alle rel="alternate"-Angaben ziehen; Sitemaps und Header einbeziehen.
3. Code-Prüfung: Regex und ISO-Listen gegen alle Werte laufen lassen.
4. Rückverweise: Prüfen, ob jedes Paar wechselseitig verweist und jede Seite sich selbst nennt.
5. Canonical-Abgleich: Zeigt jeder Canonical auf die eigene Version in derselben Sprache?
6. Search-Console-Check: Stichproben per URL-Prüfung; Seitenindexierung nach Länderverzeichnissen filtern.
7. Korrekturplan: Reihenfolge nach unserer Erfahrung: Codes, Rückverweise, Canonicals, x-default.

Bei einer überschaubaren Website mit wenigen Sprachversionen ist ein solcher Durchgang erfahrungsgemäß in wenigen Stunden erledigt; große Shops mit vielen Märkten brauchen entsprechend länger.

Monitoring & KPIs

Hreflang ist keine Einmal-Aufgabe: Neue Seiten, gelöschte Produkte und Relaunches brechen Sets, wenn niemand regelmäßig nachprüft.

• Index-Abdeckung je Markt: Werden die Länderversionen indexiert, oder tauchen sie als Duplikate mit anderer kanonischer URL auf?
• Passende Ausspielung: Im Leistungsbericht der Search Console nach Land filtern und prüfen, ob Klicks aus Österreich auch auf /de-at/ landen.
• Klickrate je Markt: Vorher-Nachher-Vergleich nach Korrekturen über identische Zeiträume.
• Fehlerquote im Crawler-Abgleich: Anzahl fehlender Rückverweise und ungültiger Codes vor und nach jedem Release.

Checkliste (Kurzprüfung)

• Sprachcodes nach ISO 639-1, Regionscodes nach ISO 3166-1 Alpha-2, kein Ländercode allein?
• Rückverweise vollständig, jede Seite nennt sich selbst?
• Canonicals selbstreferenzierend und in derselben Sprache?
• x-default gesetzt, wo sinnvoll?
• Eine Methode je Seitentyp, vollständig gepflegt?
• Nur indexierbare HTTPS-URLs mit Status 200 im Set?
• Keine automatische Weiterleitung nach IP oder Browsersprache, Sprachwechsler mit Links vorhanden?
• Monitoring per Crawler-Abgleich und Search Console eingerichtet?

Häufige Fragen

Google-Tools & Referenzen (Direktlinks)

• Google Search Console – URL-Prüfung, Seitenindexierung, Sitemaps, Leistung nach Ländern
• Google: Lokalisierte Versionen einer Seite – Regeln, Codes und Beispiele für alle drei Methoden
• Google: Doppelte URLs konsolidieren – Canonical und hreflang im Zusammenspiel
• Google: Crawling sprachabhängiger Seiten – warum eigene URLs je Sprache besser sind als automatische Anpassung
• Search-Console-Hilfe: Bericht „Internationale Ausrichtung“ eingestellt

Fazit & Kernaussagen

• hreflang steuert, welche Sprach- und Länderversion Google verlinkt – fehlerhafte Angaben werden ignoriert.
• Die drei größten Risiken: ungültige Codes, fehlende Rückverweise und Canonicals auf andere Sprachen.
• Die Grundlage ist eine saubere mehrsprachige Struktur: eigene URLs je Sprache, keine automatischen Umleitungen, echte Übersetzungen, Sprachwechsler mit Links.
• Da es keinen Hreflang-Bericht in der Search Console mehr gibt, ersetzen Crawler-Abgleich und klare Zuständigkeiten das Monitoring.

YellowFrog-Erfahrungs-Insight: Hreflang-Stabilität in großen Setups

In internationalen Rollouts sehen wir drei Hebel, die Hreflang-Fehler dauerhaft reduzieren – ohne Inhalte neu zu bauen:

• Eine zentrale Datenquelle für das Sprach-Mapping: Welche URL gehört zu welchem Set, mit welchem Code und Canonical? Templates und Sitemaps lesen aus dieser Quelle, statt Angaben von Hand zu pflegen.
• Freigabe mit Crawler-Abgleich: Vor und nach jedem Deployment wird gecrawlt; neue fehlende Rückverweise oder ungültige Codes stoppen die Freigabe.
• Regelmäßige Marktprüfung: Für Märkte mit auffälligen Klickraten oder Beschwerden über falsche Sprachversionen prüfen wir gezielt, welche Version Google tatsächlich ausspielt.

Diese Einschätzung beruht auf unserer Projekterfahrung, nicht auf einer Studie.