Hreflang in der Praxis: Internationale SEO-Fehler bei mehrsprachigen Websites

Kurzantwort

Hreflang ist ein HTML- oder Sitemap-Attribut, das Suchmaschinen mitteilt, welche Sprach- oder Länderversion einer Seite für welche Zielgruppe gedacht ist. In der Theorie einfach, in der Praxis eines der fehleranfälligsten SEO-Signale überhaupt: Schon kleine Inkonsistenzen führen dazu, dass Google die Zuordnung ignoriert und stattdessen eigene Annahmen trifft - mit dem Ergebnis, dass Nutzer:innen in der falschen Sprachversion landen oder einzelne Länderversionen kaum sichtbar sind.

Was macht Hreflang technisch überhaupt und warum ist es so fehleranfällig?

Hreflang verknüpft alle Sprach- und Länderversionen einer inhaltlich gleichwertigen Seite untereinander - jede Version muss auf alle anderen Versionen verweisen, inklusive sich selbst. Bei zwei Sprachversionen ist das trivial. Bei zwölf Kernländern mit teils mehreren Sprachvarianten pro Land, wie ich es bei Sixt umgesetzt habe, wächst die Zahl der notwendigen Verknüpfungen dagegen quadratisch: Jede einzelne Seite benötigt einen vollständigen, in sich konsistenten Satz an Verweisen zu sämtlichen anderen Länderversionen. Schon eine einzige fehlende oder falsch gesetzte Rückverknüpfung macht das gesamte Hreflang-Set für die betroffene Seite ungültig. Mehr zu den technischen Grundlagen im Glossar-Begriff hreflang. Diese quadratische Komplexität ist der Hauptgrund, warum Hreflang-Probleme mit wachsender Anzahl an Länderversionen nicht linear, sondern überproportional zunehmen - und warum eine Lösung, die bei drei Sprachversionen noch manuell handhabbar war, bei zwölf oder mehr Ländern zwingend eine automatisierte, systematische Herangehensweise erfordert - manuelle Pflege stößt hier unweigerlich an ihre Grenzen, unabhängig davon, wie sorgfältig und gewissenhaft ein einzelnes Team dabei im Alltag tatsächlich arbeitet und wie viel Erfahrung die beteiligten Personen im Umgang mit internationalen SEO-Strukturen bereits mitbringen.

Welcher Fehler kommt in der Praxis am häufigsten vor?

Der mit Abstand häufigste Fehler ist die fehlende Rückverknüpfung: Seite A verweist auf Seite B, aber Seite B verweist nicht zurück auf Seite A. Google behandelt ein solches einseitiges Signal als ungültig und ignoriert es komplett - ohne Fehlermeldung im Frontend, oft unbemerkt über Monate. Der zweite häufige Fehler betrifft die Sprachcodes selbst: Eine Verwechslung von Sprach- und Ländercode (etwa “de-DE” für Deutschland vs. “de” für die deutsche Sprache allgemein) führt dazu, dass eine für Österreich gedachte Version plötzlich weltweit allen deutschsprachigen Nutzer:innen ausgespielt werden soll. Der dritte häufige Fehler ist technisch trivial, aber folgenreich: Hreflang-Angaben, die auf weitergeleitete oder nicht mehr existierende URLs zeigen, weil eine URL-Struktur geändert wurde, ohne die Hreflang-Referenzen mit zu aktualisieren.

Wie hängen Hreflang und Duplicate Content zusammen?

Ein verbreitetes Missverständnis ist, dass Hreflang Duplicate-Content-Probleme automatisch löst. Das stimmt nur bedingt: Hreflang sagt Google, welche Version für welche Zielgruppe gedacht ist, verhindert aber nicht, dass inhaltlich nahezu identische Seiten in verschiedenen Sprachen als schwaches Signal für die jeweilige Domain wahrgenommen werden, wenn keine echte lokale Differenzierung stattfindet. Bei international tätigen Unternehmen mit 85 Franchiseländern, wie es bei meiner Arbeit für Sixt der Fall war, ist echte länderspezifische Differenzierung - unterschiedliche Keyword-Strategien, lokale Linkaufbau-Maßnahmen, eigene redaktionelle Inhalte pro Markt - der eigentliche Erfolgsfaktor, nicht nur die technisch korrekte Hreflang-Implementierung allein. Mehr zur Gesamtstrategie in der Case Study Sixt.

Welche Rolle spielt automatisierte Sprach-Weiterleitung, und warum ist sie riskanter als sie klingt?

