hreflang Tags: Der komplette Implementierungsleitfaden 2026 von ConveyThis

Fassen Sie diesen Beitrag zusammen mit: 11 Minuten Lesezeit

ChatGPT Ratlosigkeit Grok Google AI

hreflang ist das am häufigsten falsch implementierte Tag in der mehrsprachigen SEO. Nach der Prüfung von 500+ internationalen Websites kann ich Ihnen sagen, dass auf etwa 80% davon die gleichen fünf Fehler auftreten. So machen Sie es beim ersten Mal richtig — einschließlich der Randfälle, die niemand dokumentiert.

Wenn Sie jemals die Search Console geöffnet und die Warnung gesehen haben “Ihre Website hat keine hreflang-Tags” — oder schlimmer noch, die stille Variante, bei der Google einfach aufhört, Ihre übersetzten Seiten zu ranken, und Sie nicht herausfinden können, warum — dieser Leitfaden ist für Sie.

hreflang ist eines jener technischen SEO-Themen, die immer wieder erklärt werden, aber nie ganz klicken, weil bei den meisten Erklärungen die Teile übersprungen werden, die in der Produktion tatsächlich kaputt gehen. Das vierzeilige Beispiel funktioniert einwandfrei, bis Sie 23 Sprachen, regionale Varianten, AMP-Seiten und einen Checkout-Flow haben, der auf einer Subdomain lebt. Dann fällt alles still und leise auseinander und Ihr deutscher Verkehr sinkt innerhalb eines Quartals um 40 %.

Dieser Leitfaden behandelt die Implementierung, die in der realen Welt funktioniert. Nicht die Lehrbuchversion. Die Version, in der Cloudflare Ihre Header zwischenspeichert, Next.js Seiten bei Bedarf generiert und Ihr CMS abschließende Schrägstriche hinzufügt, die in Ihrer Sitemap nicht vorhanden sind.

Was hreflang eigentlich macht (und nicht macht)

hreflang teilt Suchmaschinen mit, welche Version einer Seite Benutzern in verschiedenen Sprachen oder Regionen angezeigt werden soll. Es ist ein Beziehungssignal, kein Ranking-Signal.

Diese Unterscheidung ist wichtig. Das Hinzufügen von hreflang führt nicht dazu, dass Ihr französischer PageRank in Frankreich höher ist. Es teilt Google mit: “Diese englische Seite und diese französische Seite sind gleichwertige Übersetzungen desselben Inhalts. Wenn jemand von Frankreich aus auf Französisch sucht, zeigen Sie ihm das französische.” Ohne sie könnte Google Ihre französische Seite immer noch bewerten, aber es könnte Ihre englische Seite auch französischen Suchenden zur Verfügung stellen — oder, schlimmer noch, beide als doppelten Inhalt behandeln und einen auswählen, den sie herabstufen möchten.

Drei Dinge, die hreflang tut:

• Leitet die richtige Sprachversion an den richtigen Benutzer weiter.
• Verhindert Strafen für doppelte Inhalte zwischen übersetzten Seiten.
• Konsolidiert Ranking-Signale über Sprachvarianten desselben Inhalts hinweg.

Drei Dinge, die hreflang nicht tut:

• Übersetzen Sie Ihre Inhalte (offensichtlich, aber erwähnenswert).
• Verbessern Sie das Ranking innerhalb eines Binnenmarkts.
• Beheben Sie die schlechte Übersetzungsqualität. Google bewertet die Übersetzungsqualität zunehmend unabhängig.

Die grundlegende Syntax (und warum die meisten Beispiele unvollständig sind)

Hier ist die Version, die Ihnen die meisten Anleitungen zeigen. Es ist richtig, und es fehlt auch die wichtigste Zeile:

<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />

Dieser Ausschnitt deklariert drei Sprachversionen. Es wird teilweise funktionieren. Das Problem: Jede Seite, die diese Tags verwendet, muss in der Liste auf sich selbst verweisen. Andernfalls behandelt Google die Referenzen als einseitig und verwirft sie möglicherweise.

Die vollständige Version auf der englischen Seite sieht folgendermaßen aus:

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

Zwei Dinge haben sich geändert:

