Lokalisierte URL-Slugs und hreflang: Warum wir einen englischen Slug behalten

Lokalisierte Slugs sind gültig. Ihr Preis ist die zusätzliche Zuordnungsschicht rund um hreflang. Googles Leitfaden für mehrsprachige Websites sagt ausdrücklich, dass lokalisierte Wörter in URLs in Ordnung sind. Umbenennungen, Redirects und fehlende Übersetzungen machen die Strategie nicht falsch, erzeugen aber mehr Zustände pro Dokument, die konsistent bleiben müssen.

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 technischer Trade-off für unsere Templates und Prüfungen, keine allgemeine Vorschrift.

Was hreflang tatsächlich verlangt

Der Vertrag ist einfacher, als das Tooling vermuten lässt. Googles hreflang-Dokumentation verlangt, dass jede Seite sich selbst und alle verfügbaren Versionen aufführt und jedes Ziel die Beziehung zurückgibt. Die Selbstreferenz gehört zum vollständigen Set.

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.

Vier Fehlerfälle, die ein lokalisiertes Slug-Mapping verhindern muss

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

Außerhalb des Englischen verlierst du einen lokalisierten, für Menschen leichter lesbaren Pfad. Die Adresse kann vor dem Öffnen weniger klar oder vertraut wirken.

Wir akzeptieren diese UX-Kosten, weil eine vorhersagbare Adresse unsere Templates, Prüfungen und maschinenlesbaren Spiegel vereinfacht. Google bestimmt die Seitensprache aus dem sichtbaren Inhalt und nicht aus der URL. Daher behandeln wir den englischen Slug weder als belegten Rankingnachteil noch den lokalisierten Slug als belegten Rankingvorteil.

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:

1. Wähle den englischen Slug als den kanonischen und halte ihn ab dann stabil. Die Umbenennung, die du jetzt machst, sollte die letzte sein.
2. Leite jeden alten lokalisierten Slug serverseitig permanent weiter, etwa mit 301 oder 308. Halte die Redirects mindestens ein Jahr; länger können sie Nutzern und externen Links weiterhelfen.
3. Erzeuge hreflang aus der Sprachliste statt aus einer Tabelle und prüfe, dass jede Seite eine Selbstreferenz zurückgibt.
4. Reiche die aktualisierte Sitemap in der Search Console ein und prüfe repräsentative oder wichtige URLs mit der URL-Prüfung. Googles Leitfaden für URL-Umzüge verspricht keinen festen Zeitraum.
5. 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.