One question that recently popped when talking with a customer was whether he should keep or not a same domain for his translated site. This leads to an interesting discussion: Do we keep the translation on the same site or not?

Before discussing the different solutions about where to store or host the translated site, first let’s make clear what you must NOT do. Never -and I mean never- keep the translated pages in the same directory as the non-translated pages. Not only is housekeeping and maintenance a nightmare, especially if you have many pages. The main reason why this should not be done is because of the way that search engines recognize the website language, as I pointed out in a previous series of posts. Mix up pages of different languages in a same folder and you may end up as being a site in the wrong language, with no translation at all and possibly even be penalized by search engines because of being so sloppy.

Another thing to avoid under all circumstances is to use machine translation for your website translations. Yes, I know that is dirt-cheap, but Matt Cuts has explicitly warned at Google Webmasters against machine translation, as “our guidelines against auto-generated text can also apply against auto-translated text”.  If you cannot afford a proper translation, stick to a widget that, as Matt states, “says translate into this language or something like that”, which is an acceptable practice to Google. I repeat, do NOT use machine translation, not even Google Translate. You are warned!

There are basically four ways to store the translated site:

  1. In a website database, accessing the pages by URL parameters (e.g., mysite.com?loc=fr, ?country=france)
  2. In a subdirectory of your existing domain (e.g, mysite.com/FR/ for French, mysite.com/ES/ for Spanish, etc)
  3. In a subdomain of your existing domain (e.g., fr.mysite.com for French, es.mysite.com for Spanish, etc)
  4. On a separate domain (e.g., monsite.fr for French, misitio.es for Spanish, etc).

We will have a look at each of the different options separately.

Website database with URL parameters

This might look an easy solution if your website is already stored in a database (e.g., because you use a CMS system). I think that the only potential benefit is that you do not have to set up anything else, but from my point of view it is a bad idea. First, because you cannot segment the pages, and you have the same situation as if you put a lot of HTML pages in a same directory – the search engines may not be able to solve the riddle of multiple languages on a same location. Similarly, the users might have difficulties in getting the visual clues of where they are, especially if there are many URL parameters. Not to speak about the fact that with URL parameters it is not possible to perform geotargeting in Webmaster Tools, so you are removing a very powerful weapon from your SEO arsenal.

Use a language subdirectory within your generic top-level domain

If your main site is a generic top-level domain (such as .com, .net, .org, or one of the newer ones such as .global or .club), there is some merit in creating a subdirectory for each language. Apart from the fact that all web pages are stored together and easier to set up and maintain, it is possible to geotarget this from Webmaster Tools, not to forget the fact that it is cheap as you use the same host for all translations. Many CMS systems also allow you to set up the pages in a “language subdirectory” structure such as mysite.com/FR/. Though in this case it is a virtual subdirectory, the effect is the same.

Disadvantages? Not many. Again, users might not recognize the geotargeting, but this might not be always very important. The main drawback is that as everything is hosted on a same server, this may become an issue if you get a lot of traffic. Moving each language to its own site may then become an issue, specially if you have cross-linked the pages to its translated equivalents. However, if you do not expect millions of hits, this might not be a major problem.

One additional advantage is that, since all pages are on the same site (and assuming that you have cross-linked them to each other), the increase of page rank (PR) on each page increases the overall site page rank. So the pages in French or Spanish would also increase the page rank of your English site. Nice!

Create a subdomain for each language

A different solution while maintaining the same server is to use subdomains for each language, such as fr.mysite.com for French. Again, this is good for proper site housekeeping and maintenance. No problem either with geotargeting with Webmaster Tools. It is also far easier to move a site if your traffic grows so big that you need two (or more) different servers, possibly even at different locations. After all, even if pages are interlinked, the links will always refer to the site / subsite URL, so there is no problem of a suddenly missing subdirectory and lots of  “404 Page not found” errors. And if eventually you decide to move to a country-specific top-level domain, a permanent redirect of that subdomain to the new ccTLD will solve the issue, while maintaining the page rank (more on that in a later post).

Again, there are not many disadvantages. Again, users might not recognize the geotargeting (though it’s far easier to see than the previous one) or might confuse it with the country instead of the language (e.g., does “fr” stand for “French” or “France”? Personally I would not worry much about it, most users don’t look at the URL anyhow. It means some additional work, but not that much. What might be an issue (if you are on a shared hosted site) that you might have a limit on the number of subdomains you may be allowed to create on your site. A couple of additional dollars per month usually solves that problem.

One interesting thing is that very often subdomains (on shared hosting) are created as subdomains of the main site, with their own URL  (so fr.mysite.com and mysite.com/FR/ would be actually the same thing). This might become an issue if a search engine decides that there is duplicate content.To prevent this, either choose a preferred version and redirect to it or use the “rel=canonical” link element to the subdomain.

Use a country-code top-level domain (ccTLD) for each language

Though Google prefers this particular solution (as highlighted in the video mentioned above), it is also the most complicated to manage, as well as the most expensive. Housekeeping is easy (one language at each site, such as monsite.fr for French), but cross-domain maintenance is complicated. If you need to implement a same change in five languages, that means accessing five different sites, possibly also in up to five different servers. It also means more infrastructure, and the availability of five different sites is likely to be less than that of a single one, not to speak about the detail that you might require more staff to handle so many more sites. If that were not enough, there is a risk of loss of brand, as you have a big proliferation of sites with different names.

Another issue is where do you stop? You see, a same language can be spoken in many countries. For example, Wikipedia lists 21 countries where Spanish is an official language. But these are by means not the only ones! According to existing statistics, USA has more Spanish speakers than Spain itself! Will you send all Spanish-language speakers to misitio.es? Or perhaps to misitio.mx? Or each to their specific ccTLD? Apart that you have 21 ccTLDs for a same language (remember what I said about duplicate content), what do you do with the USA, which has an official language (English) and an unofficial one (Spanish) that has over 50 millions native speakers that you can simply not ignore? Or with countries that have several official languages, such as Canada (English and French) or Belgium (French and Flemish)?

And remember, you will not always be able to get the ccTLD with your brand name in a specific country. I am not talking about site name speculators, I am talking about local companies that have the same name (or a different one, but which matches the acronym that you use) and got the local ccTLD first. Sorry. Dead end. If you did not buy up the ccTLDs of the 196 countries that exist today in the world when you created your company, it is almost certain that you will never be able to grab them all up.

Which approach is best?

The simple answer is exactly what you would expect: It depends. In any case, I feel that the usage website database, accessing the pages by URL parameters, is the worst possible solution, that I do not recommend to anybody.

For small websites, not expecting to ever hit millions of visitors, I would recommend the usage of subdirectories if there are few pages, and subdomains if they expect to use many pages in the future, or have hopes for great growth.

For medium websites, my recommendation is to use subdomains. The (small) additional work that this implies is worth it, as it is future-proof and allows for expansion/segregation with a low risk.

For big companies, I would rather go for subdomains, unless local laws require otherwise. For example, you might be legally required to have a local presence, in which case a ccTLD becomes mandatory. But, unless these sites are set as independent businesses (such as subsidiaries), I would set them up as language-specific subdomains. This would significantly simplify the management and reduce the associated costs. For example, you could redirect all 21 Spanish-speaking countries and their associated ccTLDs to es.mydomain.com. If later you created a subsidiary in Mexico and another in Spain, it would be a piece of cake to spin off two sites from this subdomain.

In another post we will discuss in detail the problem of multilingual countries, but that is a perfect example of language subdomain implementation.

Now, what do you think?

Be Sociable, Share!