When designing a website that can be viewed in multiple languages, should I put the language in the urls? Like:


Or alternatively, should I put it somewhere in the session or cookies?

I can think of a few differences. If I include it in the url:

  • If I send a page to a friend from another country, he'll see the page in my language. Which may be good (exactly the same info) or bad (not localized).
  • Bookmarked pages keep the same language even if the user clears their sessions/cookies.
  • Easier for automatic scripts to select language, but only marginally.
  • Easy to change the language if you can't find the button. Although the button is the problem there, not the url.

Of course, on the first request, a default language should be chosen intelligently based on headers etc. But after that, should the site

  1. Use that language, keeping language-neutral urls (even if the user changes the language).
  2. Use that language, by redirecting to a language-specific url.
  3. Use that language, and only change the url if the user overrules the default language.

Assume the information on the site is more or less the same in both languages. I can see why Wikipedia puts languages in their urls. But should e.g. an international brand do that?

EDIT: and assume that the urls themselves are always in the same language, independent of the website content language.

  • 1
    What does it need to be one or the other? You can support both. This will use cookies (if present) site.com. This will not use language cookie site.com/en
    – paparazzo
    Commented Dec 4, 2014 at 15:05
  • 1
    Instead of site.com/en, I'd just go with site.com?lang=en. This way you would use basically the same webpages and everything (the same files, directories, and code); you would just use json files or something to read separate translation data, but everything else would be the same. Commented Dec 4, 2014 at 18:40
  • 6
    It's worth noting that site.com/en can easily translate to site.com?lang=en on the server side. Otherwise, you end up doing something like: site.com/path/to/content?lang=en and that's ... yuck ...
    – corsiKa
    Commented Dec 4, 2014 at 20:07
  • 1
    Why not use the Accept-Language header?
    – Dan Lyons
    Commented Dec 5, 2014 at 18:20
  • 1
    Accept-Language, in my opinion is the only valid start point for multilingual websites, everything else is a set of questionable tactics and half-solutions that has been filling the gap since the dot-com bubble when the gold rush on the Web was led by cowboy developers who "learned" HTTP by word of mouth along a long string of "oral transmission" from other developers who may or may not have known what Accept-Language even was. I am sorry but there isn't a single great answer to this question among those listed as I write this. They're pragmatic, but "defective by design". Commented Feb 22, 2020 at 17:11

4 Answers 4


Assuming you handle the changing between language versions (as in the example of your first bullet point - sending a page) in a reasonable manner, then yes, you should consider having the language in your URL, but for a reason you've not mentioned here.

Note: This generally gets referred to as 'language/region' because, more often, the two letter codes are used to define both a language and a region e.g. en-us, en-uk, es-mx, es-es

The Benefit of Domain Authority

Assuming the growth and prosperity of your domain is a goal, then having all your content in subdirectories under your root domain is the best way to quickly develop domain authority and consequently to rank well in search engines.

Note: Domain Authority is gained when other sites link to yours. Generally speaking, the more links a domain (or page) has pointing to it, the more "authoritative" it is, and the more likely it is to rank for a given keyword. (This is why wikipedia does so well in search)

Your other options i.e. separate CCTLDS (.com, .ca, .co.uk) and subdomains (us.site.com, ca.site.com) both create silos for authority. That is, links to any one site or subdomain don't benefit others.

If all your content is one domain, links to anywhere benefit everywhere.

