Hauptbereich
Agency
technisches-seo

hreflang korrekt implementieren

Redaktion ·

Wenn deine Site denselben Inhalt in mehreren Sprachen oder für mehrere Länder anbietet, steht Google vor einer Auswahlfrage: Welche der Varianten soll ein Nutzer aus Österreich sehen, welche einer aus den USA? hreflang ist die Annotation, die diese Frage beantwortet. Den strategischen Überblick — ccTLD vs. Subdirectory, geografisches vs. sprachliches Targeting — liefert der Artikel International SEO. Hier geht es um die Mechanik: wie du hreflang technisch korrekt aufsetzt, ohne dass Google das ganze Set still ignoriert.

Eine Sache vorweg, weil sie das wichtigste Missverständnis auflöst: hreflang ist kein Ranking-Signal. Es macht keine Seite „besser” oder bringt sie höher. Es ist ein Cluster- und Auswahl-Signal — es sagt Google, dass mehrere URLs Übersetzungen derselben Seite sind, und welche Variante zu welcher Sprach-/Region-Einstellung passt. Google rankt dann die für den Nutzer passende Variante an der Position, die der Inhalt ohnehin verdient hätte. Mehr nicht. Und weniger, wenn die Implementierung kaputt ist.

Drei Wege, hreflang auszuliefern

Es gibt genau drei Orte, an denen hreflang stehen darf. Funktional sind sie gleichwertig — du wählst nach Architektur, nicht nach Wirkung. Mischen pro URL-Set ist nicht erlaubt; entscheide dich für einen Weg.

1. HTML-<head> link-Tags. Jede Seite trägt im <head> für jede Variante ein <link rel="alternate" hreflang="de-AT" href="…">. Vorteil: einfach zu verstehen, direkt im HTML sichtbar. Nachteil: skaliert schlecht. Bei 10 Sprachen hat jede Seite 10 Tags im Head, und jede neue Sprache vergrößert jeden Head jeder Seite. Bei vielen Seiten wird das schnell zur Pflegelast.

2. HTTP-Link:-Header. Dieselbe Information als HTTP-Response-Header: Link: <url1>; rel="alternate"; hreflang="de-AT", …. Der einzige Weg für Nicht-HTML-Dokumente wie PDFs, die keinen <head> haben. Nachteil: serverseitige Konfiguration nötig, schlechter inspizierbar.

3. XML-Sitemap mit xhtml:link. Die hreflang-Beziehungen stehen zentral in der Sitemap, jede <url>-Entry listet ihre Alternativen als <xhtml:link>. Das ist der am besten skalierende Weg bei vielen Seiten: Die Auszeichnung liegt an einer Stelle, der HTML-Head bleibt schlank, und Änderungen passieren zentral statt in jedem Template. Für große mehrsprachige Sites die Standardempfehlung.

Das Return-Tag-Prinzip: Bidirektionalität ist Pflicht

Das ist der Punkt, an dem die meisten Implementierungen scheitern — und er ist nicht verhandelbar: hreflang-Annotationen müssen gegenseitig sein. Wenn Seite A auf Seite B verweist, muss Seite B zurück auf A verweisen. Tut sie das nicht, ignoriert Google das gesamte Set, nicht nur den fehlerhaften Link. Google formuliert es eindeutig: Zeigen zwei Seiten nicht aufeinander, werden die Tags ignoriert.

Konkret heißt das: Jede Seite im Cluster listet alle Varianten — inklusive sich selbst. Eine deutsche Seite mit drei Sprachversionen trägt also vier hreflang-Einträge: de, en, fr und einen Selbstverweis auf de. Vergisst eine einzige Seite den Rücklink, kollabiert der Cluster für diese Beziehung. Genau deshalb ist die zentrale Sitemap-Variante so beliebt: Sie macht es schwerer, einen Rücklink zu vergessen, weil alle Beziehungen an einem Ort definiert sind.

x-default: die Fallback-Seite

Was passiert mit einem Nutzer, dessen Spracheinstellung zu keiner deiner Varianten passt — etwa jemand mit japanischem Browser auf deiner de/en/fr-Site? Dafür gibt es den speziellen Wert hreflang="x-default". Er markiert die Fallback-Seite: typischerweise eine Sprachauswahl-Seite oder die generische Hauptversion. x-default ist kein Pflichtfeld, aber dringend empfohlen, sobald deine Sprachen nicht den ganzen Globus abdecken — was praktisch immer der Fall ist.

Die Sprach-Region-Codes richtig setzen

hreflang-Werte folgen einem festen Format, und Tippfehler hier sind eine der häufigsten Fehlerquellen:

  • Sprache allein: ISO 639-1, zweistellig — de, en, fr. Das ist die häufigste und oft ausreichende Form, wenn du nur nach Sprache trennst, nicht nach Region.
  • Sprache + Region: ISO 639-1 plus ISO 3166-1 Alpha-2, getrennt durch Bindestrich — de-AT (Deutsch für Österreich), en-US, en-GB, pt-BR. Die Region ist immer ein Land, keine Sprache.
  • Skript-Varianten: ISO 15924, etwa zh-Hans (vereinfachtes Chinesisch) vs. zh-Hant (traditionell).

