Hreflang Implementierungsleitfaden: drei Methoden, x-default und fünf häufige Fehler
Eine Website, die in mehreren Sprachen erscheint, trifft eine stille Entscheidung. Wenn ein französischer Sucher bei Google ein Thema aufruft, das Sie behandeln, welche Version Ihrer Seite soll im Ergebnis erscheinen, das englische Original oder die französische Übersetzung? Wenn ein Spanischsprecher aus Mexiko ankommt, soll er das Spanisch aus Spanien sehen oder das Spanisch aus Lateinamerika? Hreflang ist die kleine Annotation, die Suchmaschinen diese Fragen beantwortet, und es richtig zu setzen ist das, was eine mehrsprachige Site davor bewahrt, gegen sich selbst zu konkurrieren.
Dieser Leitfaden behandelt, was hreflang tatsächlich löst, die drei Wege es zu implementieren, die Syntaxregeln, die im großen Maßstab tragen, den x-default Fallback, das oft missverstandene Verhältnis zu Canonical, die fünf Fehler, die Implementierungen leise zerbrechen, und die Validierungswerkzeuge, die Probleme finden, bevor Nutzer sie sehen.
Was hreflang tatsächlich löst
Hreflang ist eine Annotation, die Google und Yandex sagt, welche Version einer Seite für welche Sprache und Region gedacht ist. Ohne hreflang auf einer mehrsprachigen Site öffnen sich zwei Risiken.
Das erste Risiko ist die falsche Sprache. Ein Nutzer, der auf Deutsch sucht, landet auf der englischen Seite, weil Google nicht wusste, dass die deutsche Version existiert. Konversion sinkt, Absprungrate steigt, der Nutzer erinnert sich an die Reibung.
Das zweite Risiko ist Wettbewerb durch Duplicate Content. Google sieht ähnliche Seiten unter drei URLs (/en/about, /de/about, /fr/about) und behandelt sie als Varianten voneinander. Ohne hreflang wählt der Algorithmus eine zum Ranken aus und stuft die anderen herab, das Gegenteil dessen, was eine mehrsprachige Site braucht.
Hreflang löst beides. Es sagt den Suchmaschinen, “diese drei URLs sind derselbe Inhalt in drei Sprachen, zeige jedem Nutzer die Sprachversion, die zu seiner Suche passt”. Google befolgt das nicht immer perfekt, aber bei korrekter Umsetzung ist es das stärkste Signal, das Sie geben können.
Hreflang verbessert nicht das Ranking als solches. Es verbessert die Lenkung des bestehenden Traffics. Die englische Seite rankt nicht plötzlich besser in englischen Suchen, weil hreflang hinzugefügt wurde. Was sich ändert, ist, dass der deutsche Nutzer nicht mehr auf der englischen Seite landet, wenn die deutsche Seite existiert.
Drei Wege zur Implementierung von hreflang
Google unterstützt drei Platzierungen. Sie sind in der Wirkung gleichwertig, jede hat aber praktische Vor- und Nachteile.
HTML-Head-Tags. Die einfachste und häufigste Methode. Jede Seite listet ihre hreflang-Geschwister im <head> Bereich.
<link rel="alternate" hreflang="en" href="https://example.com/about" />
<link rel="alternate" hreflang="de" href="https://example.com/de/about" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/about" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about" />Das funktioniert für jede Site, die ihre Templates kontrolliert. Der Nachteil ist Seitengewicht bei Sites mit vielen Sprachversionen und die praktische Grenze, wie viele Tags ein Head-Bereich tragen kann, ohne unhandlich zu werden. Zwanzig Sprachen bedeuten zwanzig Link-Tags auf jeder Seite.
HTTP-Antwort-Header. Dieselbe Information im Antwort-Header statt im HTML-Body.
Link: <https://example.com/about>; rel="alternate"; hreflang="en",
<https://example.com/de/about>; rel="alternate"; hreflang="de",
<https://example.com/fr/about>; rel="alternate"; hreflang="fr"Das ist die richtige Wahl für nicht-HTML-Ressourcen wie PDF-Dokumente in mehreren Sprachen. Es funktioniert auch für HTML-Seiten, doch die meisten Teams bevorzugen HTML-Tags für HTML-Inhalte, weil sie leichter zu debuggen und zu validieren sind.
XML-Sitemap. Hreflang-Annotationen innerhalb des Sitemap-Eintrags für jede URL.
<url>
<loc>https://example.com/about</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/about" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about" />
<xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/about" />
</url>Das ist die beste Option für sehr große Sites. Eine Site mit 100.000 URLs in 12 Sprachen würde 1.200.000 Head-Tags tragen, wenn sie in HTML implementiert wäre. Die Sitemap-Variante ist deutlich sauberer und zentralisiert die Annotation in einer Datei. Der Preis ist, dass die Sitemap bei jeder URL-Änderung korrekt neu erzeugt werden muss, und Validierungstools Sitemaps separat behandeln. Kombinieren Sie das mit einem sauberen XML-Sitemap-Prozess, damit es im Maßstab trägt.
Die drei Methoden können gemischt werden, sollten aber für dieselbe Seite nicht kombiniert werden. Wählen Sie eine Methode pro Seite und bleiben Sie konsistent. Widersprüchliche Signale zwischen HTML-Head und Sitemap sind eine häufige Ursache für kaputte Implementierungen.
Code-Standards, die im Maßstab tragen
Hreflang hat strenge Syntaxregeln. Verstöße sind still, Suchmaschinen ignorieren die Annotation, statt zu warnen. Die wichtigsten Regeln.
Verwenden Sie ISO 639-1 für die Sprache. Zweistellige Sprachcodes, klein geschrieben. en, de, fr, es, pt, ja. Dreistellige Codes werden nicht akzeptiert.
Region nur, wenn sie nötig ist. ISO 3166-1 Alpha-2, zweistellige Regionscodes, groß geschrieben, mit Bindestrich von der Sprache getrennt. en-GB für britisches Englisch, en-US für amerikanisches Englisch, es-MX für mexikanisches Spanisch, pt-BR für brasilianisches Portugiesisch. Region ohne Sprache ist ungültig, US allein funktioniert nicht, Sie müssen en-US schreiben. Die meisten Sites brauchen keine Regionalvarianten, nur Sites mit wirklich getrenntem Inhalt für verschiedene Regionen sollten sie nutzen.
Nur absolute URLs. Jede href muss eine voll qualifizierte URL mit Protokoll und Domain sein, https://example.com/de/about, nicht /de/about. Relative Pfade werden nicht honoriert.
Selbstreferenzielle Annotation. Jede Seite muss einen hreflang-Tag enthalten, der auf sich selbst zeigt. Die englische Seite listet die englische URL mit hreflang="en" zusammen mit den deutschen und französischen URLs. Viele Implementierungen vergessen die Selbstreferenz, und die ganze Annotationsmenge wird als ungültig behandelt.
Bidirektionale Rück-Tags. Jede Seite in der Menge muss jede andere Seite in der Menge listen. Wenn die englische Seite mit hreflang auf die deutsche zeigt, muss auch die deutsche mit hreflang auf die englische zeigen. Fehlende Rück-Tags sind der häufigste Grund, warum hreflang-Implementierungen in Search-Console-Berichten scheitern. Eine SEO-Crawler-Routine fängt diese im Maßstab, manuelle Prüfung ab fünf Sprachen funktioniert nicht.
HTTPS konsistent verwenden. Alle hreflang-URLs sollten HTTPS sein, dasselbe Protokoll wie die kanonische URL. HTTP und HTTPS in derselben Annotationsmenge zu mischen, führt dazu, dass Google die inkonsistenten verwirft.
Ein Sprachcode pro URL. Eine URL kann nicht zwei hreflang-Werte haben. Wenn Sie zwei Sprachen aus einer URL bedienen wollen, haben Sie ein Inhaltsproblem, kein hreflang-Problem.
Der x-default-Tag
x-default ist die Fallback-Annotation. Sie sagt Suchmaschinen, “wenn keine Sprachübereinstimmung existiert, schicke den Nutzer hierher”.
<link rel="alternate" hreflang="x-default" href="https://example.com/" />Der klassische Anwendungsfall ist eine Site mit englischer, deutscher und französischer Version sowie einer Sprachauswahlseite. Ein Nutzer, der auf Italienisch sucht, hat keine italienische Version. Ohne x-default rät Google, an welche Version der Nutzer gehen soll. Mit x-default, das auf die Sprachauswahl (oder je nach Absicht auf die englische Version) zeigt, ist die Lenkung explizit.
x-default ist nicht streng vorgeschrieben, aber die meisten internationalen Sites profitieren davon. Ausnahmen sind Sites mit nur zwei oder drei Sprachen ohne realistische Fallback-Absicht, wo das Fehlen von x-default in Ordnung ist.
Hreflang versus Canonical
Das ist die Quelle von mehr hreflang-Implementierungsfehlern als jedes andere Konzept. Sie sind nicht dasselbe, sie ersetzen sich nicht und sie stehen sich nicht gegenüber.
Canonical sagt, “von diesen ähnlichen URLs ist diese die Master-Version”. Es wird verwendet, um Duplikate und Tracking-Parameter-Varianten unter einer indexierbaren URL zu konsolidieren. Die volle Mechanik wird im Leitfaden zu Canonical-Tags behandelt.
Hreflang sagt, “diese URLs sind in verschiedenen Sprachen gleichwertig, lenke jeden Nutzer zur richtigen”.
Die beiden arbeiten zusammen. Auf einer mehrsprachigen Site sollte jede Sprachversion ein selbstreferenzielles Canonical haben, das auf sich selbst zeigt, plus hreflang-Annotationen, die auf alle Sprachgeschwister zeigen.
<!-- Auf der deutschen Seite -->
<link rel="canonical" href="https://example.com/de/about" />
<link rel="alternate" hreflang="en" href="https://example.com/about" />
<link rel="alternate" hreflang="de" href="https://example.com/de/about" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/about" />Häufiger Fehler, die deutsche Seite setzt Canonical auf die englische Seite (<link rel="canonical" href="https://example.com/about" />). Das sagt Google, die deutsche Seite sei ein Duplikat der englischen, was im Konflikt mit dem hreflang-Signal steht, das sie als Geschwister kennzeichnet. Google ignoriert in diesem Konflikt das hreflang, und die deutsche Seite rankt nicht in deutschen Suchen. Die Lösung ist immer Self-Canonical auf Sprachvarianten, niemals Canonical auf die Master-Sprache.
Fünf häufige Fehler
Die folgenden Fehler kommen in Audits immer wieder vor. Jeder einzelne zerbricht die Implementierung leise, und Search Console zeigt sie selten klar.
Fehlende Rück-Tags. Die englische Seite listet deutsche und französische Alternativen, aber die deutsche Seite listet die englische nicht zurück. Google behandelt die Annotation als unvollständig und ignoriert sie möglicherweise ganz. Bidirektionale Verifikation ist das Erste, was in jedem Audit zu prüfen ist.
Falsche Sprach- oder Regionscodes. en-UK ist falsch, der korrekte Code ist en-GB. pt-PT und pt-BR sind gültig, pt allein ist auch gültig für “irgendein Portugiesisch”. zh ist technisch gültig, aber zh-CN (vereinfacht) und zh-TW (traditionell) sind in der Praxis weit nützlicher. Codes, die nicht parsen, werden still verworfen.
HTTP und HTTPS mischen. Eine Migration von HTTP auf HTTPS lässt einige hreflang-URLs auf dem alten Protokoll. Die gemischte Menge fällt aus. Prüfen Sie hreflang-URLs nach jeder Protokoll- oder Domain-Migration, das ist einer der Punkte in der technischen SEO-Audit-Checkliste.
Verlinkung auf noindex- oder weitergeleitete Seiten. Eine hreflang-URL muss auf eine indexierbare 200-OK-Seite auflösen. Wenn sie 301 weiterleitet oder noindex zurückgibt, wird die Annotation verworfen. Die Qualität der Annotationsmenge hängt davon ab, dass jede URL in der Menge live und indexierbar ist.
Canonical zeigt auf die falsche Sprache. Wie oben beschrieben, muss die Sprachvariante selbst-canonical sein, nicht canonical auf die Master-Sprache. Das ist der Fehler mit dem höchsten Schaden auf der Liste, weil er die Sprachversion direkt aus den Suchergebnissen entfernt.
Validierung
Hreflang-Probleme sind im normalen Browsen nicht sichtbar. Sie zeigen sich erst, wenn ein Nutzer in einer Sprache sucht und auf der falschen Version landet, oder wenn Traffic-Daten Unterperformance in einem Zielmarkt aufzeigen. Die Validierung muss auf Implementierungsebene passieren, nicht auf Nutzerebene.
Search Console International Targeting Bericht. Das native Google-Tool. Listet hreflang-Fehler auf Property-Ebene, einschließlich fehlender Rück-Tags und nicht erkannter Sprachcodes. Die Verzögerung ist real, Fehler erscheinen erst nach Tagen, aber die Daten sind autoritativ, sobald sie da sind.
Aleyda Solis hreflang-Validator. Ein kostenloses öffentliches Tool, das eine URL annimmt und die hreflang-Annotationsmenge mit Validierung zurückgibt. Nützlich für Stichprobenprüfung einzelner Seiten während der Implementierung.
SEO-Crawler. Ein Desktop-Crawler kann die gesamte hreflang-Annotationsmenge über Tausende URLs in einem Lauf prüfen. Manuelle Verifikation ab fünfzig Seiten ist unrealistisch. Crawler fangen fehlende Rück-Tags, falsche Protokolle, defekte hreflang-URLs und noindex-Ziele alle im selben Audit.
Für Sites mit aktiven mehrsprachigen Rollouts gehört die hreflang-Validierung in dieselbe monatliche Kadenz wie Broken-Link-Checks und Canonical-Audits. Sie zieht keine Aufmerksamkeit auf sich, bis etwas falsch ist, und dann ist der Schaden für internationale Rankings bereits angefallen.
Wann hreflang den größten Effekt hat
Hreflang hat den stärksten Einfluss in drei Szenarien.
Sites, in denen jede Sprache ungefähr gleiche kommerzielle Bedeutung hat. Ein SaaS-Unternehmen, das in fünf europäischen Märkten verkauft, braucht jede Sprache, um in ihrer eigenen Suche zu ranken. Hreflang ist die Lenkungsschicht, die das ermöglicht.
Sites mit Regionalvarianten derselben Sprache. Mexikanisch-spanischer Inhalt, der in lateinamerikanischen Suchen mit Spanisch aus Spanien konkurriert, ist ein häufiger Konflikt. Ohne es-MX und es-ES rät Google, und der Rat ist oft genug falsch, um zu schaden.
Migrationen und Sprach-Rollouts. Wenn eine Site eine neue Sprachversion hinzufügt, ist hreflang das, was Google sagt, die neuen Seiten als richtige Sprachgeschwister der bestehenden zu behandeln, nicht als neue duplizierte Konkurrenten.
Die Szenarien, in denen hreflang weniger Wirkung hat, vollständigkeitshalber, sind Sites mit einer wirklich dominanten Sprache, in denen die anderen kleine Traffic-Bruchteile sind, und Sites, deren Nutzer aus Nicht-Zielsprachen ohnehin nicht zum Zielmarkt gehören.
Fazit
Hreflang ist klein im Code und groß in der Wirkung. Ein paar Link-Tags oder ein Sitemap-Abschnitt, korrekt geschrieben und bidirektional referenziert, steuern das internationale Routing einer mehrsprachigen Site. Die fünf häufigen Fehler sind leicht zu machen, leicht zu beheben, und die Validierungstools existieren aus gutem Grund.
Für eine Site, die gerade eine neue Sprache hinzugefügt hat und die Implementierung bestätigen möchte, lautet die Audit-Reihenfolge, Self-Canonical auf jeder Sprachvariante prüfen, bidirektionale hreflang-Rück-Tags prüfen, alle hreflang-URLs auf HTTPS und Indexierbarkeit prüfen, Sprach- und Regionscodes auf korrektes Parsen prüfen, dann den Search Console International Targeting Bericht in den nächsten zwei Wochen beobachten.
Für Sites mit mehreren laufenden Sprachstarts kombinieren Sie hreflang-Arbeit mit Meta-Tags-Hygiene und einem regelmäßigen technischen SEO-Audit, die drei verstärken sich gegenseitig im internationalen SEO.
Wenn Sie ein Werkzeug brauchen, um hreflang über eine ganze Site ohne manuelle Prüfung zu verifizieren, laden Sie Seodisias kostenlos herunter. Es läuft lokal auf Ihrer Maschine, validiert die volle hreflang-Annotationsmenge inklusive Rück-Tags und meldet defekte URLs und Protokollmischungen als Teil jedes Audits.