Warum stehen Sprachversionen bei der Hreflang-Optimierung miteinander in Konflikt?

„Konflikte zwischen Sprachversionen“ in hreflang-Auszeichnungen bedeuten in der Regel nicht, dass der Code von Suchmaschinen nicht gelesen werden kann. Vielmehr senden Seiten derselben Gruppe gleichzeitig widersprüchliche Signale zu Sprache, Region, Kanonisierung und Indexierbarkeit. Dadurch fällt es Suchmaschinen schwer zu bestimmen, welche URL für eine bestimmte Sprache oder einen bestimmten Markt bereitgestellt werden soll. Möglicherweise wird die falsche Version in das Ranking einbezogen oder ein Teil der hreflang-Beziehungen wird direkt ignoriert.

Bei der technischen Prüfung reicht es nicht aus, lediglich zu prüfen, ob auf der Seite rel="alternate" vorhanden ist. Ob die hreflang-Optimierung tatsächlich funktioniert, hängt davon ab, ob URL-Erreichbarkeit, wechselseitige Beziehungen, Sprach- und Regionsausrichtung, canonical-Verweise und der tatsächliche Seiteninhalt eine einheitliche Logik bilden.

Das Wesen des Konflikts: Mehrere URLs konkurrieren um dieselbe Nutzeransprache

Ein gültiges hreflang-Set sollte jeder klar definierten Sprach- oder Sprach-Region-Kombination eine eindeutige indexierbare URL zuweisen. Zum Beispiel:

• en: allgemeine englische Seite für englischsprachige Nutzer;
• en-US: englische Seite für den US-Markt;
• en-GB: englische Seite für den britischen Markt;
• zh-CN: vereinfachte chinesische Seite für Nutzer auf dem chinesischen Festland;
• x-default: Standardversion oder Sprachauswahlseite für Fälle ohne passende Zuordnung.

Ein Konflikt entsteht, wenn zwei oder mehr URLs für dieselbe Zielgruppe ausgezeichnet werden, ohne dass eine klare Prioritätsbeziehung besteht. Beispielsweise sind /en/ und /us/ beide als en-US gekennzeichnet; oder dieselbe englische Seite wird gleichzeitig als einzige Alternativseite für en, en-US und en-GB deklariert. Suchmaschinen leiten die Priorität nicht aus internen Verzeichnisnamen eines Unternehmens ab, sondern bewerten, ob Seitendeklarationen, Inhalte, canonical und Crawling-Status konsistent sind.

Daher entsprechen /us/, /uk/ oder länderspezifische Top-Level-Domains im Verzeichnispfad nicht automatisch einer korrekten Regionsausrichtung. Pfade können die Bereitstellungsstrategie ausdrücken, ersetzen jedoch keine gültigen hreflang-Sprachcodes.

Die häufigsten Konflikte entstehen durch Inkonsistenzen bei vier Arten von Signalen

Eine Seite verweist auf mehrere unterschiedliche kanonische Seiten

hreflang und canonical haben unterschiedliche Aufgaben. hreflang dient dazu, gleichwertige Versionen für Nutzer unterschiedlicher Sprachen oder Regionen zu identifizieren; canonical dient dazu, bei stark ähnlichen Inhalten die bevorzugte URL festzulegen. Beide sollten einander nicht ersetzen.

Ein typischer Fehler ist: Die US-englische Seite /en-us/product-a/ wird in hreflang als en-US deklariert, ihr canonical verweist jedoch auf die allgemeine englische Seite /en/product-a/. Dadurch erhält die Suchmaschine zwei widersprüchliche Informationen: Eine besagt, dass diese Seite eine eigenständige US-Version ist, die andere, dass sie lediglich ein Duplikat einer anderen URL ist. Hat die Seite tatsächlich einen eigenständigen Marktwert, sollte canonical in der Regel auf sich selbst verweisen; verfügt sie dagegen weder über eigenständige Inhalte noch über eine eigenständige Servicebedeutung, sollte sie nicht mithilfe von hreflang als Regionsversion dargestellt werden.

