Zuletzt aktualisiert: 02.05.2026
hreflang ist ein HTML-Attribut, das Google die Sprach- und Länderzuordnung paralleler Seitenversionen mitteilt. Korrekt eingesetzt verhindert es Duplicate Content und sorgt dafür, dass Nutzer in den Suchergebnissen ihre passende Sprachversion sehen.
hreflang ist ein link-Attribut nach dem rel-alternate-hreflang-Standard, das auf alternative Sprach- und Länderversionen einer URL verweist und Suchmaschinen die korrekte Zuordnung in mehrsprachigen Suchergebnissen ermöglicht.
Internationale SEO scheitert in 80 Prozent der Fälle an hreflang. Die Syntax sieht harmlos aus, ihre Wechselwirkungen mit Canonicals, Sitemaps und Geo-Targeting sind aber komplex. Wir zeigen die drei Implementierungsvarianten, die häufigsten Fehler und wie du eine gesamte Site-Architektur sauber annotierst – mit Praxisbeispielen aus realen Migrations- und Launch-Projekten, in denen hreflang regelmäßig der zeitkritische Engpass wurde, weil eine fehlerhafte Annotation alle Sprachvarianten gleichzeitig betrifft.
Was bewirkt hreflang im SEO genau?
hreflang teilt Google mit, dass mehrere URLs denselben Inhalt in unterschiedlichen Sprach- oder Länderversionen anbieten. In der SERP zeigt Google dann dem Nutzer die passende Version – ein deutscher Suchender bekommt /de/, ein französischer /fr/ – auch wenn beide Versionen denselben Suchbegriff abdecken.
hreflang ist kein Ranking-Faktor, sondern ein Targeting-Signal. Es beeinflusst weder die Sichtbarkeit noch die Position einer URL, sondern ausschließlich, welche Variante Google in der lokalisierten SERP zeigt. Wer keine länderspezifischen Varianten hat, braucht hreflang nicht.
Außerdem hilft hreflang gegen Duplicate Content. Mehrere Sprachversionen einer Seite mit identischer oder fast identischer Struktur könnten sonst als Kopien gewertet werden. hreflang signalisiert: Es sind Alternativen für unterschiedliche Sprachen, keine Duplikate.
Welche drei Implementierungs-Varianten gibt es?
Variante 1: HTML-Tags im <head> jeder Seite. Pro Sprachversion ein <link rel="alternate" hreflang="..." href="...">. Empfohlen für kleine Sites mit überschaubarer Sprachzahl. Nachteil: Bei vielen Sprachen wird der HTML-Head schnell unübersichtlich.
Variante 2: HTTP-Header mit Link:-Direktive. Sinnvoll für nicht-HTML-Inhalte (PDF, Bilder) oder wenn der HTML-Head nicht editierbar ist. Server-Konfiguration: Apache via .htaccess, Nginx via add_header.
Variante 3: XML-Sitemap mit xhtml:link-Annotationen. Beste Wahl für große, mehrsprachige Sites. Vorteil: Zentrale Pflege, weniger Markup pro Seite. Nachteil: Sitemap muss konsistent gepflegt werden, Fehler wirken auf viele URLs.
| Variante | Empfohlen für | Aufwand | Risiko bei Fehlern |
|---|---|---|---|
| HTML head | kleine Sites, < 5 Sprachen | niedrig | lokal pro Seite |
| HTTP-Header | nicht-HTML-Inhalte | mittel | weitreichend |
| Sitemap xhtml:link | große, mehrsprachige Sites | mittel | global |
Welche Sprach- und Länder-Codes sind korrekt?
hreflang verwendet ISO-639-1 (Sprache, zwei Buchstaben) und optional ISO-3166-1 alpha-2 (Land, zwei Buchstaben), getrennt durch Bindestrich. Beispiele: de (Deutsch generisch), de-DE (Deutsch für Deutschland), de-AT (Deutsch für Österreich), en-GB (Englisch UK).
Wichtig: Land ohne Sprache ist ungültig. hreflang="DE" ist falsch, korrekt ist hreflang="de-DE". Großschreibung ist optional, aber Konvention ist Sprache klein, Land groß. Google ist tolerant, aber Tools wie Screaming Frog sind strikt.
Für die Standard-/Fallback-Version (kein Land, keine Sprache definiert) gibt es hreflang="x-default". Sie zeigt die Variante an, die Google ausspielen soll, wenn kein anderer Eintrag passt – meist die globale Englisch-Version.
Welche Fehler sind in hreflang besonders häufig?
Fehler 1: Fehlende Reziprozität. hreflang ist immer paarweise – wenn /de/ auf /fr/ verweist, muss /fr/ auch auf /de/ verweisen. Einseitige hreflang werden ignoriert. Tools wie Screaming Frog oder die GSC zeigen reziproke Lücken zuverlässig auf.
Fehler 2: hreflang verweist auf Canonical-Konflikte. Eine /fr/-Seite mit Canonical auf /de/ und gleichzeitiger hreflang-Annotation widerspricht sich selbst. Die hreflang-Annotation muss auf die kanonische Version der jeweiligen Sprachvariante zeigen.
Fehler 3: x-default fehlt oder zeigt auf nicht existente URL. Ohne x-default rät Google bei Mehrdeutigkeit – meistens nicht zur gewünschten Version. x-default sollte immer eine erreichbare, repräsentative URL liefern.
Häufige Mythen über das Thema
Die folgenden Missverständnisse begegnen uns in fast jedem Audit-Workshop. Wer sie kennt, vermeidet typische Fehler.
Realität: Ist es nicht. Es beeinflusst nur, welche Variante Google in der SERP anzeigt – nicht, ob diese Variante überhaupt rankt.
Realität: Es ist eine Komponente. Geo-Targeting in der GSC, ccTLDs, lokalisierte Inhalte und Backlinks aus dem Zielmarkt sind ebenso wichtig.
Realität: Auch identische Inhalte mit Sprach- oder Länder-Varianten profitieren – etwa /de-de/ und /de-at/ mit gleichem Text aber unterschiedlicher Preisangabe.
Realität: Sitemap-Annotationen und HTTP-Header funktionieren genauso. Wichtig ist Konsistenz innerhalb einer Variante – nicht Mischen.
Realität: Google braucht typischerweise 2-6 Wochen, um hreflang-Signale vollständig zu verarbeiten. Erfolg ist im SERP-Verhalten messbar, nicht im sofortigen Ranking.
Welche Tools helfen bei der hreflang-Validierung?
Die Google Search Console liefert im Internationalisierungs-Bericht die wichtigsten hreflang-Daten: erkannte Annotationen, Reziprozitäts-Lücken und ungültige Codes. Sie sollte erste Anlaufstelle sein, weil sie direkt Googles Sicht spiegelt. Stichprobenartige Einzel-URL-Checks sind über das URL-Inspection-Tool möglich – dort wird die Sprachvariante gezeigt, die Google für diese URL erkennt.
Externe Tools ergänzen das Bild. Screaming Frog crawlt eine komplette Site und prüft alle hreflang-Annotationen auf Konsistenz, fehlende Reziprozität und Canonical-Konflikte. Das hreflang-tags.com-Tool akzeptiert eine Sitemap-URL und liefert sofort einen Reziprozitäts-Report. Beide eignen sich für manuelle Audits vor und nach Änderungen, scheitern aber bei sehr großen Sites an Performance-Limits.
Für laufende Überwachung lohnt sich ein automatisierter Crawl-Job (z. B. wöchentlich) mit Diff-Reporting. Jede Abweichung gegenüber der Vorwoche wird als Slack- oder Mail-Alert verschickt. So fallen Regressionen durch versehentlich überschriebene Templates oder Sitemap-Generatoren sofort auf, statt erst Wochen später im GSC-Bericht. Wir nutzen dafür ein einfaches Python-Script, das Screaming Frog im Headless-Modus startet.
Wie integriere ich hreflang in einen Internationalisierungs-Workflow?
hreflang gehört in die Standard-Definition jeder neuen Sprachvariante. Sobald eine Sprachversion live geht, müssen automatisch alle bestehenden Varianten erweitert werden – einseitige hreflang-Verweise wirken nicht. Der saubere Workflow steuert das über eine zentrale Konfiguration im CMS oder Framework, die alle Templates beim Build aktualisiert.
Inhaltlich erforderlich ist eine echte Lokalisierung. Eine deutsche und eine österreichische Version mit identischem Text erfüllt zwar formal die hreflang-Anforderung, bringt aber wenig Mehrwert. Wenigstens lokale Bezüge (Währung, Adressen, Telefonnummer, gesetzliche Hinweise) sollten unterschiedlich sein, sonst kann Google die Variante als Duplicate Content statt als legitime Lokalisierung werten.
Bei Relaunches oder Domain-Migrationen ist hreflang einer der Punkte, der zuerst leidet. Ein vollständiger hreflang-Audit nach jedem strukturellen Eingriff ist Pflicht – und sollte in der Migration-Checkliste vor dem Switch-over stehen. Wir setzen typischerweise einen Pre-Live-Check, der alle hreflang-Annotationen gegen ein Soll-Mapping prüft und bei Abweichungen den Go-Live blockiert.
Ergänzend gehört ein Translation-Management in den Workflow. Werden Inhalte über ein TMS (Translation Management System) wie Phrase, Lokalise oder XTM lokalisiert, sollte das System die hreflang-Pflege automatisch übernehmen. Pro Übersetzungs-Job wird die Ziel-URL erzeugt, die Reziprozität in den anderen Sprachvarianten ergänzt und die Sitemap aktualisiert. Wer das manuell macht, verliert pro neuer Sprachversion mindestens einen halben Tag und produziert mit hoher Wahrscheinlichkeit Inkonsistenzen, die später aufwendig korrigiert werden müssen.
Weiterführende Artikel auf Digital Ultras
Folgende Beiträge vertiefen einzelne Aspekte und passen direkt in dein nächstes Audit:
- Strukturierte SEO Analyse für internationale Sites
- Local SEO Grundlagen für regionale Sichtbarkeit
- E-E-A-T richtig auf mehrsprachigen Sites zeigen
- Vollständiger SEO Audit Workflow
Häufige Fragen
Wann brauche ich hreflang?
Sobald du dieselbe Information in mehreren Sprachen oder Ländervarianten anbietest. Eine reine Englisch-Site mit globalem Publikum braucht kein hreflang.
Was ist x-default und brauche ich das?
x-default ist der Fallback, wenn keine andere Variante passt. Empfohlen für jede mehrsprachige Site, um Mehrdeutigkeit auszuschließen.
Wie validiere ich hreflang-Annotationen?
Mit dem Internationalisierungs-Bericht der Google Search Console oder externen Tools wie hreflang-tags.com. Beide zeigen Reziprozitätslücken und Syntax-Fehler.
Sind hreflang und canonical kompatibel?
Ja, aber sie müssen konsistent sein. Die hreflang-Annotation einer Sprachvariante zeigt auf die kanonische Version dieser Variante – nicht auf die Hauptsprache.
Welche Variante (HTML/Header/Sitemap) ist die beste?
Es gibt keine objektiv beste – wichtig ist, dass alle Varianten einer Site dasselbe Verfahren verwenden. Mischformen sind eine häufige Fehlerquelle.
Wie viele hreflang-Annotationen pro Seite sind sinnvoll?
Eine Annotation pro existierender Sprachversion plus x-default. Mehr nicht – auch nicht für nicht existierende Sprachen.
Wirkt hreflang auch in Bing?
Bing unterstützt hreflang offiziell, ergänzt es aber durch eigene Geo-Targeting-Hinweise (z. B. Bing Webmaster Tools). Hauptzielgruppe der Annotation bleibt Google.
Was bei sich häufig ändernden Übersetzungen tun?
Sitemap-basierte hreflang skalieren am besten, weil Updates zentral erfolgen. Bei HTML-basierten Annotationen muss bei jeder Inhaltsänderung geprüft werden, ob alle Varianten konsistent bleiben.
Fazit
hreflang ist ein präzises Werkzeug für internationale SEO – aber unverzeihlich gegenüber Inkonsistenzen. Wer Reziprozität, Canonical-Konsistenz und x-default sauber implementiert, kann mehrsprachige Sites in lokalisierten SERPs sichtbar positionieren. Die regelmäßige Validierung im GSC-Internationalisierungs-Bericht gehört zur Pflicht jedes mehrsprachigen Setups. Wer hreflang in CI/CD verankert, sich klar auf eine einzige Implementierungs-Variante festlegt und Stakeholder-Workflows mit eindeutigen Eskalations-Pfaden ausstattet, vermeidet die teuersten internationalen SEO-Fallen und gewinnt langfristig stabile Sichtbarkeit in jedem Zielmarkt.
