Sprachen

Hreflang

Was hreflang ist, die drei Wege zur Implementierung, die Regeln zu Reziprozität und Selbstreferenz, gültige Sprach- und Regionscodes und wie sich Cluster im großen Maßstab prüfen lassen.

Erstveröffentlicht: 25. Juni 2026 · Zuletzt aktualisiert: 22. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2
1 Evidenzsignal auf dieser Seite

Hreflang teilt Suchmaschinen mit, welche Sprach- oder Regionsversion einer Seite welchem Nutzer angezeigt werden soll. Deklariert wird es auf einem von drei Wegen — HTML-Tags im head, HTTP-Header oder XML-Sitemap — mit Sprachcodes nach ISO 639-1 plus Regionscodes nach ISO 3166-1 alpha-2. Es funktioniert nur als reziproker Cluster: Jede Seite muss auf sich selbst und auf alle ihre Alternativversionen verweisen, und fehlt ein Rückverweis, ignoriert Google das Paar. Es ist ein Hinweis, keine Anweisung — falsches hreflang wird ignoriert, nicht abgestraft. Es ist außerdem fragil: In meiner Studie zu 374 756 Domains mit hreflang wiesen über 67 % mindestens ein Problem auf. Bing nutzt es kaum (content-language ist dort das stärkere Signal). Dieser Hub erklärt das Gesamtbild und verweist auf die Vertiefungen.

TL;DR — Hreflang ist ein reziprokes Cluster-Signal: Jede Seite listet sich selbst und alle Alternativversionen auf, und ein fehlender Rückverweis macht das Paar ungültig. Deklarieren Sie es nur auf einem Weg — HTML-<head>, HTTP-Link-Header (PDFs) oder XML-Sitemap (am besten im großen Maßstab). Die Codes sind ISO 639-1 für die Sprache + ISO 3166-1 alpha-2 für die Region; en-UK ist falsch, richtig ist en-GB. Es ist ein Hinweis, keine Anweisung (Mueller) — falsches hreflang wird ignoriert, nicht abgestraft, und Google kann es zugunsten einer Konsolidierung gleichsprachiger Seiten oder aus Indexierungsgründen übergehen. Es geht ständig kaputt: In meiner Ahrefs-Studie zu 374 756 Domains wiesen über 67 % mindestens ein Problem auf. Bing behandelt es als weit schwächeres Signal als content-language. Prüfen Sie Cluster visuell statt in Tabellenkalkulationen.

Hreflang ist ein Cluster, kein Tag

Hreflang sits between one piece of content and the right version showing up for each market's search. Quelle: /international-seo/hreflang/

© Patrick Stox LLC · CC BY 4.0 ·

A hreflang cluster is a bidirectional graph — one missing return link breaks just that pair. Quelle: /international-seo/hreflang/

© Patrick Stox LLC · CC BY 4.0 ·

Das mentale Modell, das die meiste hreflang-Verwirrung auflöst: Es ist kein Tag pro Seite, sondern ein bidirektionaler Graph. Googles eigene Anforderung ist unmissverständlich — “Each language version must list itself as well as all other language versions,” (Übersetzung) „Jede Sprachversion muss sich selbst sowie alle anderen Sprachversionen auflisten,“ und “if two pages don’t both point to each other, the tags will be ignored.” (Übersetzung) „Wenn zwei Seiten nicht beide aufeinander verweisen, werden die Tags ignoriert.“ Verweist also Seite X auf Y, Y aber nicht auf X zurück, wird diese Kante stillschweigend verworfen. Ein einziger fehlender Rückverweis kann dazu führen, dass die betroffenen Annotationen ignoriert oder falsch interpretiert werden — Google sagt jedoch, es könne die Paare, die korrekt reziprok sind, weiterhin verarbeiten, sodass eine defekte Beziehung nicht zwangsläufig jede Annotation in einem größeren Cluster lahmlegt.

