Jetzt Kontaktieren
Flags of different countries representing multilingual hreflang implementation for international SEO

Hreflang-Implementierung: Der vollständige Leitfaden für mehrsprachige SEO (2026)

Ihre deutschen Inhalte erscheinen in US-Suchergebnissen. Ihre amerikanischen Preise werden australischen Nutzern angezeigt. Ihre sorgfältig übersetzten spanischen Seiten konkurrieren miteinander, anstatt Mexiko und Spanien separat anzusprechen. Das sind Symptome einer fehlenden oder fehlerhaften Hreflang-Implementierung — und sie betreffen 75 % der internationalen Websites.

Hreflang ist ein HTML-Attribut, das Suchmaschinen mitteilt, welche Sprach- und Regionalversion einer Seite jedem Nutzer angezeigt werden soll. Es ist kein Ranking-Faktor — es ist eine Routing-Anweisung. Aber fehlerhaftes Routing zerstört die User Experience, fragmentiert Ihre SEO-Autorität über doppelte Seiten hinweg und kostet Sie Conversions in jedem Markt, den Sie erreichen möchten.

Dieser Leitfaden geht über die grundlegende Syntax hinaus. Wir behandeln CMS-spezifische Implementierung für WordPress, Shopify und Magento, die DACH-Markt-Komplexitäten, die die meisten Guides überspringen, Edge SEO Injection via Cloudflare Workers und ein Monitoring-Framework, um Probleme zu erkennen, bevor sie Ihre Rankings beeinträchtigen.

Was ist Hreflang und wie funktioniert es?

Hreflang (formal rel="alternate" hreflang="x") ist ein Attribut, das Google 2011 eingeführt hat, um Sprach- und Regions-Targeting zu signalisieren. Es teilt Google mit: „Diese Seite hat eine gleichwertige Version für ein anderes Publikum — zeige die richtige an.”

Zwei kritische Punkte vorab:

Punkt Bedeutung Praktische Auswirkung
Hreflang ist ein Signal, keine Direktive Google behandelt es als Hinweis — es kann Ihre Tags überschreiben, wenn andere Signale im Konflikt stehen Sie können Google nicht zwingen, eine bestimmte Version anzuzeigen; Ihre Tags müssen mit Canonical-Tags, internen Links und Content-Qualität übereinstimmen
Hreflang erfordert gegenseitige Verlinkung Wenn Seite A auf Seite B als Alternativversion verweist, muss Seite B auch auf Seite A zurückverweisen Ein einziger fehlender Return-Tag kann dazu führen, dass Google den gesamten Hreflang-Cluster für diese Seite ignoriert

Das Format folgt strengen ISO-Standards:

Komponente Standard Beispiel Häufiger Fehler
Sprache ISO 639-1 (2 Buchstaben, Kleinbuchstaben) en, de, fr Vollständige Wörter: „english” statt „en”
Region (optional) ISO 3166-1 Alpha-2 (2 Buchstaben, Großbuchstaben) US, GB, DE en-UK statt en-GB (UK ist kein gültiger ISO-Code)
Kombiniert Sprache-REGION, mit Bindestrich en-US, de-AT, fr-CA Unterstrich: en_US statt en-US
⚠️ Stilles Scheitern: Google ignoriert ungültige Hreflang-Codes ohne jede Fehlermeldung. Ihr Tag existiert im HTML, aber er bewirkt absolut nichts. Deshalb haben 75 % der internationalen Websites Hreflang-Fehler, von denen sie nicht einmal wissen.

Wann Sie tatsächlich Hreflang benötigen

Szenario Hreflang nötig? Warum
Gleiche Sprache, verschiedene Regionen (en-US, en-GB, en-AU) ✅ Ja — essenziell Unterschiedliche Preise, Versand, rechtliche Bedingungen, Schreibweise
Verschiedene Sprachen, gleiche Domain (/en/, /de/, /fr/) ✅ Ja — essenziell Verhindert sprachübergreifende Kannibalisierung
Separate ccTLDs (example.com, example.de, example.fr) ✅ Ja — empfohlen Hilft Google, die Beziehung zwischen separaten Domains zu verstehen
Einsprachige Website, einzelner Markt ❌ Nein Keine alternativen Versionen vorhanden
Automatisch übersetzter Thin Content ❌ Noch nicht Minderwertige Übersetzungen können deindexiert werden — zuerst Content-Qualität verbessern

