Hreflang-Tag einfach erklärt: So steuerst du Sprache & Land bei Google

Ein Hreflang-Tag ist eines der wichtigsten Werkzeuge im internationalen SEO: Es hilft Suchmaschinen zu verstehen, welche Seitenversion (Sprache und/oder Land) für welche Nutzer:innen gedacht ist. Richtig eingesetzt, reduziert hreflang falsche Ausspielungen in den Suchergebnissen, verhindert Kannibalisierung zwischen Sprachversionen und verbessert die Nutzererfahrung. In diesem Guide lernst du, wann hreflang sinnvoll ist, wie die Implementierung funktioniert und welche Fehler du unbedingt vermeiden solltest.

Was ist ein Hreflang-Tag und wofür wird er genutzt?

Der Hreflang-Tag (genauer: das Attribut hreflang) ist eine Auszeichnung, mit der du Suchmaschinen alternative Versionen einer Seite zuordnest – typischerweise nach Sprache (z. B. de, en) und optional nach Region/Land (z. B. de-DE, de-CH, en-US). Ziel ist, dass Google Nutzer:innen die passendste Seitenversion ausspielt. Das ist besonders relevant, wenn Inhalte in mehreren Sprachen existieren oder wenn du länderspezifische Varianten mit sehr ähnlichem Content hast (z. B. Währung, Versand, rechtliche Hinweise).

Wichtig: hreflang ist kein Ranking-Boost, sondern ein Ausspielungs-Signal

Hreflang steigert Rankings nicht „magisch“. Es sorgt aber dafür, dass die richtige URL in der richtigen Region rankt. Ohne hreflang kann Google etwa die deutsche Seite in Österreich oder die US-Seite in UK anzeigen. Das führt häufig zu schlechteren Nutzersignalen (höhere Absprünge, weniger Conversions) und kann indirekt die Performance beeinträchtigen.

Hreflang im Kontext von Duplicate Content und Canonical

Viele internationale Setups haben stark ähnliche Inhalte. Das wird oft vorschnell als Duplicate Content eingeordnet. Hreflang ist hier der richtige Weg, um Varianten einander zuzuordnen. Gleichzeitig musst du verstehen, wie sich hreflang von einem Canonical-Tag unterscheidet: Canonical sagt „diese URL ist die Hauptversion“, hreflang sagt „das sind alternative passende Versionen“. Beides kann zusammen funktionieren – aber nur, wenn du es korrekt aufsetzt.

• Typische Einsatzfälle: de-DE/de-AT, en-GB/en-US, fr-FR/fr-CA
• Nutzen: weniger falsche SERP-Ausspielung, weniger interne Konkurrenz, bessere UX
• Voraussetzung: echte Alternativen, nicht willkürlich gleiche Seite in mehreren Sprachen

Wann brauchst du hreflang wirklich – und wann nicht?

Hreflang ist sinnvoll, sobald du mehrere URLs hast, die sich in Sprache oder Region unterscheiden und für unterschiedliche Zielgruppen bestimmt sind. Ein klassisches Beispiel: Du betreibst eine Website auf Deutsch für Deutschland und eine separate Version für die Schweiz, weil du CHF-Preise, andere Lieferbedingungen oder ein anderes Wording nutzt. Auch bei Englisch (US vs. UK) ist das häufig der Fall.

Klare Signale für den Einsatz

Setze hreflang ein, wenn mindestens einer dieser Punkte zutrifft:

• Du hast übersetzte Seiten (z. B. /de/ und /en/).
• Du hast länderspezifische Varianten mit sehr ähnlichem Inhalt (z. B. /de-de/ und /de-ch/).
• Du betreibst mehrere Domains oder Subdomains pro Land (z. B. .de und .at).
• Du beobachtest falsche Länder-Ausspielungen in der Search Console oder in SERP-Checks.

Wann hreflang eher unnötig ist

Wenn du nur eine Version hast (z. B. nur Deutsch, eine URL), brauchst du kein hreflang. Auch wenn du zwar international tätig bist, aber alle Nutzer:innen bewusst auf derselben Seite bedienst (z. B. Englisch als globale Sprache), ist hreflang meist überflüssig.

Wichtig ist außerdem: Hreflang ersetzt keine saubere Informationsarchitektur. Wenn du z. B. erst durch einen Relaunch oder eine neue Struktur mehrere Sprachverzeichnisse einführst, sollten Weiterleitungen, URL-Logik und Technik ebenfalls sauber geplant sein. In diesem Zusammenhang sind Konzepte wie Redirects (und speziell 301-Redirects) entscheidend, damit Google die neuen Sprach-URLs korrekt übernimmt.

1. Frage dich: Gibt es wirklich unterschiedliche Zielgruppen (Sprache/Land)?
2. Prüfe: Existieren eigene URLs pro Variante?
3. Dann: Implementiere hreflang als System, nicht „pro Seite nach Gefühl“.

