Jakob SEO
Back to blog
SEO//5 min read

Should you translate URL slugs on a multilingual site?

When a page exists in several languages, should /en/rooms become /fr/chambres, or stay /fr/rooms? Translate the descriptive parts of the path, keep names stable, and never move a live URL without a redirect.

Pick a language
Recommended
/fr/chambres/pineapple
Section · translatedName · stays stable
Avoid
/fr/rooms/pineapple

The section translates with the language. The name stays identical in every locale.

Every multilingual site hits the same fork in the road. The same page exists in several languages, so what happens to the words in the URL when the language changes? Do you translate the path so an English /rooms becomes a French /chambres, or do you keep one language for the path and only switch the content?

The short answer: translate the descriptive parts of the path, but leave names alone. The longer answer is worth a few minutes, because getting it wrong creates redirect debt and confuses search engines.

Translate the words people would actually search

Google recommends using words in the audience’s language in the URL when possible, and for multilingual sites it recommends a distinct URL per language paired with hreflang annotations. The URL is part of the search snippet, so a French visitor scanning results trusts /fr/chambres more than /fr/rooms. It reads as a page written for them.

There is a small ranking upside too: a translated slug carries the translated keyword, which can pick up long-tail relevance for the term real users type. It is a minor signal, but it points the same direction as user trust.

But don't translate everything

Names are identifiers, not descriptions. The name of a product, a plan, a room, or a brand should stay the same in every language. Translating a name like "pineapple" into "ananas" in French and Italian but not in German creates noise, multiplies the redirects you have to maintain, and quietly breaks every shared or bookmarked link that used the old spelling.

So the clean pattern is to translate the bucket and keep the leaf stable: /[locale]/[translated-section]/[stable-name]. The section that describes what the page is gets translated; the name that identifies which one it is stays put.

What to translate, what to leave alone

Translate the descriptive sections people read as categories: rooms, pricing, location, contact, faq, gallery. Keep stable: entity and product names, and blog slugs — unless you genuinely rewrite each article per language, in which case a translated slug per version is fine.

hreflang and canonical do the wiring

Whatever slugs you choose, you still have to tell search engines that these pages are translations of one another. That is what hreflang does: each language version links to all the others, with an x-default for the fallback, and each version is its own canonical. This is what keeps Google from treating the translations as duplicate content and lets it serve the right language to the right user.

The one hard rule: never move a live URL without a redirect

If you switch an existing site to translated slugs, every old URL you change needs a 301 (or 308) redirect to its new path. Skip that and bookmarks, backlinks, and already-indexed pages all dead-end on a 404, and the relevance the old URL had earned does not carry over. The redirect map is the bridge between the addresses the internet already knows and the new ones where the pages actually live.

The takeaway

Translate the descriptive parts of the path, keep names stable, wire the versions together with hreflang, and redirect anything you move. Do that and your URLs read naturally in every language without turning into a maintenance burden.