Hreflang-Leitfaden: Syntax, Fehler und Best Practices

Hreflang (auch 'rel=alternate hreflang' genannt) ist ein HTML-Link-Attribut, das Suchmaschinen mitteilt, welche Sprach- und Regionsversion einer Seite in den Ergebnissen welcher Suchenden angezeigt werden soll. Es wurde 2011 von Google eingeführt, um das Duplicate-Content-Problem mehrsprachiger Websites zu lösen: Wenn Sie eine englische und eine spanische Seite mit demselben Inhalt haben, kann Google eine als Duplikat der anderen behandeln und nur eine indexieren. Hreflang sagt Google: 'Dies sind beabsichtigte Alternates für unterschiedliche Zielgruppen – indexiere beide und leite Suchende entsprechend weiter.'

Ohne Hreflang könnte ein US-Suchender, der nach 'plumber near me' sucht, Ihre spanische Seite sehen (weil Google sie für relevant für seine Anfrage hält) – und sofort abspringen, weil er kein Spanisch liest. Mit korrektem Hreflang zeigt Google dem US-Suchenden Ihre englische Seite und einem Suchenden in Mexiko Ihre spanische Seite. Das Ergebnis: besseres Engagement, höhere Conversion und keine Kannibalisierung zwischen Locales.

Hreflang ist am wichtigsten für: mehrsprachige Dienstleistungsunternehmen (Migrantengemeinschaften, grenzüberschreitende Fachkräfte), internationalen E-Commerce und jede Website, die denselben Inhalt in mehreren Sprachen veröffentlicht. Wenn Ihre Website nur ein Locale hat, ist Hreflang unnötig – Google handhabt das auch ohne das Attribut korrekt.

Hreflang verwendet das Link-Attribut rel=alternate mit einem hreflang-Wert. Der Wert kombiniert einen ISO-639-1-Sprachcode mit einem optionalen ISO-3166-1-Alpha-2-Regionscode. Beispiele: en (Englisch, beliebige Region), en-US (Englisch Vereinigte Staaten), zh-CN (Chinesisch vereinfacht, Festlandchina), zh-TW (Chinesisch traditionell, Taiwan), es-MX (Spanisch Mexiko), fil-PH (Filipino Philippinen).

Kritisch: Regionscodes sind case-sensitive. zh-CN ist korrekt; zh-cn oder zh-cN nicht. Google ignoriert falsche Groß-/Kleinschreibung stillschweigend. Verwenden Sie Regions-Subtags immer in Großbuchstaben gemäß ISO-Standard.

Eine vollständige Hreflang-Implementierung erfordert drei Bestandteile auf jeder Seite: (1) ein selbstreferenzielles Hreflang-Tag (die Seite deklariert ihr eigenes Locale), (2) ein Hreflang-Tag für jede andere Locale-Version (die Alternates) und (3) ein x-default-Tag, das auf das Locale verweist, das angezeigt werden soll, wenn kein Alternate zum Suchenden passt. Fehlt einer dieser Bestandteile, ist die Implementierung fehlerhaft.

Jedes Alternate muss bidirektional sein. Wenn Seite A (Englisch) Seite B (Chinesisch) als ihr Alternate deklariert, muss Seite B Seite A als ihr Alternate deklarieren. Fehlende Return-Tags sind der häufigste Hreflang-Fehler – Google ignoriert beide Richtungen, wenn eine fehlt.

Fehler 1 – Falsche Groß-/Kleinschreibung des Locale-Codes. zh-cn statt zh-CN, fil-ph statt fil-PH. Google ignoriert falsch geschriebene Tags stillschweigend. Lösung: Regions-Subtags immer in Großbuchstaben.

Fehler 2 – Fehlende Return-Tags. Seite A deklariert Seite B als Alternate, aber Seite B deklariert Seite A nicht. Lösung: Jedes Alternate muss bidirektional sein; wenn Sie ein neues Locale hinzufügen, aktualisieren Sie alle bestehenden Seiten, damit sie es zurückdeklarieren.

Fehler 3 – Fehlendes oder falsches x-default. Ohne x-default rät Google, welches Locale nicht zugeordneten Suchenden angezeigt werden soll; meist wählt es Ihr am besten indexiertes Locale, was nicht unbedingt gewünscht ist. Lösung: Deklarieren Sie x-default explizit (meist mit Verweis auf Ihr primäres Geschäfts-Locale).

Fehler 4 – Hreflang-URLs, die nicht mit canonical URLs übereinstimmen. Wenn /pricing canonical /pricing hat, aber sein Hreflang auf /pricing?utm_source=internal verweist, ignoriert Google das Alternate. Lösung: Hreflang-URLs müssen zeichengenau mit canonical URLs übereinstimmen.

Fehler 5 – Hreflang auf noindex- oder weg-canonicalisierten Seiten. Seiten, die von der Indexierung ausgeschlossen sind, sollten kein Hreflang deklarieren. Lösung: Lassen Sie Hreflang-Tags auf noindex-Routen, weitergeleiteten Routen und Seiten weg, die auf andere URLs canonicalisiert sind.

Fehler 6 – Hreflang auf Soft-404- oder 'Locale nicht verfügbar'-Seiten. Deklarieren Sie kein Alternate-URL, das eine Meldung wie 'Leider ist diese Seite in Ihrer Sprache nicht verfügbar' zurückgibt – das ist ein Soft 404 und Google bestraft beide Richtungen. Lösung: Deklarieren Sie nur Alternates, die echten Inhalt enthalten; wenn eine Seite in einem Locale nicht existiert, deklarieren Sie dieses Locale nicht als Alternate.

