Wenn Canonical-Tags über Sprachgrenzen hinweg verweisen, brechen Hreflang

Eine Seite kann 2 Tags im selben <head> tragen, die denselben Crawler zur selben URL ansprechen und Gegensätzliches sagen. Auf https://example.com/fr/pricing sagt dieses Tag, dass die Seite der französische Teil eines Clusters ist:

<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />

Und dies, 1 Zeile darunter, sagt, dass die Seite eine Variante ist, die in das englische Original integriert werden soll:

<link rel="canonical" href="https://example.com/pricing" />

Reale Seiten liefern beide, aus demselben Template, auf jeder lokalen Route, die sie besitzen. Dies ist der Fehler, der nach demjenigen, den wir im Juli dokumentiert haben, bleibt — die fehlende hreflang‑Selbstreferenz, die immer noch 58 % von 88 hreflang‑Bewertungen in unseren aktuellen Daten fehlschlagen. Eine Seite kann diesen Kreis schließen, jede Selbstreferenz korrekt setzen und dennoch jede lokale Seite darum bitten, durch ihr englisches Gegenstück ersetzt zu werden.

Ein Cross‑Language‑Canonical fordert Google auf, die lokale URL in das Original zu integrieren

Ein Canonical‑Tag ist eine Konsolidierungsanfrage: Behandle diese URL als Variante von jener, und indexiere jene. Eine Hreflang‑Annotation ist ein Routing‑Anspruch: Diese URL ist die Version für diese Sprache. Zeige sie auf unterschiedliche URLs und die Seite hat eine Anfrage gestellt, die ihren eigenen Anspruch ungültig macht — der französische Slot im Cluster wird von einer Seite besetzt, die sich selbst ablehnt.

Google hat ausdrücklich gesagt, dass hreflang ein Hinweis und keine Anweisung ist, und Canonicalisierung funktioniert auf die gleiche Weise: Die Seite liefert Signale, Google löst sie auf. Diese Auflösung ist das ganze Problem. Mit einer selbst‑canonicalisierten lokalen Seite entscheidet der Publisher, welche URL französische Suchende bedient. Mit einem Cross‑Language‑Canonical hat der Publisher die Entscheidung abgegeben, während er glaubt, das Cluster sei konfiguriert — und das Ergebnis, das später gemeldet wird, ist eine lokale Seite, die in ihrem eigenen Markt nirgendwo rankt, während die englische Seite an ihrer Stelle erscheint.

Die Generatoren, die dies produzieren, sind gewöhnlich. Ein Canonical‑Helper, der aus einer Routen‑Definition statt aus dem Request‑Pfad erstellt wird, gibt die unpräfixierte URL für jede Locale aus. Ein CMS, dessen hreflang‑Einstellung pro Locale ist, aber dessen Canonical‑Einstellung global ist, tut dasselbe. So führt eine Migration, die Ländercodes zu URLs hinzufügte und den kanonischen Link auf die ursprüngliche Position des Inhalts zeigte,. In jedem Fall rendert die Seite einwandfrei, die Annotationen sehen im Quellcode vollständig aus, und die Widersprüche sind 2 Attribute getrennt.

Der Datensatz

Methodik: neueste abgeschlossene Auditsnapshot pro Domain aus unserem aktuellen Prüfsatz, ungefähr Mai 23 – August 31, 2026, anonymisiert. Denominator unterscheiden sich je nach Prüfung — 34 bis 49 Seiten — weil eine Prüfung nur läuft, wenn ihre Eingaben existieren: die Selbstreferenzprüfung liefert kein Urteil bei einer Startseite ohne hreflang‑Annotationen, weshalb ihr Seitenzähler der kleinere ist. Bewertungs‑ und Seiten‑Raten unterscheiden sich, weil einige Domains im Zeitraum mehrmals geprüft wurden. Die Stichprobe ist selbstausgewählt — Betreiber, die ein Audit durchgeführt haben — und tendiert zu klein‑bis‑mittelgroß, daher sollten die Raten als Richtwert für diesen Segment betrachtet werden.

