Introduction to multi / International domain setups

International SEO is a very complex topic with many different aspects to it. In this course, we’ve mostly talked about Google so far. We covered how Google does certain things and how Google evaluates websites regarding SEO, etc. However, this is a very limited picture. Granted, globally Google is the biggest player in the world but there are other search engines that are active in certain markets and regions. You have to pay attention to them as well to be successful on a global scale. For example, Baidu is super important in China, the same is true for Yandex in Russia. Other relevant search engines are Bing and Seznam and Naver.

So, let’s talk about keywords first. The big mistake that happens all the time is that people try to simply translate keywords. Sure, all engines will still work and return results based on what you put in, but you’re clearly missing out. When you translate a keyword to another language it might have a similar meaning, without being exactly the same. Also, by simply translating words you miss out on synonyms. Depending on the language there might be multiple words to describe the same thing: For example, the words “car insurance” have up to three different variations in Germany. If you just translate them you’ll be missing out on a significant amount of potential search traffic.

As a side note, it’s even more important to understand cultural differences. There is a different perception of color in many cultures. These differences need to be considered while building local presences, crafting local ad copy, meta descriptions, etc.

But since we’re talking about technical SEO in this course, let’s move on and cover domains in the context of international SEO.

There are two different ways – or better said three – on how to serve international domains:

When you have different types of ccTLDs, you could use country code top-level domains, like domainname.fr, domainname.es.

Or you could also have a generic TLD, that could be, e.g. domainname.com. With .com you can either decide to use country- and language-specific folders on that .com or similar to Wikipedia you do language-specific sub-domains. So using the gTLD you’d have to select between subfolder or subdomain – depending on your needs.
For ccTLDs there is a strong default geo-targeting, e.g. Google takes .fr and knows that it is supposed to rank in France. Differentiating from a technical perspective is easy. Disadvantages are that you have to register everything in the respective local market individually. There are sometimes legal restrictions, and in the worst case, ccTLD is not available anymore.

In comparison, the biggest advantage of gTLDs is that you do not have to mess around with different domains. It is one single CMS that is more cost-effective to maintain and develop, and from the inbound linking perspective, all the links help strengthen this one .com domain – rather than being split up and distributing link juice to all the different ccTLDs.

Also, the gTLD probably already has some trust. It is way easier to pass this along into the subfolders as opposed to linking your ccTLDs or even the subdomains with each other.

From an inbound link equity perspective, the global gTLD approach is most efficient. You do not need any multisite functionality as would be the case with subdomains on the gTLD.

So, my recommendation is to go for .com as a gTLD and then establish language and/or country-specific subfolders. Make sure you use the features that search engines provide E.g. Google has the ability in Google Search Console to set up individual properties based on language or country directories, and you can also do individual geo-targeting. In the past, there was a problem of missing strong geo-signals, but nowadays you can override it with GSC – which really helps to target the region that you want. Also, make sure to properly implement hreflang, we’ll cover this later in this chapter.

Geo redirects & CDNs

Another very important aspect of international SEO is dealing with international requests from different geographical regions.

Bear in mind, these requests are not just the ones that your users make (that hopefully end up on the most appropriate language or country version anyway). It is also important to know how to deal with search engine crawlers.

For example, Googlebot mainly does its crawling from the United States. Let’s consider the following scenario: If I were physically in Germany and tried to access your US site, then – if you were using geo redirects based on my dial-in IP address – I would automatically be redirected to your German website. And technically speaking that’s fine. It is just important to understand that Google almost always crawls from the US. So if you had some kind of geographical restrictions on the German site that didn’t allow any US-based traffic, this could cause a massive problem as that domain would not be crawled by Googlebot. You clearly do not want this to happen. If you‘re involved with any kind of automatic redirects, make absolutely sure that they are using the appropriate HTTP response status code. There are two that would work, either a 302 found or 303 suggesting that it is another resource. Personally, I prefer the 303. Those two status codes will also ensure that those requests won’t ever be cached – which would happen for a 301; and that’d cause potentially even more problems.

Generally speaking, I really don’t like to be forced to another geolocation and then to have to figure out how I can order from the US or UK while being in Germany; it is really annoying and a bad user experience. So please don’t do it – an overlay pointing me to my appropriate language/country version is really more than enough.

For international SEO, CDNs are important if you want to deliver a fast experience. If you serve in multi-region (Asia, US, and Europe), it is not enough to host in a single location as the latency of those server responses is simply too high. This is where a content delivery network (aka CDN) can come into play. Unfortunately, there is no one-size-fits-all solution. Also, bear in mind, that if you want to be successful in China you need to have local hosting. Otherwise, there is no way for you to be ranked within China, whatsoever. So even if you’d have a CDN, it’s not a workable solution for some markets.