Fehler 7 – Inkonsistente Locale-Varianten über Seiten hinweg. Seite A deklariert die Locales en, zh-CN, es, aber Seite B deklariert nur en und zh-CN. Inkonsistenz verwirrt Google. Lösung: Jede Seite, die in mehreren Locales existiert, sollte alle Locales deklarieren, in denen sie existiert – und keine, in denen sie nicht existiert.

Schritt 1 – Untersuchen Sie das gerenderte HTML. Zeigen Sie den Quelltext einer mehrsprachigen Seite an und prüfen Sie den Head-Bereich auf link rel=alternate-Tags. Sie sollten ein selbstreferenzielles Tag, ein Tag pro Alternate-Locale und ein x-default-Tag sehen. Überprüfen Sie Groß-/Kleinschreibung, URL-Übereinstimmung und bidirektionale Tags.

Schritt 2 – Google Search Console. Unter International Targeting > Country meldet Google Hreflang-Fehler, die es auf Ihrer Website findet. Häufige Fehler: fehlende Return-Tags, falsche Locale-Codes, defekte Alternate-URLs. Beheben Sie jeden von Google gemeldeten Fehler.

Schritt 3 – Crawl mit Ahrefs oder Sitebulb. Diese Tools erkennen Hreflang-Probleme in großem Maßstab – Bidirektionalitätskonflikte über Tausende von Seiten, defekte Alternates, falsche Locale-Codes. Führen Sie vierteljährlich einen vollständigen Website-Crawl durch.

Schritt 4 – Manueller SERP-Test. Suchen Sie Ihren Markennamen von verschiedenen locale-spezifischen Geräten aus (verwenden Sie ein VPN oder Googles länderspezifische Domains wie google.com.hk für Hongkong) und prüfen Sie, ob die richtige Locale-Version erscheint. Wenn Sie Locale-Kannibalisierung sehen (falsche Version rankt in der falschen Region), ist Hreflang wahrscheinlich die Ursache.

Schritt 5 – Prüfen Sie die Indexierung in der Search Console. Verwenden Sie URL Inspection für jede Locale-Version einer Seite, um zu bestätigen, dass Google alle Alternates indexiert hat. Wenn eine Locale-Version nicht indexiert ist, gibt Hreflang das Signal nicht korrekt weiter.

Bewährte Praxis 1 – Verwenden Sie reine Sprachcodes (en, zh, es), wenn Sie keine regionsspezifischen Inhalte haben. Verwenden Sie Regionscodes (en-US, en-GB, zh-CN, zh-TW) nur, wenn sich der Inhalt tatsächlich nach Region unterscheidet (Währung, rechtliche Hinweise, Wortschatz). Eine Über-Spezifizierung von Regionscodes bei identischem Inhalt erzeugt unnötige Alternates.

Bewährte Praxis 2 – Setzen Sie x-default auf Ihr primäres Geschäfts-Locale (meist das Locale des Heimatlandes Ihres Unternehmens). Für ein US-Unternehmen: x-default = en oder en-US. Für ein chinesisches Unternehmen mit englischer Version: x-default = zh-CN, wenn Ihre Hauptzielgruppe chinesisch ist, en, wenn international.

Bewährte Praxis 3 – Generieren Sie Hreflang aus einer einzigen Quelle der Wahrheit (Ihr CMS oder Website-Builder). Die manuelle Pflege von Hreflang über Tausende von Seiten garantiert Drift. Cogo Site, WordPress + WPML und die mehrsprachigen Funktionen von Shopify generieren Hreflang automatisch; wählen Sie einen Builder, der das tut.

Bewährte Praxis 4 – Halten Sie Hreflang-URLs sauber und stabil. Fügen Sie keine Query-Parameter, Session-IDs oder Tracking-Parameter in Hreflang-URLs ein. Sobald eine Alternate-URL veröffentlicht ist, ändern Sie sie nicht ohne Weiterleitung – Googles Hreflang-Cache braucht Wochen, um sich neu aufzubauen.

Bewährte Praxis 5 – Prüfen Sie Hreflang nach jedem Locale-Launch, jeder Locale-Entfernung oder größeren Inhaltsmigration. Drift passiert; Hreflang ist der Kanarienvogel im Kohlenbergwerk für die Gesundheit mehrsprachiger Websites.

Cogo Site generiert Hreflang aus einer einzigen Quelle der Wahrheit – dem locale-präfixierten URL-Routing. Jede Seite enthält automatisch selbstreferenzielle, Alternate- und x-default-Tags mit korrekter ISO-Schreibweise, bidirektionalen Return-Tags und canonical-konformen URLs. Sie schreiben die Tags nicht; Sie pflegen sie nicht.

Das Hinzufügen eines Locales regeneriert Hreflang über alle Seiten atomar – es gibt kein Fenster, in dem bestehenden Seiten das neue Alternate fehlt. Das Entfernen eines Locales entfernt Hreflang zu diesem Locale sauber aus allen Seiten und verhindert Soft-404s.

Die Locale-Sichtbarkeit pro Seite ermöglicht es Ihnen, eine Seite als nur-englisch oder nur-chinesisch zu markieren – Hreflang deklariert nur Alternates, wo beide existieren, und verhindert so den Fehler 'Soft-404-Alternate'.

Das x-default-Locale ist pro Website konfigurierbar und standardmäßig das ursprüngliche Veröffentlichungs-Locale. Hreflang-URLs werden aus demselben Routing wie canonical URLs abgeleitet und können daher nicht driften.