Deine hreflang-Implementierung ist wahrscheinlich kaputt. Der Fehler taucht meist nicht in deinem Traffic-Dashboard auf. Er taucht Monate später auf, wenn die spanische Version eines Artikels in Spanien auf Platz 4 rankt, die deutsche Version in Deutschland gar nicht erscheint und die französische Version irgendwie für englische Queries in Kanada rankt. Die Lösung ist selten eine Code-Änderung. Sie ist fast immer ein strukturelles Missverständnis darüber, was hreflang ist, wo es hingehört und welche Validierungsregel gebrochen wurde.
Dieser Leitfaden zeigt dir die drei Orte, an denen hreflang leben kann (HTML head, XML-Sitemap, HTTP-Header), die Regeln, die Google tatsächlich durchsetzt, die fünf Fehler, die die meisten Ranking-Ausfälle verursachen, und was Kamaans Auto-Multilingual Delivery automatisch ausgibt, damit du an nichts davon denken musst.
Schnelle Erkenntnisse
- Hreflang ist ein Beziehungssignal, kein Ranking-Signal. Es sagt Google, welche Version in welchem Markt gezeigt werden soll. Es bewegt dich nicht in der SERP nach oben.
- Drei Implementierungsmethoden existieren: HTML link-Tags in
<head>, XML-Sitemapxhtml:link-Annotationen und HTTPLink-Header. Wähle eine und bleibe dabei. Sie zu mischen ist die häufigste Quelle für Validierungsfehler. - Jede hreflang-Annotation muss reziprok sein. Seite A verweist auf Seite B, Seite B verweist auf Seite A. Verfehlst du das, ignoriert Google beide Annotationen stillschweigend.
- Der Wert
x-defaultsagt Google, was zu liefern ist, wenn keine Sprachversion passt. Ohne ihn rät Google. - Hreflang-URLs müssen HTTP 200 zurückgeben. Eine 301-Weiterleitung oder ein 404 zerstört den gesamten Annotations-Cluster, nicht nur die kaputte Seite.
Was hreflang wirklich tut (und was nicht)
Hreflang ist ein Tag, das Suchmaschinen sagt: "Diese Seite existiert in einer anderen Sprache oder Region unter dieser URL." Das ist der gesamte Geltungsbereich. Es sagt Google nicht, dass eine Seite wichtiger ist. Es boostet keine Rankings. Es ersetzt keine Sitemap. Es ersetzt keinen übersetzten Inhalt.
Was hreflang tut, ist ein spezifisches Problem zu lösen: Wenn Google fünf Sprachversionen desselben Artikels gecrawlt hat, welche soll es für eine Suche in Madrid versus Berlin versus Lyon zeigen? Ohne hreflang rät Google basierend auf Signalen wie Inhaltssprache der Seite, IP des Nutzers und Domain-TLD. Mit hreflang hat Google eine definitive Karte.
Der Mechanismus ist eine Beziehungsdeklaration. Jede Seite in einem Sprachen-Cluster verweist auf jede andere Seite im Cluster, einschließlich sich selbst. Wenn dein Blog englische, spanische, deutsche, französische und italienische Versionen eines Artikels hat, deklariert jede dieser fünf Seiten alle fünf URLs mit ihren Sprachcodes.
Das Format ist präzise. Sprachcodes folgen ISO 639-1 (zwei Buchstaben, klein): en, es, de, fr, it. Regionscodes sind optional und folgen ISO 3166-1 Alpha 2 (zwei Buchstaben, groß): en-US, en-GB, es-MX, es-ES. Du kombinierst sie mit einem Bindestrich: en-US, de-AT, fr-CA. Es gibt keine Unterstützung für dreibuchstabige Codes. Es gibt keinen Unterstrich-Separator. Es gibt keine Verschachtelung.
Die drei Implementierungsmethoden im Vergleich
Du kannst hreflang-Annotationen an einem von drei Orten platzieren. Die richtige Wahl hängt davon ab, wie viele Sprachen du bedienst und ob du die Server-Antwort kontrollierst.
Die Grafik unten zeigt die Kompromisse jedes Ansatzes, damit du den richtigen für deinen Blog wählst.
| Methode | Wo es lebt | Am besten für | Was es zerstört |
|---|---|---|---|
HTML <link>-Tags |
In <head> jeder Seite |
Sites mit 5 oder weniger Sprachen | Seitengewicht wächst pro Sprache. Leicht eine zu vergessen. |
| XML-Sitemap | In xhtml:link innerhalb jedes <url> |
Sites mit 6+ Sprachen, 100+ Seiten | Sitemap-Disziplin nötig. Re-Crawl-Latenz. |
HTTP Link-Header |
In Server-Antwortheadern | Nicht-HTML-Dateien (PDFs, JSON, Bilder) | Server-Config nötig. CDN-Schichten entfernen Header. |
HTML <link>-Tags sitzen im <head> jeder Seite im Cluster:
<link rel="alternate" hreflang="en" href="https://example.com/blog/article" />
<link rel="alternate" hreflang="es" href="https://example.com/es/blog/article" />
<link rel="alternate" hreflang="de" href="https://example.com/de/blog/article" />
<link rel="alternate" hreflang="x-default" href="https://example.com/blog/article" />
Leicht mit Quelltext anzeigen zu inspizieren. Der Nachteil zeigt sich über fünf Sprachen hinaus: das HTML-Gewicht steigt mit jeder Ergänzung.
XML-Sitemap-Annotationen verschieben die hreflang-Karte in die Sitemap als xhtml:link-Elemente innerhalb jedes <url>:
<url>
<loc>https://example.com/blog/article</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/blog/article" />
<xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/blog/article" />
</url>
Richtige Wahl ab fünf Sprachen oder hundert Seiten. Zentralisiert, auditierbar, sauberes HTML. Der Preis ist Re-Crawl-Latenz.
HTTP Link-Header sind die richtige Wahl nur für Nicht-HTML-Dateien (PDFs, JSON-Endpoints). Der Server gibt einen Link-Header aus. Erfordert Server-Config und ist anfällig über CDN-Schichten, die benutzerdefinierte Header entfernen. Verwende sie nicht für HTML-Seiten, wenn eine Alternative existiert.
Die fünf Fehler, die Rankings killen
Die meisten hreflang-Ausfälle fallen in eine von fünf Kategorien. Jeder davon ist in unter einer Stunde behebbar, sobald du weißt, wonach du suchen musst.
Fehler eins: fehlende Return-Tags. Jede hreflang-Deklaration muss reziprok sein. Wenn dein englischer Artikel die spanische Version unter /es/blog/article deklariert, muss der spanische Artikel die englische Version unter /blog/article deklarieren. Fehlt eine der beiden Richtungen, nennt Google das einen "no return tag"-Fehler in der Search Console und ignoriert beide Annotationen. Das ist die am häufigsten gescheiterte Validierungsregel im internationalen SEO und taucht meist Monate nach einem teilweisen Übersetzungs-Rollout auf, wenn eine Sprachversion veröffentlicht und die anderen vergessen wurden.
Fehler zwei: falsche Sprach- oder Regionscodes. Die Codes sind präzise und gnadenlos. Verwende uk für Ukrainisch, niemals ua. Verwende zh-Hans für vereinfachtes Chinesisch, nicht zh-CN. Dreibuchstabige Codes funktionieren nicht. Ein häufiger stiller Ausfall: en-UK statt en-GB schreiben (das Vereinigte Königreich ist GB in ISO 3166-1, nicht UK).
Fehler drei: fehlendes x-default. Der Wert x-default sagt Suchmaschinen, welche Seite zu liefern ist, wenn keine Sprachversion zum Nutzer passt. Ohne ihn entscheidet Google selbst, meist liefert es die Version, die es am häufigsten gecrawlt hat. Schließe immer ein x-default ein, das auf deine Hauptversion zeigt. Für einen Blog, dessen Hauptsprache Englisch ist, setze x-default auf die englische URL.
Fehler vier: hreflang zeigt auf eine Nicht-200-URL. Jede URL in deinem Annotations-Cluster muss HTTP 200 zurückgeben. Eine 301-Weiterleitung, ein 404 oder ein 500 zerstört das gesamte Annotations-Set. Wenn du /de/blog/old-slug zu /de/blog/new-slug weiterleitest, muss dein hreflang auf den neuen Slug zeigen, nicht auf die Weiterleitung. Wenn die deutsche Übersetzung noch nicht existiert, deklariere kein hreflang für Deutsch. Ein kaputter Zeiger ist schlimmer als ein fehlender.
Fehler fünf: Canonical-Tag-Konflikt. Wenn deine spanische Seite hreflang auf https://example.com/es/blog/article zielt, aber diese Seite ein <link rel="canonical"> hat, das auf die englische URL zeigt, folgt Google dem Canonical und ignoriert das hreflang. Jede Seite in einem hreflang-Cluster muss sich selbst kanonisieren. Die spanische Seite kanonisiert auf sich selbst. Die deutsche Seite kanonisiert auf sich selbst. Sprachübergreifende Canonicals zerstören hreflang stillschweigend.
Wie du deine Implementierung verifizierst
Drei Checks decken die meisten Fehlerquellen ab.
Verwende Google Search Console. Navigiere zu Legacy-Tools und -Reports, dann zu International Targeting. Der Report "No return tags" listet jede Seite, auf der die Reziprozität gebrochen ist. Der Report "Unknown language code" listet jeden ungültigen Code. Diese beiden Reports decken die Mehrheit der realen hreflang-Fehler auf.
Crawle mit einem Tool. Screaming Frog, Sitebulb oder Ahrefs Site Audit validieren hreflang-Cluster im großen Maßstab. Crawle deine gesamte Site, filtere nach hreflang-Fehlern, und du siehst jeden Cluster mit fehlendem Return-Tag, falschem Code oder Nicht-200-Ziel. Eine Stichprobe von fünf Artikeln reicht nicht. Ein mehrsprachiger Blog hat typischerweise Hunderte von Clustern.
Teste die Header und Tags direkt. curl -I https://example.com/blog/article zeigt die Antwortheader, einschließlich aller Link-Header. Quelltext anzeigen auf der Seite zeigt die <link>-Tags. Die XML-Sitemap ist eine URL entfernt. Wenn du dein hreflang in keinem dieser drei Orte findest, hast du kein hreflang implementiert, egal was dein CMS-Dashboard behauptet.
Was Kamaan automatisch ausgibt
Kamaans automatische mehrsprachige Auslieferung übernimmt die hreflang-Implementierung für dich. Wenn du einen Artikel auf Englisch veröffentlichst, erstellt Kamaan automatisch die spanische, deutsche, französische und italienische Version, gibt jeder einen lokalisierten Slug und gibt das vollständige reziproke hreflang-Annotations-Set auf jeder Version aus. Die Defaults sind out-of-the-box korrekt.
Konkret gibt Kamaan HTML <link>-Tags im <head> jeder Blog-Seite aus, mit dem vollständigen Set von Sprachalternativen, einschließlich x-default, das auf die englische Version zeigt. Die übersetzten URLs folgen dem Muster /{lang}/blog/{slug} (Sprach-Präfix vor blog), was Googles Empfehlung für unterverzeichnis-basierte mehrsprachige Sites entspricht. Jede URL kanonisiert sich selbst. Reziprozität ist garantiert, weil dieselbe Veröffentlichungsaktion alle fünf Versionen in einer Transaktion erstellt.
Für größere Blogs mit vielen Sprachen gibt Kamaan zusätzlich die hreflang-Karte in der XML-Sitemap als xhtml:link-Annotationen aus. Du bekommst beide Methoden gratis, was die Redundanz ist, die Googles Dokumentation für Blogs empfiehlt, die im großen Maßstab arbeiten.
Der Punkt ist nicht, dass Kamaan etwas tut, was niemand sonst kann. Der Punkt ist, dass du aufhörst, Engineering-Zeit für hreflang aufzuwenden. Auto-Multilingual Delivery veröffentlicht spanische, deutsche, französische und italienische Versionen jedes Artikels in dem Moment, in dem du auf Englisch veröffentlichst, mit gültigem hreflang auf jeder, und null zusätzlichen Schritten.
Eine praktische Setup-Checkliste
Bevor du einen mehrsprachigen Blog veröffentlichst, arbeite diese Liste einmal durch. Dann automatisiere sie (oder verwende ein CMS, das sie für dich handhabt).
- Wähle eine Implementierungsmethode. HTML-Tags für 5 Sprachen oder weniger. XML-Sitemap für 6 oder mehr. HTTP-Header nur für Nicht-HTML.
- Bestätige, dass jede Seite in jeder Sprache eine
x-default-Annotation hat, die auf die Hauptsprachversion zeigt. - Bestätige Reziprozität. Jede Seite im Cluster verweist auf jede andere Seite, einschließlich sich selbst.
- Bestätige, dass jede URL in jeder Annotation HTTP 200 zurückgibt (keine Weiterleitungen, keine 404).
- Bestätige, dass jede Seite im Cluster ein selbstreferenzierendes Canonical hat, kein sprachübergreifendes Canonical.
- Reiche die Sitemap ein (oder warte auf Re-Crawl).
- Prüfe Search Console International Targeting nach 7-14 Tagen auf Return-Tag-Fehler.
Wenn ein Schritt in dieser Liste von deinem CMS automatisiert wird, hast du eine Sache weniger, die kaputt gehen kann. Wenn dein CMS keine dieser Dinge tut, machst du es manuell und wirst irgendwann einen davon falsch machen.
Reale Szenarien
Ein Gründer, der ein B2B-SaaS-Rechnungstool betreibt, veröffentlicht einen Artikel über sein neues Recurring-Billing-Feature. Innerhalb von zehn Minuten hat Kamaan automatisch spanische, deutsche, französische und italienische Versionen unter /es/blog/, /de/blog/, /fr/blog/ und /it/blog/ veröffentlicht, jede mit dem vollständigen reziproken hreflang-Block ausgegeben in HTML <head> und gespiegelt in der XML-Sitemap. Der International-Targeting-Report von Google Search Console zeigt null "no return tag"-Fehler. Der Gründer hat keine Zeile hreflang-Konfiguration geschrieben.
Ein einzelner Entwickler hatte einen Next.js-Blog mit manuellem hreflang in <head> für drei Sprachen. Eine vierte Sprache hinzuzufügen zerstörte die Reziprozität bei 60 Prozent der älteren Artikel, weil das neue Tag nur zu neuen Posts hinzugefügt wurde. Die Migration zu Kamaan handhabte auch die historischen Artikel: die nächste Veröffentlichung löste eine vollständige Re-Ausgabe der hreflang-Karte für jeden veröffentlichten Artikel in jeder Sprache aus. Die Fehlerzahl in der Search Console fiel von 412 auf 0 innerhalb eines Re-Crawl-Zyklus.
FAQ
Brauche ich hreflang, wenn ich nur eine Sprache habe?
Nein. Hreflang ist ein Beziehungssignal zwischen Sprach- oder Regionsvarianten. Mit einer Sprache gibt es nichts zu beziehen. Überspringe es.
Helfen hreflang-Tags SEO direkt?
Nein, nicht im Ranking-Sinn. Hreflang bewegt dich nicht in der SERP nach oben. Was es tut, ist sicherzustellen, dass die richtige Version deiner Seite im richtigen Markt rankt. Das kann sich in Traffic-Gewinne übersetzen, ist aber eine Routing-Verbesserung, kein Ranking-Boost.
Kann ich hreflang in einer Single-Page-App mit Client-side-Routing verwenden?
Ja, aber mit Einschränkungen. Die hreflang-Annotation muss in der initialen HTML-Antwort sein, nicht nach JavaScript-Ausführung injiziert. Googlebot liest die initiale Antwort. Wenn deine <link rel="alternate">-Tags erst nach Client-side-Hydration erscheinen, sieht Google sie nicht. Server-rendere den Head oder verwende die Sitemap-Methode.
Was ist der Unterschied zwischen x-default und en?
x-default ist ein Fallback für den Fall, dass keine Sprache zum Nutzer passt. en zielt speziell auf englischsprachige Sucher ab. Du brauchst beide. x-default ist kein Ersatz für en, und en ist kein Ersatz für x-default.
Wie lange dauert es, bis hreflang-Änderungen wirksam werden?
Google muss jede Seite im Cluster neu crawlen, was Tage bis Wochen dauern kann, je nach deinem Crawl-Budget. Der International-Targeting-Report der Search Console aktualisiert sich nach eigenem Zeitplan und kann 7-14 Tage verzögert sein, selbst nachdem Google neu gecrawlt hat.
Warum funktioniert mein sitemap-basiertes hreflang, aber mein HTML-hreflang nicht?
Zwei häufige Ursachen. Entweder werden die HTML-Tags client-side injiziert, nachdem Googlebot das Lesen der Seite beendet hat, oder du hast einen Canonical-Konflikt, bei dem die Seite hreflang auf eine URL hat, aber auf eine andere kanonisiert. Prüfe beides.
Weiterlesen auf Kamaan
- How to Build a Multilingual Blog: A Complete Guide for SaaS Products. Die übergeordnete Pillar-Seite behandelt das vollständige mehrsprachige Setup von URL-Struktur bis Übersetzungs-Workflow.
- Multilingual SEO: What It Is, Why It Matters, and How to Get It Right. Wo hreflang in das breitere internationale-SEO-Bild passt.
- What Is a Headless CMS: A Plain-English Guide for SaaS Teams. Der architektonische Kontext, warum ein Headless CMS Mehrsprachigkeit besser handhabt als ein traditionelles CMS.
- How to Add a Blog to Your SaaS Product: A Developer Guide. Der Integrations-Aspekt: wie du einen mehrsprachigen Blog in ein bestehendes Produkt einbindest.
Starte mit Kamaan
Gültiges hreflang bei jeder Veröffentlichung, null Konfiguration
Kamaan gibt dir ein Dashboard für alle deine Produkt-Blogs, automatisch übersetzt in 99+ Sprachen bei jeder Veröffentlichung. Ein Account deckt unbegrenzte Sites zu einem flachen Preis ab. Der MCP Server lässt dich aus Claude oder ChatGPT veröffentlichen. Erster Monat gratis.