Zwei Stolperfallen: Die Region allein geht nicht — hreflang="at" ist ungültig, weil at als Sprachcode gelesen wird (den es nicht gibt). Region braucht immer eine vorangestellte Sprache. Und: en-UK ist falsch — der ISO-Ländercode für Großbritannien ist GB, nicht UK.

Die fünf häufigsten Fehler

  1. Fehlende Rücklinks. Der Klassiker. Eine Seite verweist auf ihre Varianten, aber mindestens eine verweist nicht zurück → Google ignoriert das Set. Immer alle Beziehungen bidirektional halten.

  2. Falsche Codes. en-UK statt en-GB, Region ohne Sprache, oder Nicht-ISO-Codes. Ungültige Werte werden stillschweigend verworfen — kein Fehler im Frontend, aber die Auszeichnung wirkt nicht.

  3. Mix aus self-canonical und cross-locale-canonical. Der gefährlichste Konflikt. Jede Locale muss self-canonical sein — die deutsche Seite zeigt per Canonical-Tag auf sich selbst, nicht auf die englische. Setzt du den Canonical der de-Seite auf die en-Seite, sagst du Google gleichzeitig „das ist eine eigenständige Sprachvariante” (hreflang) und „das ist nur eine Kopie der en-Seite” (Canonical). Diese Widersprüche heben sich gegenseitig auf, und der Cluster bricht. hreflang und Canonical dürfen sich nie widersprechen.

  4. hreflang auf noindex-Seiten. Eine Seite, die auf noindex steht, kann nicht Teil eines hreflang-Sets sein — Google entfernt sie aus dem Index und damit aus dem Cluster, was die Rücklink-Kette zerreißt. hreflang nur auf indexierbaren Seiten.

  5. Konflikt mit Canonical (die allgemeine Form). Über den Spezialfall 3 hinaus: Jeder Canonical, der von der ausgezeichneten Variante wegzeigt, untergräbt das hreflang-Set. Faustregel — hreflang annotiert Varianten, Canonical entscheidet über Duplikate; vermische die beiden Rollen nicht.

Debugging: woran du Fehler erkennst

hreflang-Fehler sind tückisch, weil im Frontend nichts kaputt aussieht — die Seite lädt normal, nur die internationale Zuordnung greift nicht. Drei Werkzeuge helfen:

  • hreflang-Validatoren (extern): füttern eine URL und prüfen, ob alle Rücklinks vorhanden sind, Codes gültig und keine Canonical-Konflikte bestehen. Der schnellste Reality-Check.
  • Google Search Console: Der frühere „International Targeting”-Report ist abgekündigt; aktuelle Fehler tauchen heute in der Indexierungs-/Seiten-Berichterstattung und über die URL-Prüfung auf. Prüfe dort, ob die richtige Variante als kanonisch gewählt wurde.
  • Crawler (Screaming Frog & Co.): crawlen die ganze Site und listen fehlende Rücklinks und ungültige Codes en masse — der Weg für große Sites.

Wer tiefer in Strategien für Multi-Locale-Setups einsteigen will, findet sie im Glossar unter International SEO / hreflang-Strategien.

FAQ

Ist hreflang ein Rankingfaktor? Nein. hreflang ist ein Cluster- und Auswahl-Signal, kein Ranking-Signal. Es sagt Google, welche URLs Übersetzungen voneinander sind und welche Variante zu welcher Nutzer-Sprache passt. Google rankt dann die passende Variante an der ohnehin verdienten Position — höher rankt hreflang nichts.

Warum ignoriert Google meine hreflang-Tags komplett? Mit Abstand häufigste Ursache: fehlende Rücklinks. Verweisen nicht alle Seiten gegenseitig aufeinander (inklusive Selbstverweis), verwirft Google das ganze Set. Zweithäufigst: ungültige Sprachcodes oder ein Canonical-Konflikt, bei dem die Locale nicht self-canonical ist.

Welcher Implementierungsweg ist der beste? Funktional sind alle drei gleichwertig. Bei vielen Seiten skaliert die XML-Sitemap-Variante am besten, weil alle Beziehungen zentral liegen und der HTML-Head schlank bleibt. HTML-head-Tags sind für kleine Sites okay; HTTP-Header brauchst du für Nicht-HTML-Dokumente wie PDFs.

Wofür ist x-default da? x-default markiert die Fallback-Seite für Nutzer, deren Spracheinstellung zu keiner deiner Varianten passt — etwa eine Sprachauswahl-Seite oder die generische Hauptversion. Empfohlen, sobald deine Sprachen nicht alle möglichen Nutzersprachen abdecken, also praktisch immer.

Muss jede Sprachvariante self-canonical sein? Ja. Jede Locale muss per Canonical auf sich selbst zeigen. Zeigt der Canonical stattdessen auf eine andere Sprachvariante, widerspricht das dem hreflang-Signal — Google bekommt „eigenständige Variante” und „nur Kopie” gleichzeitig und ignoriert den Cluster. hreflang und Canonical dürfen sich nie widersprechen.

Themenuebersicht

Technisches SEOCrawling & Indexierung