hreflang

Was hreflang wirklich ist: Signal, nicht Direktive

Wer hreflang als Rankingfaktor behandelt, hat das Attribut nicht verstanden. hreflang entscheidet nicht, ob eine Seite rankt, sondern welche Version eines bereits rankenden Seitenclusters in einem bestimmten Markt ausgespielt wird. Google bildet aus den per rel="alternate" annotierten URLs einen Cluster gleichwertiger Sprachversionen und tauscht zur Query-Zeit die URL gegen die Variante aus, die zur Sprache und Region des Nutzers passt. Eine Version erarbeitet sich die Position, der Cluster verteilt sie.

Seit Google das Attribut 2011 im Webmaster Central Blog eingeführt hat, ist dieses Grundprinzip unverändert: hreflang ist laut Google Search Central ein Hinweis, keine Direktive. Google kann jede Annotation ignorieren, wenn andere Signale dagegen sprechen, und tut das in der Praxis regelmäßig, etwa wenn die verlinkten Versionen inhaltlich nicht äquivalent sind oder Rückverweise fehlen. John Mueller hat hreflang öffentlich als einen der komplexesten Aspekte von SEO bezeichnet (Search Engine Journal, 2018), und das deckt sich mit unserer Audit-Erfahrung: kaum ein Setup mit mehr als fünfzig URLs ist auf Anhieb fehlerfrei.

Dieses Video liefert eine kompakte Einführung, bevor wir in die Mechanik einsteigen:

Die wichtigste Abgrenzung gleich vorweg: hreflang löst kein Duplicate-Content-Problem, sondern ein Targeting-Problem. Bei nahezu identischen Seiten für de-DE, de-AT und de-CH wäre ein Canonical das falsche Werkzeug, weil es zwei der drei Versionen aus dem Index nehmen würde. hreflang hält die Varianten getrennt indexierbar und sagt Google lediglich, welche davon wem gezeigt werden soll. Das Zusammenspiel von Canonical-Tag und hreflang ist deshalb keine akademische Frage, sondern die häufigste Fehlerquelle in internationalen Setups.

Mechanik und Implementierung im Jahr 2026

Drei Implementierungswege stehen zur Verfügung, alle gleichwertig aus Googles Sicht: Link-Elemente im head, HTTP-Header für Nicht-HTML-Dokumente wie PDFs, und die Sitemap. Die Wahl ist eine Frage der Wartbarkeit, nicht der Wirkung. Unsere klare Position: ab wenigen hundert URLs gehört hreflang in die XML-Sitemap, nicht ins Template. head-Annotationen blähen jede einzelne Seite auf (bei zwanzig Sprachversionen sind das zwanzig Link-Elemente auf jeder der zwanzig Versionen, also vierhundert Zeilen pro Cluster) und sie brechen schleichend, wenn das Template angefasst wird, ohne dass es jemand merkt. Die Sitemap zentralisiert die Pflege an einem Ort, den der Crawler ohnehin liest.

Die Syntax ist streng: Sprachcode nach ISO 639-1, optional ergänzt um einen Regionscode nach ISO 3166-1 Alpha 2, immer in dieser Reihenfolge. hreflang="de" adressiert deutschsprachige Nutzer überall, hreflang="de-AT" deutschsprachige Nutzer in Österreich. Ein Regionscode ohne Sprache ist ungültig. Ein Beispiel für ein vollständiges Cluster im head:

<link rel="alternate" hreflang="de-DE" href="https://www.example.com/de/" />
<link rel="alternate" hreflang="de-AT" href="https://www.example.com/at/" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.com/en-gb/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

Zwei Regeln entscheiden darüber, ob das Setup funktioniert oder ignoriert wird. Erstens die Selbstreferenz: jede Seite im Cluster annotiert auch sich selbst. Zweitens die Bidirektionalität: wenn Seite A auf Seite B verweist, muss B auf A zurückverweisen, sonst verwirft Google das Paar komplett (Google Search Central Dokumentation). Genau dieser Mechanismus macht hreflang so fragil: eine einzige vergessene Annotation invalidiert die Verbindung für beide Seiten.

x-default deckt alle Nutzer ab, deren Sprache und Region zu keiner annotierten Version passen. Pflicht ist der Wert nicht, Google empfiehlt ihn aber, und in der Praxis gehört er auf die Version mit der stärksten internationalen Tragfähigkeit oder auf einen Sprachwähler. Eine Fußnote, die viele übersehen: Bing verarbeitet hreflang nicht, sondern orientiert sich an content-language und eigenen Signalen (Bing Webmaster Dokumentation). Wer in mehreren Märkten relevanten Bing-Traffic hat, braucht dafür eine separate Antwort.

Wo hreflang im internationalen Linkaufbau zählt

Der Punkt, der in den meisten Glossaren fehlt: hreflang vererbt keine Linksignale. Jede Sprachversion rankt auf Basis ihres eigenen Profils, der Cluster tauscht nur die ausgespielte URL innerhalb einer bereits erreichten Position. Aus eigener Audit-Erfahrung ist das der häufigste Denkfehler bei Markteintritten: ein de-CH-Ableger mit null verweisenden Domains profitiert nicht automatisch vom starken de-DE-Profil. Wenn keine Version des Clusters für eine Query rankt, gibt es schlicht nichts zu tauschen.

