Managing an international website isn’t as straightforward as running a site focussed on a single local market.
There are several issues that need to be handled very precisely in order to maximise your traffic while maintaining a user friendly design.
Exceptions to every rule
Before we start it is important to realise that while this article discusses best practice solutions not every one will suit your website. Certainly if you already have a system that works it is wise to obtain professional advice before making any major changes.
Setting a homepage
Our recommendation for multinational sites is that they should be hosted on a .com domain and users from countries outside the main one should be forwarded to a sub-folder targeted to their country.
For example if the site is targeted towards a US market users from the UK visiting www.site.com are redirected to www.site.com/uk while users from the US remain at www.site.com.
Ideally www.site.co.uk should redirect in a search engine friendly manner to www.site.com/uk as should all other country specific domains.
We do not recommend that sites redirect users from deep content such as www.site.com/uk/product.html as the user is likely to want to visit the actual page they requested rather than being redirected.
Sites like FedEx offer a poor user experience as they require users to select their country as soon as they visit the homepage. Automatically choosing a country based on IP address would make the site far more efficient.
For details about how to setting this system up you might like to read our post about geo targeting on PHP sites.
Search engine optimisation
Using a sub-folder rather than a sub-domain or even a separate website means that any incoming links are going to help raise the overall trust of the entire domain. Using a different site for each country or redirecting to sub-domains isn’t going to make the best use of any incoming links.
It is important to remember that Googlebot and other search engine spiders are usually on a US IP address so unless your default setting is to send US users to www.site.com you might need to override the IP delivery rules for spiders. For example if the site was for a UK company but on a .com domain you might be redirecting all US users from www.site.com to www.site.com/us while keeping UK users on www.site.com. If you redirect Google to the US sub-folder it can make it hard for Google to index your real homepage.
Search engines use the following signals to determine the location of your website:
- Hosting location (the location of your server)
- Domain tld (eg .co.uk for the UK and .com for the US)
It is important to check that the actual location of your servers is reflected in their IP address using a tool like this one. I have seen UK hosts using IP addresses in the US and servers that are physically in the US resolving to India.
Ideally the site needs to be hosted in your main location of business, for example a UK site should be hosted in the UK and a US site in the US to ensure rankings in your local market across all search engines.
Recently Google allowed sites on non country specific domains such as .com or .net to assign a specific country (hence overriding the hosting location) using Webmaster Central. Here is what Google says about the issue:
If your site is aimed at users in a particular location, you can associate your site with a geographic target. We’ll use this information to help us determine how your site appears in location-specific search results.
Not only does this allow you to say that a US hosted .com site should actually be treated as a UK site but you can also set up specific sub-domains or sub-folders to target local markets.
For example Google allows you to say that www.site.com/fr is targeted to French users while www.site.com/uk is targeted to people in the UK. This means that every folder of your site should rank well in it’s target market in Google.
Yahoo and MSN are yet to implement this which is why we usually recommend hosting the main site in your target market. If traffic from a certain engine other than Google is important to you in a specific market it might pay to use a different solution such as a standalone site or sub-domain that is hosted in the target country.
Let your users switch versions
It is important to allow your users to switch to a different country version at any time and have this preference remembered (until they want to change it) using a cookie. There are several methods to do this but the best practice is usually to have a drop down list built with CSS and images of country flags. The user can click on the listing for their chosen location and easily switch versions.
An example of a good method of doing this is below from www.cj.com
The official W3 guidelines frown on the US of flags in this instance stating:
Do not use flag icons to indicate languages.
How to: Use text. See Example 23 for one illustration.
Discussion: Flags represent countries, not languages. Numerous countries use the same language as another country, and numerous countries have more than one official language. Flags don’t map onto these permutations.
However, Jakob Nielsen recommends:
The recommended solution is to use flags that match the geographical location of the service and its main intended audience. For example, a tourist site in Continental Europe would use a British flag Flag of the United Kingdom for English unless it was mostly targeted at American tourists, whereas a tourist site in the Americas would use a U.S. flag unless it was mostly targeted at Europeans.
I have seen the English flag Flag of the Kingdom of England used once, but would generally recommend against this seemingly neutral choice since few people outside the U.K. know the regional flags for England, Scotland, etc.
In summary, it is appropriate to use country flags as long as they are used alongside the name of the country and are used as a visual aid only. It is often appropriate to combine two countries together to aid the user experience. For example a UK site might let users choose US/Canada rather than offering different pages for each region.
So far we have been assuming that readers in a specific country will always want to read your site in the native language of that country. Clearly this isn’t always the case and this raises several issues.
First of all when your users select their location it is important to distinguish that from the language they want to use. For example a user in Spain might want to know about how your company operates in their local market but want to read the site in French. Do they click the French flag or the Spanish flag?
In his column on International Usability Nielsen recommends:
To choose between a small number of languages, I recommend listing the name of each language as a word, using each language’s own name for itself.
If language choice is supported by a site, I recommend providing a link to the choice on every single page since users often go directly to pages from search services or bookmarks without passing through the home page. Some sites put up a language choice page before the user can reach the home page, but I recommend against this if it is possible to determine a default language that will be used by a very large proportion of the users. Clicks and download time can be saved by going straight to a page for the main language as long as the home page has a very prominent (and internationally understood) entry for language change. Also, the pages for the various languages should have their own URLs so that users can bookmark the proper entry point and bypass language choice if they visit again.
In summary the recommendation is that you target sections of the site to customers in specific markets as well as offering that content in a range of languages. For example www.site.com/fr would be targeted towards French users and the default language would be French. User should be able to switch the language of this sub-folder to English and ideally some other European languages as well.
Assuming all your sub-folders are in different languages the site should have no duplicate content issues.
The problem of duplicate content arises when a site has site.com, site.com/uk and site.com/au for the US, UK and Australia. All of these are in English so the content is likely to be much the same. Another issue that can cause duplicate content is when you translate sub-folders such as site.com/fr into English.
It isn’t simply a question of blocking indexing of this content as this won’t help your search engine rankings in specific countries. For example if you have English content in site.com/au that is exactly the same as the content on site.com/uk then it is tempting to remove one copy from the index but you will lose the rankings that this article had.
Our preferred solution is to hand craft every single page with content specific to the target country. This is costly but it is a “best practice” solution.
Don’t forget to bookmark this article for later!