Wie Google hreflang und lokalisierte Versionen offiziell erklärt

Veröffentlichungsdatum:13-09-2026
Autor:Eyingbao
Aufrufe:
  • Wie Google hreflang und lokalisierte Versionen offiziell erklärt
Die offizielle Erläuterung von Google Search Central zu hreflang und lokalisierten Versionen für mehrsprachige und mehrregionale Websites: Beherrschen Sie Sprach- und Regionscodes, wechselseitige Verweise, die Abstimmung mit canonical sowie die x-default-Konfiguration, um doppelte Inhalte und fehlerhafte Weiterleitungen zu vermeiden und die Sichtbarkeit internationaler Websites in der Suche zu erhöhen.
Sofort anfragen : 4006552477

Die Hinweise von Google Search Central zu mehrsprachigen und länderspezifischen Websites laufen auf eine zentrale Beurteilung hinaus: Das Suchsystem muss erkennen, für welche Sprach- oder Regionszielgruppe jede URL bestimmt ist, und bestätigen können, dass diese Seiten gleichwertige lokalisierte Versionen sind – und nicht mehrere Kopien, die durch doppelte Inhalte, automatische Weiterleitungen oder unübersichtliche Parameter entstehen.hreflang ist ein Signal zur Deklaration alternativer Versionen gegenüber Suchmaschinen, keine Anweisung für die Indexierung, das Ranking oder die erzwungene Umschaltung von Seiten.

Daher sollte vor der Implementierung nicht zuerst gefragt werden, „welche Sprachcodes hinzugefügt werden müssen“, sondern zunächst die Beziehung zwischen den Seiten geklärt werden. Wenn englische, deutsche und japanische Produktseiten jeweils unterschiedliche sprachliche Leseanforderungen bedienen und das Hauptprodukt, die Funktionsbeschreibung sowie der Conversion-Pfad einander entsprechen, ist die Einrichtung einer hreflang-Beziehung angemessen. Entstehen dagegen mehrere URLs für dieselbe Sprachseite lediglich durch Werbetracking-Parameter, Filterkriterien, Seitennummerierung oder Sitzungskennungen, sollten sie nicht gegenseitig als lokalisierte Versionen ausgezeichnet werden.

Was unter einer „lokalisierten Version“ im Sinne der offiziellen Dokumentation zu verstehen ist

Lokalisierung ist nicht gleichbedeutend mit mechanischer Übersetzung. Die entsprechenden Google-Dokumente unterscheiden zwischen Sprachversionen und Regionsversionen: Sprachversionen beantworten die Frage, „in welcher Sprache eine Seite formuliert ist“, Regionsversionen die Frage, „für welches Land oder welche Region dieselbe Sprache bestimmt ist“. Beispielsweise können englische Seiten für die USA und das Vereinigte Königreich beide en verwenden. Bestehen jedoch wesentliche Unterschiede bei Währung, Liefergebiet, Steuerhinweisen, Kontaktdaten, Lagerbestand, Spezifikationen oder rechtlichen Hinweisen, können jeweils en-US und en-GB verwendet werden.

Umgekehrt führt eine erzwungene Aufteilung nach Ländern nicht zwangsläufig zu einem klareren Signal, wenn zwei Seiten hinsichtlich Inhalt, Preis und Servicebedingungen vollständig identisch sind und sich nur Domain oder Pfad unterscheiden. Der Regionscode sollte tatsächliche Unterschiede bei Inhalten oder Leistungen widerspiegeln, statt allein auf Grundlage geplanter Zielmärkte zahlreiche ähnliche Seiten zu erstellen. Bei B2B-Websites entscheiden Produktparameter, Mindestbestellmengen, Felder im Anfrageformular und der Lieferumfang häufig darüber, ob eine Seite tatsächlich einer anderen Marktversion zuzuordnen ist; bei grenzüberschreitenden Onlineshops stellen Währung, verfügbare Verkaufsregionen und Logistikregeln leichter erkennbare Lokalisierungsunterschiede dar.

Google betont außerdem, dass der sichtbare Haupttext einer Seite mit der deklarierten Sprache übereinstimmen muss. Werden nur Navigation, Footer oder einzelne Button-Texte ersetzt, während die Hauptbeschreibung, technische Unterlagen und Kaufinformationen in einer anderen Sprache bleiben, entsteht keine verlässliche Sprachversion. Die Sprachbestimmung für Suchergebnisse basiert hauptsächlich auf dem Seiteninhalt. Das Attribut lang hilft Browsern und assistiven Technologien beim Verständnis des Dokuments, kann jedoch keinen lesbaren Haupttext in der Zielsprache ersetzen.

