hreflang: Mehrsprachige Websites richtig auszeichnen

hreflang sagt Suchmaschinen, welche Sprach- oder Länderversion einer Seite sie welchem Publikum zeigen sollen. Ohne diese Auszeichnung landet die Schweizer Kundin womöglich auf der deutschen Preisliste in Euro, und der Wiener Interessent sieht Versandbedingungen, die für ihn nicht gelten. Dieser Leitfaden zeigt dir Syntax, Umsetzungswege, Fehlerquellen und Prüfmethoden, damit deine mehrsprachige Website in jedem Markt die richtige URL ausspielt.

Wozu hreflang dient

Viele Unternehmen betreiben mehrere Varianten derselben Seite: eine deutsche, eine englische, vielleicht eine französische. Oft kommen Länderversionen hinzu, die sich nur in Währung, Rechtstexten oder Lieferzeiten unterscheiden. Für Google sehen solche Seiten auf den ersten Blick sehr ähnlich aus.

Das Attribut verknüpft diese Varianten zu einem Cluster. Jede Seite im Cluster nennt alle anderen Versionen samt Sprache und optional Region. Google kann dann in den Suchergebnissen die passende Variante für Sprache und Standort der Nutzer ausspielen.

Wichtig ist die Abgrenzung: Die Auszeichnung steuert nicht, welche Sprache Google einer Seite zuordnet. Laut der Google-Dokumentation zu lokalisierten Versionen (Stand September 2026) erkennt Google die Sprache algorithmisch und wertet dafür weder diese Annotation noch das HTML-Attribut lang aus. Auch ein Subdomain-Name wie de-ch.example.com legt die Zielgruppe nicht fest. Die Zuordnung musst du explizit treffen.

Typische Einsatzfälle sind:

• Übersetzte Inhalte, etwa eine deutsche und eine englische Produktseite.
• Regionale Varianten derselben Sprache, zum Beispiel Englisch für Großbritannien und die USA.
• Teilübersetzte Seiten, bei denen nur Navigation und Footer lokalisiert sind und der Hauptinhalt gleich bleibt.

Die hreflang-Syntax: Sprach- und Ländercodes

Der Wert des Attributs besteht aus einem Sprachcode und einem optionalen Regionscode, getrennt durch einen Bindestrich. Die Regeln sind streng, und hier passieren die meisten Fehler.

• Sprache: zweibuchstabiger Code nach ISO 639-1, zum Beispiel de, en, fr. Er ist Pflicht.
• Region: zweibuchstabiger Ländercode nach ISO 3166-1 Alpha-2, etwa DE, AT, CH. Er ist optional.
• Schreibweise: Groß- und Kleinschreibung spielt keine Rolle. Üblich ist die ISO-Konvention mit kleiner Sprache und großer Region, also de-AT.
• Schriftsysteme: Für Chinesisch erlaubt Google zusätzlich Schriftcodes wie zh-Hans (vereinfacht) und zh-Hant (traditionell).

Ein Ländercode allein ist nie gültig. Wer hreflang="be" schreibt, um Belgien anzusprechen, markiert die Seite tatsächlich als belarussisch, denn be ist der Sprachcode für Belarussisch. Ebenso ignoriert Google reservierte oder nicht standardisierte Codes wie EU, UN oder UK. Für das Vereinigte Königreich lautet der korrekte Code GB. Auch Regionalcodes wie es-419 für Lateinamerika unterstützt Google laut eigener Doku nicht.

Drei Wege, hreflang umzusetzen

Google akzeptiert drei gleichwertige Methoden: Link-Elemente im HTML-Head, HTTP-Header und die XML-Sitemap. Mehrere Methoden parallel zu nutzen, bringt laut Google keinen Vorteil. Entscheide dich deshalb für den Weg, den dein System am zuverlässigsten pflegt.