Besondere Aufmerksamkeit erfordern parameterisierte URLs, URLs mit unterschiedlicher Groß- und Kleinschreibung, Versionen mit abschließendem Schrägstrich, HTTP/HTTPS-Versionen sowie Werbe-Landingpages mit Tracking-Parametern. Verweist hreflang nicht auf die endgültige kanonische URL, wird die Sprachbeziehung auf einer instabilen Adresse aufgebaut.

Rückverweise fehlen, das Sprach-Set ist unvollständig

hreflang-Beziehungen müssen einen überprüfbaren geschlossenen Kreislauf bilden. Wenn Seite A Seite B als ihre französische Version deklariert, sollte Seite B auch Seite A als entsprechende chinesische, englische oder andere Version deklarieren und einen Selbstverweis enthalten. Führt die englische Seite zehn Sprachversionen auf, während die französische Seite nur sich selbst und die englische Seite aufführt, nicht jedoch die übrigen Versionen, können Suchmaschinen diese Seiten nicht zuverlässig als ein vollständiges gemeinsames Set erkennen.

Solche Probleme treten häufig bei schrittweiser Einführung von Templates, nicht synchronisierten CMS-Multisite-Konfigurationen oder nachträglich ergänzten Übersetzungsseiten auf. Bei einer großen Anzahl von Seiten ist eine bloße Stichprobenprüfung des Quellcodes nicht zuverlässig; stattdessen sollten Prüfungen anhand von Seitentemplates, Sprachverzeichnissen und URL-Zuordnungsregeln in großen Mengen erfolgen.

Der Sprachcode ist gültig, aber die geschäftliche Ausrichtung überschneidet sich

Ein korrekter Sprachcode bedeutet nicht automatisch, dass die Ausrichtung sinnvoll ist. en steht für allgemeines Englisch, en-US für US-Englisch; pt für allgemeines Portugiesisch, pt-BR für brasilianisches Portugiesisch. Eine allgemeine Sprachseite kann neben einer Regionsseite bestehen, sofern die Rollen der Seiten klar definiert sind.

Behält eine Website beispielsweise gleichzeitig en, en-US und en-GB bei, während Preise, Einheiten, Kontaktdaten, Liefergebiete, Schreibweisen und Inhalte auf allen drei Seiten vollständig identisch sind, ist eine Auszeichnung zwar technisch möglich, geschäftlich fehlt jedoch die Grundlage für eine Unterscheidung. Das Problem liegt dann nicht nur bei hreflang, sondern auch darin, dass die Website künstlich mehrere URLs erzeugt, die um ähnliche Suchanfragen konkurrieren.

Umgekehrt werden Regionsseiten ebenso unwirksam, wenn sie falsche Codes verwenden. Der Sprachteil von hreflang sollte ISO-639-1-Sprachcodes verwenden, der Regionsteil ISO-3166-1-Alpha-2-Länder- oder Regionscodes. Das Format lautet Sprache zuerst, Region danach, beispielsweise de-DE und ja-JP. Nicht vorhandene Codes, ausgeschriebene Sprachnamen anstelle von Codes oder vorangestellte Ländercodes führen zu Analyseproblemen.

Die Seite selbst ist nicht indexierbar, wird jedoch als Sprachversion aufgeführt

Die Ziel-URL eines hreflang-Verweises sollte eine gültige, normal crawlbare Seite zurückgeben. Treten auf der Zielseite Weiterleitungen, 404, Soft-404, 5xx-Fehler, noindex, ein durch robots.txt untersagtes Crawling oder eine Anmeldepflicht auf, kann die Sprachbeziehung selbst dann kaum wirksam werden, wenn sie im Quellcode steht.

