2021 übernahm ich eine 14.000-Seiten-E-Commerce-Website von einem Kunden, dessen vorherige Agentur "die internationale SEO gemacht" hatte. Drei Wochen nach Beginn eines Audits fand ich 31.000 hreflang-Fehler in Google Search Console. Einunddreißigtausend. Die Website hatte sieben Sprachvarianten und jede einzelne Seite fehlte ihr selbstreferenzierendes Tag. Die deutschen Seiten verwiesen auf französische URLs. Das x-default wies auf eine URL hin, die an ganz anderer Stelle mit 301-Redirect weiterleitete. Der organische Traffic aus nicht-englischsprachigen Märkten war seit acht Monaten eingebrochen und niemand hatte die Verbindung gezogen.
Dieses eine Projekt ist wahrscheinlich der Hauptgrund, warum ich hreflang-Implementierung jetzt als erste Klasse Engineering-Problem behandle, nicht als Nachgedanke, den man während eines Übersetzungs-Sprints dranflickt.
Also gehen wir es richtig an.
---
Was hreflang tatsächlich macht (und was nicht)
Ich halte mich kurz, denn die meisten haben bereits eine grobe Idee davon. hreflang ist ein HTML-Attribut (oder HTTP-Header oder XML-Sitemap-Eintrag), das Google mitteilt, welche Version einer Seite welcher Sprach- und Regionskombination entspricht. Es ändert Rankings nicht direkt. Es ändert, welche URL Google welchem Nutzer in welchem Land anzeigt.
Das war's. Es ist ein Signal, keine Direktive. Google kann es ignorieren, wenn die Implementierung fehlerhaft oder widersprüchlich ist. Und das tut es auch. Regelmäßig.
Was es nicht tut: Es blockiert Nutzer nicht vom Zugriff auf die falsche regionale Version, es ersetzt deine Content-Strategie nicht, und es gleicht definitiv nicht dünne übersetzte Seiten aus, die nur maschinell übersetzte Kopien ohne Lokalisierungsaufwand sind.
Es lohnt sich, Googles eigene hreflang-Dokumentation vor allem anderen zu lesen. Sie ist trockener als ein altbackenes Keks, aber sie ist präzise.
---
Die fünf Fehler, die ich bei fast jedem Audit sehe
Fehlende selbstreferenzierende Tags
Das ist der große. Jede Seite in einem hreflang-Cluster muss ein Tag haben, das auf sich selbst verweist. Nicht nur auf die anderen Varianten. Auf sich selbst.
Wenn deine englische Seite unter example.com/en/product/ Tags hat, die auf /de/product/ und /fr/product/ verweisen, aber das hreflang="en" vergesst, das auf /en/product/ zurückverweist, ist der gesamte Cluster technisch ungültig. Google wird nicht unbedingt einen Hard Error werfen, aber es wird sein Vertrauen in den gesamten Signal-Satz reduzieren.
Ich habe diesen Fehler auf Websites von Entwicklern gesehen, die einen Blog-Post gelesen haben, ein Beispiel mit zwei Varianten sahen und das selbstreferenzierende Tag nicht bemerkt haben, weil das Beispiel schlecht geschrieben war. Ich nenne da keine Namen.
Return-Tags sind fehlerhaft oder nicht vorhanden
hreflang ist eine bidirektionale Beziehung. Wenn deine englische Seite auf deine deutsche Seite verweist, muss die deutsche Seite zurück auf die englische Seite verweisen. Fehlt dieser Return-Tag, sieht Google einen unterbrochenen Handshake.
Bei dem 2021-Projekt, das ich erwähnt habe, hatte ein Entwickler hreflang nur im englischen Template hinzugefügt. Die deutschen, französischen und spanischen Templates hatten überhaupt kein hreflang. Google erhielt also nur die halbe Konversation und ignorierte das Ganze vernünftigerweise.
Falsche Sprachcodes
Verwende BCP-47-Sprach-Tags. Das bedeutet en für Englisch generisch, en-GB für britisches Englisch, en-US für amerikanisches Englisch. Nicht en_GB. Nicht english. Nicht ENG.
Ich fand lang="english-uk" auf einer FinTech-Website, die wir bei Seahawk letztes Jahr auditiert haben. Der Entwickler hatte das Format offenbar einfach geraten. Es war 14 Monate lang live.
x-default fehlt oder ist falsch
x-default sollte auf eine Seite verweisen, die Benutzer handhabt, deren Sprache oder Region keiner deiner anderen Varianten entspricht. Normalerweise deine Startseite oder eine Sprachwahlseite. Es ist nicht einfach ein Synonym für „englische Version". Ich habe x-default auf URLs verweisen sehen, die einen 404 zurückgeben, auf Weiterleitungsketten verweisen, und einmal, unvergesslich, auf eine Staging-Umgebung.
Wenn du keine sinnvolle Fallback-Seite hast, ist es eigentlich besser, x-default wegzulassen, als es falsch zu verwenden. Aber normalerweise solltest du eine haben.
Canonical und hreflang falsch zusammen verwenden
Dein Canonical-Tag und deine hreflang-Tags dürfen sich nicht widersprechen. Wenn /en-gb/page/ ein Canonical auf /en/page/ zeigt, aber auch hreflang deklariert, dass es sich selbst als en-GB ausweist, hast du einen Signalkonflikt erzeugt. Das Canonical sagt effektiv „Ich bin nicht die bevorzugte Version dieser URL", während hreflang sagt „Ich bin die bevorzugte Version für britische Englischsprachige". Google muss sich für eine Interpretation entscheiden und wählt oft keine von beiden.
---
Implementierung auf großen Websites ohne den Verstand zu verlieren
Template-Ebene vs. Seiten-Ebene
Bei einer Website mit 50 Seiten könntest du jeden hreflang-Tag manuell erstellen. Bei einer Website mit 5.000 Seiten kannst du das nicht. Du musst sie programmatisch generieren.
Der sauberste Ansatz, den ich gefunden habe, ist, deine URL-Zuordnungen in einer strukturierten Datenquelle zu speichern (eine Datenbanktabelle oder sogar eine einfache JSON-Datei für kleinere Projekte) und die Tags zum Render-Zeitpunkt zu generieren. In WordPress behandeln Yoast SEO und Rank Math das für Standardsetups einigermaßen gut, aber beide scheitern, wenn deine URL-Strukturen sich über Sprachen hinweg unterscheiden, anstatt einem vorhersehbaren /en/, /de/, /fr/ Präfixmuster zu folgen.
Wenn deine URLs nicht einheitlich sind (sagen wir, übersetzte Slugs wie example.com/en/running-shoes/ und example.com/de/laufschuhe/), benötigst du eine explizite Zuordnungstabelle. Kein Plugin wird das automatisch herausfinden. Ich habe das auf teure Weise bei einem Sportkleidungskunden im Jahr 2022 gelernt, dessen übersetzte Slugs völlig unabhängig von den englischen waren.
XML-Sitemap-Methode
Bei sehr großen Websites bevorzuge ich die XML-Sitemap-Methode gegenüber Inline-HTML-Tags. Sie hält den <head> sauber, lässt sich programmatisch leichter auditieren, und du kannst die Sitemap aktualisieren, ohne Seiten-Templates zu verändern.
Das Format sieht konzeptionell wie folgt aus (ohne Code-Fence): Jeder <url>-Block enthält mehrere <xhtml:link>-Einträge, einen pro Sprachvariante inklusive des selbstreferenzierenden. Die xmlns:xhtml-Namespace-Deklaration muss im <urlset>-Element vorhanden sein, oder das Ganze bricht lautlos zusammen.
Eine Sache zu beachten: Die Sitemap-Methode funktioniert nur, wenn Google Ihre Sitemaps kürzlich gecrawlt und indexiert hat. Wenn Sie auf einer großen Website Crawl-Budget-Probleme haben, ist die HTML-Methode zuverlässiger, weil Googlebot Tags inline liest, während es jede Seite crawlt.
HTTP-Header für Nicht-HTML-Inhalte
Sie haben PDFs oder andere Nicht-HTML-Dateien, die hreflang benötigen? Verwenden Sie HTTP-Header. Ihr Server gibt einen Link-Header mit rel="alternate" und hreflang-Attributen zurück. Das ist in der Praxis selten, aber ich habe große Rechts- und Finanzwebsites mit Tausenden mehrsprachiger PDF-Dokumente gesehen, wo das tatsächlich wichtig ist.
---
Tools, die wirklich helfen
Ich habe im Laufe der Jahre viele Tools verwendet. Das sind die Tools, die ich tatsächlich nutze:
- Screaming Frog SEO Spider: Führen Sie einen Crawl durch, gehen Sie zum hreflang-Tab. Das Tool markiert fehlende Return-Tags, fehlende Self-References, fehlerhafte URLs und ungültige Sprachcodes an einem Ort. Das ist mein erste Anlaufstelle bei jedem internationalen Audit. Mit £199 pro Jahr ist es das beste technische SEO-Tool, das ich kenne.
- Ahrefs Site Audit: Gute sekundäre Überprüfung, besonders wenn Sie die Daten mit organischen Traffic-Daten in derselben Plattform abgleichen möchten.
- hreflang-Tags-Testtool von Merkle: kostenlos unter https://technicalseo.com/tools/hreflang/. URL einfügen, es prüft den gesamten Cluster. Perfekt zum Spot-Check einzelner Seiten während der Fehlerbehebung.
- Google Search Console: Der Bericht „Internationale Ausrichtung" unter Legacy Tools. Aktualisierung dauert, aber das ist die maßgebliche Quelle dafür, wie Google Ihre Implementierung tatsächlich interpretiert.
- Sitebulb: Wenn du einen visuellen Crawler mit anfängerfreundlicherer Berichterstattung bevorzugst, leistet Sitebulb gute Dienste bei der Visualisierung von hreflang-Cluster-Beziehungen.
Was ich nicht nutze: die hreflang-Generator-Tools, die dir einen statischen Tag-Block zum Kopieren und Einfügen erzeugen. Sie sind in Ordnung zum Erlernen der Syntax. Sie sind nutzlos für alles über 20 Seiten, weil du es dann wieder manuell verwalten musst.
---
Audits in großem Maßstab: Ein funktionierender Prozess
Hier ist der tatsächliche Schritt-für-Schritt-Ablauf, den ich bei jedem internationalen Audit durchführe, verfeinert nach über 200 mehrsprachigen Websites:
- Crawle die Website mit Screaming Frog, stelle sicher, dass JavaScript-Rendering aktiviert ist, falls die Website ein JS-Framework nutzt.
- Exportiere die hreflang-Daten in eine Tabellenkalkulation. Gruppiere URLs nach ihrem beabsichtigten Cluster.
- Prüfe jeden Cluster auf: Self-referencing Tag, Return Tags von allen Varianten, gültige BCP-47-Codes, konsistente kanonische Ausrichtung.
- Prüfe x-default-URLs auf 200-Statuscodes. Nicht 301er. 200er.
- Vergleiche gegen deine XML-Sitemaps, falls du die Sitemap-Methode nutzt. Jede URL in der Sitemap sollte 200 zurückgeben.
- Führen Sie 20–30 Seiten durch das Merkle-Testtool aus, um zu überprüfen, dass Google tatsächlich das liest, das Sie für richtig halten.
- Laden Sie den International Targeting Report aus der Search Console herunter und suchen Sie speziell nach „No return tag"-Fehlern. Dies ist fast immer ein Symptom für Templates, die nicht aktualisiert wurden, als eine neue Sprache hinzugefügt wurde.
- Beheben Sie das Problem, führen Sie in 2 Wochen ein erneutes Crawling durch und überprüfen Sie, dass die Fehleranzahl in der Search Console gesunken ist (es kann 4–6 Wochen dauern, bis die GSC-Daten Korrekturen vollständig widerspiegeln).
Dies ist kein einmaliger Prozess. Legen Sie ein regelmäßiges Crawling alle drei Monate in Ihrem Kalender fest. Internationale Websites ändern sich. Neue Seiten werden hinzugefügt, alte Seiten werden umgeleitet, und hreflang-Cluster brechen stillschweigend zusammen, wenn niemand hinschaut.
---
Wann man hreflang nicht verwenden sollte
Das wird in den meisten Guides übersprungen und das macht mich verrückt.
Wenn Sie eine Sprache haben, aber mehrere Regionen (sagen wir, Großbritannien und Australien, beide auf Englisch), lohnt sich hreflang, aber nur wenn der Inhalt unterschiedlich genug ist, um diese Nutzer unterschiedlich zu bedienen. Wenn Ihre UK- und AU-Seiten zu 95 % identisch sind, schaffen Sie möglicherweise mehr Verwirrung als Klarheit. Google kann sich dafür entscheiden, eine Variante universell zu zeigen, und Ihre hreflang-Signale werden weitgehend ignoriert.
Wenn Sie sehr geringen Traffic von internationalen Märkten haben, könnte eine Woche für die Implementierung von hreflang nicht die beste Zeitnutzung sein. Eine gut strukturierte URL-Hierarchie mit <html lang="">-Attributen und Geotargeting-Einstellungen in der Search Console bieten Ihnen ausreichend Schutz, bis das Traffic-Volumen eine vollständige Implementierung rechtfertigt.
Und wenn Ihre Website eine Single-Page App mit dynamisch geladenem Inhalt ist, machen Sie zuerst die Rendering-Seite richtig. Ich habe hreflang perfekt in der statischen HTML-Shell implementiert gesehen, während der tatsächliche Seiteninhalt per JavaScript gerendert wurde und Googlebot nur einen Lade-Spinner sah. Beheben Sie zuerst die Indexierbarkeit, bevor Sie sich Gedanken über Internationalisierungssignale machen.
---
FAQ
Beeinflussen hreflang-Tags die Rankings direkt?
Nein. hreflang-Signale teilen Google mit, welche URL welchem Nutzer angezeigt werden soll, nicht wie diese URL gerankt werden soll. Indirekt kann es sein, dass die richtige Seite vor den richtigen Nutzer kommt, was Pogo-Sticking reduziert und die Engagement-Metriken verbessert, was wiederum nachgelagert Auswirkungen auf Rankings haben kann. Aber es gibt keinen direkten Ranking-Boost durch das Hinzufügen von hreflang-Tags.
Wie lange dauert es, bis Google hreflang-Änderungen verarbeitet?
In der Regel 4–8 Wochen, bis Änderungen vollständig in den Search-Console-Daten sichtbar sind. Die Crawl-Häufigkeit spielt hier eine Rolle. Bei großen Websites mit langsamen Crawl-Raten kann es sich bis zu 12 Wochen erstrecken. Nimm keine Änderungen vor und überprüfe die Ergebnisse am nächsten Tag. Das macht dich verrückt.
Kann ich hreflang in einem Shopify-Store verwenden?
Ja, aber Shopifys native Internationalisierung (über Markets) erledigt einen großen Teil davon für dich, wenn du Subordner oder Subdomains verwendest. Wenn du separate Stores für verschiedene Regionen nutzt, musst du hreflang manuell über eine Theme-Anpassung oder eine App implementieren. Ich habe Shopifys eigene internationale SEO-Anleitung als Ausgangspunkt verwendet. Sie ist relativ umfassend.
Was ist der Unterschied zwischen Sprach-Targeting und Länder-Targeting?
Sprach-Targeting (z. B. hreflang="es") bedeutet: Zeige dies Spanischsprechern an, egal wo sie sich befinden. Länder-Targeting (z. B. hreflang="es-MX") bedeutet: Zeige dies speziell Spanischsprechern in Mexiko an. Verwende nur Sprach-Tags, wenn dein Inhalt für alle Sprecher dieser Sprache gleich ist. Verwende Sprach-Länder-Tags, wenn sich Preisgestaltung, Währung oder wesentliche Inhalte je Region unterscheiden.
Meine hreflang-Fehler sind gestiegen, nachdem ich sie behoben habe. Warum?
Normalerweise deshalb, weil die Behebung einiger Tags Google dazu veranlasst hat, deine Seiten aggressiver zu crawlen, und Google findet jetzt Fehler, die vorher nicht gemeldet wurden. Das ist ein Reporting-Artefakt, kein Zeichen dafür, dass die Fixes die Situation verschlimmert haben. Mach weiter, führe in 4 Wochen einen erneuten Crawl durch.
---
Hreflang ist wirklich eins dieser Dinge, bei dem es zu 90 % richtig zu machen fast genauso schlecht ist wie es zu 0 % richtig zu machen. Die fehlerhaften Signale erzeugen Rauschen, das Google lernt zu misstrauen. Nimm dir die Zeit, es ordnungsgemäß zu tun, prüfe es regelmäßig und behandle es wie die Infrastruktur, die es ist. Dein internationaler organischer Traffic wird dir still danken, und das ist die beste Art von Dank.