URL-Struktur für internationale Websites

Bevor Sie Hreflang implementieren, benötigen Sie eine Entscheidung zur URL-Struktur. Diese Wahl hat dauerhafte SEO-Auswirkungen:

Struktur Beispiel Geo-Targeting-Signal Link-Equity Komplexität Ideal für
Unterverzeichnisse example.com/de/ Mittel (via GSC + Hreflang) ✅ Konsolidiert unter einer Domain Niedrig Die meisten Unternehmen, die neue Märkte erschließen
Subdomains de.example.com Mittel (via GSC + Hreflang) ⚠️ Teilweise separat Mittel Große Unternehmen mit separaten Teams pro Region
ccTLDs example.de ✅ Stärkstes natives Signal ❌ Komplett separate Domains Hoch Große Marken mit etablierter regionaler Präsenz
💡 Unsere Empfehlung: Für die meisten Unternehmen sind Unterverzeichnisse (/en/, /de/, /fr/) die optimale Wahl. Sie konsolidieren die gesamte Link-Equity unter einer Domain, vereinfachen die technische Implementierung und funktionieren perfekt mit Hreflang. Wir nutzen diese Struktur selbst bei Klucco und empfehlen sie unseren Kunden, sofern kein spezifischer Grund für ccTLDs besteht.

Die drei Implementierungsmethoden

1. HTML <link>-Tags im <head>

Die gängigste Methode. Fügen Sie Link-Elemente in den <head>-Bereich jeder Seite ein, die alle Sprachversionen referenzieren — einschließlich der Seite selbst (Selbstreferenz):

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

Ideal für: Websites mit weniger als 10 Sprachversionen pro Seite.

2. HTTP-Header

Wird für Nicht-HTML-Dateien (PDFs, Downloads) oder wenn Sie den HTML-<head> nicht modifizieren können, verwendet:

Link: <https://example.com/en/page/>; rel="alternate"; hreflang="en",
      <https://example.com/de/seite/>; rel="alternate"; hreflang="de",
      <https://example.com/fr/page-fr/>; rel="alternate"; hreflang="fr",
      <https://example.com/en/page/>; rel="alternate"; hreflang="x-default"

Ideal für: Nicht-HTML-Dokumente und Websites, bei denen Edge-Level-Implementierung (via CDN) bevorzugt wird.

3. XML-Sitemap

Die skalierbare Methode für große internationale Websites:

<url>
  <loc>https://example.com/en/page/</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/seite/" />
  <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/page-fr/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/page/" />
</url>

Ideal für: Websites mit 10+ Sprachversionen und E-Commerce-Kataloge mit Tausenden von Produkten über Märkte hinweg.

⚠️ Kritische Regel: Wählen Sie EINE Methode und bleiben Sie dabei. Das Mischen von Methoden (z. B. Hreflang sowohl im HTML als auch in der Sitemap mit unterschiedlichen Werten) erzeugt Konflikte, die Google unvorhersehbar auflöst.

x-default verstehen

Der Wert hreflang="x-default" teilt Google mit, welche Seite angezeigt werden soll, wenn keine andere Hreflang-Variante der Sprache oder Region des Nutzers entspricht. Es ist nicht die „Standardsprache” — es ist der „Keine-der-obigen”-Fallback.

Verwenden Sie x-default auf:

  • Einer Sprachauswahl-Seite, die den Standort des Nutzers erkennt und weiterleitet
  • Ihrer international relevantesten Version (normalerweise Englisch)
  • Einer globalen Landing Page mit Länder-/Sprachauswahl

CMS-spezifische Implementierung

WordPress mit Polylang