Die zweite Zeile ist das ruhigere Risiko. Eine Seite ohne kanonische URL hat ihre hreflang‑Annotation nicht widersprochen, aber sie hat die Annotation auch nicht verteidigt: nichts auf der Seite sagt, welche URL sie als autoritativ betrachtet, sodass eine Ländervariante, die über mehr als 1 Adresse erreichbar ist, vollständig durch Inferenz gelöst wird. Ein korrektes Cluster zu erreichen beginnt mit kanonischer Hygiene, weshalb unser kanonischer Leitfaden die Voraussetzung für die hreflang‑Implementierungsanleitung ist, nicht ein Begleitdokument.

Der Widerspruch ist nur von beiden Enden des Clusters sichtbar

Eine einzelne Seite kann diesen Fehler nicht über sich selbst melden. /fr/pricing sieht intern konsistent aus — ein hreflang‑Set, eine kanonische URL, beide gut formatiert. Der Defekt tritt auf, wenn man die Annotation und die annotierte Seite nebeneinander betrachtet, weshalb man zur Überprüfung das Cluster abrufen muss, statt nur 1 Dokument zu lesen.

Folgen Sie jeder hreflang‑Annotation zu ihrem Ziel und halten Sie fest, was zurückkommt: den Statuscode, ob die Anfrage umgeleitet wurde, ob eine noindex‑Direktive vorhanden ist und ob die eigene kanonische URL des Ziels die URL nennt, auf die die Annotation verwiesen hat. Ein Ziel, dessen Canonical eine andere URL nennt, ist genau der Cross‑Language‑Canonical, um den es in diesem Artikel geht.

Das lang-Attribut ist ein zweiter Zeuge. Eine Seite, deren html lang eine andere Sprache nennt als das Locale, das ihr eigener hreflang-Eintrag beansprucht, widerspricht sich auf dieselbe Weise, und das ist oft das erste sichtbare Anzeichen dafür, dass eine lokalisierte Route den Inhalt des Originals ausliefert.

Eine Alternative, die nicht abgerufen werden kann, ist eine Lücke im Beweis, kein Nachweis eines Defekts. Halten Sie sie als ungeprüft fest und rufen Sie sie erneut ab, bevor Sie das Cluster für defekt erklären.

graph TD
    FR["/fr/pricing — html lang=fr"]
    EN["/pricing — englische Originalversion"]
    FR -->|"hreflang=fr, selbstreferenzierend"| CLAIM["Anspruch: diese URL an französische Suchmaschinen liefern"]
    FR -->|"rel=canonical"| EN
    EN -->|"hreflang=fr"| FR
    CLAIM --> Q{"Welche URL beantwortet eine französische Anfrage?"}
    EN --> Q
    Q -->|"die Seite hörte auf zu entscheiden"| OUT["Google Picks — normalerweise die englische URL"]

Unsere eigenen Locale-Präfixe lieferten Englisch bis August 17, 2026

Wir sind an dieser Klasse von Defekten auf seoreport.dev selbst gescheitert. Ahrefs Site Audit meldete ein hreflang und HTML lang-Übereinstimmungsproblem über 184 URLs auf unserer eigenen Seite. Das lang-Attribut war das Symptom; der Inhalt war ebenfalls Englisch, auf jedem der 9 Locale-Präfixe, was jede lokalisierte URL zu einer Duplikat ihres englischen Zwillings machte — das gleiche Ergebnis, das ein cross-language canonical erzeugt, erreicht aus der anderen Richtung.

Die Ursache war 1 Funktionsgrenze. Die Dokumenten-Shell nahm ihre Sprache von einem Helfer, der die Standardsprache zurückgibt, wann immer window undefiniert ist. Auf dem Server rendert /fr/pricing daher lang="en" und seedet das englische Übersetzungsbündel, während die Komponente, die die Head-Links ausgibt — die den Pfad liest, nicht die Laufzeit — einen korrekten fr self-hreflang direkt daneben ausgibt. Ein Client-Effekt wechselte die Sprache nach der Hydration, sodass jede browserbasierte Prüfung bestand und kein Mensch es sah. Crawler führen diesen Effekt nicht aus.

