Hreflang im mehrsprachigen E-Commerce: Fehlerguide

Sie haben einen FR-Shop und starten eine EN-Version für die USA. Alles scheint zu funktionieren — bis Sie merken, dass Google bei der Suche nach Ihrer Marke aus Frankreich die US-Seite anzeigt. Ihre französischen Kunden landen auf einer englischen Seite, Ihre Conversion sinkt.

Der Auslöser: ein falsch konfiguriertes hreflang. Dieses Tag sagt Google welche Sprach- oder Länderversion wem ausgeliefert werden soll. Richtig umgesetzt, schafft es sauberes internationales SEO. Falsch umgesetzt, erzeugt es ein Chaos aus wechselseitigen Weiterleitungen.

Was hreflang löst (und was nicht)

Hreflang löst:

Die FR-Seite an französischsprachige Nutzer ausliefern, EN an englischsprachige Nutzer
fr-FR (Frankreich) und fr-CA (Kanada) mit unterschiedlichen Preisen oder Lieferbedingungen unterscheiden
Duplicate Content zwischen 5 fast identischen Sprachversionen vermeiden

Hreflang löst nicht:

Das Ranking selbst (hreflang ist kein direktes Rankingsignal)
Die Performance pro Markt (lokale Backlinks bleiben für jeden Markt entscheidend)
Probleme mit der Übersetzungsqualität

Wenn Ihre Website nur eine Sprache hat, brauchen Sie kein hreflang. Wenn Sie 2+ Sprachen oder 2+ Regionen haben, ist es für sauberes internationales SEO Pflicht.

Die 3 Implementierungsmethoden

Methode 1 — `<link>`-Tags im HTML

Die häufigste Methode. Jede Seite listet ihre Alternativen im <head> auf:

<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/products/chaussure-derby" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/products/leather-derby-shoes" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/products/leather-derby-shoes" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/leather-derby-shoes" />

Gut geeignet für kleine Kataloge (<1000 Seiten). Bei großen Volumen schwer zu pflegen — jede Seite muss ihre Alternativen kennen.

Methode 2 — XML-Sitemap

Jede URL in der Sitemap listet ihre Varianten auf:

<url>
  <loc>https://example.com/fr/products/chaussure-derby</loc>
  <xhtml:link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/products/chaussure-derby" />
  <xhtml:link rel="alternate" hreflang="en-US" href="https://example.com/en-us/products/leather-derby-shoes" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/products/leather-derby-shoes" />
</url>

Besser für große Kataloge: zentralisiert die Beziehungen in einer einzigen Datei. Per Skript leichter zu erzeugen. Das ist die von Ecomptimize empfohlene Methode für Kataloge mit 5.000+ Produktseiten.

Methode 3 — HTTP-Header `Link`

Für Nicht-HTML-Dateien (PDFs, lokalisierte Bilder):

Link: <https://example.com/fr/catalog.pdf>; rel="alternate"; hreflang="fr-FR",
      <https://example.com/en/catalog.pdf>; rel="alternate"; hreflang="en-US"

Im E-Commerce selten, aber nützlich für herunterladbare PDF-Kataloge.

Empfehlung: Sitemap-Methode für Kataloge mit >1000 URLs, HTML-Tags für den Rest.

Hreflang vs canonical: nicht verwechseln

Das ist das häufigste Missverständnis.

Canonical sagt: "Hier ist die Referenz-URL dieses Inhalts unter mehreren identischen oder ähnlichen URLs." Dient zur Deduplizierung.

Hreflang sagt: "Hier sind die Sprachversionen dieses Inhalts, jede ist für ihr Publikum eigenständig." Dient zur Lokalisierung.

Kritische Regel: hreflang verweist auf eine andere URL (die Version in einer anderen Sprache). canonical verweist auf eine potenziell identische URL (dieselbe Seite oder eine Variante mit Parametern).

Eine Seite sollte sowohl ein hreflang als auch ein canonical haben:

<!-- Canonical dieser Seite -->
<link rel="canonical" href="https://example.com/fr/products/chaussure-derby" />

<!-- Sprachversionen dieser Seite -->
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/products/chaussure-derby" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/products/leather-derby-shoes" />

Fataler Fehler: das canonical der EN-Version auf die FR-Version zeigen zu lassen ("Übersetzungen kanonisieren"). Google interpretiert das als "Die EN-Version ist ein Duplikat von FR und kann ignoriert werden" und indexiert die EN-Seite gar nicht. SEO-Schaden.

Die bidirektionale Matrix

Hreflang muss bidirektional sein: Wenn A sagt "meine EN-Version ist B", dann muss B sagen "meine FR-Version ist A". Sonst ignoriert Google die Beziehung.

Beispiel für eine korrekte Implementierung:

Seite FR:

<link rel="alternate" hreflang="fr-FR" href=".../fr/..." />
<link rel="alternate" hreflang="en-US" href=".../en-us/..." />
<link rel="alternate" hreflang="x-default" href=".../en/..." />

Seite EN US:

<link rel="alternate" hreflang="fr-FR" href=".../fr/..." />
<link rel="alternate" hreflang="en-US" href=".../en-us/..." />
<link rel="alternate" hreflang="x-default" href=".../en/..." />

Genau dieselben 3 Zeilen auf jeder Version. Keine fehlenden Beziehungen, keine asymmetrischen Beziehungen.

Regionale Varianten: fr-FR vs fr-CA vs fr-BE

Wann sollten Regionen unterschieden werden?