Ein verdeckterer Fall ist die geografische Weiterleitung: Wenn Nutzer oder Crawler die allgemeine englische Seite aufrufen, leitet der Server sie anhand ihrer IP automatisch auf die US-Seite weiter; die US-Seite verweist in hreflang wiederum auf die allgemeine englische Seite zurück. Automatische Weiterleitungen beeinträchtigen das Crawling und die freie Auswahl der Nutzer und führen leicht zu Inkonsistenzen zwischen Seitenpositionierung und Auszeichnungsdeklaration. Regionsempfehlungen können über Hinweisleisten, Auswahlfelder oder eindeutige Links umgesetzt werden; die Einstiegs-URL von Besuchern und Suchmaschinen sollte nicht zwangsweise überschrieben werden.

HTML, HTTP Header und Sitemap sollten keine einander widersprechenden Versionstabellen ausgeben

hreflang kann über HTML<head>, HTTP-Antwortheader oder XML-Sitemaps bereitgestellt werden. Bei üblichen Webseiten sind HTML-Auszeichnungen leichter zu überprüfen; bei Nicht-HTML-Dateien können HTTP Header verwendet werden; bei sehr vielen URLs erleichtert eine Sitemap die zentrale Verwaltung. Unabhängig von der verwendeten Methode geht es nicht darum, „mehrere Stellen zu ergänzen“, sondern darum, überall dieselbe URL-Zuordnung zu verwenden.

Wenn in HTML /fr/ als fr-FR markiert wird, dieselbe URL in der Sitemap jedoch als fr-CA, erhöht dies nicht die Abdeckung, sondern erzeugt einen nicht erklärbaren Ausrichtungskonflikt. Technisch sollten Beziehungen zwischen Sprachversionen als strukturierte Daten behandelt und aus einer einheitlichen Zuordnungstabelle generiert werden, statt sie durch unterschiedliche Teams jeweils in Templates, Plugins und Sitemaps pflegen zu lassen.

Bei der Prüfung sollte zunächst die „Identität“ der Seite bestätigt und erst danach die Tags kontrolliert werden

Eine wirksame Prüfungsreihenfolge beginnt bei der URL-Identität und nicht bei Codefragmenten. Zunächst ist festzustellen, ob jede Seite ein eigenständiges Sprach- oder Regionsziel hat; danach ist sicherzustellen, dass jedes Ziel nur eine indexierbare kanonische URL besitzt; anschließend sind Selbstreferenz-canonical, HTTP-Status, robots-Anweisungen und Seiteninhalte dieser URL zu prüfen; zuletzt ist zu kontrollieren, ob sich alle alternativen Versionen innerhalb desselben Sets gegenseitig referenzieren.

Bei mehrsprachigen B2B-Websites haben Produktseiten, Kategorieseiten, Lösungsseiten und Anfrage-Landingpages häufig unterschiedliche Abdeckungsbereiche für ihre Versionen. Seiten ohne französische Inhalte müssen nicht nur der oberflächlichen Vollständigkeit halber mit künstlichem französischem hreflang versehen werden; wenn bestimmte Regionen lediglich englische Inhalte teilen, muss auch nicht für jedes Land eine englische URL dupliziert werden. Der Wert von hreflang liegt darin, tatsächlich bestehende Unklarheiten zwischen Versionen zu beseitigen, nicht darin, alle Marktverzeichnisse einmal auszuzeichnen.

Wenn Sprachversionen miteinander in Konflikt stehen, sollten zunächst doppelte Ausrichtungen entfernt, canonical und endgültige URLs korrigiert, wechselseitige Verweise vervollständigt und anschließend die Quellen der Zuordnungen in HTML oder Sitemap vereinheitlicht werden. Nur wenn Seiteninhalt, Zugriffspfad und Suchsignale auf dieselbe Versionsdefinition verweisen, kann hreflang seine Funktion bei der regionalen Zuordnung erfüllen, statt zu einer zusätzlichen Ursache für fehlerhafte Indexierung und Streuung des Traffics zu werden.