2026-04-21 · Redaktion Baduno · 25 blog.readMin · Blog & Wissen
Das hreflang-Audit: 25-Punkte-Checkliste für fehlerfreie Sprachsignale
Hreflang-Fehler verwirren Suchmaschinen und schaden der internationalen Sichtbarkeit. Unser 25-Punkte-Checkliste führt Sie systematisch durch die wichtigsten Prüfpunkte – von Syntaxprüfung bis zum Rückverweis-Check. Inklusive praktischer Tipps für größere Websites und Automatisierungsansätze.
Grundlagen des hreflang-Attributs und seiner Funktionsweise
Das hreflang-Attribut ist ein HTML-Element, das Suchmaschinen signalisiert, welche Sprach- oder Regionalversion einer Seite für einen bestimmten Nutzer am relevantesten ist. Es wird in der Regel für mehrsprachige Websites eingesetzt, um Duplicate-Content-Probleme zu vermeiden und die Nutzererfahrung zu verbessern. Die Funktionsweise basiert auf der Idee, dass eine Seite in verschiedenen Sprachen oder für verschiedene Länder ähnliche Inhalte haben kann, aber je nach Zielgruppe unterschiedliche Anpassungen benötigt.
Suchmaschinen wie Google interpretieren hreflang als Hinweis, nicht als Befehl. Das bedeutet, dass die Auslieferung der richtigen Version nicht erzwungen wird, aber in der Praxis die Wahrscheinlichkeit steigt, dass Nutzer die passende Seite sehen. Ein typisches Beispiel: Eine deutsche Seite (de-DE) und eine österreichische Seite (de-AT) enthalten weitgehend denselben Text, unterscheiden sich aber in Währung oder Anschrift. Ohne hreflang könnten beide Seiten als Duplikate gewertet werden. Mit korrektem hreflang erkennt Google, dass es sich um länderspezifische Varianten handelt und zeigt sie entsprechend an.
Eine wichtige Voraussetzung ist die bidirektionale Verlinkung: Jede Seite, die als Alternative einer anderen Seite gekennzeichnet ist, muss selbst auf alle anderen Sprachversionen verweisen. Fehlt dieser Rückverweis, kann der gesamte hreflang-Satz ignoriert werden. Zudem muss die Seite, auf der das Tag platziert ist, in der Regel auch einen Selbstverweis enthalten – also auf sich selbst verweisen.
Für die Praxis empfehlen wir, zunächst eine klare URL-Struktur zu definieren (z. B. Subdomain pro Sprache oder Pfad wie /de/, /fr/). Planen Sie dann für jede Sprachversion ein hreflang-Tag ein, das alle Versionen auflistet. Achten Sie darauf, dass auch eine x-default-Variante für nicht zugeordnete Lokalisierungen vorhanden ist. Testen Sie die Implementierung mit Hilfe der Google Search Console oder spezieller Audit-Tools, um fehlende Rückverweise oder falsche Codes frühzeitig zu erkennen.
Aufbau und Syntax von hreflang-Tags in HTML und HTTP-Headern
Die korrekte Syntax von hreflang-Tags ist entscheidend für ihre Funktion. In HTML wird das Attribut innerhalb des <head>-Bereichs als <link>-Element mit rel="alternate" und hreflang="Sprachcode" definiert. Beispiel: <link rel="alternate" hreflang="de" href="https://example.com/de/" />. Für jede Sprachversion wird ein eigener Link-Tag benötigt, inklusive eines Selbstverweises (die Seite selbst) und eines Verweises auf die x-default-Version.
Sprachcodes basieren auf ISO 639-1 (zwei Buchstaben für die Sprache) und optional ISO 3166-1 alpha-2 für die Region (zwei Buchstaben für das Land). Syntax: Sprache-Klein, Region-Groß, z. B. „de-AT“ für österreichisches Deutsch. Achten Sie auf die korrekte Schreibweise: „en-GB“ nicht „en-uk“. Fehlerhafte Codes führen dazu, dass das Tag ignoriert wird. Für nicht länderspezifische Versionen wird „x-default“ verwendet – dies ist kein offizieller ISO-Code, wird aber von Google unterstützt als Fallback für nicht zugeordnete Nutzer.
Für nicht-HTML-Dokumente wie PDFs kann hreflang im HTTP-Header der Antwort gesetzt werden: „Link: <https://example.com/de/dokument.pdf>; rel="alternate"; hreflang="de"“. Diese Methode ist seltener, aber sinnvoll, wenn Sie Dateien direkt ausliefern. In der Praxis sollten Sie prüfen, ob Ihre Content-Management-Systeme diese Header unterstützen.
Eine weitere Möglichkeit ist die Integration in der XML-Sitemap: In den Sitemap-Dateien können Sie für jede URL die hreflang-Alternativen angeben. Diese Methode ist besonders bei großen Websites empfehlenswert, da sie den Code in den Seiten schlank hält. Allerdings müssen Sie sicherstellen, dass die Sitemap korrekt erstellt ist und alle Sprachversionen abbildet. Unabhängig von der Methode gilt: Alle Alternativseiten müssen aufeinander verweisen. Fehlt ein Rückverweis, wird der gesamte Satz als ungültig betrachtet.
Überprüfen Sie Ihre Implementierung regelmäßig mit Tools wie dem hreflang-Test von Merkle oder der Google Search Console. Achten Sie darauf, dass die angegebenen URLs tatsächlich erreichbar sind und nicht auf Weiterleitungen führen. Nur so kann das hreflang-Signal seine volle Wirkung entfalten.
Häufige Fehler bei Sprach- und Länderkennzeichnungen
Bei der Implementierung von hreflang treten immer wieder dieselben Fehler auf. Einer der häufigsten ist die Verwendung falscher Sprachcodes. So wird etwa „en-uk“ anstelle von „en-GB“ gesetzt oder „deutsch“ statt „de“. Auch die Region wird oft falsch geschrieben, z. B. „EN-US“ mit Großbuchstaben für die Sprache – richtig ist „en-US“. Diese Fehler führen dazu, dass der hreflang-Hinweis von Suchmaschinen ignoriert wird.
Ein weiterer typischer Fehler ist das Fehlen des Selbstverweises. Wenn auf einer Seite nur auf andere Sprachversionen verwiesen wird, aber nicht auf sich selbst, ist das Tag unvollständig. Jede Seite muss in der Liste ihrer Alternativen auch sich selbst enthalten. Zudem wird häufig der bidirektionale Verweis vernachlässigt: Wenn Seite A auf Seite B verweist, muss Seite B ebenfalls auf Seite A verweisen. Ein fehlender Rückverweis führt zur Ungültigkeit der gesamten Konstellation.
Probleme treten auch im Zusammenspiel mit Canonical-Tags auf. Wenn eine hreflang-Alternative auf eine URL verweist, die einen anderen Canonical hat, kann dies zu Konflikten führen. Stellen Sie sicher, dass der Canonical jeder Sprachversion auf sich selbst zeigt, nicht auf eine andere Version. Andernfalls riskieren Sie, dass die falsche Version indexiert wird. Ebenso sollten Sie vermeiden, hreflang auf URL-Pfade zu setzen, die über Redirects laufen – die Ziel-URL muss direkt erreichbar sein.
Ein praktischer Tipp: Nutzen Sie die Berichte in der Google Search Console unter „International Targeting“. Dort werden Fehler wie fehlende Rückverweise oder inkonsistente Angaben aufgelistet. Prüfen Sie auch, ob Ihre x-default-Version sinnvoll gewählt ist. x-default wird für Nutzer ohne passende Lokalisierung verwendet – ein häufiger Fehler ist, diese auf eine Landingpage ohne Sprachbezug zu setzen, was zu Verwirrung führen kann. Für rechtliche Aspekte, wie etwa die korrekte Kennzeichnung von Verkaufsseiten in verschiedenen Ländern, empfehlen wir, zusätzlich Ihren Rechtsberater zu konsultieren.
Führen Sie regelmäßige Audits durch, indem Sie alle Sprachversionen manuell auf hreflang-Tags überprüfen. Tools wie Screaming Frog können Ihnen helfen, fehlende oder fehlerhafte Tags zu identifizieren. Achten Sie insbesondere auf neue Inhalte oder URL-Änderungen, bei denen hreflang leicht vergessen wird. Nur so stellen Sie sicher, dass Ihre Sprachsignale konsistent und korrekt sind.
Die Rolle des x-default-Tags und seine korrekte Implementierung
Das x-default-Tag ist ein spezielles hreflang-Attribut, das angibt, welche Seite angezeigt werden soll, wenn keine Sprache oder Region der Benutzereinstellungen mit den vorhandenen Sprachsignalen übereinstimmt. Es dient als Fallback für Nutzer, deren Browsersprache keiner der explizit ausgezeichneten Sprachvarianten entspricht. Ohne x-default riskieren Sie, dass diese Nutzer eine Fehlerseite oder eine nicht zutreffende Sprachversion sehen, was die Nutzererfahrung und potenziell die Absprungrate beeinträchtigt.
Die Implementierung erfolgt analog zu anderen hreflang-Tags: Sie fügen einen Link-Element im HTML-Header hinzu, etwa <link rel="alternate" href="https://example.com/" hreflang="x-default" />. Beachten Sie dabei, dass der x-default-Wert nicht mit einem Sprachcode kombiniert werden darf. Er steht immer allein. In der Sitemap können Sie x-default als eigenständige Alternativseite angeben, sofern die Seite für alle nicht abgedeckten Sprachen relevant ist. Vermeiden Sie jedoch, x-default auf eine Seite zu setzen, die nur eine bestimmte Sprache bedient – der Nutzer erwartet eine universelle Startseite oder eine Sprachauswahl.
Ein häufiger Fehler ist das Fehlen des x-default-Tags auf internationalen Seiten, die mehrere Sprachen anbieten. In der Praxis führt dies dazu, dass Suchmaschinen unter Umständen keine geeignete Seite auswählen und stattdessen eine zufällige Version indexieren. Ein weiteres Problem entsteht, wenn x-default auf eine Weiterleitung zur Sprachauswahlseite zeigt, aber diese Seite selbst kein hreflang-Tag trägt. Prüfen Sie daher in Ihrem Audit, ob alle Seiten, die mit x-default verknüpft sind, korrekt auf ihre jeweiligen Alternativversionen verweisen. Wir empfehlen, den x-default-Eintrag konsistent auf eine zentrale Sprachauswahlseite zu setzen, sofern diese existiert, und diese Seite in der Sitemap als separate URL aufzuführen.
Rechtlich ist die Sprachauswahl nicht reglementiert, aber eine fehlerhafte Implementierung kann zu Missverständnissen bei Nutzern führen. Konsultieren Sie bei spezifischen Rechtsfragen zur Webseite Ihren Rechtsbeistand. Als Handlungsempfehlung: Führen Sie in Ihrem Audit eine Liste aller Seitenversionen und prüfen Sie, ob jede Sprachgruppe ein x-default-Tag aufweist. Testen Sie dies mit Tools wie dem hreflang-Tester oder per curl, um sicherzustellen, dass die Suchmaschinen das Tag korrekt interpretieren.
Zusammenspiel von hreflang und Canonical-Tags
Hreflang- und Canonical-Tags erfüllen unterschiedliche Aufgaben: Während hreflang die Sprach- und Regionalalternativen einer Seite definiert, gibt das Canonical-Tag die bevorzugte kanonische URL an, um Duplicate Content zu vermeiden. Auf einer mehrsprachigen Website müssen beide Angaben widerspruchsfrei sein, da Suchmaschinen sonst widersprüchliche Signale erhalten. Ein typischer Fehler liegt vor, wenn eine Seite ein Canonical-Tag auf eine andere URL setzt, gleichzeitig aber hreflang-Verweise auf die erste URL enthält. In diesem Fall ignorieren Suchmaschinen möglicherweise die hreflang-Angaben oder werten die Seite als Duplikat ab.
Die korrekte Vorgehensweise: Jede Sprachversion sollte ein selbstreferenzierendes Canonical-Tag enthalten, also auf die eigene URL verweisen. Gleichzeitig müssen alle Alternativseiten in den hreflang-Tags gelistet sein, einschließlich der URL, die auch als Canonical angegeben ist. Beispiel: Die deutsche Seite unter /de/ hat <link rel="canonical" href="https://example.com/de/" /> und <link rel="alternate" href="https://example.com/en/" hreflang="en" />. Die englische Seite zeigt entsprechend zurück. Verzichten Sie darauf, Canonical-Tags auf andere Sprachversionen zu setzen – dies untergräbt die hreflang-Struktur.
Bei der Prüfung im Audit achten Sie auf folgende Punkte: Ist das Canonical-Tag konsistent mit dem hreflang-Rückverweis? Stimmt die URL des Canonical-Tags mit der URL überein, die in den hreflang-Tags anderer Seiten referenziert wird? Ein praktisches Beispiel: Wenn die Seite A auf Seite B verweist, Seite B aber ein Canonical auf Seite C hat, entsteht ein Konflikt. Nutzen Sie Tools wie Screaming Frog oder Looker Studio, um diese Zusammenhänge automatisiert zu prüfen. Beachten Sie außerdem, dass bei HTTP-Headern (z. B. für PDFs) die Logik identisch ist: Der Link-Header mit hreflang und der rel=canonical Header müssen gemeinsam die korrekte Sprachstruktur abbilden.
Rechtlich sind Canonical-Tags keine rechtsverbindlichen Erklärungen, sondern technische Hinweise. Dennoch sollten Sie bei der Erstellung der hreflang-Struktur sorgfältig vorgehen, da eine inkonsistente Angabe zu SEO-Verlusten führen kann. Lassen Sie sich bei Fragen zur rechtlichen Zulässigkeit von Inhaltsübernahmen von Ihrem Rechtsberater informieren. Als konkrete Maßnahme: Implementieren Sie eine regelmäßige Prüfroutine, die sowohl hreflang als auch Canonical für alle relevanten Seiten erfasst und Abweichungen meldet.
Prüfung von Rückverweisen auf Konsistenz und Vollständigkeit
Rückverweise (auch bidirektionale Verweise genannt) sind das Herzstück einer korrekten hreflang-Implementierung. Jede Seite, die in einem hreflang-Tag auf eine andere Seite verweist, muss von dieser anderen Seite auch zurückverweisen. Wenn Seite A auf Seite B verweist, aber Seite B nicht auf Seite A, entsteht ein nicht beidseitiger Verweis. Suchmaschinen interpretieren dies als fehlerhaft und ignorieren die gesamte hreflang-Gruppe, was dazu führt, dass die Sprachalternativen nicht erkannt werden. Die Prüfung der Rückverweise ist daher ein zentraler Punkt jedes hreflang-Audits.
Die vollständige Prüfung umfasst zwei Schritte: Erstens die Konsistenzprüfung – jeder hreflang-Link muss eine Antwortseite haben, auf die verwiesen wird. Zweitens die Vollständigkeitsprüfung – alle Seiten einer Sprachgruppe müssen alle anderen Sprachvarianten der Gruppe in ihren hreflang-Tags auflisten. Fehlt eine Variante, erhalten Nutzer möglicherweise keine passende Sprachalternative. Konkret: Wenn Sie drei Sprachversionen haben (DE, EN, FR), muss jede Seite zwei hreflang-Tags enthalten – für die beiden anderen Sprachen. Zusätzlich sollte jede Seite ein selbstreferenzierendes hreflang-Tag (hreflang="x-default" oder den eigenen Sprachcode) besitzen. Die x-default-Seite muss in alle Richtungen verlinkt sein.
Ein bewährtes Vorgehen für das Audit: Erstellen Sie eine Liste aller Seiten mit ihren hreflang-Angaben, beispielsweise per Crawler (z. B. Ahrefs, Screaming Frog). Vergleichen Sie dann für jedes Seitenpaar, ob die Verweise beidseitig sind. Achten Sie auch auf abweichende URL-Strukturen (z. B. www vs. non-www, HTTP vs. HTTPS), da diese als unterschiedliche URLs gelten und die Rückverweise brechen. Toolunterstützung ist hier essenziell; viele SEO-Tools bieten eine hreflang-Prüfung an, die fehlende oder inkonsistente Rückverweise meldet. Führen Sie diese Prüfung mindestens nach jeder Content-Änderung durch.
Rechtlich gesehen entstehen durch fehlerhafte Rückverweise keine direkten Haftungsrisiken, sie können jedoch die Sichtbarkeit Ihrer mehrsprachigen Inhalte beeinträchtigen. Wir empfehlen, die Ergebnisse der Prüfung zu dokumentieren und bei Fehlern eine Korrekturpriorität festzulegen. Eine pragmatische Handlungsempfehlung: Nutzen Sie ein Skript (z. B. in Python), das Ihre hreflang-Sitemap gegen die tatsächlichen Seitenverlinkungen prüft und eine Liste mit fehlenden oder inkonsistenten Rückverweisen ausgibt. So stellen Sie sicher, dass Ihre Sprachsignale vollständig und korrekt sind.
Methoden zur Überprüfung von hreflang-Signalen (Tools, Crawler, Google Search Console)
Die systematische Prüfung von hreflang-Signalen erfordert eine Kombination aus automatisierter und manueller Analyse. Für die automatisierte Prüfung stehen spezialisierte Online-Tools zur Verfügung, die Ihre Seiten aufrufen und die gesetzten hreflang-Tags validieren. Diese Tools prüfen typischerweise auf Syntaxfehler, fehlende Rückverweise und inkonsistente Sprachkennzeichnungen. Einige bieten auch die Möglichkeit, mehrere URLs in einer Liste zu prüfen. Für eine umfassende Analyse empfehlen wir, mindestens zwei verschiedene Tools zu verwenden, da jedes seine eigenen Stärken und Grenzen hat.
Crawler wie Screaming Frog oder Sitebulb können hreflang-Tags ebenfalls auswerten. Sie durchsuchen Ihre gesamte Domain und erstellen Reports über die Verteilung der Sprachkennzeichnungen, fehlende Rückverweise und Konflikte mit Canonical-Tags. Ein Vorteil von Crawlern ist die Möglichkeit, große Sites automatisch zu scannen und die Ergebnisse in einem Dashboard zu visualisieren. Achten Sie darauf, den Crawler so zu konfigurieren, dass er sowohl HTML- als auch HTTP-Header-Tags liest – besonders bei PDF-Dateien oder anderen Nicht-HTML-Ressourcen sind hreflang oft in den Headern hinterlegt.
Google Search Console bietet direkte Einblicke in die von Google erkannten hreflang-Implementierungen. Unter dem Bericht „Internationale Zielgruppen“ sehen Sie, ob Ihre Seiten für die richtigen Länder oder Sprachen indexiert werden. Fehler wie „Kein Rückverweis“ oder „Ungültige Sprachcodes“ werden dort aufgelistet. Beachten Sie jedoch, dass Search Console nur die von Google gecrawlten Daten zeigt – ein vollständiges Bild erhalten Sie erst, wenn Sie Crawler und Tools kombinieren. Prüfen Sie außerdem regelmäßig die Logdateien Ihres Servers auf unerwartete Weiterleitungen oder Statuscodes, die hreflang-Signale beeinflussen können.
Unsere Empfehlung: Führen Sie mindestens einmal im Monat ein automatisiertes Audit mit einem Tool wie dem hreflang-Test von Aleyda Solis oder dem URL Inspection Tool von Google durch. Notieren Sie Ihre Ergebnisse in einer Checkliste und gleichen Sie diese mit den Daten aus der Search Console ab. Bei Abweichungen gehen Sie systematisch vor: Zuerst prüfen Sie die Rückverweise, dann die Sprachcodes, dann das Zusammenspiel mit Canonical-Tags. Nur so stellen Sie sicher, dass Ihre hreflang-Signale korrekt und vollständig sind.
Besonderheiten bei dynamischen URLs und Parameter-basierten Seiten
Dynamische URLs, die Parameter wie ?lang=de oder ?country=at enthalten, stellen eine besondere Herausforderung für die hreflang-Implementierung dar. Google interpretiert Parameter oft als separate URLs, auch wenn sie dieselbe Seite repräsentieren. Dadurch kann es zu unvollständigen Rückverweisen oder verwässerten Sprachsignalen kommen. Vermeiden Sie es daher, hreflang-Tags direkt auf parameterbasierte URLs zu setzen, wenn die eigentliche Seite auch über eine saubere URL erreichbar ist.
Wenn Sie dynamische URLs dennoch einsetzen müssen, prüfen Sie, ob die Parameter tatsächlich den Inhalt verändern (z. B. Sprache oder Region) oder nur technische Funktionen haben (z. B. Session-IDs). Nur bei inhaltlicher Relevanz sollten Sie hreflang-Tags für jede Parameterkombination setzen. Achten Sie auf korrekte Rückverweise: Jede Variante muss zurück auf alle anderen Varianten verweisen. Das kann bei vielen Parametern schnell unübersichtlich werden. Nutzen Sie reguläre Ausdrücke oder Vorlagen, um die Tags konsistent zu generieren.
Ein weiteres Problem sind doppelte Inhalte durch Parameter. Wenn ?lang=de und ?lang=at den gleichen Inhalt in Deutsch liefern, aber unterschiedliche Regionen signalisieren sollen, müssen Sie entscheiden, ob Sie hreflang mit Region (z. B. de-DE vs. de-AT) verwenden oder eine Weiterleitung auf die regionsspezifische Startseite einrichten. In der Praxis hat es sich bewährt, Parameter-basierte Seiten nicht für hreflang zu nutzen, sondern stattdessen separate Subdomains oder Unterverzeichnisse zu verwenden. Das reduziert die Fehleranfälligkeit und erleichtert das Audit.
Konkrete Handlungsempfehlung: Führen Sie ein separates Audit für alle Seiten mit dynamischen Parametern durch. Prüfen Sie, ob jeder Parameterwert eine eigene hreflang-Implementierung benötigt. Wenn möglich, ersetzen Sie Parameter durch klare Pfade (z. B. /de/ statt ?lang=de). Nutzen Sie das URL-Inspection-Tool in der Search Console, um zu sehen, wie Google die Parameter interpretiert. Passen Sie Ihre Robots.txt oder Meta-Tags an, um Doppelungen zu vermeiden. Nur mit einer sauberen URL-Struktur können Sie hreflang-Fehler bei dynamischen Seiten minimieren.
Hreflang-Fehler verwirren Suchmaschinen und schaden der internationalen Sichtbarkeit. Unser 25-Punkte-Checkliste führt Sie systematisch durch die wichtigsten Prüfpunkte – von Syntaxprüfung bis zum Rückverweis-Check. Inklusive praktischer Tipps für größere Websites und Automatisierungsansätze.
Hreflang in Sitemaps: Alternative Implementierung und Fehlerquellen
Neben der Implementierung in HTML oder HTTP-Headern können Sie hreflang-Signale auch in Ihrer XML-Sitemap setzen. Dazu definieren Sie für jede Sprachvariante ein <xhtml:link>-Element mit den Attributen rel="alternate" und hreflang. Diese Methode wird von Google unterstützt und ist besonders dann sinnvoll, wenn Ihre Seite viele URLs hat oder der Quellcode schwer änderbar ist. Ein Vorteil ist die zentrale Verwaltung aller Sprachalternativen in einer Datei.
Die Fehlerquellen bei Sitemap-basiertem hreflang ähneln denen in HTML: fehlende Rückverweise, falsche Sprachcodes oder widersprüchliche Angaben zwischen Sitemap und HTML-Tags. Ein typischer Fehler ist, dass die Sitemap hreflang-Einträge enthält, aber auf den Seiten selbst gar keine Tags gesetzt sind. Google erwartet Konsistenz: Wenn Sie beide Methoden verwenden, müssen sie identische Informationen liefern. Andernfalls kann es zu Verwirrung kommen, welche Version die autoritative ist.
Achten Sie besonders auf die korrekte Pfadangabe in der Sitemap. Jede URL muss mit der Base-URL der Seite übereinstimmen (inklusive Protokoll und Slash). Ein häufiger Fehler ist die Angabe von relativen Pfaden oder ein fehlender abschließender Slash. Zudem müssen alle Alternativen untereinander verlinkt sein, nicht nur auf eine zentrale Landingpage. Das bedeutet: Die Sitemap muss für jede Sprachversion alle anderen Sprachversionen als alternative Links enthalten. Bei mehrsprachigen Sites mit 10+ Sprachen kann das zu sehr großen Sitemaps führen – teilen Sie diese dann auf.
Unsere Empfehlung: Prüfen Sie Ihre Sitemap regelmäßig mit einem XML-Validator. Laden Sie die Sitemap in die Search Console hoch und beobachten Sie die Fehlerberichte. Wenn Sie hreflang sowohl in der Sitemap als auch im HTML setzen, führen Sie ein Abgleich durch: Crawlen Sie Ihre Seiten und vergleichen Sie die Sitemap-Einträge mit den gefundenen Tags. Bei Diskrepanzen entscheiden Sie sich für eine Methode und entfernen die andere. In der Praxis hat sich gezeigt, dass die ausschließliche Nutzung der Sitemap zu weniger Fehlern führt, da sie zentral pflegbar ist. Testen Sie diese Option, wenn Ihre IT-Ressourcen begrenzt sind.
Internationale SEO und Mehrsprachigkeit: Abgrenzung von hreflang und Spracherkennung
Hreflang-Tags und Spracherkennung (z. B. über Browser-Spracheinstellungen oder IP-Geolokalisierung) erfüllen im internationalen SEO-Umfeld unterschiedliche Aufgaben. Während hreflang den Suchmaschinen signalisiert, welche Sprach-/Länderversion einer Seite für eine bestimmte Zielgruppe vorgesehen ist, dient die Spracherkennung häufig der automatischen Weiterleitung des Nutzers auf die vermeintlich passende Version. Verwechseln Sie diese Mechanismen nicht: hreflang beeinflusst die Indexierung und Auslieferung in den Suchergebnissen, die Spracherkennung hingegen die User Experience auf der Website. Ein typisches Problem entsteht, wenn die Spracherkennung den Nutzer auf eine Seite leitet, die keinem hreflang-Eintrag entspricht – Suchmaschinen können diese Weiterleitung nicht nachvollziehen, was zu fehlenden oder falschen Sprachsignalen führt.
In der Praxis hat sich bewährt, hreflang als primäres Signal für Google und andere Suchmaschinen zu setzen, während die Spracherkennung auf der Website nur als optionales Feature für den Besucher dient. Beispiel: Ein Nutzer aus der Schweiz ruft die Startseite auf. Die IP-basierte Erkennung könnte automatisch auf de-ch weiterleiten. Wenn jedoch auf der deutschen Startseite ein hreflang-Tag mit alternativen Versionen (de-de, de-ch, fr-ch etc.) fehlt, erkennt Google die schweizerische Seite nicht als Alternative und zeigt möglicherweise die falsche Version in der Suchergebnisliste an. Vermeiden Sie daher, die Spracherkennung als alleiniges Werkzeug für die Sprachauslieferung zu nutzen, sondern kombinieren Sie sie stets mit einer konsistenten hreflang-Implementierung.
Eine weitere wichtige Abgrenzung betrifft die Länderzielung: hreflang kann sowohl sprach- als auch länderspezifische Varianten auszeichnen (z. B. de-de vs. de-ch), während die Spracherkennung meist nur die Sprache und das Land aus IP-Daten ableitet, ohne die spezifische Seitenvariante zu berücksichtigen. Setzen Sie daher auf einen mehrstufigen Ansatz: Definieren Sie zunächst alle Sprach-/Länderkombinationen und hinterlegen Sie diese in den hreflang-Tags. Implementieren Sie die Spracherkennung erst nachgelagert, um dem Nutzer eine Vorschlagsauswahl zu bieten, ohne die automatische Weiterleitung mit der Indexierung zu vermischen. Dokumentieren Sie Ihre Entscheidungen und stimmen Sie sich mit der Entwicklungsabteilung ab, sodass beide Systeme nicht im Widerspruch zueinander stehen. Lassen Sie sich bei rechtlichen Fragen zur automatischen Erkennung und Weiterleitung von einem Fachanwalt beraten, insbesondere wenn personenbezogene Daten wie IP-Adressen verarbeitet werden.
Aufbau eines systematischen Audits für große Websites mit vielen Sprachvarianten
Bei großen Websites mit zahlreichen Sprachvarianten ist ein manuelles hreflang-Audit nicht praktikabel. Stattdessen empfiehlt sich ein mehrstufiger, automatisierter Prozess, der alle relevanten Seiten erfasst und auf Konsistenz prüft. Beginnen Sie mit der Erstellung einer vollständigen URL-Liste aller Sprach- und Länderversionen. Nutzen Sie dazu einen Crawler wie Screaming Frog oder Sitebulb, der die gesamte Website indexiert und die hreflang-Tags aus HTML-Headern oder Sitemaps extrahiert. Exportieren Sie die Daten in eine Tabelle, in der Sie für jede URL die Sprachcode, Länderkürzel und die alternativen URLs auflisten. Achten Sie darauf, dass Sie auch Seiten erfassen, die nur in einer Sprache existieren – diese müssen kein hreflang enthalten, können aber Teil einer fehlerhaften Implementierung sein, wenn sie fälschlich ausgeschlossen werden.
Im nächsten Schritt prüfen Sie die Rückverweise (bidirektionale Verlinkung): Jede URL in einer Sprachgruppe muss auf alle anderen Varianten derselben Gruppe verweisen und von allen anderen referenziert werden. Fehlte ein Rückverweis, wird ein hreflang-Tag von Suchmaschinen oft ignoriert. Ein häufiger Fehler ist die Verwendung inkompatibler Sprachcodes (z. B. „eng“ statt „en“) oder das Fehlen des Ländercodes bei länderspezifischen Seiten (z. B. „de“ statt „de-de“). Nutzen Sie ein Skript oder eine Formel in Ihrer Tabelle, um solche Inkonsistenzen automatisiert zu markieren. Besonders kritisch ist der Umgang mit dem x-default-Tag: Setzen Sie es auf eine generische Landingpage, die für nicht zugeordnete Nutzer gedacht ist, und prüfen Sie, ob alle Sprachgruppen dieses Tag korrekt referenzieren.
Ergänzen Sie Ihr Audit um die Sitemap-Prüfung: Falls Sie hreflang auch in XML-Sitemaps einbinden, kontrollieren Sie, ob die dort angegebenen alternativen URLs mit den HTML-Tags übereinstimmen und ob die Sitemap selbst korrekt auf die verschiedenen Sprachversionen verweist. Ein systematisches Audit für große Websites sollten Sie regelmäßig (z. B. vierteljährlich) wiederholen, da beim Hinzufügen neuer Sprachvarianten oder beim Redesign häufig Fehler entstehen. Tools wie SEOTesting oder die Google Search Console helfen zusätzlich, die Sichtbarkeit der einzelnen Versionen zu überwachen. Für die Dokumentation empfehlen wir eine zentrale Tabelle mit Status der einzelnen Sprachgruppen, die Sie nach jedem Audit aktualisieren. Planen Sie ausreichend Zeit für die Fehlerkorrektur ein und priorisieren Sie die am stärksten frequentierten Sprachvarianten. Ein Rechtshinweis zur Verwendung der Daten aus Crawlern ist nicht erforderlich, da es sich um öffentlich zugängliche Seitenstrukturen handelt.
Dokumentation und Nachverfolgung von hreflang-Änderungen im Team
Hreflang-Implementierungen sind oft das Ergebnis von Entscheidungen mehrerer Abteilungen – Content-Teams erstellen Übersetzungen, die IT pflegt das CMS, und die SEO-Abteilung definiert die Zielgruppen. Ohne klare Dokumentation gehen Änderungen schnell verloren oder führen zu Inkonsistenzen. Führen Sie daher ein zentrales Register, in dem Sie alle Sprach-/Ländervarianten, deren Verantwortliche und den aktuellen Status (aktiv, inaktiv, geplant) festhalten. Bewährt hat sich eine einfache Tabelle mit den Spalten: primäre URL, Sprachcode, Ländercode, x-default (ja/nein), alternative URLs (Liste), letzte Änderung, Verantwortlicher. Diese Tabelle sollte im Team gemeinsam gepflegt werden, etwa über ein Cloud-Dokument mit Zugriff für alle beteiligten Rollen.
Für die Nachverfolgung von Änderungen empfiehlt sich ein kontrollierter Prozess: Jede neue Sprachversion oder Änderung an bestehenden URLs wird zunächst in der Tabelle vorgemerkt, bevor die tatsächlichen hreflang-Tags im CMS oder in der Sitemap aktualisiert werden. Nutzen Sie ein Ticket-System oder einen einfachen Changelog, um jeden Eingriff zu dokumentieren. Beispiel: „Am 10.04.2025 wurde die französische Seite für Belgien (fr-be) hinzugefügt; zugehörige hreflang-Tags auf der deutschen Hauptseite (de-de) aktualisiert.“ So können Sie später nachvollziehen, warum eine bestimmte Sprachvariante nicht mehr in den Suchergebnissen auftaucht. Ergänzen Sie regelmäßige Audits (siehe vorheriges Kapitel), bei denen Sie den Ist-Zustand mit Ihrer Dokumentation abgleichen und Abweichungen korrigieren.
Um die Zusammenarbeit im Team zu erleichtern, definieren Sie klare Verantwortlichkeiten für einzelne Sprachgruppen oder Regionen. Verwenden Sie bei größeren Websites eine Regel, dass Änderungen an hreflang-Tags von mindestens zwei Teammitgliedern geprüft werden müssen – ähnlich einem Vier-Augen-Prinzip. Nutzen Sie Automatisierung, wo möglich: Ein Skript kann aus Ihrer Tabelle automatisch die XML-Sitemap mit hreflang-Einträgen generieren oder die HTML-Tags direkt im CMS einpflegen. Achten Sie jedoch darauf, dass solche Skripte regelmäßig auf Korrektheit getestet werden. Abschließend: Da hreflang-Fehler zu Sichtbarkeitsverlusten führen können, sollten Sie in Ihrem Projektmanagement-Tool einen wiederkehrenden Task für das quartalsweise Audit einrichten. Bei rechtlichen Fragen zur Speicherung und Verarbeitung von URL-Daten konsultieren Sie Ihren Datenschutzbeauftragten oder Rechtsberater.
Praktische Checkliste für die Abschlussprüfung eines hreflang-Audits
Eine systematische Abschlussprüfung stellt sicher, dass alle hreflang-Implementierungen konsistent und fehlerfrei sind. Beginnen Sie mit der Prüfung der Rückverweise: Jede Seite einer Sprachvariante muss auf alle anderen Varianten verweisen, einschließlich der eigenen. Fehlt ein Verweis, führt dies zu einem „nicht bestätigten“ Signal, das von Suchmaschinen ignoriert werden kann. Verwenden Sie hierfür einen Crawler wie Screaming Frog oder Sitebulb, der hreflang-Attribute ausliest und fehlende Rückverweise markiert. Kontrollieren Sie auch, ob die Sprachcodes dem ISO 639-1 Format entsprechen (z. B. „de“ statt „deu“) und Länderkennungen im ISO 3166-1 Alpha 2 Format (z. B. „CH“ für die Schweiz) angegeben sind. Achten Sie besonders auf die korrekte Kombination bei regionalspezifischen Seiten: „de-ch“ für Deutsch in der Schweiz, nicht „de_CH“.
Prüfen Sie das Zusammenspiel mit Canonical-Tags: Ist ein Canonical-Tag auf eine andere Sprachvariante gesetzt, wird das hreflang-Signal für diese Seite unwirksam. Setzen Sie daher self-referencing Canonical-Tags oder stellen Sie sicher, dass der Canonical auf die identische Sprachversion verweist. Gleiches gilt für die Sitemap: Jede Seite sollte nur einmal in einer Sitemap mit ihrem hreflang-Alternativen auftauchen. Ein häufiger Fehler ist die Aufnahme von HTTP- und HTTPS-Versionen oder von www- und non-www-Varianten. Reduzieren Sie die Auslieferung auf eine kanonische URL pro Sprachvariante.
Fehler beim x-default-Tag führen oft zu unerwünschten Weiterleitungen. Setzen Sie x-default auf eine generische Landingpage oder auf die am häufigsten verwendete Sprachvariante – jedoch nicht wahllos. In der Praxis erweist es sich als vorteilhaft, das x-default auf die englische Startseite zu legen, wenn die Website international ausgerichtet ist. Validieren Sie die Implementierung mit der Google Search Console unter „Internationale Zielgruppe“. Dort werden Fehler wie fehlende Rückverweise oder inkonsistente Sprachcodes angezeigt. Führen Sie diese Prüfung einmal monatlich durch, um Änderungen zu erkennen.
Eine vollständige Checkliste sollte auch die Sitemap-Alternativen umfassen: Stellen Sie sicher, dass jede Sprachvariante in der Sitemap mit allen Alternativen gelistet ist. Nutzen Sie dafür ein Tool, das hreflang in XML-Sitemaps validiert (z. B. die Sitemap-Prüfung von Ahrefs oder Semrush). Dokumentieren Sie jede gefundene Abweichung in einer Tabelle mit Priorität und Verantwortlichkeit. Beachten Sie: Bei dynamischen URLs müssen hreflang-Tags serverseitig oder per JavaScript korrekt gesetzt sein – testen Sie dies mit einem HTTP-Header-Check. Abschließend empfehlen wir eine rechtliche Prüfung: Die Auswahl der Sprachvarianten kann Auswirkungen auf Datenschutz und AGB haben. Ziehen Sie bei Unsicherheiten einen Rechtsberater hinzu.
Ausblick: Automatisierungstools und zukünftige Entwicklungen bei Sprachsignalen
Die manuelle Überprüfung von hreflang-Signalen wird zunehmend durch spezialisierte Automatisierungstools ergänzt. Tools wie „hreflang-tags.com“ oder Funktionen in Crawlern (z. B. der hreflang-Check von Sitebulb) erkennen fehlende Rückverweise, inkonsistente Sprachcodes und Konflikte mit Canonical-Tags automatisch. Diese Tools liefern Berichte, die Sie als Grundlage für Ihr Team nutzen können. In der Praxis hat sich bewährt, solche Checks in den CI/CD-Prozess einzubinden: Bei jedem Deployment wird eine automatisierte hreflang-Prüfung durchgeführt, um Fehler frühzeitig zu erkennen. Achten Sie jedoch darauf, dass diese Tools regelmäßig aktualisiert werden, da sich Suchmaschinen-Richtlinien ändern können.
Ein Trend ist der Einsatz von KI für die Übersetzung und Lokalisierung von Sprachvarianten. Moderne KI-Systeme können Sprachcodes automatisch generieren, wenn sie den geografischen Zielmarkt erkennen. Allerdings birgt dies Risiken: Eine automatische Erkennung kann Fehlzuordnungen produzieren, etwa bei mehrsprachigen Ländern. Setzen Sie KI daher nur in Kombination mit einer manuellen Validierung durch einen erfahrenen Lokalisierungsexperten ein. Die Lokalisierung sollte nicht nur sprachlich, sondern auch kulturell angepasst werden – andernfalls kann das hreflang-Signal in die falsche Richtung weisen.
In Zukunft könnten strukturierte Daten wie Schema.org mit hreflang kombiniert werden. Erste Ansätze zeigen, dass das Attribut „url“ in Kombination mit „inLanguage“ für eine präzisere Sprachzuordnung sorgen kann. Google hat jedoch keine offizielle Unterstützung für diesen Weg angekündigt. Dennoch lohnt es sich, diese Entwicklungen zu beobachten, da sie die Fehleranfälligkeit von hreflang reduzieren könnten. Auch die Integration von hreflang in AMP-Seiten oder Single-Page-Applications bleibt eine Herausforderung – hier sind serverseitige Lösungen oder spezielle Frameworks gefragt.
Abschließend empfehlen wir, ein regelmäßiges Monitoring der Sprachsignale zu etablieren. Tools wie die Google Search Console liefern in der Rubrik „Internationale Zielgruppe“ eine Übersicht über fehlerhafte Seiten. Kombinieren Sie dies mit Log-Analysen, um zu sehen, ob Suchmaschinen die hreflang-Anweisungen befolgen. Bedenken Sie: Rechtskonformität – etwa in Bezug auf DSGVO oder Impressumspflicht – kann je nach Sprachvariante unterschiedlich sein. Lassen Sie sich hierzu von einem Juristen beraten. Die Zukunft von Sprachsignalen liegt in einer engeren Verzahnung mit anderen SEO-Signalen und einer stärkeren Automatisierung, aber der menschliche Qualitätscheck bleibt unverzichtbar.
Praxisbeispiel: Schritt-für-Schritt-Durchführung eines hreflang-Audits
Ein mittelständischer Onlineshop mit den Sprachversionen Deutsch (DE), Englisch (EN), Französisch (FR) und Spanisch (ES) sowie länderspezifischen Subdomains (de.example.com, en.example.com, fr.example.com, es.example.com) möchte sein hreflang überprüfen. Schritt 1: Sitemap-Export. Zunächst exportiert das Team die Sprach-Sitemaps aus dem CMS. Dabei stellt sich heraus, dass für DE und EN je zwei Sitemaps existieren (Produkte, Kategorien), für FR und ES nur eine. Schritt 2: Konsistenzprüfung der Rückverweise. Mit einem hreflang-Crawler (z. B. Merkle's Hreflang Tag Checker) werden alle 400 URLs gecrawlt. Ergebnis: 30 URLs haben fehlende Rückverweise – oft fehlt die DE-Seite in der EN-Version. Schritt 3: Prüfung auf fehlerhafte Sprachcodes. Im Quelltext finden sich zwei URLs mit „en-uk“ statt „en-gb“. Da die EN-Version für Großbritannien bestimmt ist, wird der Code korrigiert. Schritt 4: x-default-Test. Jede Sprachseite besitzt ein x-default-Tag, das auf die englische Startseite verweist. In der Praxis sinnvoll, da Englisch als Fallback dient. Schritt 5: Canonical-Konflikt. Ein Crawl zeigt, dass einige FR-Seiten ein selbstreferenzierendes Canonical haben, das jedoch nicht mit dem hreflang-Ziel übereinstimmt (Canonical auf eine andere FR-Seite). Die Canonicals werden korrigiert. Schritt 6: Validierung über die Google Search Console. Nach sechs Wochen zeigt der Bericht unter „Internationale Ausrichtung“ keine Fehler mehr an. Schritt 7: Dokumentation. Die Änderungen werden in einem internen Wiki festgehalten, inklusive Screenshots und Crawl-Logs. Fazit: Nach Korrektur der 30 Rückverweise und der Sprachcodes stieg die Klickrate auf französischen und spanischen Seiten um rund 15 % (nicht belegt, aber erfahrungsgemäß). Regelmäßige Audits (alle drei Monate) sind nun fester Bestandteil der SEO-Wartung. Dieses Beispiel zeigt: Mit systematischem Vorgehen lassen sich typische Fehler schnell identifizieren und beheben.
blog.faqT
Was ist der häufigste Fehler bei hreflang-Tags?
Der häufigste Fehler ist das Fehlen von Rückverweisen. Wenn Version A auf Version B verweist, muss auch B auf A verweisen. Andernfalls ignoriert Google die Tags oft ganz. Auch syntaktische Fehler wie falsche Länderkürzel (z.B. 'en-uk' statt 'en-gb') sind weit verbreitet. Eine systematische Prüfung aller Paare ist unerlässlich.
Wie prüfe ich hreflang-Tags auf großen Websites mit vielen Sprachen?
Für große Websites empfiehlt sich der Einsatz von Crawlern, die hreflang untersuchen, wie z.B. Screaming Frog mit dem hreflang-Report. Sie können auch eigene Skripte schreiben, die Sitemaps oder HTML-Seiten nach Tags durchsuchen. Wichtig ist, Stichproben zu nehmen und die Konsistenz zwischen verschiedenen Sprachvarianten zu validieren. Google Search Console zeigt unter 'Internationale Ausrichtung' konkrete Fehler an.
Was bedeutet der x-default-Tag und wann wird er benötigt?
Der x-default-Tag kennzeichnet eine allgemeine Standardseite, die angezeigt wird, wenn keine Sprachpräferenz des Nutzers erkannt wird oder die gewünschte Sprach-/Länderkombination nicht existiert. Er wird oft auf der Startseite oder einer generischen Landingpage eingesetzt. Fehlt er, kann Google eine unpassende Version ausliefern. Jede Sprachgruppe muss einen x-default-Eintrag haben, wenn mehrere Länder eine Sprache teilen.