• Selbstreferenzierender hreflang. Die englische Seite deklariert sich nun als englische Version. Ohne dies wurde dokumentiert, dass der Algorithmus von Google den gesamten hreflang-Cluster auf dieser Seite ignoriert.
• x-Standard. Dadurch wird die Fallback-Seite für Benutzer deklariert, deren Sprache keiner angegebenen Version entspricht. Wenn ein koreanischer Benutzer auf Ihrer Site landet und Sie kein Koreanisch haben, teilt x-default Google mit, welche Seite bereitgestellt werden soll.

Hier ist nun der Teil, der fast nie richtig erklärt wird: Für die französische Seite und die deutsche Seite gilt die gleiche Logik. Auf jeder Seite müssen alle Sprachversionen aufgeführt sein, einschließlich sich selbst und x-default. Nicht nur die englische Quelle.

Auf der französischen Seite:

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

Identisch mit der englischen Seite. Das ist der Punkt. hreflang-Deklarationen müssen reziprok sein — jede Sprachversion muss auf jede andere Sprachversion verweisen. Wenn Seite A auf Seite B zeigt, muss Seite B auf Seite A zurückzeigen. Google ruft diese “Return-Tags” auf und sie sind die am häufigsten fehlgeschlagene Validierungsregel in der internationalen SEO.

Sprachcodes: der Spickzettel

hreflang-Codes folgen dem Format language oder language-REGION. Sprachen verwenden ISO 639-1 (zweistellig, kleingeschrieben). Regionen verwenden ISO 3166-1 Alpha 2 (zweistellig, Großbuchstaben). Die häufigsten Verwirrungen:

Das Vereinigte Königreich ist kein Ländercode. Dies ist der häufigste Fehler, den ich in 10 Jahren Audits gesehen habe. Der ISO 3166-1-Code für das Vereinigte Königreich lautet GB. Verwenden en-GB, nicht en-UK. Google ignoriert ungültige Codes stillschweigend — Ihr Tag existiert, aber es tut nichts.

Drei Implementierungsmethoden

hreflang kann an drei Stellen deklariert werden. Jedes hat Kompromisse.

Methode 1: HTML <head> Tags (am häufigsten)

Tags platziert in der <head> Abschnitt jeder Seite. Einfach zu debuggen, einfach zu überprüfen, wird von jedem CMS unterstützt. Der Nachteil: Jede Seite muss das Tag jeder anderen Sprache enthalten, was bedeutet, dass für eine 50-seitige Site in 10 Sprachen 500 hreflang-Deklarationen generiert und synchron gehalten werden müssen.

Verwenden Sie diese Methode, wenn Ihre Website weniger als ~10.000 Seiten hat oder Ihr CMS die hreflang-Generierung automatisch übernimmt.

Methode 2: HTTP-Header (für Nicht-HTML-Dateien)

hreflang kann als HTTP-Link-Header gesendet werden. Nur so kann hreflang für Nicht-HTML-Ressourcen wie PDFs deklariert werden:

Link: <https://example.com/en/file.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/fr/file.pdf>; rel="alternate"; hreflang="fr"

Verwenden Sie HTTP-Header, wenn Sie herunterladbare Assets haben, die in mehreren Sprachen vorhanden sind — Produkthandbücher, Regulierungsdokumente, Whitepaper.

Methode 3: XML-Sitemap (für große Websites)

Für Websites mit Hunderttausenden von Seiten deklarieren Sie hreflang in <head> Tags werden unhandlich. Sitemap-basiertes hreflang ist effizienter und hält Ihr HTML schlank:

<url>
  <loc>https://example.com/</loc>
  <xhtml:link rel="alternate" hreflang="en"
              href="https://example.com/" />
  <xhtml:link rel="alternate" hreflang="fr"
              href="https://example.com/fr/" />
  <xhtml:link rel="alternate" hreflang="x-default"
              href="https://example.com/" />
</url>

Es gelten die gleichen Gegenseitigkeitsregeln. Jeder URL-Eintrag in der Sitemap muss jede Sprachversion auflisten, einschließlich sich selbst.

Mischen Sie keine Methoden. Wählen Sie einen Ansatz pro Site und bleiben Sie dabei. Widersprüchliche hreflang Signale von <head> und Sitemap ist einer der frustrierendsten Fehler, die es zu debuggen gilt, da das Verhalten von Google in diesem Fall undokumentiert und inkonsistent ist.

Die fünf Fehler, die ich bei 80 % der Audits sehe

1. Fehlender selbstreferenzieller hreflang

