Implement International SEO

International SEO is an important topic, especially for export nations. However, it is also a topic that is often taken lightly because people are not aware of many strategic aspects, especially with regard to SEO.

There are many aspects that should be clarified in general before moving on to the optimal technical implementation.

Decision #1: Domain/URL Strategy

The fundamental question of domain/URL strategy is about a key ranking criterion: external linking. How strongly the respective domain is linked is not insignificant for the rankings of a website. Therefore, this has an influence on the optimal SEO strategy.

Generally, there are three possible setups for international websites:

  1. One domain per country, e.g., mywebsite.co.uk, mywebsite.de and mywebsite.it.
  2. One domain with subdirectories, e.g., mywebsite.com/uk/, mywebsite.com/de/ and mywebsite.com/it/.
  3. One domain with subdomains, e.g., uk.mywebsite.com, de.mywebsite.com and it.mywebsite.com.

If you decide on the first solution (one domain per country), then each website will be on a stand-alone basis. So, for example, if someone links to the .co.uk domain, the .it domain does not benefit from this in any way. And if no one links to the .it domain, it will not be able to generate relevant rankings.

The second and third solution work differently, because here external links contribute to the entire domain. To some extent, the /it/ content then benefits from someone linking to the /uk/ content.

By the way: “In the past” there used to be other solutions to display international aspects in the URL, e.g., with URL parameters like www.mywebsite.com/homepage?lang=fr. However, these have many disadvantages in terms of SEO, so you hardly find this nowadays. In any case, it is not recommended.

Are my backlinks sufficient?

In case you want to use a separate domain for each country, you need to answer a key question honestly: Are you able to obtain enough external backlinks in each country? To determine the status quo, you can of course use the SISTRIX link database, which shows, for each domain, from how many other domains it is linked.

However, a critical look or rather a deeper look at the data makes sense here. An example: The company Jongen Werzeugtechnik has decided to use a separate domain for each country (www.jongen-unimill.com, www.jongen.it …). SISTRIX assesses the so-called domain popularity of the domain www.jongen.it as 28, which means that 28 different domains link to this domain. However, if you take a look at the linking websites, you will quickly notice that there are many “internal links” from other Jongen domains as well.

Therefore, the real domain popularity is significantly lower, because Google most likely subtracts the “internal links” and does not evaluate them. From the 28 linking websites, only 17 remain.

So, is this figure good or bad? There are no general and clear threshold values for this. Here, you need to examine the competitors in the respective target country in order to find out whether you are on the losing end or whether you have real chances in terms of links.

Once you do this for all target countries, you will often realise that there is a well-linked website for the company’s country of origin (e.g., the UK), while the degree of linking is rather inadequate for other countries.

In general, the rule is that smaller companies should rely on a single domain, because they often do not manage to generate enough prominence in other countries, which is then reflected in the form of backlinks.

Generic vs. Country-Specific Domains

Another aspect should also be considered: Google generally divides domains into country-specific domains (ccTLDs, e.g., .de, .it, .fr) and generic domains (gTLDs, e.g., .com, .net, .info). Country-specific domains have the advantage that they are optimally oriented towards one country. Therefore, a .de domain is perfect for Germany. For other countries, however, this advantage can be rather negative.

Therefore, it is recommended to use a generic domain when bundling multiple languages/countries in a single domain.

By the way, Google classifies some country-specific domains as generic domains, because they are more likely to be used as such. This applies to the domain .tv, for example, which is actually a ccTLD for the island nation of Tuvalu but is in fact rarely used in this way. Google offers an overview of these domains on this help page.

