URLs in Localization: How to structure and optimize for multilingual websites

Kinga Pomykała

•Published: July 03, 2025•Last updated: July 03, 2025•7 min read

When localizing a website, one of the first, and most overlooked, decisions you will make is how to handle URLs. It is not just a matter of aesthetics or convenience. Your URL structure directly affects SEO, user trust, and how easily people can find (and understand) your content in different languages.

In this post, we break down the most common URL strategies for multilingual sites, explain their impact on search and usability, and share practical tips to help you avoid costly mistakes down the road.

URL structures for localized content

Let's start with the building blocks. There are several ways to structure URLs when supporting multiple languages or regions. Each has trade-offs, technically, logistically, and from an SEO perspective.

Country Code Top-Level Domains (ccTLDs)

This method uses domain extensions tied to specific countries:

website.com  
website.pl  ← for Poland  
website.fr  ← for France  
website.es  ← for Spain

Why use ccTLDs?

Search engines treat each as a separate website, which sends strong location-based signals. Users also trust them more; a .fr domain feels more French.

Pros:

Excellent for country-specific SEO.
Builds regional trust and authority.
Great for large brands targeting distinct markets.

Cons:

Expensive and harder to maintain (hosting, SSLs, SEO strategies per domain).
Requires duplicate infrastructure.
More effort to keep UX and content consistent.

Example: Amazon uses ccTLDs for each market — amazon.de, amazon.co.uk, amazon.co.jp.

Subdirectories (a.k.a. Subfolders)

This is the most popular approach, and often the most practical:

website.com/en/  
website.com/pl/  
website.com/es/

Why use subdirectories?

They are simple to implement, centralize your domain authority, and make routing easier.

Pros:

Low maintenance, especially with a CMS or static site generator.
Shares SEO strength across languages.
Easier for analytics and infrastructure management.

Cons:

Weaker geotargeting compared to ccTLDs.
Some extra logic required in routing, especially if using locale-specific slugs.

Good fit for startups, SaaS platforms, and blogs looking to scale localization gradually.

Subdomains

Using subdomains is another option, where each language or region gets its own subdomain:

en.website.com
pl.website.com
es.website.com

Why use subdomains?

They offer separation without needing full-blown ccTLDs which is good for large projects with shared infrastructure.

Pros:

Clear content boundaries.
Can use different teams or systems for each language.
Flexible for different hosting configurations.

Cons:

Less SEO value than subdirectories (unless carefully optimized).
Additional DNS and configuration work.
May split link equity across subdomains.

Stack Overflow and Wikipedia use subdomains (es.stackoverflow.com, fr.wikipedia.org), maintaining distinct language communities.

Query parameters

Using query parameters is the least common approach for localization, where you append a language parameter to the URL:

website.com?lang=en
website.com?lang=pl
website.com?lang=es

It is technically valid, but discouraged for language targeting. Google and other search engines struggle to index and rank parameter-based URLs for localization.

Cons:

Weak SEO signals.
Can lead to duplicate content issues.
Less user-friendly, harder to link and share.

Google uses the 'hl' (host language) query parameter in its documentation, but they are the exception, not the rule.

Client- or server-side language detection

Some websites detect the user’s preferred language and serve localized content without changing the URL.

This is common in web apps and authenticated experiences, where user context is already known.

Why use it:

Good for behind-login content or personalized dashboards.
Can be layered with any of the structures above.
Reduces need for users to manually select a language.

Caution

Always give users control. Redirecting based on IP or browser language without an option to switch can frustrate users, and search engines.

Language vs. Locale in URLs

Instead of using language codes, you can also include locale information in your URLs. Locales are language-region combinations, such as en-US for English (United States) or fr-CA for French (Canada). Learn more about the difference between language codes and locale codes.

website.com/en-US/
website.com/en-GB/
website.com/fr-CA/

Locales allow for more precise targeting (e.g., Canadian French vs. European French). They are helpful when regional nuances matter — currency, spelling, date formats, etc.

Language and locale resources:

If you use locale-specific URLs (e.g. /es-es/ and /es-mx/), make sure to provide a general fallback like /es/ to support other Spanish speakers.

URLs and SEO: What you need to know

When it comes to SEO, search engines care about:

Unique content per URL
Consistent and descriptive structure
Proper use of hreflang and canonical tags

Hreflang tags

Let search engines know which versions of a page exist in which languages. This is done using the hreflang attribute in the <head> section of your HTML. It tells search engines about the language and regional targeting of your pages.

For example, if you have an English version and a Spanish version of a page, you would include:

<link rel="alternate" hreflang="en" href="https://website.com/en/article" />
<link rel="alternate" hreflang="es" href="https://website.com/es/article" />

Add hreflang tags in the <head> section of your HTML
Also possible via HTTP headers (for non-HTML files)
Or inside your XML sitemap

Learn more about hreflang in our What is hreflang and how to use it article.

What is hreflang="x-default"?

The hreflang="x-default" attribute is used to specify a default version of a page when no other language or regional version matches the user's preferences. Add it to your language selector or fallback pages, when no specific match is found.

Canonical URLs

Avoid duplicate content penalties. If content is nearly identical across locales, set the canonical tag:

<link rel="canonical" href="https://website.com/en/" />

Be especially careful when using automatic translations or locale variants (e.g., en-US vs. en-GB). If the content is the same, use canonical tags to point to the primary version.

Should you translate URL slugs?

Translating URLs is a question that often comes up when localizing websites.

Short answer: it depends.

website.com/en/about-us  
vs.  
website.com/pl/o-nas

Translated slugs:

Improve clarity for native speakers
Help with SEO for language-specific search queries
Build familiarity and trust

But they also:

Add complexity when managing links across languages
Increase the chance of inconsistencies or broken links
Require solid redirects and fallback logic

To sum up, translated URLs are nice-to-have but not a must-have. For sure, it is easier to manage URLs in one language, especially if you have a lot of content. However, if your target audience is primarily speakers of a specific language, translating URLs can improve user experience and SEO.

Ahrefs uses translated slugs for blog posts, but keeps main site URLs in English. A balanced approach.

Make switching languages easy

To make it easy for users to switch between languages, you should provide a clear language selector on your website. This can be a dropdown menu, a list of links, or a button that opens a modal with language options.

Do:

Display the current language clearly
Use the native name for each language (e.g. "Deutsch", not "German")
Respect user preferences via cookies or local storage

Use both source and target language names in the language selector for the best user experience. For example, show "English (Angielski)" or "Spanish (Hiszpański)" when switching from page in Polish.

Avoid:

Using flags as language indicators — they don't represent languagese (read more in our blog on flags in language selectors).
Auto-switching based on location/IP
Hiding the selector behind menus or icons that are not immediately obvious

For inspiration, see our post on language selector UI examples.

Practical tips

Prefer subdirectories unless you have a clear business case for ccTLDs or subdomains.
Implement hreflang and canonical tags correctly.
Keep your structure consistent across the site.
Use hyphens in URLs, avoid special characters or camelCase.
Translate slugs only when it adds value — don't overcomplicate.
Avoid machine-translated content — it hurts both SEO and trust.
Don't forget the extras: images, units, date formats — they speak, too.

Localization starts with the right URL

Setting up a multilingual site isn't just about translating text, it's about building a better experience for everyone, everywhere. And that starts with the structure you choose.

At SimpleLocalize, we help you go beyond copy-paste translation. Our platform makes it easier to manage language files, collaborate with translators, and launch multilingual projects that actually work, for people and search engines alike.