Polylang generiert automatisch Hreflang-Tags im HTML-<head> für verbundene Übersetzungen:

  1. Polylang installieren und Sprachen definieren (Einstellungen → Sprachen)
  2. Für jeden Beitrag/jede Seite die Übersetzung erstellen und über den Sprachumschalter in der Editor-Sidebar verbinden
  3. Polylang gibt automatisch <link rel="alternate" hreflang="...">-Tags aus, einschließlich x-default

Häufige Stolperfallen bei Polylang:

  • Fehlende Übersetzungen: Wenn Sie keine Übersetzung für einen bestimmten Beitrag erstellt haben, gibt Polylang für diese Sprache kein Hreflang aus
  • Sprach-Slug-Konfiguration: URL-Slugs auf ISO-Codes setzen (z. B. /en/, /de/) und nicht auf benutzerdefinierte Slugs wie /english/
  • x-default-Zuweisung: Standardmäßig weist Polylang x-default der „Standard”-Sprache zu. Überprüfen Sie, ob dies Ihrem beabsichtigten Fallback entspricht

WordPress mit WPML

WPML behandelt Hreflang nativ und ist konfigurierbarer als Polylang für komplexe Setups:

  1. WPML → Sprachen → Ihre Sprachen mit korrekten Locale-Codes konfigurieren
  2. Für jedes Sprachpaar fügt WPML automatisch Hreflang-Annotationen hinzu
  3. Unterstützt Sprache-Region-Varianten (en-US vs en-GB) nativ

Shopify

Shopify verwaltet Hreflang über seine Markets-Funktion:

  1. Einstellungen → Markets → jeden Markt mit Sprache und Region konfigurieren
  2. Shopify generiert automatisch Hreflang-Tags für verbundene Märkte
  3. Unterordner (/en/, /de/) werden automatisch erstellt

Shopify-Einschränkung: Hreflang auf Shopify funktioniert nur mit Shopify Markets — nicht mit Drittanbieter-Übersetzungs-Apps, die URL-Parameter verwenden.

Magento 2

Magento verwaltet Hreflang über Store Views, die Sprachen zugeordnet sind. Wichtig: Standard-Magento generiert KEINE Hreflang-Tags nativ. Sie benötigen entweder eine Drittanbieter-Erweiterung (Amasty, MageWorx) oder individuelle Entwicklung.

Die DACH-Herausforderung: de-DE vs de-AT vs de-CH

Wenn Sie in deutschsprachigen Märkten operieren, wird Hreflang schnell komplex. Deutschland, Österreich und die Schweiz sprechen alle Deutsch, aber mit unterschiedlichen Preisen (€ vs CHF), rechtlichen Anforderungen, Versandzonen und sogar Vokabular.

Markt Hreflang-Code Währung Wesentliche Unterschiede
Deutschland de-DE € EUR Standarddeutsch, EU-Vorschriften, SEPA-Zahlungen
Österreich de-AT € EUR Österreichisches Deutsch, andere rechtliche Begriffe, lokale Zahlungsmethoden
Schweiz de-CH CHF Schweizer Deutsch, Nicht-EU-Vorschriften, anderer MwSt.-Satz, Twint-Zahlungen

Die Entscheidung: Wenn Ihr Content, Ihre Preise und rechtlichen Bedingungen in allen DACH-Ländern identisch sind, verwenden Sie hreflang="de" (nur Sprache, keine Region). Wenn sie sich in irgendeiner wesentlichen Weise unterscheiden, verwenden Sie regionsspezifische Codes (de-DE, de-AT, de-CH).

💡 Praxisbeispiel: Ein Online-Shop, der in allen drei DACH-Märkten mit unterschiedlichen Preisen (€ für DE/AT, CHF für CH) und verschiedenen Versandoptionen verkauft, benötigt drei separate Hreflang-Varianten. Ein Blog, der allgemeine Inhalte auf Standarddeutsch schreibt, kann ein einzelnes hreflang="de" für alle drei Märkte verwenden.

Hreflang und Canonical Tags: Die Regeln