(I've started to refer to this as 'The Microsoft Model', just because it's a high profile site that uses this method, and when I'm explaining it, I can just link to http://www.microsoft.com/ There are lots of big international brands that use this method. The other 'biggest international brand' I could find quickly is http://www.nike.com/)

Be sure to use hreflang

hreflang is a method of distinguishing between your language/region variations and is a way of telling (specifically) Google, "you are going to find other versions of this page that are very similar, but with language or other content differences. This version of this page is for english speakers in the United States."


Switching Between Languages

A best practice for how to handle this has yet to emerge, and there's a lot of variety in how this gets handled. How you implement is up to you.

Visitors to the Root

Some sites show visitors to the root i.e. 'site.com' a list of options (often just lists of text links because it's very easy to get the map/country/flag/language thing wrong) but more often these days, the users' region is detected and they are taken directly to the appropriate language/region. i.e. a link to site.com goes to site.com/en-us

Visitors to Deep Pages

You gave the example of sending a link to friend. What if you link to site.com/en-us/ux/ but he's in France?

You have a couple of options. (assuming a French version of the page exists. If not, the user goes to the linked location)

1) Simply show the user the french version of the page. In a lot of cases this will be preferable for everyone.

2) Show the user the English version of the page, but detect that they are in France, and show them an unobtrusive notice on the page (in French) that tells them there's a French version and asks if they'd prefer to see that.

You should of course make sure it's always possible and easy to switch languages, and that you keep users in the right content areas once they've been 'located' (you'd use cookies to do this, but it sounds like you've got a handle on that part)

  • 3
    This "domain authority" stuff (SEO) would apply too to a site not showing the language in the URL. Commented Dec 4, 2014 at 16:25
  • 20
    Your option 2) at the end is fine, but your option 1) is a bad idea. The essential goal of a link is to lead to a resource. If I send a link to a friend and she does not see what I see, then something has failed. First, my friend has to see the page I send her. Then, if the page allows my friend to switch to a language or country she prefers, it's a nice bonus. Commented Dec 4, 2014 at 16:37
  • 1
    +1 for empathetic problem solving. Perhaps @Mark can take then into account when considering his eventual implementation.
    – dennislees
    Commented Dec 4, 2014 at 16:52
  • 2
    @corsiKa - Flags may be used a lot, but in a lot of cases they're used incorrectly. The site flagsarenotlanguages.com shows the multitude of ways of getting the flag/language/country thing wrong. Most designers put a lot less attention than necessary into this feature. As you've mentioned it, I'll edit my answer to work it in. Thanks.
    – dennislees
    Commented Dec 4, 2014 at 20:29
  • 1
    Also, no need for the scare quotes or italics on "Domain Authority". This is not an arbitrary term or concept. It's a metric developed by the Seattle-based company Moz (formerly SEOMoz) that had been embraced by the industry.
    – dennislees
    Commented Dec 5, 2014 at 1:39

There is one quite solid reason for keeping language in the URL: data tracking. If tracking potential users and their breakdown by region is important for you (and in case of business, SaaS and e-commerce it is always important), it will be easier for you to set up the tracking and easier for various tools to track the content, campaigns and conversion if you keep the language in the URL.

  • 2
    Good point. URL as UI. Easier to share, easier to track, easier to test, easier to debug. Commented Dec 4, 2014 at 16:53

In most cases, yes it should, as pointed out in the other answers.

This is reasoned in some length in a W3C post about language negotiation, and covers especially the localisation case where there isn't necessarily a one-to-one correspondence between different language (or locale) versions.


  • A bilingual blog contains a news section in English example.org/en/news/ and French example.org/fr/news/. However, not every news item may be considered of interest to the entire audience, e.g., example.org/fr/news/mes-reflexions-a-propos-de-la-reforme-de-l-orthographe.

  • A company serving different markets may wish to offer content directed to a specific locale. E.g., example.com/en-IE/promotions/beer vs. example.com/en-ZA/promotions/wine.

Assume the information on the site is more or less the same in both languages.

Today it may be. Tomorrow they may realise that localisation is a tricky subject and that constraint / assumption may turn out to be more expensive in the long term.

I can see why Wikipedia puts languages in their urls. But should e.g. an international brand do that?

Can you think of any compelling usability reasons why not making the localisation choice explicit in the URL (this includes the host part) is more advantageous than the alternative?


Yes always, because people tend to share links mostly with people speaking the same language. Especially distinction like en-US and en-GB will less likely alienate visitors. In special cases the same product or service may have different names in different languages.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.