Should You Translate URL Slugs on a Multilingual Site?

Short answer: Translating URL slugs is usually worth it: a German page at /de/preise/ is clearer to German readers than /de/pricing/, and the local words can appear in search results and shared links. It is not a strong ranking factor on its own, so do not rename established URLs just for this. Pick one rule per language, handle accents and non-Latin scripts consistently, and when you change a slug, redirect the old URL and update hreflang, canonicals and internal links.

What a slug is and why language matters

The slug is the part of a URL that identifies a specific page, such as pricing in example.com/de/pricing/. On a multilingual site, each language version has its own URL, usually with a language folder in front. The question is whether the slug after that folder should be in the page’s language or stay in the original language.

There are three common patterns:

• Translated slugs: /de/preise/, /fr/tarifs/, /es/precios/.
• Original slugs everywhere: /de/pricing/, /fr/pricing/, /es/pricing/.
• IDs or codes: /de/p/1234/, common on some shop platforms.

All three work technically. Search engines can index and rank pages under any of them, and hreflang connects versions regardless of slug. The differences are in readability, trust, click behaviour and maintenance.

The case for translating slugs

Translating slugs has several practical benefits:

• Readability. A local reader understands what the page is about before clicking. That matters in shared links, emails, chat messages and anywhere the URL is shown without a title.
• Consistency. A fully German page with an English URL looks unfinished. Translated slugs complete the impression of a real local site.
• Search result display. Search engines sometimes show a breadcrumb-like path derived from the URL. Local words there reinforce that the result is in the searcher’s language.
• A small relevance hint. Words in URLs are a minor signal. Google has described them as a very lightweight factor, so the effect on rankings is small, but it is not zero.

The main benefit is for people, not algorithms. A clear, local URL is one more detail that makes a translated site feel native.

The case for keeping original slugs

There are also reasons to keep slugs in the original language:

• Simplicity. One slug per page across languages makes mapping, reporting and debugging easier. A developer can see at a glance that /de/pricing/ and /fr/pricing/ are the same page.
• Platform limits. Some platforms do not support translated slugs, or only through workarounds that create other problems.
• Existing URLs. If a language version has been live for years with original slugs, changing them means redirects for every page and a temporary period of re-evaluation.
• Technical content. For developer documentation or product names that are the same in every language, the original slug may already be the most natural choice.

If you keep original slugs, the rest of the page still needs to be fully localized. The slug is one of the least important elements to translate; titles, headings and content matter far more.

Accents, special characters and non-Latin scripts

Once you decide to translate slugs, you need a rule for characters outside plain ASCII letters:

Search engines handle all of these. The best choice depends on your audience and tools. Many European sites transliterate accents for simplicity; many sites in Japanese, Chinese, Arabic or Cyrillic markets use native characters because local users expect them. Whatever you choose, apply it consistently within each language and make sure your CMS, CDN, analytics and redirect rules handle encoded characters correctly.

Rules that make slugs work in every language

1. Keep them short and descriptive, using the main local term for the page, not a literal translation of a long English slug.
2. Use hyphens between words in every language, and lowercase for Latin scripts.
3. Avoid stop words where the slug remains clear without them.
4. Use the researched local keyword, not the translator’s first choice. The slug should match what local people call the thing.
5. Avoid dates and version numbers in slugs of pages you will update.
6. Do not reuse the same slug for different pages in different languages; it confuses reporting.

Slugs for country versions that share a language

Sites with several versions in one language, such as English for the US, the UK and Australia, face a smaller version of the same question. Should the UK page use British spelling in its slug, for example /en-gb/colour-guide/ instead of /en-gb/color-guide/?

There is no strict rule, but a few principles help:

• Match the spelling of the page. If the UK page uses “colour” in its title and headings, a slug with “color” looks inconsistent to British readers.
• Keep structure identical. The folder and page hierarchy should be the same across country versions, even if individual words differ. That keeps mapping and reporting manageable.
• Do not create differences for their own sake. Most slugs will be identical across English variants, and that is fine. Change only the words that genuinely differ.

The same applies to Spanish for Spain and Latin America, Portuguese for Portugal and Brazil, and French or German across countries. Local vocabulary in the slug is a nice touch where the words really differ, such as “ordenador” versus “computadora” for computer, but it is secondary to getting the page content right.

Whatever you decide, document the rule for each language in your style guide, so translators and editors create new slugs the same way. Inconsistent slugs rarely cause ranking problems, but they make the site harder to maintain and to audit over time.

Changing slugs on an existing site

If you decide to translate slugs on a site that already has original-language URLs, treat it as a small migration:

1. Map old to new URLs for every affected page, in every language.
2. Set up 301 redirects from each old URL to its new URL, one hop, no chains.
3. Update hreflang on every version so all alternates point to the new URLs. This is where errors are most likely; if one language still lists the old URL, it points to a redirect and the return link fails.
4. Update canonical tags to the new URLs.
5. Update internal links, menus and the language switcher, so they point directly to new URLs instead of through redirects.
6. Regenerate XML sitemaps with the new URLs only.
7. Crawl and monitor to confirm there are no chains, 404s or hreflang errors, and watch traffic for that language for several weeks.

Expect a temporary fluctuation while search engines process the changes. For a large, well-performing language version, weigh that risk against the modest benefit. For a new or small version, the change is usually low-risk.

Slugs in WordPress and other CMS

In WordPress, multilingual plugins generally let you set a slug per translation, and many generate it automatically from the translated title. That automatic slug is a good start but often too long; editing it to the main local keyword is quick. Category and tag slugs need translating too, along with the base slugs of custom post types if your plugin supports that.

When a translator changes a slug after publishing, most plugins update hreflang automatically, but not all create redirects. A redirect plugin or server rule is often needed so the old URL does not become a 404.

How to check slugs and related URLs

A crawl shows whether slug changes left problems behind: internal links to redirects, redirect chains, hreflang pointing to old URLs and sitemap entries that no longer resolve. Site SEO AI Audit reports these in its crawl, Links and Languages areas, weighted by how many pages they affect, and on WordPress sites gives the steps to fix them in wp-admin. You can audit your site free before and after a slug change.

Related reading

• Translation vs localization for SEO: what actually changes
• hreflang return links: how to fix “no return tags” errors
• SEO-friendly URLs: how to write clean page slugs
• Redirect chains and loops: how to find and fix them

The bottom line

Translated slugs make multilingual sites clearer and more trustworthy for local readers, with a small relevance benefit. They are the right default for new language versions. For established URLs, change them only when the benefit outweighs the migration effort, and when you do, redirect every old URL and update hreflang, canonicals, internal links and sitemaps in the same release.

FAQ

Do translated URLs help rankings?

Only slightly. Words in URLs are a minor signal. The main benefit is clarity for local readers in search results and shared links.

Can I use accented characters in URLs?

Yes. Browsers and search engines support them, but they are percent-encoded when copied in some tools. Transliterating to plain letters is simpler; keeping accents looks more natural. Choose one approach per language.

Should different language versions share the same slug?

They can, but translated slugs are usually clearer for readers. If you use the same slug everywhere, make sure the rest of each page is fully localized.

What happens to hreflang when I change a slug?

Every other language version must be updated to point to the new URL. If any still lists the old URL, it points to a redirect and the return link fails.

Should I translate category and tag slugs too?

Yes, for consistency. Archive pages are often indexed and linked, so their URLs should follow the same rule as posts and pages.