Unterschiedliche Preise (MwSt., Lieferung, Währung) → ja, unterscheiden
Leicht unterschiedlicher Inhalt (US- vs. EU-Größen, lokaler Wortschatz) → ja, unterscheiden
Identischer Inhalt, nur andere Währung → nein, nicht unterscheiden; Währung im Checkout verwalten

Die regionale Unterscheidung erfordert eigene URLs:

/fr/products/chaussure-derby     (hreflang="fr")
/fr-ca/products/chaussure-derby  (hreflang="fr-CA")
/fr-be/products/chaussure-derby  (hreflang="fr-BE")

Wenn Sie keine 3 getrennten Versionen pflegen können, ist es besser, nur eine fr-Version zu behalten und Unterschiede (Währung, Lieferung) zur Laufzeit zu steuern.

x-default: warum es unverzichtbar ist

hreflang="x-default" gibt an, welche Version ausgeliefert werden soll, wenn keine passende Zuordnung gefunden wird. Zum Beispiel ein Nutzer in Rumänien, der weder FR noch EN-US noch EN-GB in seinen Einstellungen hat — welche Version soll er sehen?

Ohne x-default wählt Google zufällig. Mit x-default steuern Sie es selbst (typischerweise die allgemeinste EN-Version).

Empfehlung: immer ein x-default angeben, idealerweise die generische englische Version.

Implementierung nach Plattform

Shopify

Shopify Markets (seit 2022) verwaltet hreflang nativ, wenn Sie mehrere markets mit eigenen Domains oder Subdomains konfigurieren. In den meisten Fällen ist keine Anpassung nötig.

Grenzen: Shopify Markets unterstützt nicht alle Sprach-/Länderkombinationen mit feiner Granularität. Für komplexe Fälle (10+ Märkte) nutzen Sie besser eine App wie Langify plus ihr manuelles hreflang-Modul.

WooCommerce

WooCommerce hat keine native Unterstützung. Drei Optionen:

WPML (paid): führendes mehrsprachiges Plugin, verwaltet hreflang automatisch
Polylang (free/paid): Alternative mit guter hreflang-Unterstützung
TranslatePress (paid): einfacher für kleine Kataloge

Achtung: Kombinieren Sie nicht zwei Plugins (WPML + Polylang), das erzeugt doppelte und fehlerhafte hreflang-Tags.

Headless oder custom

Wenn Sie ein custom Frontend nutzen (Next.js, Nuxt), erzeugen Sie hreflang serverseitig. In Next.js mit next-intl erfolgt die Generierung automatisch, wenn Sie die Routen /[locale]/... verwenden.

Hreflang-Audit in 15 Minuten

Prüfen Sie auf Ihrer aktuellen Website:

Bidirektionalität: Für 10 Testseiten prüfen, ob jede Version wechselseitig auf die anderen verweist (über Screaming Frog oder hreflang.org)
x-default vorhanden: auf allen lokalisierten Seiten
Kein sprachübergreifendes canonical: Die EN-Version darf nicht auf FR kanonisieren
Gültige ISO-Codes: "fr", "en" (Sprache) oder "fr-FR", "en-US" (Sprache-Land). Nicht "french" oder "uk".
Gleiche URL in hreflang und canonical derselben Seite: vermeidet Abweichungen

Kostenlose Tools:

hreflang.org — Audit pro URL
Screaming Frog (SEO Spider) — Audit in größerem Umfang
Google Search Console — hreflang-Fehlerberichte unter Settings → International Targeting

FAQ

Wie lange dauert es, bis Google hreflang berücksichtigt?

4 bis 8 Wochen für eine saubere Implementierung in einem bestehenden Katalog. Google muss jede Seite erneut crawlen, die bidirektionalen Beziehungen validieren und das Ranking pro Markt anpassen. Es gibt keinen Soforteffekt.

Kann ich hreflang nur in der Sitemap ohne HTML-Tags verwenden?

Ja, das ist für große Kataloge sogar empfohlen. Google unterstützt alle 3 Methoden gleichwertig. Wählen Sie die Methode, die für Ihren Stack am einfachsten zu pflegen ist.

Funktioniert hreflang auch bei Bing und Yandex?

Bing ja. Yandex ja. Baidu teilweise. Alle nutzen denselben Standard. Sie müssen keine spezielle Variante implementieren.

Was tun, wenn meine Übersetzungen mit IA erzeugt werden und nicht perfekt sind?

Hreflang funktioniert unabhängig von der Herkunft des Inhalts — menschlicher Übersetzer oder IA. Entscheidend ist, dass die Seiten pro Locale eigenständig sind (selbst wenn sie zu 80 % ähnlich sind und die Übersetzung solide ist), nicht ihre Herkunft.

Kann ich hreflang für identischen Inhalt mit nur einer anderen Währung verwenden?

Technisch ja, aber es droht eine Abstrafung, wenn der Unterschied zu gering ist. Google könnte die Seiten als Duplikate ohne lokalen Mehrwert einstufen. Besser: eine einzige Seite mit dynamischer Währung in der Navigation.

Sollte mein mehrsprachiger Blog hreflang haben?

Ja, genau wie Ihre Produktseiten. Jeder übersetzte Artikel sollte auf seine Versionen verweisen, und Ihr Blog-Hub sollte ebenfalls auf die lokalisierten Hubs verweisen. Sehen Sie dazu unseren Redaktionsplan für 7 Sprachen für den vollständigen Prozess.

Für die Ausrollung Ihres Katalogs in 7 Sprachen mit sauberem hreflang sehen Sie Ecomptimize für Shopify oder Ecomptimize für WooCommerce.