Auf der englischen Seite sind die französische und die deutsche Version aufgeführt, sie wird jedoch nicht als englische Version bezeichnet. Google ignoriert den gesamten hreflang-Cluster. Fix: Jede Seite muss ein hreflang-Tag enthalten, das auf sich selbst zeigt.

2. Nicht reziproke Rücksendeetiketten

Die englische Seite verweist auf die französische Seite. Die französische Seite zeigt nicht zurück. Google hält dies für kaputt und verwirft die Beziehung möglicherweise. Fix: Jede Referenz muss auf Gegenseitigkeit beruhen. Auf der französischen Seite muss die englische Seite als englische Alternative aufgeführt sein.

3. Verweisen von hreflang auf umgeleitete URLs

Ihre englische Seite gibt die französische Version an unter https://example.com/fr/ aber diese URL 301-leitet weiter zu https://example.com/fr/home/. Google folgt der Weiterleitung, aber das hreflang-Signal wird abgeschwächt — und in einigen Fällen vollständig ignoriert.

Fix: hreflang muss auf die endgültige kanonische URL verweisen, nicht auf eine Umleitungskette. Audit mit einem Crawler, der Nicht-200-Hreflang-Ziele markiert.

4. hreflang und kanonische Konflikte

Ihre französische Seite verfügt über einen kanonischen Verweis auf die englische Seite (weil jemand das kanonische Tag kopiert und eingefügt hat). Google liest dies so “die französische Seite ist nur ein Duplikat der englischen Seite” und die hreflang-Beziehung wird ignoriert. Fix: Jede übersetzte Seite muss sich selbst kanonisieren. Der Kanon der französischen Seite verweist auf sich selbst, nicht auf das englische Original.

5. Uneinheitliches Mischen von Sprach- und Regionalcodes

Einige Seiten deklarieren hreflang="en", erklären andere hreflang="en-US". Google behandelt diese als separate Sprachcluster. Wählen Sie eine Strategie pro Sprache und bleiben Sie auf der gesamten Website dabei.

Edge-Fälle, die niemand dokumentiert

Randfall 1: Nur regionales Targeting (en-CA ohne en)

Sie haben eine englisch-kanadische Variante Ihrer Seite, aber keine globale englische Version. Nicht verwenden hreflang="en" allein — Google stellt Ihre kanadische Seite möglicherweise britischen Benutzern zur Verfügung, was wahrscheinlich nicht das ist, was Sie möchten. Stattdessen erklären hreflang="en-CA" Konkret und lassen x-default Nicht-kanadische Englischsprachige behandeln.

Edge Case 2: Gleicher Inhalt, unterschiedliche Regionen

US-amerikanische, britische und australische englische Versionen derselben Produktseite mit identischem Text. Das ist in Ordnung — jede Region explizit deklarieren:

<link rel="alternate" hreflang="en-US" href="https://example.com/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />
<link rel="alternate" hreflang="en-AU" href="https://example.com/au/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Auch wenn der Inhalt identisch ist, sind regionale hreflang-Varianten für Produkte mit regionalspezifischer Preisgestaltung, Währung oder Versand wertvoll.

Edge Case 3: Mobile und Desktop-Varianten

Wenn Sie separate mobile Seiten mit m.-Subdomänen haben, benötigt jede mobile Seite ihre eigenen hreflang-Deklarationen, die auf andere mobile Sprachvarianten verweisen. Richten Sie eine mobile französische Seite nicht auf eine englische Desktop-Seite — Google betrachtet dies als defekten Cluster.

Edge Case 4: Subdomains vs. Unterverzeichnisse

Beide funktionieren für hreflang. fr.example.com und example.com/fr/ sind gleichermaßen gültig. Die Wahl ist operativ (DNS, Hosting, Analytik) — kein SEO-Faktor für sich. Entscheidend ist die Konsistenz: Wählen Sie eine Struktur aus und wenden Sie sie auf alle Sprachen an.

Randfall 5: Paginierung

Seite 2 Ihres französischen Blogindex sollte hreflang auf Seite 2 Ihres englischen Blogindex deklarieren, nicht auf Seite 1. Ordnen Sie äquivalente Seiten äquivalenten Seiten zu, einschließlich Paginierung, Abfrageparametern und Filtern.

Edge Case 6: 404 und 410 Seiten

