Mehrsprachige Websites: Plugin-Lösung gegen natives i18n — was hreflang wirklich braucht

Mehrsprachigkeit ist der Bereich, in dem technisches SEO am zuverlässigsten kaputtgeht — und zwar leise. Eine falsche Meta-Description sieht man im Suchergebnis. Eine gebrochene hreflang-Zuordnung sieht man gar nicht: Die Seiten sind erreichbar, der Umschalter funktioniert im Browser, und trotzdem behandelt die Suchmaschine die Fassungen als unabhängige Seiten oder liefert die falsche aus.

Die Frage, ob man dafür eine Plugin-Lösung nimmt oder mit den Bordmitteln eines Frameworks arbeitet, ist berechtigt — aber sie ist nicht die erste Frage. Die erste Frage ist, welche Bedingungen erfüllt sein müssen, damit die Angaben überhaupt gewertet werden. Erst danach lässt sich sinnvoll beurteilen, welcher Weg diese Bedingungen leichter dauerhaft hält.

Was hreflang tatsächlich ist und was es nicht ist

Die hreflang-Angabe ist eine Zuordnung zwischen URLs, kein Rankingsignal und keine Anweisung. Sie teilt Google mit, dass eine bestimmte URL die deutschsprachige, eine andere die englischsprachige Fassung desselben Inhalts ist, damit die passende Version ausgeliefert werden kann. Google beschreibt die Funktion genau so: Die Annotation dient dazu, die Varianten eines Inhalts als lokalisierte Fassungen erkennbar zu machen.

Daraus folgen zwei Dinge, die in Projekten regelmässig verwechselt werden. Erstens rankt eine Seite nicht besser, weil sie hreflang hat — sie wird lediglich der richtigen Zielgruppe zugeordnet. Zweitens ersetzt hreflang keinen Canonical und widerspricht ihm auch nicht: Jede Sprachfassung ist eine eigenständige Seite mit einem Canonical auf sich selbst. Der Klassiker, der ganze Setups lahmlegt, ist ein Canonical auf der englischen Seite, das auf die deutsche zeigt. Damit erklärt man die englische Fassung zur Kopie, und alle hreflang-Angaben daneben sind wirkungslos.

Für die Umsetzung nennt Google drei gleichwertige Wege: Elemente im Kopfbereich der HTML-Seite, HTTP-Header oder die XML-Sitemap. Man braucht nicht alle drei. Man braucht einen, vollständig.

Die Bedingungen, ohne die hreflang ignoriert wird

Vier Bedingungen entscheiden darüber, ob deine Annotationen überhaupt gewertet werden, und drei davon stehen wörtlich in Googles Dokumentation. Erstens die Gegenseitigkeit: Verweisen zwei Seiten nicht beide aufeinander, werden die Angaben ignoriert. Zweitens die Selbstnennung — jede Sprachfassung muss sich selbst mit auflisten, nicht nur die anderen. Drittens die Codes: Der Sprachcode folgt ISO 639-1, die optionale Region ISO 3166-1 Alpha 2, und ein Ländercode allein ist ausdrücklich nicht zulässig. Viertens, und das ist Erfahrung statt Dokumentation: Die genannten URLs müssen die kanonischen, direkt mit Status 200 antwortenden Adressen sein. Ein hreflang auf eine URL, die per Weiterleitung antwortet, ist eine halbe Angabe.

Dazu kommt x-default als optionale, aber sinnvolle Ergänzung. Der reservierte Wert greift, wenn keine der angebotenen Sprachfassungen zur Einstellung des Nutzers passt. In der Schweizer Praxis zeigt er fast immer auf die deutsche Fassung, weil das die vollständigste ist. So sieht das Ergebnis für eine zweisprachige Seite im Kopfbereich aus:

<link rel="alternate" hreflang="de-CH" href="https://example.ch/leistungen" />
<link rel="alternate" hreflang="en" href="https://example.ch/en/services" />
<link rel="alternate" hreflang="x-default" href="https://example.ch/leistungen" />

Entscheidend: Genau derselbe Dreierblock muss auch auf https://example.ch/en/services stehen. Nicht ein anderer, nicht ein gekürzter — derselbe.

Die Rechnung: wie schnell die Zahl der Annotationen wächst

Die Zahl der zu pflegenden Annotationen wächst quadratisch mit der Zahl der Sprachen, und das ist der eigentliche Grund, warum manuelle Pflege in diesem Bereich nicht funktioniert. Bei n Sprachen trägt jede einzelne Seite n Einträge plus x-default, also n+1 Zeilen. Eine Seitengruppe besteht aus n Seiten, die diesen Block alle tragen müssen — macht n × (n+1) Annotationen pro Inhalt.