So funktioniert hreflang technisch: HTML, HTTP-Header und Sitemap

Google akzeptiert hreflang in drei gängigen Implementierungsformen. Welche für dich die beste ist, hängt von deinem Setup (CMS, Anzahl Seiten, Ressourcen) ab. Wichtig: Egal welche Methode du wählst, die Logik bleibt gleich: Du deklarierst alternative Seitenversionen als ein zusammengehöriges Set.

Hreflang im HTML (link rel=”alternate”)

Die bekannteste Variante ist die Einbindung im <head> der Seite. Beispiel (vereinfacht):

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

Wenn du noch tiefer in die Grundlagen von Markup einsteigen willst, hilft auch ein Verständnis dafür, was ein HTML-Tag ist und wie der Head-Bereich technisch aufgebaut ist.

Hreflang via XML-Sitemap

Bei großen Websites ist hreflang in der Sitemap oft wartungsärmer, weil du nicht jede Seite im Head pflegen musst. In der Sitemap verknüpfst du pro URL die alternativen Sprach-URLs. Das ist besonders hilfreich bei Shops mit tausenden Produktseiten oder bei stark automatisierten CMS-Prozessen.

Hreflang per HTTP-Header

Diese Methode ist relevant, wenn du Inhalte auslieferst, die nicht (nur) HTML sind, z. B. PDFs. Dann kannst du hreflang über den Header setzen. In der Praxis ist das seltener, aber für internationale Dokumentationen durchaus wichtig.

Die richtige Syntax: Sprach- und Länder-Codes, x-default und Best Practices

Bei hreflang ist die Syntax entscheidend. Ein einziger falscher Code (oder ein Tippfehler) kann dazu führen, dass Google die Zuordnung ignoriert. Grundlage sind standardisierte Codes: ISO 639-1 für Sprache (z. B. de, en, fr) und ISO 3166-1 Alpha 2 für Länder (z. B. DE, AT, CH, US). Die Kombination wird üblicherweise mit Bindestrich geschrieben: de-DE, de-AT, en-GB.

Sprache vs. Land: Was du wirklich auszeichnen solltest

Wenn der Inhalt primär sprachlich unterscheidet, reicht häufig die Sprache (z. B. de, en). Wenn du aber länderspezifische Anpassungen hast (Preis, Recht, Liefergebiet), ist die Kombination aus Sprache und Land sinnvoll. Wichtig: Verwende nicht aus Gewohnheit Länder-Codes, wenn es keine echte länderspezifische Variante gibt – sonst erschaffst du unnötige Komplexität.

x-default: Die „Fallback“-Seite für unklare Fälle

x-default ist für Seiten gedacht, die als neutraler Einstieg funktionieren, z. B. eine Sprach-/Länderauswahl oder eine globale Startseite. Sie ist hilfreich, wenn Nutzer:innen aus Ländern kommen, für die du keine eigene Version hast. x-default ist kein Muss, kann aber bei internationalem Traffic die Trefferqualität verbessern.

• Gültig: hreflang=”de”, hreflang=”de-CH”, hreflang=”en-GB”
• Ungültig/typisch falsch: hreflang=”de-EN”, hreflang=”ger”, hreflang=”uk” (für Englisch in UK ist es en-GB)
• Case: Sprache klein, Land groß (Best Practice: de-CH)

Best Practice ist außerdem, dass jede Sprach-/Länderversion in einem Set sauber auflösbar ist (200 OK), indexierbar bleibt und nicht durch technische Hürden ausgebremst wird. Wenn du z. B. Probleme hast, dass wichtige Seiten nicht indexiert werden, lohnt sich ein Blick auf Ursachen wie Crawling- und Indexierungsfragen, etwa in unserem Beitrag Was ist Crawling?.

Rückverlinkung & Konsistenz: Warum hreflang-Sets immer vollständig sein müssen

Eine der wichtigsten hreflang-Regeln wird am häufigsten übersehen: Rückverlinkung. Wenn Seite A auf Seite B als Alternative verweist, muss Seite B auch auf Seite A (und alle anderen Alternativen) verweisen. Google spricht hier von „bidirectional links“. Fehlt diese Konsistenz, wird das hreflang-Cluster oft teilweise oder komplett ignoriert.

So sieht ein vollständiges hreflang-Set aus

Angenommen, du hast drei Versionen derselben Seite:

• Deutsch (Deutschland): /de-de/
• Deutsch (Schweiz): /de-ch/
• Englisch (global): /en/

Dann muss jede dieser drei Seiten im Head (oder in der Sitemap) alle drei Alternativen enthalten – jeweils mit der korrekten URL. Optional kommt noch eine x-default-URL hinzu.

