Localized URLs Break hreflang. We Keep One English Slug Instead.
Most hreflang bugs on multilingual sites are not hreflang bugs. They are slug bugs. Translate the URL as well as the page and every rename, redirect and missing translation becomes a way for the language graph to fall apart, silently, on a subset of pages nobody is looking at.
We run this site in four languages and we deliberately do not translate slugs. The German page for AI visibility lives at /de/services/ai-visibility/, not at a German path. This is a real trade-off with a real cost, and we think it is the right one for most teams. Here is the reasoning, and the cost.
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. Every page in a language set must point at every other version, including itself, and every one of those pointers must be returned by the page it points at. A self-referencing hreflang is correct and required, 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.
The four failures localized slugs create
| 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 301s | The annotation is discounted, so the pages compete instead of grouping |
| 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 the keyword in the URL for every language except English. For a German buyer searching a German phrase, a German slug is a small, real relevance and click-through signal, and we are choosing not to have it.
We accept that for three reasons. The URL keyword is a weak signal compared with the title, headings and body, which are all fully translated. The failure mode it prevents is silent and compounding, while the benefit it costs is small and measurable. And on a site where answer engines matter as much as search engines, a predictable address is worth more than a keyword in a path.
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.
- 301 every localized slug to it, permanently. Leave those redirects in place; there is no good reason to ever remove them.
- Regenerate hreflang from the locale list rather than from a table, and confirm every page returns a self-reference.
- Resubmit the sitemap and ping the index-now endpoints so the change is picked up in days rather than months.
- 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
Translating the URL adds a per-document mapping table to a system that otherwise needs none, and every entry in that table is a chance for the language graph to break quietly.
Keep one language-independent slug, put the language in the path prefix, generate hreflang from the locale list, and gate translation parity in the build. You give up a weak keyword signal and you remove an entire class of silent failures.