Hreflang: die Konfiguration, die verhindert, dass die falsche Sprachversion in der Suche erscheint

Eine Website, die mehrere Sprachen ohne korrektes Hreflang-Markup veröffentlicht, hat ein stilles Problem: Google indexiert eine Version, zeigt sie aber manchmal dem falschen Publikum. Ein Leser in Spanien landet auf der englischen Seite, eine deutsche Leserin auf der französischen Version. Der Inhalt existiert, ist vielleicht sogar gut geschrieben, erreicht aber nicht das richtige Publikum. Hreflang ist der Mechanismus, der genau dieses Problem lösen soll, und er verzeiht wenig Ungenauigkeit.

#Wozu das Hreflang-Attribut tatsächlich dient

Das Attribut hreflang teilt Suchmaschinen mit, dass eine Seite Entsprechungen in anderen Sprachen oder für andere Regionen besitzt, und gibt die URL jeder einzelnen an. Es übersetzt nichts und beeinflusst das Ranking einer Seite nicht direkt: Es steuert lediglich, welche Version einer bestimmten Besucherin gezeigt wird, je nach Sprache ihrer Oberfläche oder der Region, aus der sie sucht.

Jede Deklaration besteht aus zwei Teilen: einem Sprachcode nach ISO 639-1 (fr, en, es, de), optional ergänzt durch einen Regionscode nach ISO 3166-1 (fr-ca für ein kanadisches Französisch, das sich vom Französisch aus Frankreich unterscheidet). Eine Region hinzuzufügen ist nur sinnvoll, wenn sich der Inhalt zwischen den Märkten tatsächlich unterscheidet; andernfalls genügt der Sprachcode allein und verringert das Fehlerrisiko.

#Zwei Methoden, nie beide gleichzeitig

Google lässt eine Kombination dieser Methoden technisch zu, empfiehlt sie aber selten: Sobald sich zwei Quellen zur selben URL widersprechen, muss die Suchmaschine entscheiden, und diese Entscheidung begünstigt nicht immer die tatsächliche Absicht der Website. Eine einzige Methode zu wählen und sie auf der gesamten Domain beizubehalten, vermeidet dieses Risiko.

#Die Regel, die am häufigsten bricht: Rückverlinkungen

Jede Seite einer Übersetzungsgruppe muss nicht nur ihre Entsprechungen deklarieren, sondern auch sich selbst. Verweist die französische Seite auf die englische Version, muss die englische Version im Gegenzug auf die französische verweisen — und auf alle anderen Sprachen derselben Gruppe. Ein fehlender Link in nur einer Richtung macht die gesamte Gruppe aus Sicht einer Suchmaschine häufig ungültig, ohne dass auf der Website selbst ein offensichtlicher Fehler sichtbar wird.

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

Genau dieser Block muss mit dem vollständigen Satz an Sprachen identisch auf jeder der vier Seiten erscheinen. Die Zeile x-default bezeichnet die Version, die einer Besucherin gezeigt wird, deren Sprache oder Region keiner der deklarierten Versionen entspricht: eine Sprachauswahlseite oder ersatzweise die neutralste Version der Website.

Ein einseitiges Hreflang ist kein unvollständiges Hreflang — es ist ein Hreflang, das Suchmaschinen für die gesamte Gruppe schlicht ignorieren.

#Deklarierte URLs müssen erreichbar sein, nicht nur korrekt

Eine in einem Hreflang-Block aufgeführte URL darf niemals weiterleiten, einen 404-Fehler zurückgeben oder selbst auf eine andere Adresse kanonisiert sein. Diese drei Fälle treten häufig nach einem Website-Relaunch auf: Alte Sprach-URLs bleiben in einer Sitemap gelistet, die nie neu erzeugt wurde, während der Inhalt bereits auf neue Adressen umgezogen ist.

