views:

61

answers:

5

What would be a good way to handle URLs on a website that offers multiple languages, but has one primary language (in my case, English).

What should be the address of the home page in English? http://example.com/? http://example.com/en/? http://example.com/english/? Other?

What should be the address of the home page in another language, say, German? http://example.com/german/? http://example.com/de/? http://example.com/deutsch/?

Would the use of language-specific subdomains be appropriate? What would you do and why?

A: 

What should be the address of the home page

Would the use of language-specific subdomains be appropriate?

How you like it, doesn't really matter. Design it to be intuitive to the users.

Language names encrypted in URLs won't matter for SEO because nobody will be searching for "en", "de". The names of the products you're offering however will matter very much, because people will be searching for products like "gifts" or "geschenke".

Developer Art
A: 

I would prefer the ISO 639 aplha 2 language code as 1st part of path. It's not only niftier, but it's for the developer also much easier to detect if someone has chosen the website in a specific language. You just have to check if the first path of the request URI matches [a-z]{2}.

BalusC
A: 

I think that the better stylish solution is to use the address in the format http://yourdomain.com as the home page URL, and identify the localized web pages with ISO 639-1 language codes

BitDrink
+1  A: 

It kind of depends on the structure of your site:

  • If every language is considered a completely different site, use sub-domains for the language.

    This is because different sub-domains is considered different sites by many technologies. Wikipedia does this (http://de.wikipedia.org/) to separate content for different languages entirely.

    I wouldn't recommend you to choose this option unless your site is very big.

  • If every language has its own structure, but is still considered to be versions of the same site, use a top-level "directory" for languages.

    For the sake of consistency, I would say that you should also have one for the default language (and omitting it would cause a redirect to the appropriate structure.) I would recommend you to use /en/, /de/, etc. since it's short and concise, and also the standard way of indicating languages.

    This is probably your best bet.

  • If the structure of the site is identical no matter what language it is, and only content on the pages changes depending on the language, you could also consider putting the language modifier as a parameter: /home?lang=en

    Google does this, for example: http://www.google.com/search?hl=de&q=foo (they also separate languages by TLD, though.)

Blixt
Request parameters are not SEO-able.
BalusC
While request parameters do not have keyword weighting, you wouldn't be searching for "en" or "de" either. Request parameters indicate unique pages, and therefore there is no SEO issue with using query parameters for a matter such as this. The only issue would be that the path would be the same for every language, but that's also the only time you would use the method (as I already indicated in my answer.)
Blixt
Request parameters are perfectly fine for SEO. I thought they did have "keyword weighting", Blixt, since they are bolded in Google search results.
DisgruntledGoat
They probably do have some weighting... but they are far less important (according to search engines) than keywords in the domain, path and title of the page.
Blixt
+1  A: 

Away from the question of how the international URLs should be styled (as that has been covered adequately already)...

One thing that I would personally do is make the site's 'main' domain (i.e. http://example.com) redirect the user appropriately depending on the Accept-Language HTTP header passed by the browser. This is what google.com does, for example.

If you do this, however, make sure that it's possible to switch to another language easily - and save the settings via some other mechanism to allow persistent override (cookies!).

Chris R