Was in der Praxis oft schiefgeht

• Unvollständige Sets: Manche Seiten enthalten nur 2 von 3 Alternativen.
• Falsche URLs: Parameter-URLs oder Weiterleitungs-URLs werden verlinkt.
• Inkonsistenz durch Templates: Ein Template wird aktualisiert, ein anderes nicht.
• Indexierungsprobleme: Eine Alternative ist per noindex blockiert oder liefert 404.

Technisch hängt das oft an der Gesamtqualität der Website-Struktur: defekte Pfade, alte URL-Versionen oder fehlerhafte Weiterleitungen führen schnell zu hreflang-Chaos. Prüfe deshalb auch regelmäßig auf technische Stolpersteine wie Broken Links oder ungewollte Umleitungen.

Wenn du hreflang sauber als System denkst, lohnt sich ein standardisierter Prozess: Sprachseiten werden immer gemeinsam veröffentlicht, Sitemaps werden automatisch aktualisiert, und Tests prüfen die Vollständigkeit der Sets.

Typische hreflang-Fehler – und wie du sie zuverlässig vermeidest

Hreflang ist konzeptionell einfach, scheitert aber häufig an Details. Die gute Nachricht: Die meisten Probleme sind wiederkehrende Muster und lassen sich mit Checklisten und Tests sehr zuverlässig vermeiden.

Die häufigsten Fehlerbilder

• Falsche Codes: Nicht standardisierte Sprach-/Ländercodes oder falsche Kombinationen.
• Keine Rückverlinkung: Einseitige Referenzen innerhalb des Sets.
• Konflikt mit Canonical: Canonical zeigt auf eine andere Sprachversion (falsches „Hauptdokument“).
• Weiterleitung statt Ziel-URL: hreflang verweist auf eine URL, die per Redirect weiterleitet.
• Geoblocking/Consent-Walls: Googlebot bekommt nicht die Seite, die Nutzer:innen sehen.
• Automatische Sprachweiterleitung: Nutzer:innen (und Bots) werden per IP/Browser zwangs-umgeleitet.

Warum automatische Weiterleitungen oft schaden

Eine Browser- oder IP-Weiterleitung kann sinnvoll wirken, führt aber in der Praxis zu Problemen: Google crawlt aus verschiedenen Rechenzentren, Tests werden unzuverlässig, und Nutzer:innen können die Sprache nicht frei wechseln. Besser ist: Sprachwahl anbieten und hreflang für die Suchmaschine sauber pflegen. Weiterleitungen solltest du gezielt einsetzen und sauber dokumentieren (siehe auch Redirect-Arten).

1. Validiere Codes (ISO-konform) und halte die Schreibweise konsistent.
2. Nutze 200-OK Ziel-URLs, keine Redirect-Ketten.
3. Checke Canonical: Jede Sprachversion sollte in der Regel auf sich selbst canonicalisieren.
4. Teste Sets stichprobenartig nach Deployments.

Gerade bei internationalen Relaunches summieren sich diese Fehler schnell. Wenn du ohnehin an der Struktur arbeitest, ist es sinnvoll, hreflang in den technischen Ablauf zu integrieren – ähnlich wie man bei einem Website-Relaunch Redirect-Mappings und Indexierungschecks von Anfang an mitplant.

Hreflang in WordPress, Shops und Multi-Domain-Setups umsetzen

Die Umsetzung unterscheidet sich je nach System. Wichtig ist weniger das Tool selbst, sondern dass du am Ende vollständige, konsistente hreflang-Sets erzeugst. In der Praxis gibt es drei typische Szenarien: ein CMS mit Plugins (z. B. WordPress), ein Shop-System (oft mit Templates) oder ein Multi-Domain-Setup, bei dem jedes Land eine eigene Domain hat.

WordPress: Plugin-Logik verstehen, nicht blind aktivieren

In WordPress wird hreflang häufig über Mehrsprachigkeits-Plugins oder SEO-Plugins ausgespielt. Prüfe nach der Aktivierung immer, ob:

• alle Sprachversionen korrekt erkannt werden,
• die URLs wirklich final sind (ohne Redirect),
• jede Seite im Set alle Alternativen ausgibt.

Gerade bei komplexen Themes oder Page-Builder-Setups kann es zu Sonderfällen kommen. Wenn du tiefer im Ökosystem bist, kann es helfen, die Grundlagen von WordPress und typischen Erweiterungen zu kennen.

Shops: Varianten, Filter und Parameter im Griff behalten

Shop-Seiten erzeugen oft Parameter-URLs (Filter, Sortierung). Diese sollten in hreflang in der Regel nicht als Alternativen auftauchen, weil sie schnell unübersichtlich werden. Ziel sind stabile, kanonische Produkt- und Kategorieseiten. Kombiniere hreflang daher mit einer sauberen URL-Strategie und achte darauf, dass wichtige Seiten gut crawlbar bleiben.

