Hreflang Tag

Kurz gesagt

Der Hreflang Tag sagt Google, welche Sprach- oder Regionsversionen einer Seite zusammengehoeren. Er hilft, Nutzerinnen und Nutzer zur passenden lokalisierten Version zu fuehren, zum Beispiel zur deutschen, englischen, franzoesischen oder spanischen Seite.

Einfach erklaert

Hreflang ist wie ein Wegweiser fuer internationale Seiten. Eine Seite sagt nicht nur: "Ich bin die deutsche Version", sondern auch: "Hier sind meine passenden Alternativen in Englisch, Frankreich, Spanien oder fuer alle anderen Sprachen."

Wichtig ist: Hreflang uebersetzt nichts, erkennt keine Sprache und macht eine schlechte Lokalisierung nicht besser. Google nutzt eigene Systeme, um die Sprache einer Seite zu erkennen. Hreflang hilft vor allem dabei, die richtigen Alternativen derselben oder sehr aehnlicher Inhalte zu verbinden.

Wenn Hreflang sauber funktioniert, landet ein Nutzer aus Deutschland eher auf der deutschen Version, ein Nutzer aus Spanien eher auf der spanischen Version und ein internationaler Nutzer eventuell auf einer x-default-Seite.

Warum Hreflang fuer SEO wichtig ist

Internationale Websites haben oft sehr aehnliche Seiten: englisch USA, englisch UK, deutsch Deutschland, deutsch Schweiz, spanisch Spanien, spanisch Mexiko. Ohne klare Alternates kann Google zwar vieles selbst verstehen, aber es kann die falsche regionale Version zeigen.

Hreflang hilft besonders, wenn Inhalte uebersetzt oder regional angepasst sind. Es reduziert nicht automatisch Duplicate-Content-Probleme, aber es erklaert Google, dass diese Seiten lokale Varianten derselben Seite sind.

Fuer Unternehmen mit mehreren Maerkten ist das wichtig, weil Suchergebnisse nicht nur ranken, sondern auch passen muessen. Eine starke US-Seite hilft einem deutschen Nutzer weniger, wenn Preise, Recht, Sprache oder Ansprechpartner nicht passen.

Hreflang Ist Cluster-Logik

Ein einzelner Hreflang Tag ist selten die ganze Wahrheit. Google muss ein konsistentes Set erkennen: Diese URL gehoert zu dieser Gruppe, diese anderen URLs sind passende Alternativen, und alle Varianten bestaetigen diese Beziehung.

Deshalb funktionieren Hreflang-Projekte nicht wie einfache Meta-Tag-Aufgaben. Sie sind eher eine Architekturfrage. Jede neue Sprachseite veraendert das ganze Set. Wenn eine Variante fehlt, eine andere auf noindex steht oder ein Canonical quer schiesst, wird nicht nur eine Zeile falsch. Der gesamte Cluster wird weniger verlaesslich.

Was Hreflang leistet

Passende Sprachversion anzeigen

Hreflang hilft Google, Nutzern die Version zu zeigen, die besser zu Sprache oder Region passt.

Varianten als zusammengehoerig erklaeren

Die Tags verbinden Seiten, die inhaltlich zusammengehoeren. Das ist besonders nuetzlich bei mehreren Sprach- oder Laenderversionen.

x-default definieren

x-default kann eine Fallback-Seite kennzeichnen, etwa eine globale Startseite oder Sprachwaehler-Seite fuer Nutzer, die keiner konkreten Variante zugeordnet werden.

Was Hreflang nicht leistet

Kein Ranking-Booster

Hreflang ist kein direkter Trick fuer bessere Rankings. Es hilft eher, die richtige URL fuer den passenden Nutzer zu zeigen.

Keine Sprach-Erkennung

Google verwendet Hreflang nicht, um die Sprache einer Seite zu erkennen. Die Sprache muss aus dem Inhalt selbst klar werden.

Keine Canonical-Reparatur

Wenn Canonicals falsch gesetzt sind, kann Hreflang scheitern. Eine deutsche Seite, die auf Englisch kanonisiert, ist meistens kein sauberer Hreflang-Kandidat.

Beispiel im HTML

Eine Seite mit Deutsch, Englisch und Spanisch koennte im Head so aussehen:

~~~html <link rel="alternate" hreflang="de" href="https://example.com/de/produkt/" /> <link rel="alternate" hreflang="en" href="https://example.com/en/product/" /> <link rel="alternate" hreflang="es" href="https://example.com/es/producto/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" /> ~~~

Diese Links muessen im Head stehen und fuer jede Variante gleichwertig vorhanden sein.

Rueckverweise sind Pflicht

Hreflang funktioniert nur stabil, wenn die Seiten gegenseitig aufeinander verweisen. Wenn die deutsche Seite auf Englisch verweist, aber die englische Seite nicht zurueck auf Deutsch, kann Google diese Verbindung ignorieren.

Jede Sprachversion sollte sich selbst und alle relevanten Alternativen nennen. Das wirkt redundant, ist aber der Punkt: Google soll ein konsistentes Set erkennen.

Vollstaendige URLs verwenden

Hreflang-URLs sollten vollstaendig sein, also inklusive Protokoll und Domain:

~~~txt https://example.com/de/produkt/ ~~~

Relative Pfade wie "/de/produkt/" sind fuer Hreflang keine gute Basis. Bei internationalen Setups mit Subdomains, ccTLDs, Staging und mehreren Hosts koennen relative oder unklare URLs schnell zu falschen Clustern fuehren.

Sprach- und Regionscodes

Ein Sprachcode wie "de" steht fuer Deutsch allgemein. Ein kombinierter Code wie "de-CH" zielt auf Deutsch in der Schweiz. Fuer Englisch koennen "en", "en-US", "en-GB" oder andere Kombinationen sinnvoll sein.

Wichtig ist, nur echte Varianten auszuzeichnen. Wenn die US- und UK-Seite fast gleich sind, aber Preise, Schreibweise, Versand oder rechtliche Details unterschiedlich sind, kann eine regionale Auszeichnung sinnvoll sein. Wenn es keinen echten Unterschied gibt, braucht es nicht immer eine eigene URL.

HTML, HTTP Header oder Sitemap

HTML

HTML-Hreflang im Head ist gut fuer kleinere bis mittlere Setups und wenn Templates sauber kontrollierbar sind.

HTTP Header

HTTP Header eignen sich fuer Nicht-HTML-Dateien wie PDFs, bei denen kein HTML-Head vorhanden ist.

XML Sitemap

Hreflang in Sitemaps kann bei grossen internationalen Websites leichter zu pflegen sein. Wichtig ist, nicht mehrere Methoden durcheinander widerspruechlich zu nutzen. Google betrachtet die Methoden als gleichwertig; die beste Methode ist die, die dein Team dauerhaft sauber halten kann.

Hreflang und Canonical

Jede lokalisierte Seite sollte auf eine kanonische Version zeigen, die zur gleichen Sprache oder zur passenden lokalen Variante gehoert. Hreflang sagt: "Das sind Alternativen." Canonical sagt: "Das ist die bevorzugte Version dieses Inhalts."

Wenn alle Sprachversionen per Canonical auf eine englische URL zeigen, koennen die anderen Sprachversionen ihre eigene SEO-Rolle verlieren. Hreflang und Canonical muessen also dieselbe Architektur erzaehlen.

Mobile und Hreflang

Bei Mobile-First Indexing muss Hreflang auch in der mobilen Version sichtbar und korrekt sein. Wenn Desktop saubere Alternates hat, Mobile aber nicht, entsteht ein Risiko.

Bei separaten mobilen URLs wird es noch komplexer: Mobile-URL, Desktop-URL, canonical, alternate und hreflang muessen sauber aufeinander abgestimmt sein. Responsive Design ist hier oft deutlich einfacher.

Haeufige Fehler

• Fehlende Rueckverweise zwischen Sprachversionen.
• Falsche Sprach- oder Regionscodes.
• Relative statt vollstaendige URLs.
• Hreflang zeigt auf 404, Redirect, noindex oder falsche Canonical-Ziele.
• x-default fehlt bei globalen Sprachwaehlern.
• HTML- und Sitemap-Hreflang widersprechen sich.
• Mobile-Versionen enthalten andere Hreflang-Sets als Desktop.
• Inhalte sind maschinell uebersetzt, aber nicht wirklich lokalisiert.

Praxisbeispiel

Ein SaaS-Anbieter hat Seiten fuer Deutschland, USA, UK und Spanien. Alle Seiten beschreiben dasselbe Produkt, aber Preise, Sprache, Testimonials und rechtliche Hinweise unterscheiden sich.