Das rel="canonical"-Tag jeder Sprachversion muss ebenfalls auf sich selbst verweisen, niemals auf die als „Hauptversion“ betrachtete französische Seite. Ein sprachübergreifendes Canonical bedeutet faktisch, Suchmaschinen zu bitten, nur eine einzige Version zu indexieren, was den gesamten Sinn von Hreflang aufhebt.

#Unterverzeichnisse, Subdomains oder getrennte Domains

Hreflang funktioniert unabhängig von der gewählten Architektur zum Hosten der Sprachen, doch diese Architektur verändert den Pflegeaufwand. Eine Struktur mit Unterverzeichnissen (/fr/, /en/) bündelt die Autorität der Domain auf einer einzigen Adresse und bleibt für ein kleines Team am einfachsten zu pflegen. Sprachsubdomains trennen die technischen Konfigurationen stärker, was vor allem hilft, wenn jeder Markt ein eigenständiges Redaktionsteam hat. Getrennte Länderdomains (.fr, .de) rechtfertigen sich in der Regel nur durch eine rechtliche oder geschäftliche lokale Präsenz, selten allein durch die Übersetzung redaktioneller Inhalte.

Unabhängig von der gewählten Architektur entfällt keine der vorherigen Regeln: vollständige Rückverlinkungen, erreichbare URLs, selbstreferenzierendes Canonical. Eine getrennte Domain pro Land birgt sogar ein eigenes Risiko: die wechselseitige Deklaration zwischen zwei unterschiedlichen Domains zu vergessen — ein Fehler, der zwischen zwei Unterverzeichnissen derselben Website naturgemäß leichter auffällt.

#Code-Fehler und Kontrolle nach der Veröffentlichung

Ein fehlerhaft formatierter Sprach- oder Regionscode zeigt auf der Website keinen sichtbaren Fehler, führt aber dazu, dass Suchmaschinen die Deklaration ignorieren. Die häufigsten in Audits beobachteten Fälle:

Das erwartete Format setzt den Sprachcode stets klein geschrieben vor einen eventuellen Regionscode; die Groß-/Kleinschreibung spielt für Suchmaschinen keine Rolle, aber die Kleinschreibungs-Konvention verhindert uneinheitliches Kopieren zwischen Teams.

Eine regelmäßige Kontrolle statt einer einmaligen Prüfung beim Launch bleibt der beste Schutz gegen diese Fehler: das Hinzufügen einer Sprache, ein teilweiser Relaunch oder ein Wechsel des Übersetzungswerkzeugs sind die drei Momente, in denen ein Rücklink am häufigsten verloren geht. Strukturierte Daten in JSON-LD werden auf jeder Sprachversion separat deklariert: Ein englisches Article– oder NewsArticle-Schema darf keinen französischen Inhalt beschreiben, selbst wenn beide Seiten dieselbe Struktur teilen. Beim Tracking sollte jede Version als eigenständige Property in den Analysewerkzeugen erscheinen, um sprachweise zu prüfen, ob der organische Traffic tatsächlich zur vorgesehenen geografischen Zone passt — eine Kontrolle, die sich in das GA4- und Search-Console-Dashboard einer bereits laufenden Website einfügt.

#Das Wichtigste in Kürze

Hreflang verlangt keine komplexe Konfiguration, sondern eine exakte: eine einzige Implementierungsmethode, vollständige und in beide Richtungen geprüfte Rückverlinkungen, ein explizites x-default und ausnahmslos erreichbare URLs ohne Weiterleitungen oder sprachübergreifende Canonicals. Die meisten in Audits gefundenen Probleme entstehen durch ein punktuelles Versehen nach einer Inhaltsaktualisierung, nicht durch einen fehlerhaften ursprünglichen Entwurf.

Zum Weiterlesen: Die offizielle Google-Search-Central-Dokumentation zu lokalisierten Versionen behandelt Sonderfälle, unter anderem Websites, die mehrere Domains pro Sprache kombinieren.