Evidence for this claim Each hreflang set should include the page itself, use fully qualified URLs, and include return links; without reciprocity, the affected annotations may be ignored or misinterpreted. Scope: Google Search hreflang guidelines; the documentation does not say one missing return link invalidates every annotation in a cluster. Confidence: high · Verified: Google: Localized versions guidelines

Daraus folgen zwei nicht verhandelbare Punkte:

  • Reziprozität. Jede Referenz muss erwidert werden. Genau hier brechen Implementierungen im großen Maßstab: Sobald ein Template, ein CMS-Feld oder die Seiten einer Region aus dem Takt geraten, fehlen Rückverweise.
  • Selbstreferenz. Jede Seite listet sich selbst auf. Mueller nennt das “optional—but good practice” (Übersetzung) „optional – aber empfehlenswert“; in der Praxis ist ein selbstreferenzieller Satz der sauberste Weg, Cluster konsistent zu halten, und sein Fehlen wird als Problem gemeldet.

Absolute, vollständig qualifizierte URLs sind ebenfalls Pflicht — https://example.com/foo, niemals //example.com/foo oder /foo.

Drei Methoden — und die Abwägungen

Google behandelt HTML-Tags, HTTP-Header und XML-Sitemaps als gleichwertig — es bringt in der Suche keinen Vorteil, mehr als eine davon umzusetzen. Wählen Sie eine Methode pro Website, abhängig davon, was Ihr Stack zuverlässig pflegen kann; sie zu mischen lädt zu Konflikten ein.

  • HTML-Tags im <head>. Am einfachsten, am sichtbarsten. Nachteil: Auf einer Website mit Dutzenden Locales trägt jede Seite einen großen Block von <link>-Tags, was Markup-Gewicht hinzufügt, und alles im <body> (durch fehlerhaftes HTML oder JS-Injektion) ist ungültig — hreflang zählt nur im <head> der Seite, so wie Google sie rendert bzw. parst.
  • HTTP-Link-Header. Die einzige Option für Nicht-HTML-Ressourcen wie PDFs. Sie werden in der Antwort gesendet und blähen das Dokument nicht auf.
  • XML-Sitemaps. Die richtige Wahl im großen Maßstab. Die Annotationen liegen zentral (xhtml:link-Kindelemente unter jedem <url>, mit dem Namensraum xmlns:xhtml="http://www.w3.org/1999/xhtml"), sodass Sie den gesamten Cluster aus einer Datenbank neu erzeugen können, ohne Seiten neu auszurollen. Es gibt keine „schnellere“ Methode — sowohl HTML als auch Sitemaps werden zur Crawl-Zeit aufgelöst —, aber Sitemaps lassen sich weit leichter prüfen, weil Sie den gesamten Graphen in einer Datei validieren können, statt jede Seite zu crawlen.
Evidence for this claim Google accepts hreflang in HTML, HTTP headers, or XML sitemaps and says the methods are equivalent from its perspective. Scope: Google Search hreflang implementation methods. Confidence: high · Verified: Google: Localized versions

Reziproke Verlinkung im großen Maßstab — wo sie bricht

Bei einer Website mit 5 Locales ist das eine 5×5-Matrix an Referenzen pro Seitensatz, die jedes Mal neu erzeugt werden muss, wenn Sie eine Locale hinzufügen oder entfernen, einen Slug korrigieren oder eine URL migrieren. Die Fehlermodi sind vorhersehbar:

  • Uneinheitliche URL-Formate. Mit oder ohne abschließenden Schrägstrich, http statt https, www statt Apex-Domain oder Groß- statt Kleinschreibung im Pfad — jede Abweichung zwischen der URL im hreflang und der URL, die Google tatsächlich indexiert, zerstört die Übereinstimmung des Rückverweises.
  • Auf weitergeleitete oder defekte URLs zeigen. Eine Locale-URL ändert sich, die Weiterleitung wird eingerichtet, aber das hreflang zeigt weiterhin auf die alte URL. Der Cluster referenziert nun eine 301 oder eine 404.
  • Code-Drift. jp statt ja für Japanisch, dreibuchstabige Codes, wo zweibuchstabige verlangt sind, en-UK statt en-GB. Ungültige Codes werden ignoriert.

