Should You Translate Your URLs? When It Helps and When It Costs You

Translated URLs are one of those multilingual decisions that look purely technical and turn out to be strategic. /fr/summer-dresses or /fr/robes-ete. It is a small difference on screen and a large one in consequences, because URLs are the part of a website that other people copy, link to and index.

The short answer is that translating them is usually right, that the gain is smaller than most guides claim, and that the cost of doing it carelessly on a live site is much larger than the gain.

What you actually gain

Words in a URL are a weak ranking signal. They have been weak for years, and anyone who tells you a translated slug will move you up the results page is selling something.

What translated URLs really buy you is trust and clickability. A French shopper scanning results sees a French address and reads it as a French site. Someone pasting your link into a message conveys what the page is about. In markets where the source language is not widely read, an untranslated URL reads as a machine-made subfolder of a foreign site, and that impression costs more clicks than the ranking signal was ever worth.

There is also an internal benefit that nobody mentions: your own team can read the analytics. A traffic report full of translated URLs is legible to the person running that market.

What it costs when you get it wrong

Changing a URL that already exists means every link to it, every index entry and every bookmark now points at something that must be redirected or is gone.

On a site with no history, that costs nothing. On a five-year-old store with backlinks, it is the single most common cause of a traffic drop after a multilingual project, and it is entirely avoidable.

Two rules cover almost every case.

Decide before launch, not after. Translating a slug on day one costs nothing. Translating it two years later costs a redirect plan.

If you change one, redirect it. Not a soft link from the sitemap. A real 301 from the old address to the new one, kept for as long as anything still points there, which is longer than you think.

The platform decides how dangerous this is

This is the part most guides skip, and it changes the risk completely.

PrestaShop, by default, protects you. Its standard routes carry the object ID: /3-clothes, /hommes/1-1-shirt.html. The front controller reads the ID, sees that the rewrite no longer matches, and redirects to the current address. Changing a product or category rewrite therefore does not produce a 404.

The exception is the static meta pages, whose rewrites carry no ID. Translate /content/1-delivery and the old address is a genuine 404. Those are exactly the pages that accumulate backlinks, so they are the ones that need the redirect.

WordPress does not protect you at all. A permalink is the address. Change a slug and the old URL is dead unless something redirects it. WordPress will sometimes guess its way to the new page, but that behaviour is not something to plan around, and it does not survive a slug that changed in a different language.

So the same decision is nearly free on one platform and needs a plan on the other. Any tool that changes URLs on a live site should be capturing the old addresses and serving redirects for them, and you should verify that it does before you let it run.

The case for not translating them

Three situations where leaving URLs alone is the better call.

Non-Latin scripts. Japanese, Chinese, Korean, Arabic, Thai. Transliteration produces addresses that are neither readable nor useful, and the usual automatic transliteration is worse than that: Japanese kanji frequently come out as Chinese pinyin, which is meaningless to a Japanese reader. Percent-encoded native characters are technically valid and hostile to read in a message or an email. Keep the Latin slug and put the effort into the title and the meta description, which is where a Japanese searcher actually looks.

Sites with heavy inbound links per page. A publisher with thousands of externally linked articles is taking on a large redirect surface for a small benefit. Translate new content's URLs, leave the archive alone.

Short-lived pages. Campaign pages, seasonal collections, anything you will delete in three months. Not worth the surface.

The mistakes that turn a good idea bad

Translating the language prefix. The /fr/ or /de/ segment is a code, not a word. Leave it. Some setups end up with /francais/ or a translated prefix that no longer matches the language definition, and the language detection stops working.

Letting slugs drift from titles. If a title is rewritten later and the slug follows automatically, you have silently changed a URL. Slugs should be sticky: generated once from the first title, then left alone unless you deliberately change them and redirect.

Duplicate slugs across languages. Two pages in different languages with the same translated slug can collide depending on how routing is configured. Most platforms handle it, some append a suffix, and the ones that do it silently produce addresses nobody intended.

Forgetting the sitemap and the hreflang tags. Both must carry the new addresses. If the sitemap still advertises the old slugs, you are asking search engines to crawl a redirect chain on every page.

A decision you can make in five minutes

Translate your URLs if: the site is new or the pages are new, your target market uses a Latin script, and the platform or tool captures redirects for anything that changes.

Leave them alone if: the script is non-Latin, the pages have real inbound links and no redirect plan, or the content is temporary.

And whichever you choose, apply it consistently. A store with half its categories translated and half not looks less deliberate than one that never translated any.

If you are moving from another multilingual setup and old addresses are already in the index, the sequence matters more than the decision itself. That is its own subject, covered in how to migrate a multilingual site without losing SEO.