Für alle drei Wege gelten dieselben Grundregeln. URLs müssen vollständig qualifiziert sein, also mit Protokoll (https://) und Domain. Jede Version listet sich selbst und alle anderen Versionen auf. Die Varianten dürfen auf verschiedenen Domains liegen.

Methode 1: Link-Elemente im HTML-Head

Der verbreitetste Weg. Du setzt in den <head> jeder Sprachversion einen identischen Block von Link-Elementen. Ein Beispiel für eine Seite mit deutscher, englischer und Fallback-Version:

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

Die Elemente müssen in einem sauber aufgebauten Head stehen. Rutschen sie durch fehlerhaftes Markup, etwa ein schließendes </head> zu früh oder ein Skript, das Body-Elemente einschleust, in den Body, wertet Google sie nicht aus. Kombiniere das Attribut außerdem nicht mit weiteren Attributen wie media im selben Link-Element.

Der Nachteil zeigt sich bei großen Websites: Bei 20 Sprachversionen trägt jede Seite 20 oder mehr Link-Zeilen im Head. Das bläht den Quellcode auf und erhöht die Fehleranfälligkeit bei Template-Änderungen.

Methode 2: HTTP-Header

Für Dateien ohne HTML-Head, typischerweise PDFs, nutzt du den Link-Header in der Serverantwort. Auch hier liefert jede Version dieselbe Liste aus:

Link: <https://www.example.com/de/handbuch.pdf>; rel="alternate"; hreflang="de",
      <https://www.example.com/en/manual.pdf>; rel="alternate"; hreflang="en",
      <https://www.example.com/fr/manuel.pdf>; rel="alternate"; hreflang="fr"

Die Header-Variante setzt Zugriff auf die Serverkonfiguration oder das CDN voraus. Für normale HTML-Seiten ist sie selten die erste Wahl, weil Fehler im Header schwerer zu sehen sind als im Quelltext.

Methode 3: XML-Sitemap

Bei vielen Sprachversionen ist die Sitemap oft der sauberste Weg. Du hältst den HTML-Code schlank und pflegst alle Verknüpfungen zentral. Jeder <url>-Eintrag listet über xhtml:link sämtliche Varianten inklusive sich selbst:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.example.com/de/preise/</loc>
    <xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/preise/" />
    <xhtml:link rel="alternate" hreflang="en" href="https://www.example.com/en/pricing/" />
  </url>
  <!-- denselben Block für /en/pricing/ wiederholen -->
</urlset>

Zwei Details entscheiden über den Erfolg: Der Namespace xmlns:xhtml muss deklariert sein, und eine Sitemap darf nur URLs unterhalb des Verzeichnisses enthalten, in dem sie liegt. Für jede Variante brauchst du einen eigenen <url>-Block mit identischen Alternativ-Links.

Welche Methode passt zu dir? Eine grobe Orientierung:

• HTML-Head: kleine bis mittlere Websites mit wenigen Sprachen und einem CMS-Plugin, das die Tags erzeugt.
• XML-Sitemap: große Shops und Portale mit vielen Märkten, bei denen du den Quellcode schlank halten willst.
• HTTP-Header: PDFs und andere Nicht-HTML-Dokumente.

x-default: der Fallback für alle anderen

Der Sonderwert x-default definiert die Seite, die Nutzer sehen sollen, wenn keine deiner Sprach- oder Länderversionen passt. Ein Beispiel: Du bietest Deutsch und Englisch an, und jemand sucht auf Portugiesisch. Dann greift die x-default-URL.

Google empfiehlt x-default vor allem für Sprachauswahlseiten und für Startseiten, die Besucher automatisch weiterleiten. Viele Websites setzen stattdessen die englische Version als Fallback, was ebenfalls zulässig ist. x-default ist kein Pflichtbestandteil, schließt aber Lücken, die sonst Google nach eigenem Ermessen füllt.

Rückverweise: Ohne Gegenseitigkeit keine Wirkung

Die wichtigste Regel steht unscheinbar in der Doku: Die Annotationen müssen wechselseitig sein. Verweist Seite A auf Seite B als Alternative, muss B auch auf A zurückverweisen. Fehlt der Rückverweis, ignoriert Google die Angaben für dieses Paar.

Dazu gehört der Selbstverweis. Jede Seite nennt sich selbst in ihrer Liste der Alternativen. Am einfachsten erreichst du das, wenn alle Versionen eines Clusters exakt denselben Block ausgeben. Ein Template, das die eigene Sprache aus der Liste herausfiltert, ist ein klassischer Fehler.

Google räumt eine Ausnahme ein: Wenn du nicht alle Verknüpfungen pflegen kannst, etwa weil neue Sprachversionen nach und nach entstehen, solltest du zumindest die neuen Seiten mit der dominanten Sprachversion verbinden. Ein vollständiger Cluster bleibt aber das Ziel.

hreflang und Canonical: so arbeiten beide zusammen

Das Verhältnis zum Canonical-Tag sorgt regelmäßig für Verwirrung. Die Grundregel: Jede Sprachversion setzt einen Canonical auf sich selbst, nicht auf die Hauptsprache. Zeigt der Canonical der österreichischen Seite auf die deutsche Version, signalisierst du Google, dass die österreichische Seite gar nicht indexiert werden soll. Damit verliert die Sprachverknüpfung ihre Grundlage.

Googles Leitfaden zur Konsolidierung doppelter URLs formuliert es so: Bei Sprachclustern soll der Canonical auf eine Seite in derselben Sprache oder der bestmöglichen Ersatzsprache zeigen. Zugleich bevorzugt Google bei der Kanonisierung URLs, die Teil eines hreflang-Clusters sind. Ein Detail am Rande: Canonical-Angaben mit Attributen wie lang, media oder type nutzt Google nicht für die Kanonisierung.

Achte zudem darauf, dass die Annotationen nur auf indexierbare, kanonische URLs verweisen. Links auf weitergeleitete Seiten, noindex-Seiten oder URLs mit Parametern schwächen den Cluster. Bei einer Umstellung von Domains oder Verzeichnissen gehört die Sprachlogik deshalb fest in deinen Plan für den Website-Relaunch.

Der DACH-Fall: de-DE, de-AT und de-CH

Für deutschsprachige Anbieter ist das Thema besonders relevant, weil Deutschland, Österreich und die Schweiz dieselbe Sprache teilen, aber unterschiedliche Märkte sind. Inhalte unterscheiden sich oft nur in Details: Franken statt Euro, andere Versandkosten, das Schweizer „ss“ statt „ß“, regionale Begriffe wie „Jänner“ oder „Velo“.

Genau solche fast identischen Seiten erkennt Google ohne Auszeichnung leicht als Duplikate und zeigt dann womöglich nur eine Version in allen drei Ländern. Laut Google gelten lokalisierte Seiten allerdings nur dann als Duplikate, wenn der Hauptinhalt unübersetzt bleibt. Mit einem sauberen Cluster machst du die Zuordnung eindeutig:

<link rel="alternate" hreflang="de-DE" href="https://www.example.com/de-de/" />
<link rel="alternate" hreflang="de-AT" href="https://www.example.com/de-at/" />
<link rel="alternate" hreflang="de-CH" href="https://www.example.com/de-ch/" />
<link rel="alternate" hreflang="de" href="https://www.example.com/de-de/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

Die Zeile mit dem reinen Sprachcode de ist kein Zufall. Google empfiehlt, bei mehreren Länderversionen einer Sprache eine allgemeine Version für alle übrigen Nutzer dieser Sprache anzugeben. Ohne sie bleibt offen, was jemand aus Liechtenstein, Luxemburg oder Südtirol sieht. Viele DACH-Websites lassen dafür die deutsche Länderseite einspringen.

Prüfe außerdem, ob sich der Aufwand lohnt. Unterscheiden sich die Versionen inhaltlich gar nicht, reicht oft eine einzige deutschsprachige Seite mit hreflang="de". Separate Länderseiten zahlen sich vor allem aus, wenn Preise, Sortiment, Rechtstexte oder Ansprechpartner wirklich abweichen. Wer viele Standorte und Märkte betreut, findet weitere Strukturfragen im Beitrag zu Enterprise SEO.

Bing und Yandex: was anders läuft

hreflang ist vor allem ein Google-Standard. Andere Suchmaschinen gehen eigene Wege, und das solltest du bei internationalen Projekten einplanen.

Bing hat in seinem Webmaster-Blog (2011) eine eigene Rangfolge an Signalen für Sprache und Land beschrieben. An erster Stelle steht die Meta-Angabe content-language im Head, danach folgen der gleichnamige HTTP-Header, die Länderdomain (ccTLD) und zuletzt die Server-IP. Generische Domains wie .com zählen dabei nicht als Länderhinweis. Eine ausführliche offizielle Bing-Dokumentation zu dem Attribut, vergleichbar mit der von Google, gibt es nicht. Wer Bing ernst nimmt, ergänzt daher pro Version eine Angabe wie diese:

<meta http-equiv="content-language" content="de-at" />

Diese Angabe ergänzt die Google-Auszeichnung. Wie Bing deine Seiten crawlt und indexiert, kannst du in den Bing Webmaster Tools nachvollziehen.

Yandex unterstützt die Annotation über Link-Elemente im HTML-Head, inklusive x-default. Die XML-Sitemap als Weg für Sprachversionen unterstützt Yandex laut seiner Webmaster-Hilfe dagegen nicht mehr. Wer für Yandex optimiert, kommt um die Head-Variante also nicht herum.

Typische hreflang-Fehler und wie du sie vermeidest

Die meisten Probleme entstehen nicht beim ersten Einbau, sondern Monate später, wenn Seiten umziehen, gelöscht werden oder Templates sich ändern. Diese Fehler tauchen in Audits immer wieder auf:

• Fehlende Rückverweise: Seite A nennt B, B nennt A nicht. Google ignoriert das Paar.
• Kein Selbstverweis: Die Seite listet alle Alternativen außer sich selbst.
• Falsche Codes: en-UK statt en-GB, de-at-AT, reine Ländercodes wie at oder Unterstriche wie de_DE.
• Relative URLs: /de/preise/ statt der vollständigen Adresse mit Protokoll und Domain.
• Verweise auf nicht indexierbare Seiten: Ziel-URLs mit Weiterleitung, 404-Status, noindex oder abweichendem Canonical.
• Widersprüchliche Canonicals: Alle Sprachversionen kanonisieren auf die Hauptsprache.
• Tags außerhalb des Heads: durch fehlerhaftes HTML, Tag-Manager-Skripte oder Plugins, die Elemente in den Body schieben.
• Automatische Weiterleitung nach IP: Leitest du jeden Besucher zwangsweise auf seine Länderversion um, sieht der Googlebot womöglich nur eine Variante. Biete besser eine Auswahl oder einen Hinweisbanner an.

Ein Fehler, der seltener auffällt: Sprachangaben in mehreren Quellen, die sich widersprechen. Wenn ein Plugin Tags im Head ausgibt und parallel eine Sitemap mit abweichenden URLs existiert, entstehen unklare Signale. Halte dich an eine Quelle.

hreflang prüfen: Search Console und Tools

Lange war die Search Console die erste Anlaufstelle. Der Bericht „Internationale Ausrichtung“ zeigte Fehler wie fehlende Rückverweise an. Google hat diesen Bericht im August 2022 als veraltet erklärt und im September 2022 entfernt, wie Search Engine Land damals berichtete. Einen Nachfolgebericht speziell für hreflang gibt es nicht. Google betonte dabei, das Attribut weiterhin zu unterstützen.

In der Search Console bleiben dir trotzdem indirekte Hinweise:

• URL-Prüfung: Zeigt, welche URL Google als kanonisch gewählt hat. Weicht sie von deiner Länderversion ab, stimmt etwas am Cluster nicht.
• Leistungsbericht nach Ländern: Filtere nach Land und Seite. Rankt in Österreich die deutsche URL statt der österreichischen, greift deine Auszeichnung nicht.
• Seitenindexierung: Meldungen wie „Duplikat, Google hat eine andere kanonische Seite als der Nutzer ausgewählt“ deuten oft auf zu ähnliche Länderseiten hin.

Für die eigentliche Validierung brauchst du externe Werkzeuge. Google nennt in seiner Doku selbst zwei Drittanbieter-Tools, die es weder betreibt noch prüft: den hreflang-Tag-Generator von Aleyda Solis und das hreflang-Testtool von Merkle. Für größere Websites eignen sich Crawler wie der Screaming Frog SEO Spider, der Sprachannotationen seitenweit ausliest und fehlende Rückverweise, falsche Codes oder nicht indexierbare Ziele auflistet. Auch die Site-Audit-Funktionen gängiger SEO-Suiten prüfen diese Angaben.

Eine sinnvolle Routine sieht so aus:

1. Nach jedem Template- oder Plugin-Update einen Crawl mit Auswertung der Sprachverknüpfungen starten.
2. Stichproben im Quelltext oder in der Sitemap machen, besonders bei neuen Sprachversionen.
3. Monatlich im Leistungsbericht prüfen, ob in jedem Land die richtige URL rankt.
4. Bei Abweichungen die URL-Prüfung nutzen und den gewählten Canonical kontrollieren.

hreflang im größeren SEO-Kontext

hreflang ist ein technisches Signal unter vielen. Es hilft Google, zwischen bestehenden Versionen zu wählen, verbessert aber nicht das Ranking einer schwachen Seite. Wenn deine österreichische Version kaum Inhalte, keine lokalen Signale und keine Backlinks aus Österreich hat, wird ein korrekter Tag daran wenig ändern.

Sinnvoll ist ein Gesamtpaket: echte Lokalisierung statt reiner Übersetzung, lokale Kontaktdaten, Preise in Landeswährung und passende Rechtstexte. Ergänzend kannst du mit strukturierten Daten wie Organization- oder LocalBusiness-Markup Adresse und Region einer Länderversion maschinenlesbar machen. Achte darauf, dass Sprache und Region in Inhalt, URL-Struktur, Markup und Sprachcluster zusammenpassen.

Bei der URL-Struktur hast du die Wahl zwischen Länderdomains (example.at), Subdomains (at.example.com) und Verzeichnissen (example.com/de-at/). Die Auszeichnung funktioniert mit allen drei Varianten. Verzeichnisse lassen sich am einfachsten pflegen, Länderdomains senden das stärkste Länder-Signal, besonders für Bing, das ccTLDs als Hinweis auf den Zielmarkt nutzt.

Fazit

hreflang ist kein komplexes Attribut, verzeiht aber wenig. Kleine Fehler wie ein fehlender Rückverweis oder ein falscher Ländercode reichen, damit Google die Angaben verwirft. Die Grundregeln sind dagegen überschaubar. Achte auf korrekte ISO-Codes, vollständige URLs, Selbstverweise, wechselseitige Verknüpfungen und Canonicals auf die eigene Version.

Für DACH-Anbieter lohnt sich der Aufwand besonders, sobald sich Preise, Sortiment oder Rechtstexte zwischen Deutschland, Österreich und der Schweiz unterscheiden. Wähle eine Umsetzungsmethode, die dein System zuverlässig pflegt, ergänze für Bing die content-language-Angabe und prüfe deinen Cluster regelmäßig mit einem Crawler. Da die Search Console keinen hreflang-Bericht mehr bietet, liegt die Kontrolle bei dir.

Häufige Fragen zu hreflang

Was ist hreflang?

hreflang ist ein HTML-Attribut, das Suchmaschinen anzeigt, welche Sprach- oder Länderversion einer Seite für welches Publikum gedacht ist. Google nutzt die Angabe, um Nutzern in den Suchergebnissen die passende Variante zu zeigen.

Welche Codes verwende ich für Deutschland, Österreich und die Schweiz?

Für deutschsprachige Seiten nutzt du de-DE, de-AT und de-CH. Der Sprachcode folgt ISO 639-1, der Ländercode ISO 3166-1 Alpha-2. Ergänze eine allgemeine Version mit de für alle übrigen deutschsprachigen Nutzer.

Brauche ich x-default?

x-default ist optional, aber empfehlenswert. Es legt die Seite fest, die Nutzer sehen, wenn keine deiner Sprachversionen passt, etwa eine Sprachauswahl oder die englische Startseite.

Wie prüfe ich hreflang ohne Search-Console-Bericht?

Google hat den Bericht zur internationalen Ausrichtung 2022 entfernt. Prüfe die Tags mit Crawlern wie dem Screaming Frog SEO Spider oder Testtools wie dem von Merkle und kontrolliere im Leistungsbericht der Search Console, welche URL in welchem Land rankt.

Wie verhalten sich Canonical und Sprachversionen zueinander?

Jede Sprachversion setzt einen Canonical auf sich selbst. Zeigt der Canonical auf eine andere Sprachversion, signalisierst du Google, dass die Seite nicht indexiert werden soll, und die Sprachverknüpfung verliert ihre Wirkung.