What is the best way to set up a website that requires both country and language targeting? Well, this is a much-debated issue among SEO experts and unfortunately there isn’t a clear-cut answer. Regardless of how you choose to set up your website, there will be shortcomings since every situation is different and dependent on the unique nature of your business.
However, as an introduction to the topic, I’m going to explore how to approach the issue of language and country targeting in an e-commerce environment using the SizeGenetics brand as an example.
When initially considering our approach, there were many different issues that needed to be taken into account, but fundamentally, there were two important factors to bear in mind:
- Search Engine Optimisation (SEO)
- Conversion Rate Optimisation (CRO)
There were two separate aspects to consider for both of these factors when we were choosing our domain setup: the way in which we target languages and the way in which we target countries. A multilingual site is a website that offers its content in more than one language, for example a Canadian business that provides its content in both English and French.
A multi-regional website, on the other hand, is a website that specifically targets users in different countries. This is frequently done to improve CRO by personalising content such as the order process, shipping details, address lookup and any other content to improve conversions based on geographic location. In addition to these two individual setups, it is important to bear in mind that a site can be both multi-regional and multilingual.
The SizeGenetics brand is popular in many different countries, some of which such as Canada, serve users in multiple countries, and this added yet another level of complexity to our setup. How were we to serve users the correct language while also providing them with a user experience tailored to their geographic location to give them realistic expectations of shipping and guarantees?
WHAT DID OUR PREVIOUS SETUP LOOK LIKE?
Previously we had been using a subdirectory setup for all sites on the MoreNiche network, with the US version at https://sizegenetics.com/us/, the French version at https://sizegenetics.com/fr/ and the Canadian version of the site at https://sizegenetics.com/can/.
Consequently, Canadian users could end up at either /can/ or /fr/ depending on the language they searched in, with some Canadian users even landing on the /us/ site even though the locale was set to en-US. In fact, almost half of all Canadian users had been landing on the US site and missed out on many of the important usability improvements that had proven to greatly benefit CRO.
Overall, when it came to targeting both language and country correctly, our accuracy was in the region of 70%, meaning that a fair proportion of site users weren’t having an optimal experience. This was a dramatically poorer performance than the CrazyBulk site which was already using a multi-domain setup and registered 90% accuracy.
This was reflected in both the conversion rates and country-by-country branded rankings. In general Google seemed to favour the language site setup, and users benefited from the improved customised checkout experience and our other CRO efforts.
WHAT DOES THE PERFECT SOLUTION LOOK LIKE?
So what is the ideal solution for a setup that requires both geographic- and language-based targeting? This is a tricky question, with no perfect answer; in fact SEOs are forever debating this contentious issue.
Our long-term vision is that all sites should be on language (ccTLDs) domains (or subdomains (on a gTLD) where the ccTLD isn’t available) to ensure the experience is tailored to the specific country. Countries that require more than one language should eventually have a multi-language setup, for example https://sizegenetics.ca would serve the primary Canadian English language site whereas https://sizegenetics.ca/fr/ would serve the slightly less important French Canadian language site.
With the clear majority of traffic being from affiliates, we felt it was more important to consider CRO first to ensure that most users have an experience that is tailored to their geographic location.
In order to support this setup and ensure that we didn’t run into issues with duplicate content, we needed to be certain that we were making correct use of hreflang to explain to search engines exactly what we were targeting. In addition, we needed to be mindful of duplicate content across multiple domains and carefully consider whether we should be using canonicalisation or whether it was, in fact, ok to have duplicate content since we were targeting different users in different countries. Below is an extract from Google’s advice on duplicate content in the case of language- and country-specific websites.
Often, especially when wearing your SEO hat, it’s far too easy to become overly fearful of having duplicate content on your website. A lot of this fear has been caused by the overzealous nature of the initial Google Panda update in February 2011. Although duplicate content had always been something to bear in mind, its importance increased tenfold with the introduction of Panda.
Overnight many sites that had previously ranked well simply disappeared due to content quality and duplication issues which raised a flag against the site and effectively marked the whole domain as low quality. In fact I’d still advise you to read this old post on Moz that provides some detailed advice on duplicate content in a post-Panda world.
One thing that’s worth noting now is that since January 2016 Panda is effectively just another part of the Google core algorithm and it is a lot more granular in nature. This means that even in a worst-case scenario you shouldn’t find your whole domain penalised. But on the off-chance that it is, you should be able to recover much quicker as you don’t have to wait several months for the next refresh of the algorithm.
In addition, Google learned pretty fast that some duplicate content is OK, especially where it’s targeted to different users in different countries. With this in mind, in December 2011 it introduced the hreflang attribute so you could indicate to Google who should see which version of your content when coming from Google search.
OUR FIRST STEP IS NOW COMPLETED
So we couldn’t get directly from our previous setup to our dream setup for a variety of technical and resource-related reasons, instead we took a few baby steps along the way. Right now for SizeGenetics, we have the following domains in place:
As you can see there is a mixture of subdomains on the .com gTLD domain and ccTLDs. As and when we acquire ccTLDs we’ll be moving from subdomain to ccTLD to standardise our setup, with some other potential benefits in mind that we’ll discuss later.
Since completing this migration, we’ve updated our sitemaps and ensured that the new domains are set up correctly in Google and Bing webmaster tools. We’ve also set up permanent (301) redirects so that traffic landing in the old locations doesn’t simply get lost and so that we retain some of the value of other websites linking to pages on the old setup.
As of the 6th February we’re also ready to release server changes to the way in which we handle redirection from ‘www.’ to ‘non-www.’ domains as well as changes to the way in which we ensure all traffic is secure and redirects to https://.
Alongside these changes, we’ll also be updating the robots.txt file for each site to clearly point out the new sitemap location and to prevent common problems such as the indexing of search result pages on some brand websites.
WHAT OTHER OPTIONS DID WE CONSIDER?
During the decision-making process for our new setup we had several options to consider:
- Country-specific domains, e.g. https://sizegenetics.es
- Subdomains on a gTLD, e.g. https://fr.sizegenetics.com
- Subdirectories on a gTLD, e.g. https://sizegenetics.com/el/
- Our current setup, e.g. as example 3 but with no site at root level, e.g. https://sizegenetics.com/us/
- URL parameters, e.g. https://sizegenetics.com?lang=de
Why didn’t we stick with the current setup?
Straight away we dismissed our current setup because not having a site at root level caused a variety of issues:
- Users were frequently being redirected from the root level domain to a language subdirectory, slowing down their load time. This was caused by a mixture of old internal links, external links without language folders or users directly visiting the domain via the browser.
- Google expects a website to exist at root level. In fact, the branded rankings for the site were showing in Google as https://sizegenetics.com even though no page existed here. We weren’t making its job easy and this was being reflected in branded rankings for the US site of many of our brands.
- Verification of a domain often requires a tag to appear on the homepage; this can be using social or webmaster tools setup. While we could work around some by validating using another method such as DNS entries, with others we couldn’t and this caused us some issues with social integration.
- We were confusing language and country targeting and making things more difficult than they needed to be for users. For example, our Spanish directory was set to the locale es_ES while a lot of the traffic was actually coming from Spanish users in Mexico (es_MX). This was setting hreflang=“es_ES”, whereas hreflang=“es” to cover all Spanish speaking countries may have been more effective for SEO. But this would create its own issues with cart personalisation in terms of local flags and shipping providers.
Simply put, we needed to be able to personalise the site to the user’s location, so we needed to separate out language and country targeting.
With these four points in mind we were instantly able to dismiss our current setup and look at alternatives that would bring us the level of flexibility we required.
URL parameters – why are they a terrible idea?
The next obvious option that we didn’t even want to consider was languages being set up as URL parameters. The obvious reason for this is you simply can’t geo-target the separate languages in webmaster tools.
In addition, it’s extremely difficult for users to recognise the website and manually land on the correct domain, and we also had concerns over maintaining the language site a user was on and generally managing internal linking effectively.
There are some situations where URL parameters can work, but this tends to be when you’re less concerned about SEO and are manually filtering the landing page traffic. For example, websites that are driven wholly by affiliate traffic that aren’t expecting much in the way of supporting SEO traffic can thrive with a URL parameter language setup.
Weighing up the remaining options – what were the pros and cons?
So we were left with three available options to consider:
- Country-specific domains
- Subdomains on a gTLD
- Subdirectories on a gTLD
Each of these options has its own pros and cons, and I want to make it clear that there is no perfect solution. While SEOs everywhere will most likely be proponents of one of these options over all others, it’s a completely situational choice that requires consideration of multiple factors:
- The impact on your digital marketing team resources
- The cost to set up and maintain the solution
- How the user experience is impacted
- The potential impact on search engines
These factors can be broken down further into multiple elements that should be considered for each option and the table below summarises these. However, bear in mind that the value of these elements for your website or organisation is something completely personal to your situation.
Time to set up
|Level of UX customisation|
|Time to maintain||Domain cost||Simplicity for user|
Simplicity for search engines
|Accuracy of targeting|
Accuracy of targeting
The importance of these twelve elements varies dramatically depending on your situation. This is why ultimately there is no one size fits all solution for language and country targeting. Rather, it’s a judgement call that requires careful consideration since your decision will impact your website and the ability to change it for years to come.
|Aspect under consideration||Country-specific domains||Subdomains on a gTLD||Subdirectories on a gTLD|
Time to set up
Time to maintain
Increased if each domain is hosted separately.
Increased if each subdomain is hosted separately.
|Increased but minimal||Standard|
Level of UX customisation
|Improved due to ability to regionalise order process.||Improved due to ability to regionalise order process.|
|Simplicity for user||Easily to understand what country site they are on.||Subdomains aren’t always as easily recognised but still ok.|
Not ideal, user may not be clear if folder is country or language.
|Improved as can host larger ccTLDs separately and more local to users.||Improved as can host larger subdomains separately and more local to users.|
Accuracy of targeting
|In region of 90%, based on our data.||Unknown, expect somewhere between other two options.|
In region of 70%, based on our data.
|Domain can only target country it’s designed for. Multiple languages in same country can be created with subfolders.||A subdomain can be targeted to any chosen country. Not as clear as a ccTLD. Multiple languages can be targeted with subfolders.|
Works best when there’s only one of each language on the same domain. Appears more like duplicate content than ccTLDs and subdomains.
Simplicity for search engines
|ccTLD specifically states where you’re trying rank. Making it very easy to interpret.|
Concerns that spreading links between multiple domains reduces authority.
|You can set where you want to rank in Google Search Console.|
Some concerns over spreading links between subdomains and if they are treated independently.
Even with correct hreflang mark up, have seen wrong country landing page rank.
Strong from SEO links position. Some debate as to whether ranking in country is local link dependant.
From a purely SEO perspective, there are risks associated with separating out one site into multiple domains, and the greatest of these is the unknown effect of multiple domains on backlinks. However Google has become much more granular in the way it treats links so it would be wise to conclude that it pays greater attention to local niche-specific links when determining rankings in a specific country.
But the CRO benefits of the change outweigh the risks involved with any additional SEO work required to ensure rankings. Using domains to target a country, and separating out language and location targeting allows a much more accurate approach to targeting site users.
In addition, there is some SEO benefit in the separation as it helps to prevent some of the issues we’ve seen with the wrong country site ranking in a specific location. As an example, we’ve quite frequently seen the main US English language site ranking in place of the localised version, for example the /can/ folder in Canada. It will also help us in the future to speed up the site in specific countries, where demand is deemed to be large enough, by hosting domains on separate location-specific servers.
Many organisations have implemented separate country-specific domains in the same way we have, including Google, Amazon and Wikipedia (subdomains). Since our websites are e-commerce sites, it makes them ideal candidates for this level of separation requiring both country and language variation to be tailored for the user. In addition the concern of duplicate content can be prevented through proper hreflang markup and heeding Google’s advice on duplicate content on international sites.
WHAT COMES NEXT?
We’ve completed the first phase of our changes to the websites and we’re now looking to improve:
- Hreflang markup: in some places the plugin we’re using appears to be causing issues with no return tags. This effectively means that not all language and country variant sites cross-reference each other. This must include a self-reference with the page linking to itself with hreflang markup.
- Expand the language variations once we have greater hreflang control. One perfect example of this would be to create a French-Canadian version of the site, which would be a subdirectory on the Canadian domain. We can also look to move default location unspecified language variations to sizegenetics.com and have multiple languages on the domain, for example:<link rel=”alternate” href=”https:// uk.sizegenetics.com/ ” hreflang=”en-GB” />
<link rel=”alternate” href=”https:// ca.sizegenetics.com/ ” hreflang=”en-ca” />
<link rel=”alternate” href=”https:// au.sizegenetics.com/ ” hreflang=”en-au” />
<link rel=”alternate” href=”https:// sizegenetics.com/ ” hreflang=”en-US” />
<link rel=”alternate” href=”https:// sizegenetics.com/” hreflang=”en” />
<link rel=”alternate” href=”https://sizegenetics.es/ ” hreflang=”es-ES” />
<link rel=”alternate” href=”https://sizegenetics.com/es/” hreflang=”es” />
- More language sites with checkout processes tailored to the country, including trust factors such as local delivery providers and flags. Also start to look into country-specific split tests where appropriate, since buyer behaviour and UX expectations vary globally.