Für eine Netlinking-Operation heißt das: jeder Markt braucht ein eigenes Linkprofil aus sprachlich passenden Quellen. Ein deutsches Publikum erreicht man über deutsche Medien, nicht über übersetzte Ankertexte auf französischen Domains. Genau dafür betreiben wir bei Stringer deutschsprachige Medien im Eigenbetrieb, deren Metriken offen einsehbar sind; wer Quellen für einen bestimmten Markt evaluieren will, kann den Katalog ohne Anmeldung filtern. Der operative Punkt bleibt derselbe, egal woher die Links kommen: hreflang verteilt Sichtbarkeit, die pro Markt erst aufgebaut werden muss.

Die Reihenfolge beim Markteintritt ergibt sich daraus fast von selbst: zuerst die Version mit dem stärksten Linkprofil stabilisieren und x-default darauf setzen, dann die Märkte einzeln nachziehen und pro Markt verlinken. Wer alle Versionen gleichzeitig launcht und auf einen Cluster-Effekt hofft, wartet auf einen Mechanismus, den es nicht gibt.

Typische Fehler aus der Audit-Praxis

Der mit Abstand häufigste Fehler sind fehlende Rückverweise. Er entsteht selten durch Nachlässigkeit, sondern durch Architektur: die deutsche Version wird im CMS gepflegt, die englische in einem separaten Shop-System, und keines der beiden Templates weiß vom anderen. Das Ergebnis sind einseitige Annotationen, die Google komplett verwirft. Das Setup sieht im Quelltext korrekt aus und tut trotzdem nichts.

Das folgende Video ergänzt die Fehlerliste um zehn praxisnahe Hinweise zur korrekten Einbindung:

Direkt danach kommen ungültige Codes. en-UK statt en-GB ist der Klassiker (Großbritannien heißt im ISO-Standard GB), gefolgt von erfundenen Kombinationen wie eu für ein europäisches Targeting, das in der Spezifikation nicht existiert. Relative URLs sind die dritte Stolperfalle: hreflang verlangt absolute URLs inklusive Protokoll.

Subtiler und teurer sind Annotationen auf nicht-indexierbare Ziele. Jede hreflang-URL muss der kanonischen, indexierbaren Endform der Seite entsprechen: kein Redirect dazwischen, kein noindex, kein Canonical auf eine andere URL. Sobald eine Version per Canonical auf die deutsche Hauptversion zeigt (ein Muster, das wir regelmäßig in de-AT-Setups finden), kollabiert der Cluster: Google indexiert nur das Canonical-Ziel, und die österreichische Version verschwindet aus genau dem Markt, für den sie gebaut wurde.

Was dabei beruhigen sollte: kaputtes hreflang führt selten zu einer Abstrafung, es führt zu Wirkungslosigkeit. Google fällt auf seine eigene Heuristik zurück und spielt die Version aus, die es für passend hält. Das Risiko ist also kein Penalty, sondern falsche Versionen in falschen Märkten, messbar als de-DE-Impressionen in der Schweiz oder als englische Snippets für deutsche Queries.

Tools und Debugging: was nach dem GSC-Report bleibt

Google hat den International-Targeting-Report in der Search Console 2022 eingestellt (Google Search Central). Seitdem existiert keine native hreflang-Fehlerliste mehr, und das verändert den Debugging-Workflow grundlegend: die Prüfung wandert in Crawler. Der Ahrefs Site Audit deckt fehlende Rückverweise und ungültige Codes zuverlässig auf, Sistrix bringt Validator und Generator im Toolset mit, und Screaming Frog bleibt das Arbeitstier für die Cluster-Analyse auf URL-Ebene.

Wie man der Search Console trotz des weggefallenen Reports noch hreflang-relevante Signale entlockt, zeigt dieses kurze Video:

Der Workflow, der sich bei uns bewährt hat: ein repräsentatives Cluster pro Template-Typ auswählen, alle Mitglieder crawlen, Rückverweise und Indexierbarkeit jeder Ziel-URL verifizieren, dann im Leistungsbericht der Search Console nach Land filtern und prüfen, ob die richtige Version die Impressionen einsammelt. Deutsche Impressionen auf der österreichischen URL sind das deutlichste Symptom eines ignorierten Clusters. Wer diese Prüfung quartalsweise ansetzt statt einmalig beim Launch, fängt die schleichenden Template-Brüche ab, die hreflang-Setups erfahrungsgemäß zersetzen.

Taktische Einordnung für den Arbeitsalltag

hreflang ist 2026 weder wichtiger noch unwichtiger als vor fünf Jahren, aber es wird konsequenter ignoriert, wenn es schlampig implementiert ist. Google verlässt sich zunehmend auf eigene Sprach- und Geo-Erkennung; das Attribut ist die Möglichkeit, dieser Heuristik zuvorzukommen, nicht sie zu überstimmen. Für die Priorisierung heißt das: bei zwei oder drei Versionen mit klar getrennten Sprachen ist hreflang in einer Stunde sauber aufgesetzt und danach kein Thema mehr. Bei Same-Language-Splits wie de-DE gegen de-AT gegen de-CH ist es dagegen geschäftskritisch, weil nur hreflang die Märkte trennt, und genau dort verdient die Implementierung den Aufwand einer eigenen Sitemap-Pipeline plus quartalsweisem Audit.

Die ehrliche Schlussbemerkung, ohne Floskeln: hreflang gewinnt keine Rankings, es verhindert, dass gewonnene Rankings im falschen Markt landen. Die Reihenfolge der Investition bleibt Inhalt und Linkprofil pro Markt zuerst, Annotation danach. Wer es umgekehrt macht, optimiert die Verteilung von Sichtbarkeit, die noch gar nicht existiert.