Canonical ist nicht hreflang: So prüfen Sie mehrsprachige Websites richtig

Ein Unternehmen übersetzt seine Website sauber ins Deutsche und Englische. Beide Sprachversionen sind erreichbar, intern verlinkt und in der Sitemap enthalten. Trotzdem zeigt Google für eine deutsche Suchanfrage plötzlich die englische URL – oder eine lokalisierte Seite verschwindet aus dem Index.

Dann fällt oft der Satz: „Wir haben doch hreflang gesetzt.“

Genau hier liegt ein verbreitetes Missverständnis: hreflang und rel="canonical" lösen zwei unterschiedliche Probleme. Wer beide Signale wie austauschbare SEO-Tags behandelt, kann eine technisch gepflegte Mehrsprachigkeit bauen, die sich selbst widerspricht.

Google beschreibt Canonicalisierung als Auswahl einer repräsentativen URL aus gleichen oder sehr ähnlichen Seiten. hreflang dagegen verbindet Sprach- oder Regionsvarianten miteinander, damit die passende Variante für Nutzer ausgespielt werden kann. Für vollständig übersetzte Inhalte gilt außerdem: Lokalisierte Seiten werden nicht allein deshalb als Duplikate behandelt, weil sie denselben Zweck erfüllen.

Die praktische Konsequenz: Eine deutsche und eine englische Seite brauchen in der Regel jeweils ihre eigene kanonische URL und zusätzlich eine konsistente Beziehung als Sprachalternativen.

Das typische Fehlbild

Angenommen, es gibt diese Seiten:

• https://example.com/de/leistungen
• https://example.com/en/services

Die deutsche Seite enthält ein Canonical auf die englische Seite, weil beide „inhaltlich dasselbe“ darstellen. Gleichzeitig verweisen beide per hreflang aufeinander.

Für Menschen klingt das plausibel: gleicher Inhalt, zwei Sprachen. Für Suchsysteme sind die Signale aber nicht sauber getrennt. Das Canonical sagt sinngemäß: Diese andere URL ist die repräsentative Version meines Inhalts. Das hreflang sagt: Diese URL ist eine eigenständige lokalisierte Alternative.

Eine robustere Konfiguration ist normalerweise:

• die deutsche Seite canonicals auf sich selbst,
• die englische Seite canonicals auf sich selbst,
• beide Seiten listen sich selbst und die jeweils andere Sprachversion als hreflang-Alternativen,
• beide URLs sind erreichbar, indexierbar und final,
• Sitemap und interne Links zeigen auf dieselben finalen URLs.

Google empfiehlt bei hreflang, eine kanonische Seite in derselben Sprache zu wählen oder, falls das nicht möglich ist, die bestmögliche Ersatzsprache.

Canonical und hreflang: zwei Fragen, zwei Signale

Canonical beantwortet: Welche URL repräsentiert diesen Inhalt?

Canonicalisierung ist relevant, wenn derselbe oder sehr ähnliche Inhalt über mehrere URLs erreichbar ist. Typische Ursachen sind Tracking-Parameter, Filter, alte Pfade, HTTP/HTTPS-Varianten oder sehr ähnliche regionale Seiten.

Google behandelt rel="canonical" als starkes Signal, aber nicht als unumstößliche Anweisung. Weiterleitungen, Canonicals und Sitemap-Signale können zusammenwirken. Wenn die Signale widersprüchlich sind, kann Google eine andere URL als die von Ihnen bevorzugte auswählen.

hreflang beantwortet: Welche lokalisierte Variante gehört zu dieser Seite?

hreflang beschreibt Beziehungen zwischen Sprach- oder Regionsvarianten. Eine deutsche Version kann beispielsweise de, eine englische en und eine Schweizer deutsche Variante de-CH verwenden.

Wichtig: Google verwendet hreflang oder das HTML-Attribut lang nicht als alleinige Methode zur Erkennung der Seitensprache. Die sichtbaren Inhalte müssen die Sprache selbst eindeutig machen.

Acht Red Flags bei mehrsprachigen Websites

1. Alle Sprachen canonicalisieren auf eine einzige Sprache

Wenn /de/, /en/ und /fr/ alle auf /en/ canonicalisieren, obwohl die Hauptinhalte tatsächlich übersetzt sind, ist die Mehrsprachigkeit konzeptionell falsch modelliert.

2. hreflang ist nur in eine Richtung vorhanden

Wenn die deutsche Seite auf die englische verweist, die englische aber nicht zurück, kann Google die Annotationen ignorieren oder nicht korrekt interpretieren. Google verlangt für zuverlässige Zuordnung Rückverweise.

3. Eine Seite vergisst sich selbst

Jede Sprachversion soll in ihrem hreflang-Set auch sich selbst aufführen. Ein Cluster besteht nicht nur aus den „anderen“ Sprachen.

4. hreflang zeigt auf Redirects, 404s oder nicht indexierbare Seiten

Sprachbeziehungen sollten auf finale, erreichbare URLs zeigen. Ein hreflang-Cluster, der erst durch Redirect-Ketten aufgelöst wird oder auf noindex-Seiten zeigt, ist unnötig fragil.

5. Sprach- und Regionscodes sind falsch

en-GB ist eine Sprache plus Region. Ein Regionscode allein reicht nicht. Außerdem sind umgangssprachlich naheliegende Codes nicht automatisch gültig. Google nennt beispielsweise UK als wirkungslos; für das Vereinigte Königreich ist GB der relevante Regionscode.

6. HTML, HTTP-Header und Sitemap erzählen unterschiedliche Geschichten

Google unterstützt hreflang über HTML, HTTP-Header oder Sitemap. Alle drei Methoden gleichzeitig zu pflegen bringt laut Google keinen Suchvorteil und erhöht die Gefahr, dass sich Implementierungen auseinanderentwickeln.

