Hreflang: Praxisleitfaden zur mehrsprachigen SEO

Sie suchen in Vietnam nach einer Marke und Google öffnet die englische Seite. Ein Besucher in den USA landet gelegentlich bei vietnamesischen Inhalten. Beide Seiten sind indexiert und ihre Canonicals scheinen korrekt. Wo liegt die falsche Zuordnung?

Dann verdient hreflang Aufmerksamkeit. Es übersetzt keine Inhalte und verbessert allein keine Rankings. Es hilft Google zu verstehen, welche URLs sprachlich oder regional gleichwertig sind, damit die passendste Version für jeden Suchenden erscheint.

Was ist Hreflang?

hreflang kennzeichnet Beziehungen zwischen lokalisierten Versionen desselben Inhalts. Ein vietnamesischer und englischer Beitrag könnten Folgendes verwenden:

<link rel="alternate" hreflang="vi"
      href="https://example.com/blog/huong-dan-seo">
<link rel="alternate" hreflang="en"
      href="https://example.com/en/blog/seo-guide">
<link rel="alternate" hreflang="x-default"
      href="https://example.com/blog/huong-dan-seo">

Drei Unterscheidungen sind wichtig:

• Hreflang ist keine Kanonisierung;
• Google bestimmt die Seitensprache nicht allein anhand von Hreflang;
• ein /en/-Verzeichnis stellt die Beziehung nicht von selbst her.

Wann benötigt eine Website Hreflang?

Es hilft, wenn:

• dasselbe Thema vollständig übersetzt vorliegt;
• Inhalte dieselbe Sprache, aber unterschiedliche Regionen bedienen, etwa en-US und en-GB;
• Hauptinhalte ähnlich bleiben, während Navigation oder Unterstützung je Markt abweichen;
• Preise, Währung, Versand oder Bestände eines Onlineshops nach Land variieren.

Eine einsprachige Website gewinnt nichts durch dekoratives Hreflang. Seiten mit völlig unterschiedlichen Themen können eigenständig statt Alternativversionen sein.

Drei Umsetzungsmethoden

Methode 1: HTML-Tags im Kopfbereich

Auf HTML-Websites ist das leicht prüfbar. Jede Version nennt sich selbst und alle anderen.

Auf der vietnamesischen Seite:

<link rel="alternate" hreflang="vi" href="https://example.com/bai-viet">
<link rel="alternate" hreflang="en" href="https://example.com/en/article">

Die englische Seite benötigt denselben Satz. Verweist EN auf VI, aber VI nicht zurück, fehlt die Rückbeziehung.

Methode 2: HTTP-Header

Header eignen sich für PDFs und andere Dokumente ohne HTML-Kopfbereich:

Link: <https://example.com/guide.pdf>; rel="alternate"; hreflang="vi",
      <https://example.com/en/guide.pdf>; rel="alternate"; hreflang="en"

Methode 3: XML-Sitemaps

Jede URL enthält xhtml:link-Unterelemente für jede Version einschließlich sich selbst. Das skaliert auf Tausende Seiten, erschwert aber die manuelle Dateiprüfung.

Google betrachtet alle drei Methoden als gleichwertig. Alle zu nutzen bringt keinen Rankingbonus und schafft mehr Möglichkeiten für Widersprüche. Wählen Sie die zuverlässig pflegbare Quelle.

Sprach- und Regionalcodes

Die Sprache verwendet ISO 639-1, die optionale Region ISO 3166-1 Alpha 2:

• vi: Vietnamesisch ohne regionale Einschränkung;
• en: allgemeines Englisch;
• en-US: Englisch für die USA;
• en-GB: Englisch für Großbritannien;
• fr-CA: Französisch für Kanada.

Verwenden Sie keinen Ländercode wie US allein. Die erste Komponente ist immer eine Sprache. Großschreibung ist meist nicht das Kernproblem, doch kleine Sprach- und große Regionalcodes verbessern die Lesbarkeit.

Was bewirkt x-default?

x-default nennt eine Ausweichversion, wenn keine Sprache oder Region zum Besucher passt. Besonders hilfreich ist es für:

• Länderauswahlseiten;
• Startseiten mit Aufforderung zur Sprachauswahl;
• eine globale Standardversion.

Bei nur VI und EN kann die Hauptsprache x-default sein. Verwenden Sie x-default nicht statt einer tatsächlichen Sprachanweisung: Es ergänzt vi oder en.

Wie Canonical und Hreflang zusammenarbeiten