Durchgespieltes Deployment-Beispiel: Der Rückverweis zeigt auf die URL von gestern

Angenommen, die britische Produktseite ist von /gb/shoes/ nach /uk/shoes/ umgezogen. Die US-Seite wurde nicht neu erzeugt und veröffentlicht daher weiterhin:

<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/gb/shoes/" />

Die alte UK-URL leitet auf /uk/shoes/ weiter, während die neue UK-Seite von ihrer finalen kanonischen URL aus auf die US-Seite zurückverweist. Damit bleiben zwei verschiedene Probleme: Die US-Annotation zielt auf eine Weiterleitung, und die finale UK-URL stimmt nicht mit der von der US-Seite deklarierten URL überein. Korrigieren Sie den Generator so, dass beide Seiten den vollständigen Satz mit finalen, indexierbaren URLs veröffentlichen:

<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/uk/shoes/" />

Prüfen Sie nach dem Deployment beide Richtungen; eine Kontrolle allein des US-Tags würde den fehlerhaften Rückverweis übersehen. Dies ist ein illustrativer .example-Cluster.

Die Lehre aus meinen Konferenzvorträgen gilt weiterhin: Erzeugen Sie hreflang automatisiert aus einer einzigen Quelle der Wahrheit. Handgepflegtes hreflang im großen Maßstab ist eine Garantie für verrottende Rückverweise.

Konflikte mit der Canonicalization

Hreflang hängt davon ab, was indexiert ist, nicht davon, was kanonisiert ist — doch beides greift ineinander, und Fehler dabei zerstören Cluster:

  • Selbstreferenzierende Canonicals sind die sichere Voreinstellung. Jede Sprachversion sollte auf sich selbst kanonisieren. Wenn Ihre spanische Seite auf die englische kanonisiert, teilen Sie Google mit, dass die spanische URL nicht die zu indexierende ist — und hreflang, das auf eine nicht-kanonische URL zeigt, gehört zu den häufigeren Fehlern.
  • Der Sonderfall gleiche Sprache, mehrere Länder. Wenn Sie etwa en-us- und en-gb-Seiten haben, die nahezu identisch sind, konsolidiert Google sie möglicherweise und indexiert nur eine — kann aber dennoch über die hreflang-Links die angezeigte URL in den Suchergebnissen gegen die passende Länderversion austauschen. Eine „wegkanonisierte“ URL kann also weiterhin für den richtigen Nutzer erscheinen. Das ist ein Feature, kein Bug, überrascht aber Menschen, welche die Indexabdeckung prüfen.
  • noindex und robots.txt. Eine von der Indexierung ausgeschlossene Seite kann nicht an einem Cluster teilnehmen — ihr hreflang kann nicht umgesetzt werden, und auf eine noindexierte oder blockierte URL zu zeigen, zerstört den Rückverweis. Blockieren oder noindexieren Sie keine Sprachvarianten, die ausgeliefert werden sollen.

Es ist ein Hinweis, keine Anweisung

Das ist die Rahmung, die man verinnerlichen sollte. Im Mai 2025 reagierte John Mueller auf Bluesky auf einen Fall, in dem fr-be-Seiten trotz korrektem hreflang in fr-Ergebnissen auftauchten: “hreflang doesn’t guarantee indexing, so it can also just be that not all variations are indexed,” (Übersetzung) „hreflang garantiert keine Indexierung, es kann also auch einfach sein, dass nicht alle Varianten indexiert sind,“ und “I suspect this is a ‘same language’ case where our systems just try to simplify things for sites.” (Übersetzung) „Ich vermute, das ist ein Fall von ‘gleicher Sprache’, in dem unsere Systeme einfach versuchen, die Dinge für Websites zu vereinfachen.“ Google behält sich vor, hreflang zugunsten einer Konsolidierung gleichsprachiger Seiten, wegen Indexierungslücken oder aufgrund eigener kanonischer Entscheidungen zu übergehen.