Die goldenen Regeln:

  1. Jede Hreflang-URL muss self-canonical sein. Die Seite unter /de/seite/ muss ein <link rel="canonical" href="/de/seite/"> haben — auf sich selbst zeigend
  2. Niemals cross-canonical zwischen Sprachversionen. Ihre deutsche Seite sollte KEIN Canonical haben, das auf die englische Version zeigt
  3. Hreflang-URLs müssen exakt mit Canonical-URLs übereinstimmen. Protokoll- oder www-Abweichungen führen dazu, dass Google die Hreflang-Annotation verwirft

Hreflang und Crawl-Budget

Jeder Hreflang-Cluster vervielfacht die Anzahl der URLs, die Google crawlen und validieren muss. Eine Website mit 10.000 Seiten in 5 Sprachen erzeugt 50.000 URLs in der Crawl-Warteschlange.

Für große internationale Websites hat dies reale Crawl-Budget-Auswirkungen:

  • Stellen Sie sicher, dass alle Hreflang-URLs 200-Statuscodes zurückgeben
  • Verwenden Sie XML-Sitemap-Implementierung für große Websites
  • Entfernen Sie Hreflang-Annotationen für eingestellte Sprachversionen
  • Begrenzen Sie AI-Crawler, die alle Sprachversionen gleichzeitig scannen

Edge SEO: Hreflang via Cloudflare Workers injizieren

Wenn Sie Ihr CMS nicht modifizieren können — Legacy-Plattformen, gesperrte Enterprise-Systeme oder extern gehostete Storefronts — ermöglicht Edge SEO die Hreflang-Injection auf CDN-Ebene. Ein Cloudflare Worker kann Antworten abfangen und die korrekten <link rel="alternate">-Tags hinzufügen, bevor die Seite den Nutzer (oder Googlebot) erreicht.

Besonders wertvoll für:

  • Magento-Shops ohne installierte Hreflang-Erweiterung
  • Websites, bei denen Entwicklerressourcen zum Engpass werden
  • Multi-Domain-Setups (ccTLDs), bei denen zentralisiertes Hreflang-Management die Wartung vereinfacht
  • Temporäre Hreflang-Injection während einer Website-Migration

Content-Lokalisierung vs. wörtliche Übersetzung

Hier scheitern die meisten internationalen SEO-Maßnahmen — nicht an der technischen Implementierung, sondern am Content selbst. Hreflang funktioniert nur, wenn Google tatsächlich unterschiedlichen, wertvollen Content hat, an den Nutzer weitergeleitet werden können. Eine maschinell übersetzte Seite mit unnatürlichen Formulierungen und Keywords, nach denen niemand in diesem Markt sucht, wird unabhängig von Ihrem Hreflang-Setup unterperformen.

Warum maschinelle Übersetzung für SEO nicht ausreicht

Problem Beispiel SEO-Auswirkung
Keyword-Mismatch „Project management software” wird wörtlich zu „Projektmanagementsoftware” — aber deutsche Nutzer suchen tatsächlich nach „Aufgabenverwaltung” oder „Projektmanagement-Tool” Sie ranken für Begriffe, die niemand sucht
Thin-Content-Signale Automatisch übersetzte Seiten fehlt die Tiefe und natürliche Formulierung, die native Inhalte haben Googles Qualitätssysteme können die Seite unterdrücken
Fehlender lokaler Kontext Eine US-Seite über Rechnungssoftware betont IRS-Compliance; die deutsche Version braucht DATEV-Integration und GoBD-Konformität Content entspricht nicht der Suchintention in diesem Markt

Was stattdessen zu tun ist

  • Keyword-Recherche pro Locale: Google Keyword Planner oder Ahrefs mit der Ziel-Locale und -Sprache explizit einstellen. Nicht davon ausgehen, dass sich englische Keywords direkt übersetzen lassen
  • Suchintention variiert nach Markt: Dieselbe Produktanfrage kann in einem Markt kommerzielle und in einem anderen informelle Intention haben. Content entsprechend anpassen
  • Lokalisieren, nicht nur übersetzen: Datumsformate, Währungen, Maßeinheiten, kulturelle Referenzen, rechtliche Anforderungen und lokale Wettbewerber müssen angepasst werden
  • Lokale Trust-Signale: Deutsche Nutzer vertrauen Trusted Shops und TÜV-Siegeln. US-Nutzer vertrauen BBB und Norton. Ihre lokalisierten Seiten brauchen lokal relevante Vertrauenselemente

