Best practice for URLs of multi-language websites

问题:

What is considered the best strategy for URLs of translated websites? Something I see happen frequently is:

http://example.com/english-slug.html
http://example.com/de/english-slug.html
http://example.com/fr/english-slug.html

This has the (minor) advantage that a user can manually switch to another language by modifying the URL. The disadvantage seems to be that the URL consists of a slug in the wrong language for every page not in the default language. That would cause a SEO penalty, I think.

The alternative would be to translate the slugs as well and optionally omit the language identifier as well:

http://example.com/english-slug.html
http://example.com/deutscher-slug.html
http://example.com/slug-francois.html

Some languages do not really lend themselves to be 'sluggified', such as Russian, Chinese and Arab. You'll end up with transliterations that make little sense.

回答1:

I think you should use language tags and translated slugs:

http://example.com/en/hello-world
http://example.com/de/hallo-welt

Why language tags? To avoid collisions.
Sometimes you might want to have the same slug for different languages (for example, "team" in English as well as in German).

Why translated paths? For better usability.
Not all users understand the "default" language, and depending on its script, they might not even be able to type/remember/dictate the slug. (It doesn’t make sense in the first place to use human-readable slugs that only part of your users are able to understand.)

Yes, it would be a "(minor) advantage that a user can manually switch to another language by modifying the URL". But it’s unlikely that users or search engines would expect this to work (see my related answer on Webmasters). So you would gain little (URL hacking for advanced users) and lose much (bad usability for users using the non-default language).

That said, it would still be possible to enable this URL hacking feature in most cases: When users change the language tag de (in /de/hallo-welt) to en (/en/hallo-welt), you could check if it exists (if yes, show it), and if not, check if there exists a slug "hallo-welt" in any language, find its English translation and redirect to it (from /en/hallo-welt to /en/hello-world).

回答2:

The best solution, if you can afford it, is to send the document with the right name, that means, using the right word on each language.

Of course each document should be sent with the respective language setting on the headers.

For storing them, you can use folders and let the web server choose the right document according to the language preference; or you can use server side technology, like PHP, perl, etc to send the document and adjust the URL.

In any case, you have to have a default language to be sent when you don't have the requested language.

If you can't or don't want to send document with the right name, using subdomains is the best next option. This option, is not as common as adding the language after the domain, and that means, that people may not be used to it, although, it has some advantages, for instance;

• Each language behaves like a whole new URL/site (almost).
• People feel like visiting a dedicated site, not a subsection where the second language is relegated and may fail at any moment (some content may not be translated).
• Some people are not familiar with their two letter representation of language, but everybody knows how his language is called and spelled.
• It generates cleaner URL's.
• It is believed that having subdomains increases appearance on SERPs (I don't have knowledge of this and it may have changed).
• It's easier to have different layouts if you want to.
• It's easier to set different servers according to language.

Of course subdomains have some disadvantages, like:

• A bit more work to set properly from the server perspective.
• Less collaboration from the part towards high ranking.
• Some people may not expect it but expect a subfolder.

Next would be the subfolder option, as you show on the question. This is the recommended way if your main perspective is SEO since all the relevance of the domain stays on that same domain and each language helps to a common "pot" of ranking.

My perspective when choosing a solution, is never SEO, under any circumstance. Whatever ranking I get is due to the content itself and the best use I can give to technology. But I understand that my point ov view is not the most common.

One thing to consider also, is that you should provide some kind of explanation or help the user so he can take actions to change to the preferred language. It may be using icons, a tooltip, or any other method that works for your design and verbosity.

One thing to avoid, and you didn't ask for it, but is related; is using language autodetection. Lots of times, the user is in a different country or using a version of a browser that has a different language from what he can understand and the autodetction just makes a big mess. Offer the default version and a clear way to change it.