Das Team legt ein Hreflang-Set an: de-DE, en-US, en-GB, es-ES und x-default fuer die globale Auswahlseite. Jede Seite listet sich selbst und alle Alternativen. Die Canonicals zeigen jeweils auf die lokale Version. Die Sitemap enthaelt die gleichen Beziehungen.

Das Ergebnis: Google kann die Varianten als Gruppe verstehen und Nutzer eher zur passenden Marktseite schicken.

Pruefung in der Praxis

Pruefe Hreflang nicht nur an einer Seite. Internationale Fehler entstehen oft im Cluster. Nimm eine URL-Gruppe und kontrolliere alle Varianten gemeinsam: Statuscode, Canonical, hreflang, x-default, Sprache, mobile Ausgabe, Sitemap und interne Links.

Wenn eine Variante fehlt, kaputt ist oder auf eine falsche Canonical zeigt, ist nicht nur diese Seite betroffen. Das ganze Alternates-Set kann unzuverlaessig werden.

Search Console Hinweis

Der alte International-Targeting-Report in Search Console ist deprecated. Das bedeutet nicht, dass Google Hreflang nicht mehr nutzt. Es bedeutet nur, dass dieser alte Bericht nicht mehr die zentrale Pruefoberflaeche ist.

In der Praxis musst du deshalb anders pruefen: URL Inspection fuer einzelne Beispiele, Crawling-Tools fuer komplette Cluster, Sitemap-Checks fuer grosse Sets und Logikpruefungen fuer Canonical, Statuscode und Indexierbarkeit. Hreflang ist gerade deshalb ein Thema, das man nicht nur visuell im Browser kontrollieren sollte.

Governance fuer internationale Teams

Hreflang ist selten ein einmaliges Setup. Neue Maerkte, neue CMS-Templates, ein Domainwechsel, ein Relaunch oder eine neue mobile Navigation koennen die Signale veraendern. Deshalb sollte jedes internationale Team klare Verantwortlichkeiten haben: Wer legt neue Sprachcodes an? Wer prueft Canonicals? Wer kontrolliert, ob die Sitemap nach dem Publishing wirklich aktualisiert wurde?

Eine gute Regel: Jede neue lokale Seite darf erst live gehen, wenn ihr gesamtes Alternates-Set komplett ist. Sonst entsteht ein halb fertiger Cluster, der fuer Nutzer und Suchmaschinen widerspruechlich wirkt.

Mini-Workflow

1. Definiere die echten Sprach- und Regionsvarianten. 2. Entscheide dich fuer HTML, HTTP Header oder Sitemap. 3. Erzeuge fuer jede URL ein vollstaendiges Hreflang-Set inklusive Self-Reference. 4. Fuege x-default hinzu, wenn es eine globale Auswahl- oder Fallback-Seite gibt. 5. Pruefe Canonicals, Statuscodes und Indexierbarkeit. 6. Vergleiche mobile und Desktop-Ausgabe. 7. Wiederhole die Pruefung nach neuen Laendern, CMS-Aenderungen oder Relaunches.

Contextter-Perspektive

Contextter kann Hreflang als Teil der Content-Lokalisierung behandeln. Es reicht nicht, Texte zu uebersetzen. Jede lokale Seite braucht passende Suchintention, lokale Belege, richtige technische Signale und eine klare Beziehung zu den anderen Varianten.

So wird Hreflang nicht nur ein Tag im Head, sondern ein Qualitaetscheck fuer internationale SEO-Architektur.

Verwandte Begriffe

• international-seo
• content-localization
• canonical-tag
• xml-sitemap
• mobile-first-indexing
• duplicate-content

Quellen und weiterfuehrende Ressourcen

• Google Search Central: Localized versions of your pages
• Google Search Central: Managing multi-regional and multilingual sites
• Google Search Central: How Google crawls locale-adaptive pages
• Google Search Central: Canonicalization
• Google Search Central: Specify canonical URLs
• Google Search Central: Fix canonicalization issues
• Google Search Central: Build and submit a sitemap
• Google Search Central: Mobile-first indexing
• Google Search Central: Site moves with URL changes
• Google Search Console Help: URL Inspection tool
• Google Search Console Help: International Targeting report deprecated