Was Hreflang Tags leisten — und was nicht
Hreflang Tags teilen Google mit, welche Sprachversion oder regionale Version einer Seite für welche Nutzergruppe gedacht ist. Sie sind kein Ranking-Signal im klassischen Sinne, sondern ein Targeting-Signal: Sie helfen dem Crawler zu verstehen, welche URL einem Nutzer aus Deutschland, Österreich oder der Schweiz ausgespielt werden soll.
Was Hreflang Tags nicht leisten: Sie verhindern kein Duplicate Content-Problem eigenständig. Wenn zwei Seiten nahezu identischen Inhalt haben, sollte zusätzlich mit Canonical Tags gearbeitet werden, um die Signale sauber zu trennen. Hreflang und Canonical ergänzen sich — sie ersetzen sich nicht gegenseitig.
Google unterstützt Hreflang offiziell. Bing ebenfalls, allerdings mit leicht abweichender Implementierungslogik. Für den DACH-Markt ist Google die primär relevante Suchmaschine, weshalb sich dieser Artikel an der Google Search Central Dokumentation orientiert.
Die korrekte Syntax für DE, AT und CH
Die Hreflang-Auszeichnung folgt dem BCP 47-Standard und kombiniert einen Sprachcode (ISO 639-1) mit einem optionalen Ländercode (ISO 3166-1 alpha-2). Für den DACH-Raum ergeben sich folgende Kombinationen:
de-DE— Deutsch für Deutschlandde-AT— Deutsch für Österreichde-CH— Deutsch für die Schweizde— Deutsch ohne Regionalbezug (Fallback)x-default— Fallback für alle nicht explizit zugeordneten Nutzer
Ein vollständiges Hreflang-Set für eine DACH-Seite sieht im <head> so aus:
<link rel='alternate' hreflang='de-DE' href='https://example.com/de-de/produkt/' />
<link rel='alternate' hreflang='de-AT' href='https://example.com/de-at/produkt/' />
<link rel='alternate' hreflang='de-CH' href='https://example.com/de-ch/produkt/' />
<link rel='alternate' hreflang='x-default' href='https://example.com/produkt/' />Wichtig: Jede Seite im Set muss auf alle anderen Seiten des Sets verweisen — einschließlich auf sich selbst. Fehlt der Self-Referential Tag, behandelt Google das Set als unvollständig und kann die Signale ignorieren.
Drei Implementierungswege im Vergleich
Hreflang Tags können auf drei Wegen implementiert werden. Welcher Weg sinnvoll ist, hängt von der technischen Infrastruktur ab.
1. HTML <head>
Die direkteste Methode. Der Tag wird im <head>-Bereich jeder betroffenen Seite platziert. Funktioniert zuverlässig, erfordert aber bei großen Seiten mit hunderten URLs eine template-basierte Lösung im CMS. Bei JavaScript-lastigen Frameworks ist Vorsicht geboten — wenn der Head serverseitig gerendert wird, ist das kein Problem. Wird er clientseitig injiziert, kann Google den Tag möglicherweise nicht lesen. Mehr dazu im Kontext von JavaScript SEO und Crawler-Problemen.
2. HTTP-Header
Für nicht-HTML-Ressourcen wie PDFs die einzige Option. Der Server liefert den Hreflang-Wert als Response-Header:
Link: <https://example.com/de-at/whitepaper.pdf>; rel='alternate'; hreflang='de-AT'In der Praxis selten genutzt, aber relevant für B2B-Seiten, die mehrsprachige Dokumente indexieren lassen wollen.
3. XML-Sitemap
Die skalierbarste Methode für große Seiten. Alle Hreflang-Beziehungen werden zentral in der Sitemap definiert, ohne dass jede einzelne Seite angepasst werden muss. Die Struktur folgt dem xhtml:link-Element:
<url>
<loc>https://example.com/de-de/produkt/</loc>
<xhtml:link rel='alternate' hreflang='de-DE' href='https://example.com/de-de/produkt/' />
<xhtml:link rel='alternate' hreflang='de-AT' href='https://example.com/de-at/produkt/' />
<xhtml:link rel='alternate' hreflang='de-CH' href='https://example.com/de-ch/produkt/' />
<xhtml:link rel='alternate' hreflang='x-default' href='https://example.com/produkt/' />
</url>Hinweise zur korrekten Sitemap-Struktur finden sich im Artikel zu XML Sitemaps und was Google wirklich braucht. Wichtig: Auch bei der Sitemap-Methode müssen alle URLs im Set gegenseitig aufeinander verweisen.
Die häufigsten Fehler bei DACH-Implementierungen
Die Fehlerquote bei Hreflang-Implementierungen ist hoch. Google selbst hat in der Search Central Dokumentation darauf hingewiesen, dass fehlerhafte Hreflang-Sets häufig einfach ignoriert werden — ohne Fehlermeldung in der Search Console.
Fehlender Self-Referential Tag
Der häufigste Fehler: Die Seite verweist auf ihre Alternativen, aber nicht auf sich selbst. Jede URL im Set muss einen hreflang-Tag enthalten, der auf die eigene URL zeigt.
Inkonsistente URLs
Trailing Slashes, HTTP vs. HTTPS, www vs. non-www — wenn die URLs im Hreflang-Tag nicht exakt mit den kanonischen URLs übereinstimmen, erkennt Google das Set nicht als zusammengehörig. Die im Hreflang verwendeten URLs müssen identisch mit den Canonical URLs sein.
Nur Sprachcode statt Sprach-Länder-Kombination
Wer für alle drei DACH-Märkte nur hreflang='de' setzt, gibt Google kein regionales Signal. Für die Differenzierung zwischen DE, AT und CH sind die kombinierten Codes de-DE, de-AT und de-CH zwingend notwendig.
Fehlendes x-default
x-default ist technisch optional, aber praktisch empfehlenswert. Es definiert die Fallback-URL für Nutzer, deren Sprache oder Region keiner der explizit definierten Varianten entspricht — etwa ein Schweizer Nutzer, der auf Französisch sucht, wenn nur de-CH definiert ist.
Nicht indexierbare URLs im Hreflang-Set
Wenn eine der verlinkten URLs durch robots.txt gesperrt oder mit noindex ausgezeichnet ist, kann Google das Hreflang-Signal für das gesamte Set nicht korrekt verarbeiten. Die robots.txt Konfiguration sollte daher mit der Hreflang-Struktur abgestimmt sein.
DACH-spezifische Überlegungen
Im DACH-Kontext stellt sich regelmäßig die Frage: Wann lohnt sich die Aufwand für drei separate Varianten überhaupt? Die Antwort hängt vom Grad der inhaltlichen Differenzierung ab.
Wenn die Seiten für DE, AT und CH nahezu identisch sind — gleiche Preise, gleiche Produktbezeichnungen, gleiche Texte — dann liefert Hreflang zwar das richtige regionale Signal, aber der SEO-Mehrwert ist begrenzt. Google kann dann zwar die richtige Version ausspielen, aber die organische Sichtbarkeit profitiert vor allem dann, wenn die Inhalte tatsächlich lokalisiert sind: österreichische Rechtschreibvarianten, Schweizer Franken statt Euro, länderspezifische Referenzen.
Für B2B-Seiten mit unterschiedlichen Preislisten, Ansprechpartnern oder Compliance-Anforderungen je nach Land ist die Trennung hingegen klar sinnvoll. Die interne Verlinkung zwischen den Varianten sollte dabei konsistent sein — Grundlagen dazu im Artikel zur Internal Linking Strategie.
URL-Struktur für DACH
Für die DACH-Differenzierung gibt es drei gängige URL-Strukturen:
- Subdomains:
de.example.com,at.example.com,ch.example.com - Unterverzeichnisse:
example.com/de/,example.com/at/,example.com/ch/ - Separate Domains:
example.de,example.at,example.ch
Google behandelt alle drei Varianten als gleichwertig für Hreflang. Unterverzeichnisse sind in der Praxis am einfachsten zu verwalten und teilen die Domain Authority. Separate ccTLDs senden ein starkes geografisches Signal, erfordern aber separate Linkbuilding-Strategien. Die Entscheidung sollte strategisch getroffen werden — ein nachträglicher Wechsel ist mit erheblichem Aufwand verbunden.
Validierung und laufendes Monitoring
Nach der Implementierung ist die Überprüfung essenziell. Folgende Tools sind praxisrelevant:
- Google Search Console: Unter „Internationale Ausrichtung" werden Hreflang-Fehler gemeldet — allerdings nicht vollständig. Fehlende gegenseitige Verlinkungen werden beispielsweise nicht immer explizit angezeigt.
- Screaming Frog SEO Spider: Crawlt die gesamte Seite und prüft Hreflang-Sets auf Vollständigkeit, Konsistenz und nicht erreichbare URLs.
- Ahrefs Site Audit: Identifiziert fehlende Return-Tags und inkonsistente URL-Formate im Hreflang-Set.
- hreflang.org Validator: Kostenloses Tool zur schnellen Überprüfung einzelner URLs oder Sitemaps.
Monitoring sollte nach jeder größeren Inhaltsmigration oder URL-Änderung wiederholt werden. Hreflang-Fehler entstehen häufig nicht bei der initialen Implementierung, sondern wenn URLs umstrukturiert werden, ohne die Hreflang-Sets entsprechend zu aktualisieren.
Wer die technische Gesamtstruktur seiner B2B-Website systematisch prüfen will, findet in der Technical SEO Checkliste für B2B-Websites einen umfassenden Rahmen — Hreflang ist dort ein Baustein unter vielen, der mit anderen Signalen wie HTTPS, Ladezeit und Core Web Vitals zusammenwirkt.