Lokalisierte URLs zerlegen hreflang. Wir behalten stattdessen einen englischen Slug.

TL;DR

Die meisten hreflang-Defekte auf mehrsprachigen Websites entstehen daraus, die URL zu übersetzen, und nicht aus den Annotationen selbst. hreflang verlangt, dass jede Seite eines Sprachsets auf jede Version zeigt, auch auf sich selbst, und dass jeder Verweis von seinem Ziel zurückgegeben wird. Mit übersetzten Slugs hängt diese Reziprozität an einer korrekten, aktuellen Mapping-Tabelle zwischen mehreren Strings pro Dokument, was vier wiederkehrende Fehler erzeugt: gebrochene Reziprozität nach einer Umbenennung, Annotationen, die auf Redirects zeigen, tote Verweise, wo eine Übersetzung noch fehlt, und Pfadkollisionen, wenn zwei Dokumente zum selben Slug übersetzen. Alle vier treten pro Dokument auf und nicht site-weit, Stichproben sehen also sauber aus. Ein sprachunabhängiger Slug macht den Sprachgraph zu einer Funktion des Pfadpräfixes, hreflang lässt sich damit ohne Tabelle aus der Sprachliste erzeugen, und Übersetzungsparität wird ein Mengenvergleich, den ein Build-Gate erzwingen kann. Der Preis ist echt: du verlierst das URL-Keyword in jeder Sprache außer Englisch. Das ist ein schwaches Signal neben vollständig übersetzten Titeln, Überschriften und Body und bei vier Sprachen und mehreren hundert Routen den Tausch wert. Bei einer kleinen Website in einem Markt übersetze die Slugs.

Die meisten hreflang-Bugs auf mehrsprachigen Websites sind keine hreflang-Bugs. Es sind Slug-Bugs. Übersetze die URL zusätzlich zur Seite, und jede Umbenennung, jeder Redirect und jede fehlende Übersetzung wird zu einem Weg, auf dem der Sprachgraph auseinanderfällt: still, und auf einer Teilmenge von Seiten, auf die niemand schaut.

Wir betreiben diese Website in vier Sprachen und übersetzen Slugs bewusst nicht. Die deutsche Seite zu KI-Sichtbarkeit liegt unter /de/services/ai-visibility/, nicht unter einem deutschen Pfad. Das ist ein echter Trade-off mit echten Kosten, und wir halten ihn für die richtige Entscheidung für die meisten Teams. Hier ist die Begründung, und der Preis.

Du betreibst eine Website für mehrere Märkte und weißt nicht, was ein Crawler pro Sprache wirklich sieht?

Kostenlosen Checker starten

Was hreflang tatsächlich verlangt

Der Vertrag ist einfacher, als das Tooling vermuten lässt. Jede Seite eines Sprachsets muss auf jede andere Version zeigen, auch auf sich selbst, und jeder dieser Verweise muss von der Seite zurückgegeben werden, auf die er zeigt. Ein selbstreferenzierendes hreflang ist korrekt und erforderlich und keine Redundanz, die man wegoptimiert.

Genau diese Reziprozität macht lokalisierte Slugs teuer. Mit einem Slug musst du die Sprachpräfixe kennen. Mit übersetzten Slugs brauchst du eine korrekte, aktuelle Mapping-Tabelle zwischen vier verschiedenen Strings pro Dokument, und die muss jede Änderung überleben, die irgendwer macht.

Die vier Fehler, die lokalisierte Slugs erzeugen

Fehler	Was ihn auslöst	Symptom
Gebrochene Reziprozität	Der Slug einer Sprache wurde umbenannt, die anderen zeigen noch auf den alten String	Das Sprachcluster spaltet sich in zwei Cluster, die beide autoritativ aussehen
hreflang auf einen Redirect	Annotationen zeigen auf die URL von vor der Umbenennung, die jetzt 301 liefert	Die Annotation wird abgewertet, die Seiten konkurrieren statt zu gruppieren
Teilweise Übersetzung	Eine Sprache hat noch keine Version dieses Dokuments	Entweder ein toter Verweis oder eine stille Lücke, je nachdem, wie die Schleife geschrieben wurde
Pfadkollisionen	Zwei englische Dokumente übersetzen zum selben Slug in der Zielsprache	Eine Seite überschreibt die andere, meist bemerkt von einem Kunden

Keiner davon ist unlösbar. Alle sind pro Dokument, und genau das ist das Problem: sie treten auf einer Handvoll Seiten auf und nicht site-weit, eine Stichprobe sieht also sauber aus.

Was ein einziger Slug dir bringt

Ist der Slug sprachunabhängig, wird der Sprachgraph zu einer Funktion des Pfadpräfixes. Das Template kann jeden hreflang-Verweis aus der Sprachliste und dem eigenen Dateinamen der Seite erzeugen, ohne Mapping-Tabelle und ohne etwas, das aus dem Takt geraten kann. Reziprozität wird strukturell, statt etwas, das du prüfen musst.

Es macht auch die Nachbarchecks günstig. Sobald jede Sprachversion eines Dokuments denselben Slug teilt, ist „ist dieses Dokument überall übersetzt?“ ein Mengenvergleich über Dateinamen. Das sichern wir im Build ab: ein Skript stellt sicher, dass die vier Sprachen für jede Datendatei dieselben Eintragsmengen enthalten, ein zweites vergleicht die Inhalte pro Sprache auf Drift. Beides ist nur möglich, weil der Identifier geteilt ist.