Multi-Domain: hreflang domainübergreifend

Wenn du z. B. example.de und example.at betreibst, kann hreflang domainübergreifend gesetzt werden. Wichtig ist, dass beide Domains gegenseitig korrekt referenzieren. Häufige Stolpersteine sind abweichende URL-Strukturen oder unterschiedliche Templates, die zu unvollständigen Sets führen.

Hreflang prüfen, testen und überwachen: Tools, Signale, Vorgehen

Nach der Implementierung beginnt der wichtigste Teil: Validierung. Denn hreflang ist fehleranfällig, und kleine Änderungen (neue Templates, URL-Änderungen, Redirects) können die Sets unbemerkt beschädigen. Deshalb brauchst du einen Prozess, der sowohl stichprobenartige Checks als auch regelmäßige Überwachung umfasst.

Was du konkret prüfen solltest

• Existenz: Sind hreflang-Tags überhaupt vorhanden (Head, Sitemap oder Header)?
• Vollständigkeit: Enthält jede URL alle Alternativen des Sets?
• Rückverlinkung: Verweisen die Alternativen gegenseitig aufeinander?
• Statuscodes: Liefern alle hreflang-Zielseiten 200 OK (keine 3xx/4xx)?
• Indexierbarkeit: Sind die Zielseiten nicht per noindex ausgeschlossen?

Monitoring in der Praxis

Plane Monitoring in sinnvollen Intervallen ein, z. B. nach Releases und monatlich als Qualitätscheck. Besonders hilfreich ist das, wenn du viele Inhalte hast oder Teams in mehreren Ländern veröffentlichen. Sobald neue Seiten online gehen, sollten die Sprachversionen „als Paket“ live gehen, damit keine halben Sets entstehen.

Auch technische SEO-Basics spielen hier hinein: Wenn Google bestimmte Bereiche schlecht erreicht, kann hreflang zwar korrekt sein, aber die Alternativen werden nicht zuverlässig verarbeitet. Das ist dann weniger ein hreflang-Problem als ein Crawling- und Strukturthema. Wenn du merkst, dass Seiten grundsätzlich nicht sauber auftauchen, ist ein Blick auf Ursachen wie „Website wird nicht bei Google angezeigt“ sinnvoll.

1. Stichprobe: Prüfe einige wichtige Templates (Startseite, Kategorie, Produkt/Leistung, Blogartikel).
2. Fehler sammeln: Codes, Rückverlinkung, Status, Canonical-Konflikte.
3. Fix & Re-Check: Nach Deployment erneut prüfen.

Hreflang-Strategie für internationale SEO: Struktur, Content und Nutzerführung

Hreflang ist nur ein Baustein. Wirklich stark wird internationales SEO, wenn Struktur, Content und Nutzerführung zusammenpassen. Denn selbst mit perfektem hreflang wirst du Probleme bekommen, wenn Inhalte nicht zielgruppengerecht sind oder wenn die Website die falschen Erwartungen setzt (z. B. Sprache passt, aber Versandland nicht).

URL-Strukturen, die sich bewährt haben

• Verzeichnisse: /de/, /en/, /fr/ (einfach zu pflegen, ideal für eine Domain)
• Subdomains: de.example.com, en.example.com (technisch getrennt, mehr Aufwand)
• Länderdomains: example.de, example.at (starke regionale Signale, höchster Pflegeaufwand)

Content: Übersetzen reicht oft nicht

Gute internationale Seiten sind nicht nur übersetzt, sondern lokalisiert. Das heißt: Begriffe, Maßeinheiten, Tonalität, rechtliche Hinweise, Zahlungsarten und Trust-Elemente stimmen. Dadurch steigen Engagement und Conversions. Wenn du den Content-Teil strategisch angehen willst, hilft eine saubere Keyword-Planung pro Land – häufig mit spezifischen Suchphrasen. Dazu passt auch das Prinzip der Long-Tail-Keywords, weil Suchintentionen sich je Markt stark unterscheiden können.

Nutzerführung ist ebenfalls ein Faktor: Eine sichtbare Sprach-/Länderwahl (z. B. im Header) verhindert Frust, wenn hreflang einmal nicht perfekt greift. Außerdem sollte jede Version eine konsistente Navigation und klare CTAs haben, damit Nutzer:innen nicht „in der falschen Version stecken bleiben“.

• Empfehlung: Sprachwechsel-Links auf jeder Seite, nicht nur auf der Startseite.
• Empfehlung: Lokale Trust-Signale (Währung, Versand, Kontakt) pro Land.
• Empfehlung: Redaktionelle Prozesse für parallele Veröffentlichungen je Sprache.