Wenn eine übersetzte Version einer Seite (noch) nicht existiert, deklarieren Sie hreflang nicht für diese Sprache. hreflang auf eine 404 zu verweisen ist schlimmer, als es gar nicht zu deklarieren — Google sieht darin eine kaputte Beziehung und degradiert möglicherweise den gesamten Cluster.

So validieren Sie vor der Veröffentlichung

Drei Tools decken 95 % des Validierungsbedarfs ab:

• Google Search Console → Internationales Targeting. Zeigt hreflang-Fehler an, die vom Crawler von Google erkannt wurden. Langsam zu aktualisieren (3–7 Tage nach einer Änderung), aber maßgeblich.
• Schreiender Frosch. Crawlt Ihre gesamte Site und meldet nicht reziprokes hreflang, fehlende Return-Tags, defekte hreflang-URLs und Inkonsistenzen. Das beste Tool für die Qualitätssicherung vor dem Start.
• Merkles hreflang-Tag-Testtool. Kostenlos, browserbasiert, gut für Stichprobenkontrollen während der Entwicklung.

Führen Sie alle drei vor jedem größeren Start aus. Die Search Console erfasst, was Google sieht. Screaming Frog fängt ein, was sich tatsächlich auf Ihrer Site befindet. Merkle fängt auf, was Sie bei der Codeüberprüfung übersehen haben.

Wie automatisierte Tools mit hreflang umgehen

Wenn Sie eine Website-Übersetzungsplattform wie ConveyThis, Weglot oder ähnliches verwenden, sollte die hreflang-Generierung automatisch erfolgen. Die Plattform crawlt Ihre Inhalte, erkennt neue Seiten und fügt in jede übersetzte Version die richtigen hreflang-Tags ein — einschließlich selbstreferenzierender Tags, Return-Tags und x-default.

Dies ist das stärkste Argument für die Verwendung einer Übersetzungsplattform gegenüber einer manuellen Übersetzungspipeline. Die manuelle Pflege von hreflang auf einer 200-seitigen Website in 12 Sprachen bedeutet die Verfolgung von 31.200 Tag-Beziehungen. Jede neue Seite fügt 12 neue Beziehungen hinzu, die an 12 Stellen hinzugefügt werden müssen. Manuelle Wartungspausen im großen Maßstab.

Wenn Sie eine Plattform verwenden und in der Search Console immer noch hreflang-Fehler sehen, liegt die Ursache normalerweise an einem von drei Dingen: einer CDN-Caching-Schicht, die Header entfernt, einem CMS-Plugin, das Tags überschreibt, oder einer Umleitungsregel, die die kanonische Struktur stört. Alle drei sind reparierbar, erfordern jedoch eine Koordination zwischen Ihrer Übersetzungsplattform, Ihrem Hosting-Setup und Ihrem CDN.

Das Fazit

hreflang ist nicht kompliziert. Es ist ausführlich. Die Komplexität ergibt sich aus der Menge der Deklarationen und der Fragilität jedes einzelnen fehlenden Tags. Machen Sie die Grundlagen richtig — selbstreferenzierend, reziprok, kanonisch ausgerichtet, x-Standard vorhanden — und der Rest ist nur Wartung.

Die meisten internationalen Websites verlieren 20–40% ihres potenziellen fremdsprachigen Datenverkehrs durch hreflang-Fehlkonfigurationen. Beheben Sie die Grundlagen und Sie werden wahrscheinlich eine sinnvolle Wiederherstellung des Datenverkehrs in den Sprachversionen sehen, die zuvor falsch eingestuft oder mit dem falschen Original zusammengeführt wurden.

Es handelt sich um den technischen SEO-Fix mit der höchsten Hebelwirkung auf mehrsprachigen Websites. Verbringen Sie den Nachmittag.

Über den Autor

Alex Buran, Gründer von ConveyThis

Alex hat das letzte Jahrzehnt damit verbracht, die Infrastruktur für mehrsprachige Websites aufzubauen. Er schreibt über Lokalisierung, KI-Suche und die technische Seite der Globalisierung.

LinkedIn: https://www.linkedin.com/in/alexburan/

Sind Sie es leid, hreflang manuell zu debuggen? ConveyThis generiert automatisch gültige, reziproke, selbstreferenzielle hreflang-Tags auf jeder übersetzten Seite — einschließlich x-Standard- und Randfällen. Siehe die API-Dokumentation