In this piece
Localized URL Slugs vs hreflang: Why We Keep One English Slug
Localized slugs are valid. Their cost is the extra mapping layer around hreflang. Google's multilingual-site guidance explicitly says localized words in URLs are fine. Renames, redirects and missing translations do not make the strategy wrong, but they create more per-document states to keep aligned.
We run this site in four languages and deliberately do not translate slugs. The German page for AI visibility lives at /de/services/ai-visibility/, not at a German path. This is an engineering trade-off that suits our templates and validation gates, not a universal prescription.
Running a multi-market site and not sure what a crawler actually sees per language?
Run the free checkerWhat hreflang actually demands
The contract is simpler than the tooling suggests. Google's hreflang documentation says every page in a language set must list itself and every other available version, and each target must return the relationship. A self-reference is part of the complete set, not a redundancy to optimise away.
That reciprocity requirement is where localized slugs get expensive. With one slug you need to know the language prefixes. With translated slugs you need a correct, current mapping table between four different strings per document, and you need it to survive every edit anyone makes.
Four failure modes a localized-slug mapping must prevent
| Failure | What causes it | Symptom |
|---|---|---|
| Broken reciprocity | One locale's slug was renamed, the others still point at the old string | The language cluster splits into two clusters that each look authoritative |
| hreflang to a redirect | Annotations point at the pre-rename URL, which now redirects | The annotation points at a non-final URL and becomes harder to validate |
| Partial translation | A locale has no version of this document yet | Either a dangling pointer or a silent gap, depending on how the loop was written |
| Path collisions | Two English documents translate to the same target-language slug | One page overwrites the other, usually noticed by a customer |
None of these is unfixable. All of them are per-document, which is the problem: they appear on a handful of pages rather than site-wide, so a spot check looks clean.
What one slug buys you
If the slug is language-independent, the language graph becomes a function of the path prefix. The template can generate every hreflang pointer from the locale list and the page's own file name, with no mapping table to maintain and nothing to drift out of sync. Reciprocity is structural rather than something you verify.
It also makes the neighbouring checks cheap. Once every locale's version of a document shares a slug, "is this document translated everywhere?" is a set comparison over file names. We gate that in the build: one script asserts that the four locales contain the same entry sets for every data file, and another compares per-locale content for drift. Both are only possible because the identifier is shared.
The same property helps machines that are not search engines. An agent that has your English URL can construct the German one by rule. Combined with a Markdown mirror per route, that means one predictable address per document per language, with no lookup step.
The honest cost
You lose a localized, human-readable path in every language except English. That can make the address less clear or familiar to a reader before they open it.
We accept that user-experience cost because a predictable address simplifies our templates, validation and machine-readable mirrors. Google says it determines a page's language from visible content rather than the URL, so we do not treat the English slug as a proven ranking penalty or the localized slug as a proven ranking boost.
If your business is primarily local-language search in one market and you have two dozen pages, translate the slugs. The mapping stays small enough to keep correct by hand. The argument here is about what happens at four languages and several hundred routes, where nobody keeps a mapping table correct by hand.
Migrating without losing the pages you have
If you already have localized slugs, this is not urgent and it is not free. When you do it:
- Pick the English slug as the canonical one and keep it stable from then on. The rename you do now should be the last one.
- Use server-side permanent redirects, such as 301 or 308, from every old localized slug. Keep them for at least one year; retaining them longer can still help users and external links.
- Regenerate hreflang from the locale list rather than from a table, and confirm every page returns a self-reference.
- Submit the updated sitemap in Search Console and use URL Inspection for representative or important URLs. Google's URL-move guidance does not promise a fixed discovery timeline.
- Check that internal links point at the new slug directly rather than through the redirect, because a site full of internal 301s is its own slow problem.
Step five is the one people skip. A redirect that is only reachable from your own navigation is a redirect you will never notice is wrong.
Frequently Asked Questions
Should URL slugs be translated for each language?
Is a self-referencing hreflang tag required?
Does an English slug hurt local rankings?
What if a page is not translated into every language yet?
How do we keep translations from drifting apart?
Do we need to keep the old localized URLs working?
Final thoughts
Localized slugs are supported and can make paths clearer to readers. They also require a reliable per-document mapping when alternate URLs differ across languages.
For our four-locale site, one language-independent slug makes hreflang generation and translation-parity checks simpler. That is our engineering trade-off, not a rule every multilingual site must follow.