Locale-spezifische Metadaten

Übersetzter Seiteninhalt allein reicht nicht aus. Jede Locale benötigt eigene vollständig übersetzte Metadaten — Title-Tags, Meta-Descriptions, Open-Graph-Tags und kanonische URLs.

<title>Vollständiger Leitfaden zur Hreflang-Implementierung | Klucco</title>
<meta name="description" content="Alles über Hreflang-Tags für mehrsprachige SEO..." />
<link rel="canonical" href="https://example.com/de/hreflang-guide/" />
<meta property="og:locale" content="de_DE" />
<meta property="og:locale:alternate" content="en_US" />
⚠️ Wichtig: Open Graph verwendet Unterstrich-getrennte Locale-Codes (de_DE), während Hreflang Bindestrich-getrennte BCP-47-Codes verwendet (de-DE). Das Mischen dieser Formate ist eine häufige Fehlerquelle. Außerdem: Title-Tags und Meta-Descriptions auf Englisch auf nicht-englischen Seiten zu belassen, führt zu englischen Snippets in fremdsprachigen SERPs — was Ihre CTR erheblich senkt.

Structured Data für mehrsprachige Websites

Strukturierte Daten (JSON-LD) müssen zusammen mit Ihrem HTML-Content lokalisiert werden. Google nutzt die inLanguage-Eigenschaft im Schema-Markup, um zu verstehen, welches Publikum ein Inhalt anspricht.

Lokalisiertes Article-Schema

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Vollständiger Leitfaden zur Hreflang-Implementierung",
  "inLanguage": "de-DE",
  "url": "https://example.com/de/hreflang-guide/",
  "datePublished": "2026-08-23",
  "author": {
    "@type": "Organization",
    "name": "Klucco"
  }
}

Mehrsprachiges FAQ-Schema

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "inLanguage": "de-DE",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Was ist Hreflang?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Hreflang ist ein HTML-Attribut, das Google mitteilt, welche Sprachversion einer Seite für welche Nutzer gedacht ist."
      }
    }
  ]
}
💡 Update 2026: Google hat kürzlich seinen JSON-LD-Parser geändert und wendet nur noch einen einzigen Durchlauf der HTML-Unescaping an. Doppelt-escaped Entities (wie &amp;amp;) werden nicht mehr aufgelöst. Stellen Sie sicher, dass Ihr Code Standard-JSON-Escapes oder Unicode-Hexadezimal-Escapes (wie \u0026) verwendet, um stille Parsing-Fehler zu vermeiden.

Hreflang für AI-Suche 2026: Der AEO- und GEO-Aspekt

Im Jahr 2026 geht es bei Hreflang nicht mehr nur um Google. AI-gestützte Suchtools — ChatGPT, Perplexity, Claude, Google AI Overviews — liefern Antworten in der Muttersprache der Nutzer. Korrekt implementiertes Hreflang hilft, Ihren Content in der richtigen Sprache über diese neuen Entdeckungskanäle zu präsentieren.

  • AI-Assistenten liefern sprachspezifische Antworten. Wenn ein französischer Nutzer ChatGPT eine Frage stellt, bevorzugt es französischsprachige Quellen. Wenn Ihre französische Seite korrekt mit Hreflang versehen und indexiert ist, wird sie eher zitiert
  • Mehrsprachige Hreflang-Cluster signalisieren globale Autorität. Für Generative Engine Optimization (GEO) zeigt korrekt verlinkter Content in mehreren Sprachen AI-Systemen, dass Ihre Website eine umfassende, autoritative Quelle ist
  • AI-Crawler scannen alle Sprachversionen. GPTBot, ClaudeBot und PerplexityBot crawlen mehrere Sprachversionen Ihrer Website. Sauberes Hreflang verhindert, dass sie Ihre Sprachvarianten verwechseln oder zusammenführen

