--- title: "Lokalisierte URLs zerlegen hreflang: ein englischer Slug genügt" canonical: https://wavect.io/de/blog/english-slugs-vs-localized-urls-hreflang/ language: de description: "Übersetzte URL-Slugs fügen eine Mapping-Tabelle pro Dokument und eine Klasse stiller hreflang-Fehler hinzu. Das Argument für einen sprachunabhängigen Slug, inklusive Trade-off." image: "https://wavect.io/img/blog/headers/header_english-slugs-vs-localized-urls-hreflang.png" --- [**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 18. August 2026 [**Weiter**](/de/blog/can-an-ai-agent-use-your-product/) # 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. ## 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](/de/blog/agent-readable-website-llms-txt-markdown-mirrors/) 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: 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. 301 jeden lokalisierten Slug dauerhaft darauf. Lass diese Redirects stehen; es gibt keinen guten Grund, sie je zu entfernen. 3. Erzeuge hreflang aus der Sprachliste statt aus einer Tabelle und prüfe, dass jede Seite eine Selbstreferenz zurückgibt. 4. Reiche die Sitemap neu ein und pinge die IndexNow-Endpoints, damit die Änderung in Tagen statt Monaten ankommt. 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? 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. ## 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 ## In diesem Cluster weiterlesen Coding Agents, MCP, Kontextsysteme, Evaluation und Kontrollen für verlässliche Automatisierung. [Mit dem Grundlagenartikel starten**Graph Engineering für KI-Agenten: Wann lohnt sich ein Knowledge Graph?**](/de/blog/graph-engineering-ai-agents/) - [Agentenlesbare Websites: llms.txt, Markdown-Spiegel und was kaputtgeht](/de/blog/agent-readable-website-llms-txt-markdown-mirrors/) - [Kann ein KI-Agent dein Produkt benutzen, oder nur darüber lesen?](/de/blog/can-an-ai-agent-use-your-product/) - [Graft Review 2026: Gehört die Repo-Map ins Git?](/de/blog/graft-review-agent-repo-map/) - [Wie du Coding-Agenten mit Tool-Ausgabe-Kompression skalierbar machst](/de/blog/codag-cost-control/) - [Intelligenterer Token-Einsatz mit deinem AI-Coding-Agenten](/de/blog/smarter-token-usage-with-your-ai-coding-agent/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**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 18. August 2026 [**Weiter**](/de/blog/can-an-ai-agent-use-your-product/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/english-slugs-vs-localized-urls-hreflang/#webpage", "@type": "WebPage", "dateModified": "2026-08-18", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-18", "url": "https://wavect.io/de/blog/english-slugs-vs-localized-urls-hreflang/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "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.", "articleBody": " Blog-Übersicht/AI und Agents/Agent Engineering 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. 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 FehlerWas ihn auslöstSymptom Gebrochene ReziprozitätDer Slug einer Sprache wurde umbenannt, die anderen zeigen noch auf den alten StringDas Sprachcluster spaltet sich in zwei Cluster, die beide autoritativ aussehen hreflang auf einen RedirectAnnotationen zeigen auf die URL von vor der Umbenennung, die jetzt 301 liefertDie Annotation wird abgewertet, die Seiten konkurrieren statt zu gruppieren Teilweise ÜbersetzungEine Sprache hat noch keine Version dieses DokumentsEntweder ein toter Verweis oder eine stille Lücke, je nachdem, wie die Schleife geschrieben wurde PfadkollisionenZwei englische Dokumente übersetzen zum selben Slug in der ZielspracheEine 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", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-08-18", "datePublished": "2026-08-18", "description": "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.", "headline": "Lokalisierte URLs zerlegen hreflang: ein englischer Slug genügt", "image": "https://wavect.io/img/blog/headers/header_english-slugs-vs-localized-urls-hreflang.svg", "inLanguage": "de", "keywords": "KI-Sichtbarkeit, Mehrsprachigkeit", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/english-slugs-vs-localized-urls-hreflang/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/english-slugs-vs-localized-urls-hreflang/", "wordCount": 1562 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/agent-engineering/", "name": "Agent Engineering", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/english-slugs-vs-localized-urls-hreflang/", "name": "Lokalisierte URLs zerlegen hreflang: ein englischer Slug genügt | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Sollen URL-Slugs für jede Sprache übersetzt werden?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Ist ein selbstreferenzierendes hreflang-Tag erforderlich?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Schadet ein englischer Slug den lokalen Rankings?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Was, wenn eine Seite noch nicht in jede Sprache übersetzt ist?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Wie verhindern wir, dass Übersetzungen auseinanderdriften?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Müssen wir die alten lokalisierten URLs am Leben halten?" } ] } ```