Jede lokalisierte Seite sollte sich selbst oder eine kanonische URL derselben Sprache als Canonical nennen.

Eine schlüssige Konfiguration:

• /bai-viet kanonisiert auf /bai-viet;
• /en/article kanonisiert auf /en/article;
• beide Seiten sind per Hreflang verbunden.

Eine widersprüchliche Konfiguration:

• /en/article kanonisiert auf /bai-viet;
• beide werden zugleich als Sprachalternativen angegeben.

Canonical fordert Google auf, EN in VI zusammenzuführen, während Hreflang beide für die Sprachausrichtung erhalten möchte.

Sieben häufige Hreflang-Probleme

1. Fehlende Rückverweise

A verweist auf B, B aber nicht zurück. Erzeugen Sie Angaben aus einer einzigen Übersetzungsdatenquelle statt manuell in jeder Vorlage.

2. Alternative URLs leiten weiter oder liefern 404

Hreflang sollte die endgültige gültige URL nennen. Aktualisieren Sie nach Migrationen Routen, Canonicals und Alternativverweise gemeinsam.

3. Nur die Navigation ist übersetzt

Bleibt der Haupttext in der Ursprungssprache, kann Google die Seiten als Duplikate statt echte Übersetzungen betrachten. Übersetzen Sie Titel, Überschriften, Haupttext, Alt-Texte und wichtige Daten.

4. Jede Version besitzt einen anderen Satz

VI nennt VI/EN/JP, EN dagegen nur VI/EN. Alle Mitglieder einer Gruppe benötigen denselben Beziehungssatz.

5. Relative URLs

Verwenden Sie absolute URLs mit Protokoll und Hostnamen. So vermeiden Sie Unklarheiten über Domains und Subdomains hinweg.

6. Alternativverweise führen zu Noindex-Seiten

Eine Seite mit Noindex, Sperre oder Canonical zu einer anderen URL ist keine nützliche Alternative. Nehmen Sie nur indexierbare URLs auf.

7. Jede englische Seite führt zur vietnamesischen Startseite

Alternativversionen müssen gleichwertig sein. Ein englisches Produkt gehört zum entsprechenden vietnamesischen Produkt, nicht zu Startseite oder ungefähr passender Kategorie.

Daten für dauerhaft korrektes Hreflang gestalten

Leiten Sie Übersetzungen bei unterschiedlichen Slugs nicht durch Ersetzen von /en/ in der URL ab. Speichern Sie eine Übersetzungsgruppe:

Laden Sie beim Rendern sämtliche Gruppendatensätze. Dieselbe Quelle kann Sprachumschalter, Sitemap-Angaben und Berichte über fehlende Übersetzungen versorgen.

Existiert eine Übersetzung nicht, verweisen Sie nicht auf die Startseite. Geben Sie nur echte indexierbare Sprachversionen aus.

Prüfung vor der Veröffentlichung

HTML-Quelltext untersuchen

Verwenden Sie den Seitenquelltext oder Meta Tag Checker, nicht nur den JavaScript-gerenderten DOM. Prüfen Sie Canonical, lang und jede Alternative.

Beide Richtungen überprüfen

Öffnen Sie jede Gruppen-URL. Jede Seite muss sich selbst und alle anderen nennen. Bei drei Sprachen enthalten alle drei Seiten dieselben drei Alternativen sowie gegebenenfalls x-default.

Status und Indexierbarkeit prüfen

Jede URL liefert 200, hat kein Noindex, ist crawlbar und nennt einen Canonical derselben Sprache. Nutzen Sie nach URL-Migrationen den Redirect Chain Checker.

Tatsächliche Lokalisierung der Inhalte bestätigen

Titel, H1, Haupttext, CTA und FAQs sollten die Zielsprache verwenden. Eine übersetzte Vorlage um einen unübersetzten Beitrag ist keine mehrsprachige Erfahrung.

Search Console beobachten

Prüfen Sie nach Veröffentlichung die URL-Prüfung und Leistung nach Land und Seite. Hreflang unterstützt die Auswahl, doch Google kann bei widersprüchlichen Inhalten oder Canonicals anders entscheiden.

Verbessert Hreflang Rankings?

Nicht im Sinne eines Positionsgewinns allein durch zusätzliche Tags. Sein Wert liegt darin, Einstiege in der falschen Sprache zu verhindern, Signale je Version auszurichten und die Sucherfahrung zu verbessern.

Eine dünne englische Seite wird nicht allein durch die Paarung mit einem starken vietnamesischen Beitrag maßgeblich. Jede Version benötigt nützliche Inhalte, interne Links und eigene Metadaten.