Viele Websites versuchen, Besucher:innen anhand von Browsersprache oder IP-Standort automatisch auf die “passende” Länderversion umzuleiten. Aus Nutzersicht wirkt das komfortabel, aus SEO-Sicht ist es riskant: Automatisierte Weiterleitungen können verhindern, dass Googlebot überhaupt alle Länderversionen einer Seite crawlen kann, weil der Bot selbst konsequent auf eine einzelne Version umgeleitet wird. Die robustere Lösung ist, Nutzer:innen initial auf die anhand ihrer Signale wahrscheinlichste Version zu leiten, ihnen aber jederzeit eine klar sichtbare, manuelle Wechselmöglichkeit zu anderen Sprach- und Länderversionen anzubieten - und Googlebot selbst von automatischen Weiterleitungen komplett auszunehmen, damit er alle Versionen unabhängig crawlen kann.

Sitemap oder HTML-Head: Wo sollte Hreflang implementiert werden?

Beide Methoden sind von Google offiziell gleichwertig unterstützt, in der Praxis unterscheiden sie sich aber deutlich in der Wartbarkeit. HTML-Head-Implementierung bedeutet, dass jede einzelne Seite alle Referenzen zu allen anderen Sprachversionen im eigenen Quellcode enthalten muss - bei großen, mehrsprachigen Websites ein erheblicher Wartungsaufwand und eine häufige Fehlerquelle bei Templateänderungen. Sitemap-basierte Implementierung zentralisiert diese Information dagegen an einer Stelle und lässt sich deutlich einfacher automatisiert validieren und pflegen. Bei Websites mit mehr als einer Handvoll Sprachversionen empfehle ich fast immer die Sitemap-Variante, allein aus Wartungsgründen.

Wie testet man Hreflang zuverlässig, bevor Probleme live auffallen?

Die Google Search Console bietet einen eigenen internationalen Targeting-Bericht, der fehlende Rückverknüpfungen und andere strukturelle Probleme anzeigt - allerdings mit spürbarer Verzögerung. Für den produktiven Alltag lohnt sich zusätzlich ein automatisiertes Validierungsscript, das bei jedem Deployment prüft, ob alle Hreflang-Referenzen einer Seite tatsächlich reziprok sind und auf finale, nicht weitergeleitete URLs zeigen. Diese Art von technischer Absicherung direkt im Deployment-Prozess spart in der Praxis deutlich mehr Aufwand, als im Nachhinein Fehler in tausenden Seiten zu identifizieren und zu korrigieren.

Wie sollte eine internationale URL-Struktur grundsätzlich aufgebaut sein?

Es gibt drei gängige Ansätze: separate Länder-Domains (etwa .de, .fr, .es), Subdomains (de.example.com) oder Unterverzeichnisse (example.com/de/). Für die meisten Unternehmen ohne eigenständige lokale Rechtseinheiten pro Land sind Unterverzeichnisse die pragmatischste Lösung: Sie bündeln die gesamte Domain-Autorität an einer Stelle, statt sie auf viele einzelne Domains zu verteilen, die jede für sich neues Vertrauen aufbauen müssten. Separate Domains lohnen sich in der Regel nur, wenn dahinter tatsächlich unterschiedliche rechtliche Einheiten, Angebote oder Marktpositionierungen stehen.

Welche organisatorische Herausforderung unterschätzen Unternehmen bei internationalem SEO am meisten?

Die technische Seite von Hreflang ist lösbar - die eigentliche Herausforderung ist organisatorisch: Wer verantwortet die Konsistenz über zwölf Kernländer und 85 Franchiseländer hinweg, wenn lokale Teams eigenständig Inhalte pflegen? Bei Sixt lag der Schlüssel in einem international geführten 12-köpfigen Team mit klaren, zentral vorgegebenen Guidelines, die trotzdem genug Raum für lokale Keyword- und Linkstrategien pro Markt ließen. Ohne diese zentrale Koordination driften internationale SEO-Strukturen über Zeit fast zwangsläufig auseinander, weil jedes lokale Team seine eigenen, untereinander inkonsistenten Lösungen entwickelt.

Welche Rolle spielt x-default bei der Hreflang-Implementierung?

Das Attribut x-default definiert, welche Version einer Nutzerin oder einem Nutzer angezeigt werden soll, deren Sprache oder Standort keiner der explizit definierten Versionen entspricht - etwa Besucher:innen aus einem Land, für das keine eigene lokale Version existiert. In der Praxis wird x-default am häufigsten vergessen oder falsch auf eine beliebige Sprachversion statt auf eine echte internationale Startseite gesetzt. Bei international tätigen Unternehmen mit vielen Länderversionen empfiehlt sich eine dedizierte, sprachneutrale oder englischsprachige x-default-Seite, die Nutzer:innen aktiv zur Auswahl ihrer bevorzugten Länderversion einlädt, statt sie unkommentiert in eine zufällige lokale Version zu leiten, die sprachlich nicht zu ihnen passt.