Consider the regions where the majority of users you are targeting are located. Consider that in Africa bandwidth is limited and internet access is mainly from mobile devices. This means, if you are going to use your built-for-desktop-site, you might not get a good reaction from those users. It is about understanding the audience and their capabilities. Many mobile devices are not up to date. From a web performance perspective, for example, they cannot handle Javascript fast enough and may not have 4g+. So it may be about trimming down sites and tailoring them to the geo-locations that you wish to serve.


When your website starts to receive significant traffic from Google`s foreign sites and you have the capability of serving these international countries, it’s time to implement an international version of your site and develop your international SEO strategy further.

We have already talked about domains, subdomains, and subfolders. In addition to these, implementing hreflang tags would be the next logical step, and they can really help a lot. Hreflang tags tell Google which version of the website should be shown in which country. It ensures that the correct language version of the site is shown to the right user in the correct country. Essentially, it is a way to create a better user experience.

The simplest approach is to have language-specific versions. You have one website for all German-speaking people, one website for all English-speaking people and you might have another one for people who speak French.

However, we all understand that German in Germany can differ from German in Switzerland, the same is true for English in the States versus English in the UK, so you‘ll most likely end up combining regional and language-specific directories with each other.

For example, you can set an hreflang tag that reflects one URL that is available for French in Belgium and another for French in France.

The simplest approach to implementation is to think about another group of HTML tags. You have to connect a set of URLs with each other. For simplicity let’s choose English, German and French. On all of these URLs, you will be adding three lines of the same code to their HTML. , then the hreflang attribute with its value being de for Germany, en for English and fr for French respectively. Href is the location of the language versions‘ URL.

Once this is done, Google needs to recrawl all three URLs to see if the tag is actually present. In the interim, Google can report errors in Search Console saying that there is a circular reference missing or that something is broken. Don‘t worry about it too much if you work with large-scale sites. It can take a long time before Google figures out that all tags are present on each and every URL.

You should also be aware that it is not just possible to specify hreflang in HTML; it can also be done more globally and at scale. Personally, I would prefer to create a dedicated XML sitemap, not only to feed URLs to Google but also to have one centralized location and tool that is going to maintain and manage hreflangs on a global scale. It is especially helpful when you deal with large scale sites. If you have 20, 50 or even 100 different pairs of language-region combinations to manage and maintain, it will massively bloat up the source code, slow down the site and will make it really unmanageable. So when the setup is getting more complex, I strongly vote for an XML sitemap. Very often in large organizations, this can be maintained more easily as it is one project, one job, fewer stakeholders, etc. – and you do not have to talk to different regions, different teams and different managers of the CMS system. XML sitemaps are a good way to control and manage hreflang setups.

You can also deploy hreflang using x-robots headers. Basically, you can do the same with the header as you would in HTML with your hreflang tags. This could be a feasible solution for PDFs, for example, where you can’t deploy any HTML hreflang.

There is also a special directive called x-default. If you are looking for a catch-all fallback solution regarding languages, this could help. Say you are serving Spain and Italy, so you’ve set up two hreflangs for those. Now let’s further assume you have an English site which you’d want everyone else to end up on – so serving English as a fallback. In this case, the x-default would be very useful.

The last recommendation would be to make sure you work with a tool that validates the implementation. Lots of things can go wrong, for example, there could be invalid country-language pairs, or some circular references could be missing. To automate the testing and validation, using tools to make sure (during deploy or before deploy) that what are you‘re doing or planning on doing is actually valid. The SEMrush Site Audit tool has a whole report devoted to the international SEO implementation. It informs you of issues your website has with hreflang values, conflicts, and incorrect links, as well as hreflang language mismatch issues.

Learn Technical SEO with Digitalgeetam

  1. Ultimate Guide To Website Performance Optimization
  2. XML Sitemap
  3. Redirects
  4. JavaScript SEO
  5. Internal Linking
  6. Log File Auditing
  7. Structured Data
  8. Accelerated
  9. X Robots Header
  10. Post Redirect Pattern
  11. SEO Friendly URL
  1. This article is one of the best articles I have read on this topic. Your article is very informative and I must appreciate your writing skills. Thank you for writing such an amazing article. I am definitely gonna share it with my friends. Keep writing such fresh and new content.

Leave a Reply

Your email address will not be published. Required fields are marked *