Die drei Voraussetzungen für hreflang

Erstens muss die Alternativbeziehung beidseitig geschlossen sein. Wenn Seite A erklärt, dass B ihre deutsche Version ist, sollte Seite B auch erklären, dass A ihre englische Version ist. Fehlt der Rückverweis, kann das Suchsystem nur schwer bestätigen, dass es sich um eine gepflegte Zuordnung handelt. Mehrere Sprachversionen sollten sich innerhalb derselben Gruppe gegenseitig referenzieren, und jede Seite muss einen eigenen hreflang-Eintrag enthalten. Der Selbstverweis ist keine Dekoration; er sorgt dafür, dass jede URL einheitlich der zugehörigen Sprachgruppe zugeordnet wird.

Zweitens müssen gültige Sprach- und Regionskombinationen verwendet werden. Der Sprachanteil verwendet ISO-639-1-Codes wie de, ja und zh; der Regionsanteil verwendet ISO-3166-1-Alpha-2-Codes wie DE, JP und CN. Die Sprache steht vorn, die Region dahinter, verbunden durch einen Bindestrich. de-DE kann Deutsch für Deutschland bezeichnen, während de Deutsch ohne regionale Einschränkung bezeichnet. Werden Ländercodes allein als Sprachcodes verwendet, benutzerdefinierte Markt-Abkürzungen eingesetzt oder Sprache und Region vertauscht, verliert die Deklaration ihre beabsichtigte Bedeutung.

Drittens muss die Ziel-URL eine für Nutzer und Crawler zugängliche kanonische Seite sein. Verweist hreflang auf eine URL, die weiterleitet, einen Fehler zurückgibt, durch robots-Regeln am Crawling gehindert wird oder deren canonical auf eine andere Adresse verweist, entstehen widersprüchliche Signale. Häufiger Überarbeitungsbedarf tritt nach dem Go-live auf: Das Content-Team ändert den Pfad einer Produktseite, während die Entwicklung die alte Sprachzuordnung beibehält; oder ein Shop leitet nach einer regionalen Bestandsumschaltung nicht verfügbare Seiten auf die Startseite weiter. Solche Änderungen zerstören die ursprüngliche Alternativgruppe.

Wie Google hreflang und lokalisierte Versionen offiziell erklärt

Drei Implementierungsmethoden – wählen Sie eine, die stabil gepflegt werden kann

Google unterstützt das Hinzufügen von <link rel="alternate" hreflang="..." href="..."> im <head> von HTML, außerdem die Übermittlung über HTTP-Antwortheader oder in einer XML-Sitemap. Alle drei Methoden beschreiben dieselbe Art von Beziehung; in der Regel genügt es, die Methode zu wählen, die am besten zur Veröffentlichungsarchitektur passt. Bei gewöhnlichen HTML-Seiten lassen sich head-Tags bequem aus Seitentemplates erzeugen; nicht HTML-basierte Dokumente wie PDFs eignen sich besser für HTTP-Header; bei einer großen Zahl von Sprachversionen, die durch ein zentrales Content-System gepflegt werden, kann eine Sitemap wiederholte Ausgaben in Seitentemplates reduzieren.

Es wird nicht empfohlen, mehrere Quellen als Mechanismus zur gegenseitigen Fehlerbehebung zu behandeln. Stimmen die URL-Sets oder Codes in HTML, Sitemap und Antwortheadern nicht überein, fehlt bei der Fehleranalyse eine eindeutige Grundlage. Unabhängig von der gewählten Methode sollte eine Zuordnungstabelle auf Seitenebene als einzige zuverlässige Datenquelle dienen: Ursprüngliche URL, kanonische URL, Sprachcode, Regionscode, entsprechende Version und Status der Deaktivierung sollten synchron aktualisiert werden. Bei Produktabkündigungen, Katalogmigrationen oder Domainwechseln ist diese Zuordnungstabelle verlässlicher als ein vorübergehender Massenersatz von Code.

Rolle und Grenzen von x-default

x-default dient zur Angabe der Standardseite, wenn keine passendere Sprach- oder Regionsübereinstimmung vorhanden ist. Es wird häufig für Sprachwahlseiten, globale Einstiegsseiten oder Standardversionen verwendet, auf denen Besucher ihren Markt selbst auswählen können. Es ist kein festes Label für die „Startseite einer internationalen Website“ und sollte auch nicht die hreflang-Deklaration jeder konkreten Sprachseite ersetzen.