Was passiert, wenn Hreflang und Canonical-Tags widersprüchliche Signale senden?

Ein besonders folgenreicher, aber in der Praxis überraschend häufiger Fehler: Eine Seite verweist per Hreflang auf mehrere gleichwertige Länderversionen, während gleichzeitig ein Canonical-Tag auf eine einzelne dieser Versionen als “die eigentliche” Seite zeigt. Für Google sind das zwei widersprüchliche Anweisungen - das Ergebnis ist häufig, dass die Hreflang-Angaben komplett ignoriert werden und Google stattdessen der Canonical-Anweisung folgt, wodurch Länderversionen faktisch aus dem Index für ihre lokalen Suchanfragen verschwinden. Die Grundregel: Jede Sprach- oder Länderversion sollte selbstreferenzierend kanonisiert sein - sie zeigt per Canonical-Tag auf sich selbst, niemals auf eine andere Sprachversion. Dieser Fehler entsteht in der Praxis oft technisch unbeabsichtigt, etwa wenn ein CMS bei der Erstellung neuer Länderversionen automatisch das Canonical-Tag der Ursprungsseite übernimmt, statt es korrekt auf die neue URL anzupassen - ein Detail, das bei der technischen Abnahme neuer Länderversionen immer explizit geprüft werden sollte.

Wie testet man Hreflang besonders gründlich nach einem Website-Relaunch?

Ein Relaunch ist einer der häufigsten Auslöser für neue Hreflang-Fehler, weil sich URL-Strukturen, Templates und teils die gesamte technische Basis gleichzeitig ändern. Vor dem Go-Live sollte deshalb ein vollständiger Abgleich stattfinden: jede alte Hreflang-Referenz mit ihrer neuen Ziel-URL abgleichen, prüfen, ob alle Rückverknüpfungen im neuen System korrekt generiert werden, und sicherstellen, dass das neue Canonical-Tag-Verhalten nicht versehentlich mit den Hreflang-Angaben kollidiert. Besonders bei einem gleichzeitigen CMS-Wechsel - mehr dazu im Artikel SEO-Relaunch ohne Traffic-Verlust - lohnt sich ein dediziertes Test-Set für internationale URLs in der Staging-Umgebung, weil Hreflang-Fehler im Gegensatz zu klassischen 404-Fehlern selten unmittelbar sichtbar werden, sondern sich erst über Wochen als schleichender Sichtbarkeitsverlust einzelner Länderversionen zeigen.

Welche Tools eignen sich, um Hreflang-Fehler auf großen internationalen Websites laufend zu überwachen?

Neben dem internationalen Targeting-Bericht der Google Search Console lohnt sich bei großen mehrsprachigen Websites ein spezialisiertes Crawling-Tool, das Hreflang-Reziprozität automatisiert über die gesamte Website prüft, statt sich auf Stichproben zu verlassen. Wichtig dabei ist ein wiederkehrender, nicht nur einmaliger Prüfzyklus - idealerweise als fester Bestandteil des Deployment-Prozesses, damit neue Fehler durch Templateänderungen oder neue Länderversionen sofort auffallen, statt sich unbemerkt über Monate anzusammeln. Bei Websites mit zwölf oder mehr Länderversionen, wie im Sixt-Beispiel, ist manuelle Stichprobenkontrolle allein nicht mehr praktikabel - die schiere Anzahl möglicher Kombinationen macht automatisierte, regelmäßige Prüfungen zur einzig verlässlichen Methode, um die Konsistenz dauerhaft sicherzustellen.

Was hat das mit Crawl-Budget bei sehr großen internationalen Websites zu tun?

Bei Websites mit vielen Länder- und Sprachversionen multipliziert sich das Problem des Crawl-Budgets: Jede zusätzliche Sprachversion einer Seite ist eine weitere URL, die Googlebot crawlen muss. Wenn zusätzlich noch fehlerhafte Hreflang-Referenzen auf weitergeleitete oder doppelte Inhalte verweisen, verschwendet das zur Verfügung stehende Crawl-Budget zusätzlich. Mehr zum Thema im Artikel Crawl-Budget bei Millionen-Seiten-Websites und auf der Kompetenz-Seite Internationales SEO.