Die 7 häufigsten Hreflang-Fehler

# Fehler Häufigkeit Lösung
1 Fehlende Return-Tags (nicht-gegenseitig) 43 % aller Fehler Jede Seite muss jede Alternative referenzieren und jede Alternative muss zurückverweisen
2 Ungültige Sprach-/Regionscodes Häufig en-GB verwenden, nicht en-UK. Nur ISO 639-1 + ISO 3166-1
3 Fehlender Selbstreferenz-Tag Häufig Jede Seite muss einen Hreflang-Tag enthalten, der auf sich selbst zeigt
4 Hreflang zeigt auf weitergeleitete URLs Nach Migrationen Hreflang aktualisieren, damit es auf finale Ziel-URLs zeigt
5 Canonical-/Hreflang-Konflikte Häufig Sicherstellen, dass Hreflang-URLs self-canonical sind
6 Relative URLs in Hreflang Gelegentlich Immer absolute URLs mit Protokoll verwenden
7 Fehlendes x-default Häufig Immer x-default einschließen, das auf Ihre Fallback-/globale Seite zeigt
8 noindex + Hreflang-Konflikt Randfälle Eine Seite mit sowohl Hreflang als auch noindex erzeugt einen Widerspruch — Google entfernt sie aus dem Index und bricht den gesamten Hreflang-Cluster. Entweder noindex entfernen oder die Seite aus dem Hreflang-Set nehmen

Validierungstools und Testing

Tool Funktion Ideal für Kosten
Google Search Console International Targeting-Bericht — zeigt erkannte Hreflang-Annotationen und markiert Fehler Offizielle Validierung, laufendes Monitoring Kostenlos
Screaming Frog SEO Spider Vollständiger Site-Crawl, der alle Hreflang-Annotationen extrahiert und validiert Umfassende Website-Audits Kostenlos (bis 500 URLs) / 259 £/Jahr
Aleyda Solis Hreflang Testing Tool Einzelne URLs auf korrekte Hreflang-Syntax und Return-Tags prüfen Schnelle Einzelseiten-Validierung Kostenlos
Merkle Hreflang Tag Generator Generiert syntaktisch korrekte Hreflang-Markup aus strukturierter Eingabe Neue Hreflang-Sets von Grund auf erstellen Kostenlos

Monitoring: Probleme erkennen, bevor sie Rankings schaden

Prüfung Frequenz Methode
GSC International Targeting-Fehler Wöchentlich Search Console → Alte Tools → Internationales Targeting
Neue Seiten ohne Hreflang Wöchentlich Geplanter Screaming-Frog-Crawl — Seiten ohne Hreflang-Annotationen filtern
Hreflang zeigt auf Nicht-200-URLs Monatlich Screaming Frog Hreflang-Tab — nach Nicht-200-Antwortcodes filtern
Nicht-gegenseitige Links Monatlich Screaming Frog — „Anzahl Hreflang-URLs” vs „Gefundene Return-Links” vergleichen

Screaming-Frog-Hreflang-Audit: Schritt-für-Schritt-Workflow

  1. Crawl konfigurieren: Config → Spider → Crawl → „Store Hreflang” aktivieren
  2. Sitemap-Crawling aktivieren: Falls Ihre Website XML-Sitemaps für Hreflang verwendet, „Crawl Linked XML Sitemaps” unter Config → Spider → Crawl aktivieren
  3. Crawl starten: Root-URL eingeben und Start klicken
  4. Hreflang-Tab prüfen: Zeigt alle URLs mit ihren Hreflang-Annotationen und der Anzahl der Vorkommen
  5. Crawl-Analyse durchführen: Crawl Analysis → Start klicken, um alle Hreflang-spezifischen Filter zu befüllen

Die 12 Hreflang-Filter im Überblick