Behebt auf August 17, 2026: die Shell ermittelt ihre Sprache aus dem Pfad, das lokalisierte Layout löst das Locale-Bündel in einem Loader auf, sodass Server-Render und Hydration es teilen, und ein unterstütztes Locale ohne Bündel wirft stattdessen anstatt still Englisch unter seinem Präfix zu liefern. Die Textausrichtung war ebenfalls falsch — Arabisch hatte ltr geliefert.

Der Regressionstest ist ein Lauf gegen rohes HTML ohne JavaScript, weil ein Browser-Check blind gegenüber dieser gesamten Fehlerklasse ist. Run red-first gegen Produktion meldete 440 Fehler über 128 lokalisierte URLs, jede Seite bei 100% Englisch-Übertrag. Gegen die gefixte Version: 0 Fehler über 144 URLs. Ein Vergleich von lang mit hreflang hätte zuerst an unserer eigenen Seite angeschlagen.

x-default erbt, was die Fallback-Seite deklariert

Unsere Stichprobe von Seiten, die x-default deklarieren, ist zu klein, um eine Fehlerquote zu veröffentlichen. Das HTML beweist außerdem weniger, als es scheint: Es zeigt, dass eine x-default-Annotation deklariert ist, nicht welche Zielgruppe der Publisher damit bedienen wollte. Prüfbar sind die benachbarten Fakten — URL-Form, Zielgesundheit, wechselseitige Annotationen und kanonische Ausrichtung.

Was der Mechanismus impliziert, ist trotzdem erwähnenswert. x-default ist der Fallback für Suchende, deren Sprache die Seite nicht bedient, sodass er normalerweise auf die Seite des Primärmarktes zeigt. Wenn diese Seite einen cross-language canonical trägt, erbt der Fallback für jeden nicht übereinstimmenden Suchenden auf dem Planeten die Widersprüchlichkeit, und der Widerspruch zeigt sich in der Gesundheit des Ziels statt in der x-default-Zeile selbst.

Überprüfe es in rohem HTML, pro Locale, in beide Richtungen

Rufe die Seite so ab, wie ein Crawler es tut, und lese 3 Dinge:

curl -s -A "Googlebot" https://example.com/fr/pricing | grep -iE '<html|rel="canonical"|hreflang'

Das lang-Attribut, der selbstreferenzierende hreflang-Eintrag und der Canonical müssen auf 1 Locale und 1 URL übereinstimmen:

<!-- On https://example.com/fr/pricing -->
<html lang="fr">
<link rel="canonical" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="en" href="https://example.com/pricing" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

Wiederhole dann auf 1 Seite pro Locale und rufe jeden URL ab, den die Annotation benennt, um zu bestätigen, dass jeder selbst kanonisiert. Die Regel ist kurz genug, um sie einem Entwickler zu geben: jedes Mitglied eines hreflang-Clusters kanonisiert sich selbst. Ein cross-language canonical ist genau in 1 Situation korrekt — wenn der lokalisierte URL überhaupt nicht lokalisiert ist und dieselbe Sprache wie das Original bedient — und in dieser Situation gehört der URL nicht einmal in den Cluster.

Die URL-Inspektion von Search Console gibt die autoritative zweite Meinung darüber, welcher Canonical Google tatsächlich ausgewählt wurde, pro URL. Eine kostenpflichtige SEOReport-Diagnose durchläuft die Schleife über den Cluster und listet jedes widersprüchliche Paar mit der Seite, auf der es gefunden wurde. Die 9 Locale-Präfixe auf seoreport.dev bestehen jetzt, und sie bestehen, weil wir den Defekt zuerst ausgeliefert haben, auf einer Seite, deren gesamtes Produkt ihn findet.