Googles Leitlinie zur Canonicalization ist die Kehrseite davon: Sie empfiehlt, eine kanonische URL in derselben Sprache wie die Seite zu wählen (oder den besten verfügbaren Ersatz), und besagt, dass Google URLs, die Teil eines vollständigen reziproken hreflang-Clusters sind, gegenüber ansonsten ähnlichen URLs außerhalb davon bevorzugt. Das ist eine Präferenz, kein Versprechen — in einem korrekt gebauten Cluster zu sein, erhöht die Chancen, dass die richtige URL ausgewählt wird, garantiert aber weder die Indexierung noch, welche URL angezeigt wird.

Die praktische Konsequenz: Falsches hreflang wird ignoriert, nicht abgestraft. Ist Ihr Cluster defekt, fällt Google auf die eigene Sprach- und Regionserkennung zurück. Der Preis ist eine verpasste Gelegenheit (für manche Nutzer erscheint die falsche URL), kein Ranking-Verlust. „Mein hreflang ist falsch“ ist also selten ein Notfall — aber es bringt eben auch selten etwas.

Bing und die anderen Suchmaschinen nutzen einen anderen Stack

Hreflang ist ein Signal von Google (und Yandex). Bings Signal-Stack ist komplett anders. Fabrice Canel, Principal Program Manager bei Microsoft Bing, hat unmissverständlich gesagt: “hreflang is indeed a far weaker signal than content-language at Bing.” (Übersetzung) „hreflang ist bei Bing tatsächlich ein weit schwächeres Signal als content-language.“ Bing stützt sich auf den HTTP-Header bzw. das Meta-Tag content-language, das Attribut <html lang="">, eingehende Links, die Geografie der Besucher sowie Server- und ccTLD-Standort, und Canel hat in den meisten Fällen davon abgeraten, “duplicating URLs just to have them tagged with these language-markets” (Übersetzung) „URLs zu duplizieren, nur um sie mit diesen Sprach-Märkten auszuzeichnen“. Baidu unterstützt hreflang überhaupt nicht (es orientiert sich an Hosting-Standort, chinesischer Domainregistrierung, ICP-Lizenzierung und content-language). Ein robustes internationales Setup kombiniert daher hreflang für Google mit einem korrekten content-language / html lang für alle anderen.

Die Fehlerquote ist die eigentliche Geschichte

Over 67% of domains using hreflang have at least one issue — missing x-default is the top offender. Quelle: Data: Ahrefs

Als ich die bislang größte hreflang-Studie bei Ahrefs durchgeführt habe — 374 756 Domains, fast 10× größer als jede frühere Studie — wiesen über 67 % der Domains, die hreflang nutzen, mindestens ein Problem auf. Die Verteilung:

Problem% der Domains
Fehlendes x-default56,3 %
Fehlende selbstreferenzierende Tags18,0 %
Verweise auf defekte/weitergeleitete Seiten16,9 %
Fehlende reziproke Tags15,3 %
Verweise auf nicht-kanonische URLs8,0 %
Falsche Sprach-/Ländercodes4,6 %
Uneinheitliche Sprachattribute3,2 %
Mehrere Seiten für dieselbe Sprache2,5 %
Dieselbe Seite für mehrere Sprachen2,5 %

Das Fazit meiner Studie gilt weiterhin: Hreflang ist komplex und schwer richtig umzusetzen, und es kann auf sehr viele verschiedene Arten brechen.

Prüfung im großen Maßstab — visualisieren Sie den Cluster, lesen Sie keine Tabelle