Filter Was er findet Priorität
Missing Return Links Nicht-gegenseitige Annotationen — der #1 Hreflang-Fehler 🔴 Kritisch
Missing Self Reference Seiten, die sich nicht selbst in ihrem Hreflang-Set referenzieren 🔴 Kritisch
Missing X-Default Keine Fallback-Seite für nicht zugeordnete Nutzer definiert 🟠 Hoch
Non-200 Hreflang URLs Hreflang zeigt auf Redirects, 404s oder 5xx-Seiten 🔴 Kritisch
Non-Canonical Return Links Hreflang-URLs, die nicht self-canonical sind 🔴 Kritisch
Noindex Return Links Hreflang zeigt auf Seiten mit noindex — bricht den Cluster 🟠 Hoch
Incorrect Language & Region Codes Ungültige ISO-Codes (en-UK, sp, etc.) 🟠 Hoch
Inconsistent Language & Region Widersprüchliche Codes zwischen Seiten im selben Cluster 🟡 Mittel
Unlinked Hreflang URLs Seiten in Hreflang-Sets ohne interne Links 🟡 Mittel
Multiple Entries Doppelte Hreflang-Einträge für dieselbe Sprache 🟡 Mittel
Not Using Canonical Seiten ohne Canonical-Tag in Hreflang-Sets 🟡 Mittel
Contains Hreflang Zeigt alle Seiten mit Hreflang — für Basis-Audit ℹ️ Info

Technische Implementierungs-Checkliste

Bevor Sie Ihr mehrsprachiges Setup starten oder ändern, überprüfen Sie jeden Punkt:

URL-Struktur

  • ☐ Konsistentes Locale-Prefix-Format auf allen Seiten (/en/, /de/, etc.)
  • ☐ Kleingeschriebene, bindestrichgetrennte Locale-Codes in URLs
  • ☐ Alle Locale-URLs geben 200-Status zurück (keine Redirects)

Hreflang-Tags

  • ☐ Jede Locale-Seite enthält Hreflang-Tags für alle anderen Locales
  • ☐ Jede Seite enthält einen Selbstreferenz-Hreflang-Tag
  • ☐ x-default ist auf allen Seiten gesetzt
  • ☐ Alle Hreflang-URLs sind absolut (nicht relativ)
  • ☐ Hreflang mit EINER Methode implementiert (HTML ODER Sitemap ODER HTTP-Header)
  • ☐ Alle Hreflang-Tags sind gegenseitig (bidirektional)
  • ☐ Keine Hreflang-URLs zeigen auf weitergeleitete oder noindex-Seiten

Metadaten

  • ☐ Title-Tags pro Locale übersetzt
  • ☐ Meta-Descriptions pro Locale übersetzt
  • ☐ Canonical-URLs zeigen auf die korrekte Locale-URL (self-canonical)
  • ☐ Open Graph og:locale pro Locale gesetzt
  • ☐ Open Graph og:locale:alternate listet andere Locales

Strukturierte Daten

  • ☐ JSON-LD enthält inLanguage-Eigenschaft pro Locale
  • ☐ FAQ-Schema verwendet übersetzte Fragen/Antworten pro Locale
  • ☐ Keine doppelt-escaped Entities in JSON-LD (Parser-Update 2026)

Sitemap

  • ☐ Alle Locale-Varianten in Sitemap mit Hreflang-Annotationen enthalten
  • ☐ Sitemap bei Google Search Console eingereicht
  • ☐ Sitemap-Hreflang stimmt mit HTML-Head-Annotationen überein

Praxisbeispiel: DACH-E-Commerce-Hreflang-Korrektur

Eine mittelgroße E-Commerce-Marke, die in Deutschland, Österreich und der Schweiz mit 12.000 Produkten operierte, hatte regionale Seiten, die sich in den Suchergebnissen gegenseitig kannibalisierten. Deutsche Nutzer sahen Schweizer Preise. Österreichische Nutzer landeten im deutschen Shop mit falschen Versandoptionen.

Was wir festgestellt haben

  • Hreflang verwendete de (nur Sprache) für alle drei Märkte — keine regionale Differenzierung
  • 23 % der Produktseiten hatten fehlende Return-Tags
  • Canonical-Tags auf österreichischen Seiten zeigten auf deutsche Seiten (Cross-Canonical-Fehler)
  • x-default fehlte komplett