Besondere Vorsicht ist geboten, wenn Seiten mit automatischer Geolokalisierung als x-default gekennzeichnet werden. Google empfiehlt ausdrücklich, Crawler und Nutzer nicht anhand der IP-Adresse oder Browsersprache zwangsweise auf unterschiedliche Seiten umzuleiten. Automatische Weiterleitungen können Nutzern den Zugriff auf eine bestimmte URL erschweren und auch Crawler daran hindern, die Inhalte der einzelnen Versionen stabil abzurufen. Sicherer ist es, zugängliche Versions-URLs beizubehalten und auf der Seite eine sichtbare Möglichkeit zum Wechseln von Sprache oder Region bereitzustellen; Präferenzen sollten erst gespeichert werden, nachdem der Nutzer eine eindeutige Auswahl getroffen hat.

canonical und hreflang dürfen nicht unabhängig voneinander konfiguriert werden

canonical beantwortet die Frage, welche Version unter mehreren ähnlichen URLs bevorzugt wird; hreflang beantwortet die Frage, wie verschiedene Sprach- oder Regionsversionen einander zugeordnet sind. Beide werden häufig verwechselt. Selbst wenn eine englische und eine französische Seite dieselbe Struktur aufweisen, sollte die französische Seite nicht wegen ähnlicher Inhalte per canonical auf die englische Seite verweisen. Damit würde Suchmaschinen mitgeteilt, dass die französische Seite keine eigenständige bevorzugte Seite ist, was ihrer Deklaration als französische Alternativversion widerspricht.

Eine geeignetere Konfiguration ist: Jede Sprach- oder Regionsseite verwendet ein selbstreferenzierendes canonical, während hreflang sie mit anderen gleichwertigen Versionen verbindet. Nur wenn innerhalb derselben Sprachversion URL-Parameter, Groß- und Kleinschreibung, abschließende Schrägstriche, Druckversionen oder doppelte Pfade existieren, sollte innerhalb dieser Sprache ein canonical gewählt werden. Wenn zuerst die Kanonisierung bereinigt und anschließend die internationale Zuordnung aufgebaut wird, lässt sich vermeiden, Probleme bei der URL-Bereinigung fälschlich als Probleme von Sprachversionen zu behandeln.

Nach der Veröffentlichung zu beobachtende Signale

Die Überprüfung sollte nicht darauf beschränkt sein, ob die Tags im Quellcode erscheinen. Prüfen Sie zunächst stichprobenartig eine Seitengruppe: Gibt jedes href eine erfolgreich indexierbare Antwort zurück, führt es direkt zur endgültigen kanonischen URL, enthält die Seite einen Rückverweis und stimmen Sprachcode, Haupttext sowie Marktbedingungen überein? Prüfen Sie anschließend Sitemap, Template-Rendering und Caching-Schicht, um sicherzustellen, dass bei Zugriffen aus unterschiedlichen Regionen keine unterschiedlichen hreflang-Sets ausgegeben werden.

In Search Console können Auffälligkeiten im Zusammenhang mit internationaler Ausrichtung, entdeckte, aber nicht korrekt verarbeitete alternative Seiten sowie die Ergebnisse der Auswahl kanonischer Seiten zur Problemfindung genutzt werden. Hier müssen zwei Phänomene unterschieden werden: Wenn in den Suchergebnissen keine Seite für die Zielregion angezeigt wird, bedeutet dies nicht zwangsläufig, dass hreflang nicht funktioniert; Abfragesprache, Nutzerstandort, Seitenrelevanz und Indexierungsstatus beeinflussen ebenfalls die Anzeige. Wenn alternative Seiten hingegen langfristig nicht gecrawlt werden können, gegenseitige Verweise fehlen oder canonical auf sprachübergreifende Seiten verweist, sind dies Signale auf Konfigurationsebene, die vorrangig behoben werden müssen.

Der Wert von hreflang liegt darin, dass das Suchsystem weniger über die Beziehung zwischen Sprachversionen raten muss. Voraussetzung ist nicht eine ausreichend große Zahl von Tags, sondern dass URLs, Inhaltssprache, Kanonisierungsstrategie und der tatsächliche Leistungsumfang der Website auf dieselbe Tatsache verweisen.

Sofort anfragen

Verwandte Artikel

Verwandte Produkte