Hreflang ohne websiteweiten Vorfall einführen

Behandeln Sie Hreflang wie eine Datenmigration statt Vorlagendekoration. Beginnen Sie mit einer Inhaltsgruppe, deren Übersetzungen vollständig und redaktionell geprüft sind. Kontrollieren Sie die Zuordnung der Gruppenschlüssel zu den vorgesehenen URLs und veröffentlichen Sie diese Gruppe vor der Erweiterung.

Eine sichere Einführung hat vier Phasen:

1. Bestandsaufnahme: Alle indexierbaren URLs mit Sprache, Canonical, Status und Übersetzungsgruppenschlüssel erfassen.
2. Vollständigkeit: Gruppen mit fehlenden Übersetzungen oder doppelten Sprachdatensätzen markieren.
3. Pilot: Angaben für einen stabilen Bereich veröffentlichen und jedes Mitglied crawlen.
4. Erweiterung: Weitere Bereiche erst aufnehmen, wenn Rückverweise und Search-Console-Verhalten unauffällig bleiben.

Bauen Sie automatische Prüfungen um die Datenquelle. Eine Bereitstellung sollte scheitern, wenn eine Gruppe zwei englische URLs enthält, eine Alternative weiterleitet oder eine lokalisierte Seite auf eine andere Sprache kanonisiert. Das ist zuverlässiger als Fehler erst nach Googles Crawling zu finden.

Planen Sie auch den Inhaltslebenszyklus. Wird der vietnamesische Beitrag aktualisiert, während Englisch noch aussteht, entscheiden Sie, ob beide Versionen nützlich bleiben. Hreflang verlangt keine Wort-für-Wort-Identität, aber gleichwertige Antworten. Wird eine Version veraltet, entfernen Sie sie aus allen Gruppenmitgliedern und liefern Sie einen passenden Status oder eine Weiterleitung.

Sprachumschalter sollten dieselbe Zuordnung verwenden. Führt der Umschalter Nutzer zu einer anderen URL als Hreflang die Crawler, ist das Datenmodell bereits auseinandergefallen. Eine gemeinsame Übersetzungsquelle für Umschalter, Head-Tags und Sitemap reduziert solche Abweichungen.

Beobachten Sie schließlich nach Gruppen. Vergleichen Sie Impressionen, Einstiege in der falschen Sprache und ausgewählte Canonicals im Pilotbereich. Einige Wochen stabilen Verhaltens sind aussagekräftiger als ein reiner Syntaxvalidator.

Sprachwahl der Besucher respektieren

Hreflang hilft Suchmaschinen bei der Zielseitenauswahl, doch die Website benötigt weiterhin einen bedienbaren Sprachumschalter. Erzwingen Sie keine Sprache allein anhand der IP-Adresse. Vietnamesischsprachige Reisende möchten vielleicht Vietnamesisch lesen, englischsprachige Kunden in Vietnam dagegen Englisch.

Bieten Sie bei automatischer Erkennung einen Vorschlag statt einer unumkehrbaren Weiterleitung. Halten Sie jede Sprach-URL direkt zugänglich, vermeiden Sie Schleifen zwischen Länder- und Sprachlogik und speichern Sie eine ausdrückliche Auswahl in einem angemessenen Cookie.

Der Umschalter sollte zur gleichwertigen Seite führen, nicht nur zur lokalisierten Startseite. Fehlt eine Übersetzung, weisen Sie darauf hin oder bieten Sie eine klare Alternative, statt die Startseite als dieselbe Ressource auszugeben. Das schützt Vertrauen und hält die Hreflang-Zuordnung korrekt.

Testen Sie Sprach-URLs in einer neuen Sitzung und prüfen Sie tatsächliche Weiterleitungen, Canonical und Hreflang. Ein öffentlicher Cloudflare-Check simuliert weder Cookies noch Accept-Language-Varianten.

Vor dem Eintritt in einen weiteren Markt: Prüfen Sie mit einem kostenlosen SEO-Audit Canonicals, Indexierbarkeit und Metadaten über VI-/EN-Routen hinweg.

Fazit

Hreflang funktioniert, wenn Übersetzungen in Daten gruppiert sind, jede URL sich selbst nennt, Seiten gegenseitig zurückverweisen und Canonicals widerspruchsfrei bleiben. Eine korrekte Konfiguration ist fast unsichtbar, verhindert aber einen sehr sichtbaren Fehler: richtige Inhalte vor dem falschen Publikum.

Quelle: Google Search Central – Localized versions.