Sehen Sie sich Ihren eigenen Cluster mit returntag an:

  1. Fügen Sie eine Seiten-URL, eine Sitemap-URL oder eine Liste von Seiten-URLs in das Tool ein.
  2. Klicken Sie auf Validate cluster.
  3. Lesen Sie die Ansicht GRAPH — defekte oder fehlende Rückverweise stechen durch die Farbcodierung nach Schweregrad hervor — oder wechseln Sie zu MATRIX für eine zeilenweise Ansicht und exportieren Sie eine CSV mit der Fixliste, wenn diese an andere Beteiligte weitergegeben werden soll.

Der Grund, warum sich hreflang-Fehler verstecken: Ein Rückverweis-Problem ist eine Beziehung zwischen Seiten, und Beziehungen lassen sich über Zeilen einer Tabellenkalkulation hinweg kaum lesen. Ahrefs Site Audit war das erste Tool, das den hreflang-Cluster als Graph darstellt — öffnen Sie die URL-Details einer beliebigen Seite, und der Tab Hreflangs zeichnet den gesamten Cluster als Netzwerk, wobei die defekten Seiten und die fehlenden oder falschen Verweise rot hervorgehoben sind. Sie erkennen auf einen Blick, welcher Rückverweis fehlt oder welcher Link versehentlich hinzugefügt wurde — und es lässt sich weit besser präsentieren als eine CSV. Site Audit führt außerdem die zugrunde liegenden Prüfungen durch (ungültige Annotation, fehlende Selbstreferenz, mehr als eine Seite pro Sprache, Abweichung zwischen hreflang und html lang, fehlender reziproker Rückverweis, nicht-kanonisches Ziel, defektes Ziel), die direkt auf die Fehlerliste der Studie abbilden.

Darüber hinaus:

  • URL-Prüfung in der Google Search Console bestätigt, wie eine einzelne URL gecrawlt und indexiert wurde. Beachten Sie: Der alte Bericht zur internationalen Ausrichtung wurde am 22. September 2022 eingestellt — Google erklärte, er habe “had little value for the ecosystem.” (Übersetzung) „nur geringen Wert für das Ökosystem.“ Die hreflang-Tags selbst funktionieren weiterhin; nur der Bericht ist weg.
  • Manuelle SERP-Tests mit den Parametern &hl= (Oberflächensprache) und &gl= (Standort) an einer Google-Such-URL erlauben eine Vorschau darauf, wie die Ergebnisse einer bestimmten Locale aussehen.

Hreflang ist auch ein Thema für technische SEO-Audits

Auch wenn hreflang seine Heimat in der internationalen SEO hat, taucht es in nahezu jedem technischen SEO-Audit einer mehrsprachigen oder mehrregionalen Website auf — es steht direkt neben den Prüfungen zu Canonicalization, Indexierung und Crawl-Zugänglichkeit und gehört zu den Punkten, die am ehesten stillschweigend defekt sind. Wenn Sie ein technisches Audit durchführen und die Website mehr als eine Locale hat, gehört der hreflang-Cluster auf die Checkliste.

Wie es weitergeht

Dieser Hub ist die Landkarte für das hreflang-Subcluster. Die erste Vertiefung:

  • x-default — der Fallback-Wert für Nutzer, deren Locale zu keinem Ihrer expliziten Tags passt (eine Länderauswahl oder eine globale Startseite). Er ist nicht erforderlich, war in meiner Studie aber die mit Abstand häufigste Auslassung (56,3 % der Websites). Das eigene Unterthema behandelt, wann Sie ihn einsetzen, wann Sie ihn weglassen und wie er mit dem restlichen Cluster zusammenspielt.

Für die übergeordnete Strategie, die damit umgesetzt wird, siehe die Säule International SEO — hreflang ist die technische Ebene einer internationalen Strategie; es ersetzt keine echte Lokalisierung (lokale Intention, lokale Inhalte, lokale Autorität).

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.