7. Sprache hängt nur von Cookies oder Browsererkennung ab

Wenn dieselbe URL je nach Cookie, IP oder Accept-Language unterschiedliche Inhalte liefert, kann ein Crawler nicht zuverlässig alle Varianten entdecken. Google empfiehlt getrennte URLs für Sprachversionen und warnt vor erzwungenen automatischen Sprachweiterleitungen.

8. Der Sprachumschalter führt nicht zur entsprechenden Seite

Ein sichtbarer Umschalter, der Nutzer immer nur auf die Startseite der anderen Sprache wirft, ist kein technischer hreflang-Fehler – aber ein Produktproblem. Wer auf einem konkreten Artikel oder einer Leistung die Sprache wechselt, erwartet die semantisch passende Seite.

Der nützlichste Audit ist ein Beziehungs-Audit

Bei hreflang reicht es nicht, einzelne Seiten isoliert zu prüfen. Entscheidend ist der Graph zwischen den Varianten.

Für jede indexierbare Sprachseite sollte ein Audit mindestens erfassen:

Schon bei zehn Seitentypen und drei Sprachen entsteht daraus keine kleine Liste mehr, sondern eine Matrix. Genau deshalb fallen Fehler oft erst nach Relaunches oder CMS-Änderungen auf.

x-default ist ein Fallback, keine vierte Sprache

Für Sprach- oder Länderauswahlseiten kann hreflang="x-default" sinnvoll sein. Es bezeichnet eine Fallback-Seite für Nutzer, deren Sprache oder Region keiner expliziten Variante entspricht.

Das ist besonders praktisch bei einer neutralen Länderauswahl oder einer globalen Startseite. x-default ersetzt jedoch nicht die normalen Sprachvarianten und ist auch kein Signal dafür, dass eine bestimmte Seite „die wichtigste“ ist.

Was bei regional ähnlichen Inhalten anders ist

Nicht jede internationale Website besteht aus vollständigen Übersetzungen. Manchmal gibt es beispielsweise drei englische Seiten für USA, Großbritannien und Australien mit fast identischem Hauptinhalt und nur regionalen Preisen oder Versandinformationen.

Hier liegen Canonicalisierung und Lokalisierung enger beieinander. Google empfiehlt bei ähnlichen oder doppelten Inhalten derselben Sprache, eine bevorzugte Version zu wählen und Canonical- sowie hreflang-Signale koordiniert einzusetzen.

Das ist ein guter Grund, nicht eine globale Canonical-Regel für alle Sprachen und Regionen zu programmieren. Die richtige Entscheidung hängt davon ab, ob Seiten wirklich übersetzt, nur regional angepasst oder technisch dupliziert sind.

So bauen Sie die Prüfung in den Betrieb ein

1. Seitenfamilien definieren

Legen Sie fest, welche URLs semantisch zusammengehören: Startseite, Produkt, Leistung, Kategorie, Artikel, Hilfe, Kontakt, Login oder andere Seitentypen.

2. Erwartete Sprachmatrix erzeugen

Für jede Seitenfamilie sollte klar sein, welche Sprach- und Regionsvarianten existieren müssen. Fehlende Übersetzungen sollten bewusst als fehlend gelten – nicht durch zufällige Links auf die Startseite kaschiert werden.

3. Canonical und hreflang getrennt validieren

Prüfen Sie zuerst die kanonische Identität jeder URL und danach die Beziehungen zu ihren Alternativen. So sehen Sie sofort, ob eine Seite gleichzeitig „ich bin eigenständig“ und „eine andere URL repräsentiert mich“ signalisiert.

4. Live-Antworten statt CMS-Felder prüfen

Entscheidend ist nicht, was im SEO-Plug-in oder CMS eingetragen wurde, sondern was Browser und Crawler tatsächlich erhalten: HTML, Response-Header, Redirects und Sitemap.

5. Nach Releases automatisiert regressieren

Neue Sprachen, Routenänderungen, CMS-Plug-in-Updates, Middleware, Reverse Proxies oder ein Relaunch können Canonicals und hreflang-Cluster verändern. Repräsentative Seitenfamilien gehören deshalb in technische Regressionstests.

Was Website-Pflichtencheck prüfen würde

Ein Mehrsprachigkeits-Audit von Website-Pflichtencheck würde nicht nur nach dem String hreflang suchen. Geprüft werden können unter anderem:

• finale Statuscodes und Redirects,
• Canonicals pro Sprach- und Regionsseite,
• vollständige und bidirektionale hreflang-Cluster,
• gültige Sprach- und Regionscodes,
• Unterschiede zwischen Quell-HTML und gerendertem DOM,
• hreflang-Angaben in HTML, HTTP-Headern oder Sitemaps,
• Sitemap-Konsistenz,
• noindex- und Robots-Konflikte,
• interne Verlinkung und Sprachumschalter,
• unerwartete Cross-Domain- oder Staging-Ziele,
• Musterfehler über ganze Seitentypen hinweg.

Das Ziel ist nicht, möglichst viele SEO-Tags abzuhaken. Es ist, dass jede Sprachversion technisch eine eindeutige Identität hat und gleichzeitig sauber mit ihren echten Alternativen verbunden ist.

Wenn eine mehrsprachige Website nach jedem Relaunch manuell „irgendwie richtig aussieht“, aber niemand den vollständigen Canonical-hreflang-Graph geprüft hat, ist das kein kontrollierter Zustand. Ein kleiner Fehler im Template kann tausende Beziehungen verändern.

Mehrsprachigkeit ist keine Sammlung einzelner Seiten. Sie ist ein System aus Beziehungen – und genau so sollte sie geprüft werden.