Was wir behoben haben

  1. Regionsspezifische de-DE, de-AT, de-CH Hreflang-Tags auf allen Produkt- und Kategorieseiten implementiert
  2. Alle Canonical-Tags auf Selbstreferenz innerhalb jeder regionalen Version korrigiert
  3. Vollständige XML-Sitemap mit Hreflang-Annotationen für alle 36.000 URLs generiert
  4. x-default hinzugefügt, das auf die deutsche (de-DE) Version als primären Fallback zeigt
  5. Wöchentliches Monitoring via geplante Screaming-Frog-Crawls eingerichtet

Ergebnisse nach 60 Tagen

Metrik Vorher Nachher Veränderung
Korrekte regionale Seite in SERPs ~45 % ~94 % +109 %
Organischer Traffic aus Österreich 800 Sitzungen/Monat 2.100 Sitzungen/Monat +163 %
Organischer Traffic aus der Schweiz 520 Sitzungen/Monat 1.350 Sitzungen/Monat +160 %
Regionsübergreifende Absprungrate 68 % 34 % −50 %

Der größte Gewinn: Österreichische und Schweizer Kunden sehen sofort korrekte Preise und Versandoptionen, was die Warenkorbabbruchrate reduziert und die regionalen Konversionsraten deutlich gesteigert hat.

Brauchen Sie Hilfe bei der Hreflang-Implementierung?

Unser Technical-SEO-Team ist auf internationale SEO für DACH- und globale Märkte spezialisiert. Wir auditieren Ihr bestehendes Hreflang-Setup, beheben Fehler und implementieren korrekte Annotationen über alle Ihre Sprachversionen hinweg.

Internationales SEO-Audit anfordern →

Antwort innerhalb von 24 Stunden · Keine Verpflichtung

Häufig gestellte Fragen

Verbessert Hreflang die Rankings?

Nicht direkt. Hreflang ist ein Routing-Signal, kein Ranking-Faktor. Es teilt Google mit, welche Version angezeigt werden soll — nicht, wo sie gerankt werden soll. Korrektes Hreflang verbessert jedoch die User Experience (richtige Sprache, richtige Preise), was Absprungraten senkt und Engagement-Signale verbessert, die indirekt den Rankings zugutekommen.

Kann ich Hreflang mit verschiedenen Domains (ccTLDs) verwenden?

Ja. Hreflang funktioniert über Domains hinweg. Ihre example.com kann example.de referenzieren und umgekehrt. Alle gleichen Regeln gelten — gegenseitige Tags, Selbstreferenz, absolute URLs und konsistente Canonical-Tags innerhalb jeder Domain.

Wie lange dauert es, bis Google Hreflang-Änderungen verarbeitet?

Typischerweise 2–4 Wochen, bis Google aktualisierte Hreflang-Annotationen vollständig neu crawlt und verarbeitet. Bei großen Websites kann dies länger dauern. Reichen Sie Ihre aktualisierte XML-Sitemap über die GSC ein und nutzen Sie das URL-Prüftool, um das Recrawling von Schlüsselseiten anzufordern.

Unterstützt Bing Hreflang?

Bing verwendet einen anderen Mechanismus: den <meta name="language" content="...">-Tag und den Content-Language-HTTP-Header. Bing hat jedoch bestätigt, dass es Hreflang als sekundäres Signal erkennt. Für maximale Kompatibilität implementieren Sie Hreflang (für Google) und den Content-Language-Header (für Bing) auf denselben Seiten.

Sollte gleicher Content in verschiedenen Sprachen Hreflang verwenden?

Ja — das ist der häufigste und wichtigste Anwendungsfall für Hreflang. Wenn Sie eine englische Seite und eine deutsche Übersetzung desselben Inhalts haben, verhindert Hreflang, dass Google die deutsche Version als Duplicate Content behandelt, und stellt sicher, dass die richtige Version in den Suchergebnissen des richtigen Marktes erscheint.

Klucco