Even among the “new domains” (see https://en.wikipedia.org/wiki/Generic_top-level_domain#New_top-level_domains) there are some domains that seem to have a local reference, e.g., .berlin or .africa. However, these are considered generic domains and therefore offer no SEO advantage for the respective region.

Subdomain or Subdirectory?

There is one question we have ignored up to this point: If you decide to use a single domain, should you go for subdirectories (mywebsite.com/fr/) or subdomains (fr.mywebsite.com)?

The answer to this age-old question probably leans more towards “subdirectories”. At least, the analysis of many international websites shows that this solution is preferred.

Hybrid Solutions are Possible

As so often in life, when deciding on a domain/URL strategy, there are of course interim solutions. It is not uncommon for companies to choose to use a country-specific domain (e.g., .co.uk and .de) for the most important markets and to bundle all other markets in a single generic domain.

Note: Do Not Forget Redirects

The domain/URL concept should never be taken lightly, because incorrect implementation can lead to great losses in the rankings. Most important in any case are 301 redirects, which redirect from the previous structure to the new URLs.

So, for example, if you used to use a country-specific domain for each country in the past, after the switch to a single generic domain, you need to ensure that the old URLs like mywebsite.de/x redirect to mywebsite.com/de/x.

Decision #2: Language, Country or Language-Country?

Along with the question of “URL mapping” (domains, subdirectories/subdomains), the question of what exactly you map there also arises. There are three possibilities for this – each illustrated using the example of a subdirectory solution:

  1. www.mywebsite.com/german/ (language): All German-language content is filed into this subdirectory.
  2. www.mywebsite.com/germany/ (country): This is where the content for Germany is filed – in this case, probably in German.
  3. www.mywebsite.com/german-germany/ (language-country): This subdirectory contains all content for Germany in German language.

At what point is this question even relevant? Unfortunately, there are many international websites that provide an English-language section for many countries, e.g., www.mywebsite.com/kenya-english/ and www.mywebsite.com/norway-english/. Since the wheel is not completely reinvented in that case, there is then a lot of duplicate content that can lead to real indexing problems. Even if you add the correct canonical tags, Google will often decide against these instructions.

Ideally, such duplicates should not exist in the first place. Therefore, the best practical solution is to use language trees, e.g., /language/ instead of /country/. Of course, there can always be cases in which language-country trees make sense – for example, for online shops that have different prices and availabilities for different countries. For the majority of internationally oriented companies, however, it is recommended to avoid duplicates and work with language trees instead.

Technical Implementation of Internationalisation

Technical Implementation #1: Hreflang Tags

In terms of technical implementation, international websites should use hreflang tags. These are tags that can be found in all variants of a page and that mutually refer to all variants. So, for example, if a website has the two pages /en/homepage.html and /de/startseite.html, you can include the following tags in both pages:

<link rel=”alternate” hreflang=”en”
href=”https://www.mywebsite.com/en/homepage.html “/>

<link rel=”alternate” hreflang=”de”
href=”https://www.mywebsite.com/de/startseite.html “/>

Of course, these tags can also be generated manually (e.g., with the SISTRIX generator). However, this is certainly not practical, so that in practice the shop or content management system should always generate the hreflang tags automatically. By the way, hreflang tags always apply per page, so it does not suffice to only include them in the homepage.

In any case, it is important to know that hreflang tags do not improve the Google ranking. They just ensure that the correct content is displayed. So, if someone searches something and Googles decides on a specific page in the search results, Google will exchange this page for the most suitable variant in the same moment. Because the user immediately lands on a suitable page, this can still yield conversion benefits, for example.

Another thing you should know: Not every website necessarily needs hreflang tags. If a website has an English-language and German-language content tree (so, /en/ and /de/), Google will generally direct the user to the correct section depending on their search query and origin. It is highly unlikely for someone who enters a German-language search query to be directed to an English-language search result, even without hreflang tags. Of course, adding a hreflang tag does no harm here, but it also does not generate a positive effect. So, if the implementation of hreflang tags turns out to be very extensive, you can also forgo them for some websites.

This is different for websites that have different country trees for one language, e.g., /de-de/ and /de-at/. In that case, both contents are considered equal and Google can send a user from Germany to the content created for Austria. This can best be seen in the following Visibility comparison, which compares www.zalando.de and www.zalando.at in Austria:

Before 2014 www.zalando.de often had a higher Visibility in Austria than the actual, “better” domain www.zalando.at. It was only with the introduction of hreflang-tags that the tables turned, so that since then www.zalando.at has been the primary domain in Austria.

Technical Implementation #2: IP Redirect

Many companies also identify their users based on their IP addresses. So, depending on the programming of the website, it is possible that someone with an IP address from Austria is automatically redirected to the Austrian page. The user who visits the page https://www.mywebsite.com/ will then be redirected directly to https://mywebsite.com/at/. This is a so-called IP redirect.

Generally, this is quite unproblematic and rather a question of UX, but with regard to SEO, using an IP redirect can have real consequences, because Google also crawls websites with a certain IP address. This address is usually assigned to the US. So if the website is programmed to always redirect users with an IP address from the US to the US content, Google will not be able to crawl the non-US content and index it as well.

The best solution would be to avoid using IP redirects altogether, so that such problems do not occur at all. If you do not want to do this, you must ensure that the redirection does not apply to search engine crawlers – especially Googlebot. This should be checked with the “URL Inspection Tool” in the Google Search Console.

Technical Implementation #3: Internal Linking

Google mainly accesses the content of a website through internal links. Of course, this should also apply to the international content. Therefore, all international homepages (e.g., /de/, /it/, /fr/ …) should be linked from all pages so that the Googlebot can also reach them.

An ideal place for this is the “flag navigation” found on many websites, where you click on a flag or on text to select a language/country. However, such a navigation can be implemented in various ways, so it may happen that there are no internal links readable for search engines, when using JavaScript. Here, you need to ensure that the links can also be recognised as such by search engines.

Technical Implementation #4: Localise Everything

Even though this shouldn’t be a specific requirement, this is still mentioned here because it is so often done wrong: If a website offers content in different languages, all elements of a page should also be adjusted to the respective language.

Ideally, this should include all the following elements:

  • Page title
  • Meta description
  • URL or the URL path
  • The content of a page (main content, but also all navigation elements)
  • Markup (e.g., the BreadcrumbList markup or Video markup)
  • Images (especially: image URL, alt attribute, caption)
  • Possibly social media tags (Open Graph tags, Twitter Cards … – not relevant for SEO)

Therefore, it is necessary to assess in each case which options are available for these page elements with regard to the shop or content management system.

Conclusion

Internationalisation generally revolves around a few fundamental issues: Which domain/URL structure makes sense for your company? And do you need language, country or language-country trees for your content? Of course, these questions can only be answered on a case-by-case basis, but you can still find recommendations for the typical case in this article.

Then it is a matter of implementing that technically and in the best way possible. It is not difficult to find websites where German page titles are displayed on French pages. Many practical detail errors happen here that are entirely avoidable.

At the end of the day, content is also a fundamental issue. Many companies simply translate their content, while others adapt it to the requirements of the respective country. If “content” truly is “king”, this should of course also apply to internationalisation.

The SEO Strategy Guide

Take the next step in this training program. This set of learning documents will help improve your SEO results and the way you use SISTRIX.

Overview

SEO Strategy Made Easy

Introduction to the SISTRIX step-by-step guide

International SEO

How do I display multiple languages and countries optimally for search engines?

This guide was created in cooperation with Markus Hövener from Bloofusion. Your feedback is welcome.

Steve Paine