Dieselbe Eigenschaft hilft Maschinen, die keine Suchmaschinen sind. Ein Agent mit deiner englischen URL kann die deutsche per Regel konstruieren. Zusammen mit einem Markdown-Spiegel pro Route heißt das: eine vorhersagbare Adresse pro Dokument und Sprache, ohne Nachschlageschritt.

Die ehrlichen Kosten

Du verlierst das Keyword in der URL für jede Sprache außer Englisch. Für einen deutschen Käufer, der eine deutsche Phrase sucht, ist ein deutscher Slug ein kleines, echtes Relevanz- und Klickratensignal, und wir entscheiden uns dafür, es nicht zu haben.

Das nehmen wir aus drei Gründen hin. Das URL-Keyword ist ein schwaches Signal im Vergleich zu Titel, Überschriften und Body, die alle vollständig übersetzt sind. Der Fehlerfall, den es verhindert, ist still und kumuliert sich, während der Nutzen, den es kostet, klein und messbar ist. Und auf einer Website, auf der Answer Engines genauso zählen wie Suchmaschinen, ist eine vorhersagbare Adresse mehr wert als ein Keyword im Pfad.

Wenn dein Geschäft primär Suche in einer Landessprache in einem Markt ist und du zwei Dutzend Seiten hast, übersetze die Slugs. Das Mapping bleibt klein genug, um es von Hand korrekt zu halten. Das Argument hier gilt für vier Sprachen und mehrere hundert Routen, wo niemand eine Mapping-Tabelle von Hand korrekt hält.

Migrieren, ohne die vorhandenen Seiten zu verlieren

Wenn du schon lokalisierte Slugs hast, ist das nicht dringend und nicht kostenlos. Wenn du es machst:

Wähle den englischen Slug als den kanonischen und halte ihn ab dann stabil. Die Umbenennung, die du jetzt machst, sollte die letzte sein.
301 jeden lokalisierten Slug dauerhaft darauf. Lass diese Redirects stehen; es gibt keinen guten Grund, sie je zu entfernen.
Erzeuge hreflang aus der Sprachliste statt aus einer Tabelle und prüfe, dass jede Seite eine Selbstreferenz zurückgibt.
Reiche die Sitemap neu ein und pinge die IndexNow-Endpoints, damit die Änderung in Tagen statt Monaten ankommt.
Prüfe, dass interne Links direkt auf den neuen Slug zeigen und nicht durch den Redirect, denn eine Website voller interner 301 ist ihr eigenes langsames Problem.

Schritt fünf ist der, den man überspringt. Ein Redirect, der nur über deine eigene Navigation erreichbar ist, ist ein Redirect, bei dem du nie merkst, dass er falsch ist.

Häufige Fragen

Sollen URL-Slugs für jede Sprache übersetzt werden?

Bei einer kleinen Website in einer oder zwei Sprachen ja, das Keyword lohnt sich und das Mapping bleibt handhabbar. Ab einigen hundert Routen und drei oder mehr Sprachen ist ein sprachunabhängiger Slug pro Dokument robuster, weil hreflang-Reziprozität dann aus dem Pfadpräfix folgt und nicht aus einer Tabelle, die niemand aktuell hält.

Ist ein selbstreferenzierendes hreflang-Tag erforderlich?

Ja. Jede Seite eines Sprachsets muss jede Version auflisten, auch sich selbst. Es ist nicht redundant, und es zu entfernen ist eine häufige Ursache dafür, dass ein Sprachcluster ignoriert wird.

Schadet ein englischer Slug den lokalen Rankings?

Leicht, und das sagen wir offen. Du verlierst ein schwaches Relevanz- und Klickratensignal in der Zielsprache. Titel, Überschriften und Body wiegen deutlich mehr und bleiben vollständig übersetzt, deshalb halten wir den Tausch bei größerem Umfang für sinnvoll.

Was, wenn eine Seite noch nicht in jede Sprache übersetzt ist?

Gib hreflang nur für die existierenden Versionen aus und zeige nie auf eine URL, die fehlt oder weiterleitet. Eine tote Annotation ist schlimmer als keine.

Wie verhindern wir, dass Übersetzungen auseinanderdriften?

Mach den geteilten Slug zum Join-Key und prüfe ihn im Build. Wir stellen sicher, dass alle vier Sprachen für jede Datendatei dieselben Eintragsmengen enthalten, und vergleichen die Inhalte pro Sprache auf Drift. Beide Checks hängen daran, dass der Identifier über Sprachen hinweg geteilt ist.

Müssen wir die alten lokalisierten URLs am Leben halten?

Ja, dauerhaft. 301 sie auf den kanonischen Slug und lass die Redirects stehen. Externe Links und Zitate werden nicht aktualisiert, und eine kaputte alte URL ist eine verlorene Referenz.

Fazit

Die URL zu übersetzen fügt einem System eine Mapping-Tabelle pro Dokument hinzu, das sonst keine braucht, und jeder Eintrag darin ist eine Chance, dass der Sprachgraph still bricht.

Behalte einen sprachunabhängigen Slug, steck die Sprache ins Pfadpräfix, erzeuge hreflang aus der Sprachliste und sichere Übersetzungsparität im Build ab. Du gibst ein schwaches Keyword-Signal auf und entfernst eine ganze Klasse stiller Fehler.