--- title: "Lokalisierte URL-Slugs und hreflang: unser Shared-Slug-Trade-off" canonical: https://wavect.io/de/blog/english-slugs-vs-localized-urls-hreflang/ language: de description: "Lokalisierte URL-Slugs sind gültig, erfordern aber Zuordnungen pro Dokument. Das Argument für einen sprachunabhängigen Slug und der ehrliche Trade-off." image: "https://wavect.io/img/blog/headers/header_english-slugs-vs-localized-urls-hreflang.png" author: ["Kevin Riedl"] published: "2026-08-18" updated: "2026-09-02" reviewed: "2026-09-02" --- # Lokalisierte URL-Slugs und hreflang: Warum wir einen englischen Slug behalten [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 7 min Lesezeit · 18. Aug 2026 Zuletzt geprüft 2. September 2026 [**Weiter**](/de/blog/can-an-ai-agent-use-your-product/) TL;DR Google erlaubt lokalisierte Wörter in URLs, und lokalisierte Slugs beschädigen hreflang nicht grundsätzlich. Der operative Preis ist die Zuordnungsschicht: Jede Seite eines Sprachsets muss sich selbst und alle verfügbaren Alternativen aufführen, während jede Alternative die Beziehung zurückgeben muss. Eine korrekte Slug-Zuordnung pro Dokument kann diesen Vertrag erfüllen, muss aber Umbenennungen, Redirects, fehlende Übersetzungen und Pfadkollisionen zusätzlich absichern. Wir behalten einen sprachunabhängigen Slug, weil Templates die Alternativen dann aus dem Sprachpräfix ableiten und der Build Übersetzungsmengen über einen gemeinsamen Schlüssel vergleichen kann. Das ist eine technische Entscheidung, keine allgemeine SEO-Regel. Der Trade-off ist außerhalb des Englischen ein weniger lokalisierter, weniger lesbarer Pfad. Google bestimmt die Seitensprache laut eigener Dokumentation aus dem sichtbaren Inhalt, nicht aus der URL. Deshalb behaupten wir für keine der beiden Strategien einen direkten Rankingeffekt. **Lokalisierte Slugs sind gültig. Ihr Preis ist die zusätzliche Zuordnungsschicht rund um hreflang.** Googles [Leitfaden für mehrsprachige Websites](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) 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](https://developers.google.com/search/docs/specialty/international/localized-versions) 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 | 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](/de/blog/agent-readable-website-llms-txt-markdown-mirrors/) 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](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) 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. ## Häufige Fragen ### Sollen URL-Slugs für jede Sprache übersetzt werden? Das ist möglich. Ein lokalisierter Pfad kann für Menschen klarer sein, während ein sprachunabhängiger Slug Zuordnung und Prüfung vereinfacht. Wähle das Modell, das dein Routing- und Publishing-System zuverlässig korrekt 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? Google erkennt die Seitensprache laut Dokumentation aus dem sichtbaren Inhalt und erlaubt lokalisierte URL-Wörter. Wir haben keinen belastbaren Beleg für einen automatischen Rankingnachteil durch einen gemeinsamen englischen Slug gefunden. Teste die Nutzerreaktion in deinem Markt. ### 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? Google empfiehlt Redirects für mindestens ein Jahr. Länger können sie weiterhin Nutzern und externen Links dienen, die noch die alte Adresse verwenden. ## Fazit Lokalisierte Slugs werden unterstützt und können Pfade für Leser klarer machen. Sie brauchen zugleich ein zuverlässiges Mapping pro Dokument, wenn sich alternative URLs zwischen Sprachen unterscheiden. Für unsere Website mit vier Sprachen vereinfacht ein sprachunabhängiger Slug die hreflang-Erzeugung und die Prüfung der Übersetzungsparität. Das ist unser technischer Trade-off, keine Regel für jede mehrsprachige Website. ## Das könnte dich auch interessieren.. [**Agentenlesbare Websites: llms.txt und Markdown-Spiegel** Die vier Oberflächen, die entscheiden, ob eine Answer Engine dich lesen kann, und die Konvertierungsfehler, die ein Gate braucht.](/de/blog/agent-readable-website-llms-txt-markdown-mirrors/) [**Wavect vs generalistische Dev-Agentur** Wo sich die Arbeit überlappt und wo Preismodell und Scope-Ownership es nicht tun.](/de/compare/wavect-vs-dev-agencies/) Agent Engineering ## Weiterlesen Coding Agents, MCP, Kontextsysteme, Evaluation und Kontrollen für verlässliche Automatisierung. [Hier starten**Graph Engineering für KI-Agenten: Wann lohnt sich ein Knowledge Graph?**](/de/blog/graph-engineering-ai-agents/) - [RTK AI 1.0: Token-Ersparnis, Einrichtung und Lizenzen](/de/blog/rtk-ai-token-savings-review/) - [Anatomy für Claude Code: Interaktive SVG für die Dokumentation](/de/blog/anatomy-claude-code-interactive-svg/) - [Google AX: Suspend/Resume, Neustartkosten und Selbsthosting](/de/blog/google-ax-agent-executor-security-self-hosting/) - [WikiSkill: Wie Agenten SKILL.md aus Erfahrung weiterentwickeln](/de/blog/wikiskill-self-evolving-agent-skills/) - [Tencent Octop im Review: Was Entwickler tatsächlich kostenlos bekommen](/de/blog/tencent-octop-ai-assistant-review/) [Vorheriger Artikel**Agentenlesbare Websites: llms.txt, Markdown-Spiegel und was kaputtgeht**](/de/blog/agent-readable-website-llms-txt-markdown-mirrors/) [Nächster Artikel**Kann ein KI-Agent dein Produkt benutzen, oder nur darüber lesen?**](/de/blog/can-an-ai-agent-use-your-product/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 7 min Lesezeit · 18. Aug 2026 Zuletzt geprüft 2. September 2026 [**Weiter**](/de/blog/can-an-ai-agent-use-your-product/)