Noch deutlicher wird es beim Nachziehen. Eine dreisprachige Website mit 40 Seitengruppen trägt 480 Annotationen. Kommt eine vierte Sprache dazu, gewinnen die 120 bestehenden Seiten je einen Eintrag (120 Änderungen), und 40 neue Seiten kommen mit je fünf Einträgen dazu (200). Aus 480 werden 800 Annotationen, 320 davon sind neu oder geändert. Wer das von Hand pflegt, macht irgendwo einen Fehler — und der Fehler ist unsichtbar, weil er nur die Auswertung deaktiviert, nicht die Seite.

Die Konsequenz gilt für beide Welten gleichermassen: Die Annotationen müssen generiert werden, aus genau einer Zuordnungstabelle. Ob diese Tabelle in einer CMS-Datenbank oder in einer Datei liegt, ist zweitrangig. Dass es nur eine gibt, ist die ganze Anforderung. Dieselbe Logik gilt übrigens für jede Form von Programmatic SEO: Sobald Seiten aus Vorlagen entstehen, entscheidet die Datenquelle über die Qualität, nicht das Template.

Wo Plugin-Lösungen brechen

Plugin-Lösungen brechen fast nie beim Erzeugen der Annotationen, sondern beim Verwalten der Übersetzungsbeziehung, aus der sie erzeugt werden. WPML etwa gibt hreflang automatisch aus, sobald die Sprachen eingerichtet sind, und dokumentiert dafür drei URL-Formate: Verzeichnisse, Subdomains beziehungsweise eigene Domains, sowie Query-Parameter. Das funktioniert, und für viele Projekte ist es die pragmatischste Lösung überhaupt.

Die Bruchstellen liegen woanders. Die erste ist die Beziehung selbst: Die Zuordnung existiert als Verknüpfung zwischen zwei Beiträgen in der Datenbank. Wird eine Übersetzung auf Entwurf gesetzt, in den Papierkorb verschoben oder nach einem Import neu angelegt, verschwindet der Rückverweis — und damit die Wertung, ohne dass irgendwo eine Warnung erscheint. Die zweite ist das Zusammenspiel mit dem Rest der Installation: WPML bietet eine eigene Einstellung für die Position der hreflang-Ausgabe im Kopfbereich, mit zwei wählbaren Prioritäten, und empfiehlt den Wechsel ausdrücklich zur Lösung von Konflikten mit bestimmten Themes und Plugins. Dass diese Einstellung existiert, ist ein Qualitätsmerkmal — aber sie existiert, weil das Problem real ist.

Die dritte Bruchstelle sind die Sprachcodes. WPML bringt 65 vorkonfigurierte Sprachen mit und erlaubt eigene Sprachen für Fälle wie Schweizerdeutsch oder kanadisches Französisch. Genau dort entstehen die ungültigen Codes: Eine selbst angelegte Sprache mit einem frei gewählten Kürzel ist im Frontend sichtbar und in der Sitemap plausibel — und für Google trotzdem wertlos, wenn das Kürzel nicht ISO 639-1 entspricht.

Wo natives i18n bricht

Natives i18n bricht dort, wo Automatik erwartet wird, die es nicht gibt: Ein Framework liefert die Mechanik für Sprachcodes, Routen und Annotationen, aber die Zuordnung, welche deutsche Seite welcher englischen entspricht, muss jemand bauen. In Next.js etwa deklariert man die Sprachfassungen im Metadata-Objekt als alternates.languages, und das Framework rendert daraus die Elemente im Kopfbereich sowie die Alternates in der Sitemap. Was es nicht tut: erraten, welche Seiten zusammengehören.

Genau an dieser Stelle liegt die Erfahrung, die uns auf dieser Website am meisten gekostet hat. Eine Zuordnungstabelle steuert bei uns beides — den Sprachumschalter und die Alternates in der Sitemap. Der Grund ist banal: Zwei getrennte Listen wären im ersten Deployment identisch und danach nie wieder. Genau so entstehen hreflang-Angaben auf Seiten, die der Umschalter nicht kennt, und umgekehrt Umschalter-Links, für die es keine Annotation gibt. Seiten ohne Eintrag in dieser Tabelle bleiben bei uns bewusst einsprachig annotiert, damit kein hreflang auf eine 404 zeigt — lieber gar keine Zuordnung als eine falsche.

Die zweite typische Bruchstelle ist die Sprachauszeichnung des Dokuments selbst. Wer beide Sprachbäume durch dasselbe Wurzel-Layout schickt, liefert am Ende auf allen Seiten dieselbe Sprachangabe im HTML-Element aus. Das ist kein hreflang-Problem im engeren Sinn, aber es widerspricht der Annotation und ist ein vermeidbarer Widerspruch. Wir lösen das über getrennte Wurzel-Layouts je Sprachbaum. Dritte Bruchstelle: der Sprachumschalter, der aus Bequemlichkeit auf die Startseite der Zielsprache zeigt statt auf die übersetzte Seite. Für Nutzer ärgerlich, für die interne Verlinkung schädlich — verwandt mit dem Muster, das wir bei verwaisten Seiten beschrieben haben.

de-CH, de oder ch-de: die Schweizer Sonderfälle

In der Schweiz ist die häufigste Fehlerquelle nicht die Mehrsprachigkeit an sich, sondern die Versuchung, die Region vor die Sprache zu stellen. Gültig ist ausschliesslich die Reihenfolge Sprache, dann optional Region: de-CH, fr-CH, it-CH, en. Ungültig sind ch-de und ein blosses ch, weil Google die Regionsangabe ohne vorangestellten Sprachcode ausdrücklich nicht akzeptiert.

Die zweite Frage ist, ob man überhaupt eine Region braucht. de-CH sagt: Diese Fassung ist für deutschsprachige Nutzer in der Schweiz. Das ist sinnvoll, wenn es daneben eine deutsche Fassung für Deutschland oder Österreich gibt. Existiert nur eine deutschsprachige Version, ist schlichtes de die robustere Wahl, weil es alle deutschsprachigen Regionen abdeckt. Wir setzen auf dieser Website de-CH mit x-default auf die deutsche Fassung, weil das Angebot bewusst auf den Schweizer Markt zugeschnitten ist — das ist eine Positionierungs-, keine Technikentscheidung.

Der dritte Punkt betrifft die Vollständigkeit. Eine Sprachfassung, die nur aus einer übersetzten Startseite und drei Unterseiten besteht, während die deutsche Fassung achtzig Seiten hat, erzeugt vor allem Lücken. Wer eine zweite Sprache anfängt, sollte einen Kernbereich vollständig übersetzen statt überall ein bisschen. Was das für Umfang und Budget bedeutet, steht in unserer Übersicht zu den Webdesign-Preisen; mehrsprachige Auftritte liegen aus genau diesem Grund im oberen Bereich der Spanne.

Der Prüfablauf, der in zehn Minuten Klarheit schafft

Ob dein hreflang-Setup gewertet wird, prüfst du in zehn Minuten mit vier Schritten und ohne Werkzeug. Erstens: Öffne den Quelltext einer übersetzten Unterseite — nicht der Startseite, die ist fast immer richtig — und lies die Annotationen. Steht die Seite selbst mit drin? Zweitens: Rufe jede genannte URL auf. Antwortet sie direkt mit 200, ohne Weiterleitung? Drittens: Öffne den Quelltext der Zielseite und vergleiche den Block Zeile für Zeile mit dem der Ausgangsseite. Sind sie identisch? Viertens: Prüfe auf beiden Seiten das Canonical. Zeigt es jeweils auf die Seite selbst?

Wenn alle vier Antworten Ja lauten, funktioniert die Zuordnung. Wenn eine Nein lautet, ist der Rest egal, bis sie behoben ist. Der Test ist bewusst manuell, weil er dabei auch die Fragen beantwortet, die kein Werkzeug stellt: Ist die englische Seite tatsächlich die Übersetzung der deutschen, oder nur ein thematisch ähnlicher Text? Führt der Umschalter dorthin, wohin die Annotation zeigt?

Für einen kompletten Bestand ist dieselbe Logik der Kern dessen, was wir im Website-Audit prüfen, weil sich hreflang-Fehler über Hunderte von Seiten nicht mehr stichprobenartig finden lassen. Und wer eine mehrsprachige Seite neu aufsetzt, sollte die Zuordnungstabelle vor der ersten Übersetzung anlegen, nicht danach — beim Website erstellen lassen ist das der Punkt, an dem sich später am meisten Aufräumarbeit sparen lässt. Das Ableiten der Annotationen aus einer bestehenden Tabelle ist im Übrigen genau die Art mechanischer Arbeit, bei der KI-gestützte Entwicklung zuverlässig Zeit spart, weil sie kein Urteil, sondern Konsistenz verlangt.

Fazit

Nicht das System entscheidet über funktionierendes hreflang, sondern die Frage, ob Sprachumschalter, Kopfbereich und Sitemap aus derselben Zuordnung lesen. Eine Plugin-Lösung erzeugt die Annotationen automatisch und nimmt einem viel Arbeit ab, hängt aber vollständig an einer Übersetzungsbeziehung, die im Redaktionsalltag leise zerbrechen kann. Natives i18n nimmt einem gar nichts ab, macht die Zuordnung dafür zu einem sichtbaren Artefakt, das versioniert, geprüft und beim Deployment mitgetestet wird.

Beide Wege führen zum Ziel, und beide scheitern am selben Muster: an der zweiten Liste, die niemand mitpflegt. Wenn du an deinem Setup nur eine Sache änderst, dann die: Finde heraus, wie viele Stellen in deinem Projekt behaupten dürfen, welche englische Seite zu welcher deutschen gehört. Wenn die Antwort grösser als eins ist, hast du deinen nächsten Arbeitsschritt. Wenn du dabei Unterstützung brauchst, ist das eine der Fragen, mit denen wir als Web-Agentur regelmässig starten.