hreflang tags implementation guide – How to implement hreflang

Webmasters who serve several versions of their content in different languages or for users in different countries should use hreflang annotations to help Google show the right version in the search results for each user.

Note: This guide was first published on rebelytics.com in 2014 and has since then been updated several times and moved to this blog.

The correct implementation of hreflang can be quite a challenge. With this guide, I want to help you develop a correct implementation for your website. However, there is no one-size-fits-all-solution for hreflang. So if anything remains unclear, feel free to ask your questions in the comments section of this article. I normally reply within a couple of days.

Google provides instructions for implementing hreflang, but when you look at how hreflang is implemented on most websites, it becomes clear that those instructions are often misunderstood by webmasters. Before you continue reading this article, you should still check out Google’s instructions here.

After reading Google’s official instructions, following the advice in this article will help you avoid the most common mistakes and provide you with some additional tips.

Here we go! These are the steps I want to walk you through. How do you implement hreflang correctly?

• Step 1: Determine whether you need hreflang annotations on your website
• Step 2: Create a map of your website’s language and country versions
• Step 3: Double-check your website structure and domain strategy
• Step 4: Assign an hreflang value to each language and country version
• Step 5: Check if you need hreflang=”x-default”
• Step 6: Decide which pages to link with hreflang annotations
• Step 7: Decide which hreflang implementation method to choose
• Step 8: Implement hreflang on your website
• Step 9: Create a Google Search Console Property for each language and country version
• Step 10: Align your international targeting options in Google Search Console with your hreflang implementation
• (OPTIONAL) Step 11: Audit your hreflang setup with searchVIU

Step 1: Determine whether you need hreflang annotations on your website

It’s quite simple: As soon as there is more than one version of your website for users from different countries or if your website is available in different languages, you should consider implementing hreflang annotations on your website.

Here are some typical examples of websites that require hreflang annotations:

• Example 1: A website in English language with a version for the US, a version for the UK, and a version for the rest of the world.
• Example 2: An international website with English, French and Spanish language versions.
• Example 3: A global website with one version for Europe, one for the US and Canada and one for Asia/Pacific, all in English language.
• Example 4: A website that targets users in the US with an English and a Spanish language version.
• Example 5: A website with several country domains, some of which have more than one language version (for countries with more than one language spoken).

We will be using these examples throughout this guide and we will develop a correct hreflang implementation for all of them.

Is your website similar to one of the examples above? In this case you most likely need an hreflang implementation. Let’s get started by getting a clearer picture of your international or multilingual website structure.

Step 2: Create a map of your website’s language and country versions

The purpose of hreflang annotations is to signal to Google that there are several versions of a URL for users of different languages or from different countries. URLs for users of the same language or from the same country are normally grouped into language or country versions of a website. So, in order to determine which hreflang values each URL on your website should receive, it is a good idea to start by mapping out exactly which users your different website versions target.

I suggest you start by creating a table with the following three columns:

• Website version: Your website versions can be located in different subdirectories on the same domain, on different subdomains or on different domains.
• Language: Each website version can be assigned exactly one language, the language of the content of this version. Make sure you do not mix languages within website versions.
• Countries: Last but not least, each website version can target users in any number of countries ranging from 1 country to all countries in the world.

For some websites, this table might be very simple, but for others, especially websites with lots of different version, this approach will be very helpful.

Let’s recall the examples for different international or multilingual website structures from the previous step and have a look at what the structure map would look like for these examples.

Example 1: A website in English language with a version for the US, a version for the UK, and a version for the rest of the world.

Website version	Language	Countries
https://www.rebelytics.com/us/	English	US
https://www.rebelytics.co.uk/	English	UK
https://www.rebelytics.com/en/	English	Rest of the world

This is a typical example for companies from the UK or the US that have already expanded into the other market and are targeting English speaking users from the rest of the world on top of that. Note that here, the UK content is hosted on a .co.uk domain, but it might as well be hosted on the .com domain, like the other two versions. This example is just to show that hreflang can be implemented across different domains.

Example 2: An international website with English, French and Spanish language versions.

Website version	Language	Countries
https://www.rebelytics.com/en/	English	All countries
https://www.rebelytics.com/fr/	French	All countries
https://www.rebelytics.com/es/	Spanish	All countries

This is an example of a company targeting users globally in different languages, a scenario you often see with location-independent companies in B2B sectors, like SaaS or similar industries. All three language versions are hosted on the .com domain in different subdirectories.

Example 3: A global website with one version for Europe, one for the US and Canada and one for Asia/Pacific, all in English language.

Website version	Language	Countries
https://www.rebelytics.eu/	English	Selected countries in Europe: Austria, Belgium, Switzerland, Czech Republic, Germany, Denmark, Finland, France, UK, Greece, Hungary, Croatia, Ireland, Iceland, Italy, Luxembourg, Norway, Netherlands, Poland, Portugal, Romania, Sweden
https://www.rebelytics.com/	English	US, Canada
https://apac.rebelytics.com/	English	Selected countries in Asia/Pacific: Australia, China, Hong Kong, India, Indonesia, Japan, Malaysia, New Zealand, Philippines, Singapore, Taiwan, Thailand, Vietnam

Global brands often separate their web presences into versions for economic zones or continents, and this structure often represents the top-level organisational structure of the corporation. Although I would prefer a more user-centric approach to structuring website versions, this is a scenario we do see a lot in reality and it is one that we need a good hreflang solution for. The mixed domain and subdomain structure is also something I would not necessarily recommend, but structures like this one do exist and should be accounted for. If your website structure resembles this example, this guide will provide a solution for you!

Example 4: A website that targets users in the US with an English and a Spanish language version.

Website version	Language	Countries
https://en.rebelytics.com/	English	US
https://es.rebelytics.com/	Spanish	US

This is a website structure you will see a lot in countries that have more than one language spoken. The country and the languages in this example could be replaced and you will often see this structure on a country-specific domain, like .be for Belgium or .ca for Canada.

Example 5: A website with several country domains, some of which have more than one language version (for countries with more than one language spoken).

Website version	Language	Countries
https://www.rebelytics.de/	German	Germany
https://www.rebelytics.be/fr/	French	Belgium
https://www.rebelytics.be/nl/	Dutch	Belgium
https://www.rebelytics.at/	German	Austria
https://www.rebelytics.ch/de/	German	Switzerland
https://www.rebelytics.ch/fr/	French	Switzerland
https://www.rebelytics.co.uk/	English	UK

The last example we are looking at in this guide is typical for e-commerce players that operate across several countries. While B2B companies tend to choose global language versions over country versions, online shops and other B2C companies often prefer country versions. Country-specific versions can be hosted on country-specific domains, like in this example, but they can also be hosted on subdomains or in subdirectories on a generic domain.

I deliberately mixed different domain, subdomain and subdirectory strategies in the examples above, in order to show you that you can implement hreflang across almost all combinations of domains, subdomains and subdirectories.

A note on international domain strategies: My favourite approach is to avoid different domains and subdomains and to group all website versions in different subdirectories on the same domain. I have good arguments for this, but I will not discuss them in this article and not today 😉 Give me a shout if you want to talk about international domain strategies with me!

So, have you mapped out your international or multilingual website structure? I hope so! If you have an international or multilingual website structure that is completely different from the examples listed here, I would love to hear about it! Now, let’s continue with step 3…

Step 3: Double-check your website structure and domain strategy

If you have read the previous step carefully, you probably noticed that I said that you can implement hreflang across almost all combinations of domains, subdomains and subdirectories. Caution, there is one important rule that you need to pay attention to when developing your hreflang implementation strategy:

Google automatically interprets content on country-specific domains (ccTLDs) as targeted at users from exactly one country.

ccTLDS (country code top-level domains), as opposed to gTLDs (generic top-level domains), are domains that are associated with a specific country. gTLDs, on the other hand, are not country-specific.

This has important consequences for your international targeting. With a subdirectory or a subdomain on a ccTLD (i.e. a country domain), you should only target users from the country that your ccTLD is associated with.

Are you looking for proof for what I’m saying? Go to a Google Search Console property for a gTLD, open the report Search Traffic > International Targeting, change the tab to “Country” and have a look at the options you have here to target your content at users from a certain country.

You will see that, for each property on a gTLD that you verify in Google Search Console, you can choose to target the content within this property at users from a specific country. This targeting option will become crucial for you at a later stage in this guide if you are targeting users in certain countries with content on a gTLD.

Now, go to the same report in the Google Search Console property for a ccTLD and try to change the country in the option “Target users in … “ you just saw in the property for the gTLD. See what I’m going on about?

For ccTLDs, Google does not let you specify a country. Rather, the country is already specified by the ccTLD you chose. You will learn more about this targeting option in step 10. For now, let’s see what you can do to avoid problems with this.

The following example would not work, as it would involve trying to target users outside of the UK with a ccTLD that is associated with the UK (.co.uk):

Website version	Language	Countries
https://www.rebelytics.co.uk/us/	English	US
https://www.rebelytics.co.uk/uk/	English	UK
https://www.rebelytics.co.uk/en/	English	Rest of the world

If you use ccTLDs, in Google’s eyes, you automatically target users from the corresponding country and not users from other countries with the content on your domain.

Before you move on, make sure that, in the previous step, you have not created a structure where a website version that is hosted on a ccTLD targets users in countries other than the country associated with the ccTLD.

This also goes for the targeting options “Rest of the world” or “All countries”. Website versions that target users in several countries should always be hosted on gTLDs.

Speaking of gTLDs, which (in case you have not noticed) I am a huge fan of, let’s have a look at a potential of multilingual and international websites that lots of businesses miss out on: Do you have a website structure with several versions for different countries but no version for the rest of the world? Why would you want to miss out on more potential traffic by not creating a website version for users outside of your main target markets?

Let’s assume you have a website with several country versions (no matter whether you host them on a gTLD or on ccTLDs), but no generic language versions for users in other countries. Your structure could look like the one we already saw above (example 5):

Website version	Language	Countries
https://www.rebelytics.de/	German	Germany
https://www.rebelytics.be/fr/	French	Belgium
https://www.rebelytics.be/nl/	Dutch	Belgium
https://www.rebelytics.at/	German	Austria
https://www.rebelytics.ch/de/	German	Switzerland
https://www.rebelytics.ch/fr/	French	Switzerland
https://www.rebelytics.co.uk/	English	UK

Here, it would make sense to add generic language versions on a gTLD in the languages we already have in order to better target users outside of the markets we already have website versions for. This would leave us with the following structure:

Website version	Language	Countries
https://www.rebelytics.de/	German	Germany
https://www.rebelytics.be/fr/	French	Belgium
https://www.rebelytics.be/nl/	Dutch	Belgium
https://www.rebelytics.at/	German	Austria
https://www.rebelytics.ch/de/	German	Switzerland
https://www.rebelytics.ch/fr/	French	Switzerland
https://www.rebelytics.co.uk/	English	UK
https://www.rebelytics.com/en/	English	Rest of the world
https://www.rebelytics.com/de/	German	Rest of the world
https://www.rebelytics.com/fr/	French	Rest of the world
https://www.rebelytics.com/nl/	Dutch	Rest of the world

This structure targets the same users as example 5 above, but on top of that, it provides website versions for users in other countries that speak one of the languages already available. As the languages are already available, it is normally not a big effort to add these additional versions to a website and a lot of additional search traffic can be driven this way.

Now that we’ve made sure that you have a decent international or multilingual domain structure, we’re all set for defining a hreflang value for each website version. The next step is dead simple, so let’s move on quickly:

Step 4: Assign an hreflang value to each language and country version

With all the good preparation we have done in the previous steps, nothing much can go wrong here. There are a few simple rules we have to follow when defining hreflang values for our website:

• Each hreflang value consists of a language code and, optionally, a country code. The language code and the country code are separated by a hyphen.
• The language codes have to be in the format ISO 639-1, the country codes in the format ISO 3166-1 Alpha-2.
• Each hreflang value can only be assigned once. This means you cannot have two website versions targeted at users of the same language and from the same country. Each combination of language and country has to be unique in your hreflang structure.
• URLs may receive multiple hreflang values. This will come in handy in examples like no. 3 above, where a website version targets users in multiple countries, but not all countries in the world.

Now, let’s add a fourth column to our website structure table from earlier on and get things going!

Example 1: A website in English language with a version for the US, a version for the UK, and a version for the rest of the world.

Website version	Language	Countries	hreflang values
https://www.rebelytics.com/us/	English	US	en-US
https://www.rebelytics.co.uk/	English	UK	en-GB
https://www.rebelytics.com/en/	English	Rest of the world	en

Here, the English version for users in the rest of the world receives only the language code for English, while the two country versions for the US and the UK receive the optional country codes.

Example 2: An international website with English, French and Spanish language versions.

Website version	Language	Countries	hreflang values
https://www.rebelytics.com/en/	English	All countries	en
https://www.rebelytics.com/fr/	French	All countries	fr
https://www.rebelytics.com/es/	Spanish	All countries	es

The website versions in this example are not country-specific, so they all just receive language codes and no optional country codes.

Example 3: A global website with one version for Europe, one for the US and Canada and one for Asia/Pacific, all in English language.

Website version	Language	Countries	hreflang values
https://www.rebelytics.eu/	English	Selected countries in Europe: Austria, Belgium, Switzerland, Czech Republic, Germany, Denmark, Finland, France, UK, Greece, Hungary, Croatia, Ireland, Iceland, Italy, Luxembourg, Norway, Netherlands, Poland, Portugal, Romania, Sweden	en-AT, en-BE, en-CH, en-CZ, en-DE, en-DK, en-FI, en-FR, en-GB, en-GR, en-HU, en-HR, en-IE, en-IS, en-IT, en-LU, en-NO, en-NL, en-PL, en-PT, en-RO, en-SE
https://www.rebelytics.com/	English	US, Canada	en-US, en-CA
https://apac.rebelytics.com/	English	Selected countries in Asia/Pacific: Australia, China, Hong Kong, India, Indonesia, Japan, Malaysia, New Zealand, Philippines, Singapore, Taiwan, Thailand, Vietnam	en-AU, en-CN, en-HK, en-IN, en-ID, en-JP, en-MY, en-NZ, en-PH, en-SG, en-TW, en-TH, en-VN

Every website version in this example targets more than one country, so they all receive multiple hreflang values. We will see how to implement this later on, but if you’re curious about assigning multiple hreflang values to one URL, check this out: Multiple hreflang tags can point to one URL.

Example 4: A website that targets users in the US with an English and a Spanish language version.

Website version	Language	Countries	hreflang values
https://en.rebelytics.com/	English	US	en-US
https://es.rebelytics.com/	Spanish	US	es-US

In this simple example, we see two versions with the same country code appended to different language codes.

Example 5: A website with several country domains, some of which have more than one language version (for countries with more than one language spoken).

Website version	Language	Countries	hreflang values
https://www.rebelytics.de/	German	Germany	de-DE
https://www.rebelytics.be/fr/	French	Belgium	fr-BE
https://www.rebelytics.be/nl/	Dutch	Belgium	nl-BE
https://www.rebelytics.at/	German	Austria	de-AT
https://www.rebelytics.ch/de/	German	Switzerland	de-CH
https://www.rebelytics.ch/fr/	French	Switzerland	fr-CH
https://www.rebelytics.co.uk/	English	UK	en-GB

All website versions in this example are targeted at a specific country on hosted on a ccTLD, so they all receive the optional country codes. Mind you, in this case the country codes are not really optional, as the website versions are hosted on ccTLDs. As we have learned above, ccTLDs are automatically associated with countries. In order to be consistent, URLs on ccTLDs should always receive hreflang values with the correct country code.

Step 5: Check if you need hreflang=”x-default”

If you have been doing research about how to implement hreflang on your website, you have most likely come across the concept hreflang=”x-default”. Google and Yandex introduced “x-default” in 2013 and it certainly hasn’t made the implementation of hreflang any easier for webmasters. Quite the contrary: This new value has caused a lot of confusion among international SEOs over the last few years, so let’s clear things up.

There are three scenarios in which you might want to assign the hreflang value “x-default” to a URL:

Scenario 1: Some of your URLs automatically redirect to another URL based on the user’s location or browser language:

This most often applies to home pages. In Example 2, which we last saw in Step 4, the URL https://www.rebelytics.com/ might redirect users who have English as their browser language to https://www.rebelytics.com/en/. Users with French and Spanish set as their browser languages might be automatically redirected to https://www.rebelytics.com/fr/ and https://www.rebelytics.com/es/, respectively.

In this case, the URL https://www.rebelytics.com/ would be included in the hreflang annotations and would receive the value “x-default”.

This is obviously not limited to home pages. Although cases like this are a lot rarer, the URL https://www.rebelytics.com/products/ might redirect to https://www.rebelytics.com/en/products/ for English-speaking users, to https://www.rebelytics.com/fr/produits/ for French speaking users, and to https://www.rebelytics.com/es/productos/ for Spanish speaking users.

In this case, an “x-default” version would not only be defined for the home page, but for all sub-pages of the website. We will learn more about implementing hreflang on an URL level in the next step of this guide.

Let’s have a look at what our website structure map with hreflang values would look like if we include this “x-default” scenario in Example 2:

Website version	Language	Countries	hreflang values
https://www.rebelytics.com/	default	default	x-default
https://www.rebelytics.com/en/	English	All countries	en
https://www.rebelytics.com/fr/	French	All countries	fr
https://www.rebelytics.com/es/	Spanish	All countries	es

In this case, Google would show the URL https://www.rebelytics.com/ to all users that are not using Google in English, French or Spanish. At this point it is important to note that Google will pull the information displayed in the search result snippet from the URL the Google bot is redirected to, so pay attention to this.

Let us now move on to the next (very similar) scenario where you might want to consider using “x-default”.

Scenario 2: For a set of versions of a URL for different languages or countries, you provide a default version with a country or language selector.

Like Scenario 1, this second scenario normally applies to (but is not limited to) home pages. In plain and simple English this situation would mean that your multilingual or international website has a home page where the user can select the language he or she wants the content to be shown in or the country he or she is located in (or both). The difference to Scenario 1 is that the selection of the right URL version for the user does not happen automatically by means of a redirect, but is executed manually by the user.

The hreflang annotations would be the same as in Scenario 1: The URL that hosts the language or country selector is assigned the “x-default” hreflang value, just like the URL that redirects the user based on the browser language or user location in Scenario 1. The result is also similar: Google will now show this version of the URL to users that are not using Google in English, Spanish or French, with the slight difference that here, the page provides its own content to be included in the search result snippet. Think about how to optimise this snippet for a global audience!

The third and last scenario is one that can be used by almost all websites that do not separate URLs with an automatic or manual language or country selection like the ones described above.

Scenario 3: You want to declare one of the website versions you already have assigned a hreflang value to as the default or fallback version for users who use languages or are located in countries that you do not have a website version for.

This scenario can easily be applied to all of the examples we have seen above. Just pick one of the website versions you have already defined hreflang values for and add the value “x-default” to it if you want this version to show for all users that use languages or are located in countries you do not have a website version for.

If we wanted the English Rest of the world version in Example 1 to also be the fallback version for all users that use Google in a language that is not English, we would simply add the value “x-default” to this version:

Website version	Language	Countries	hreflang values
https://www.rebelytics.com/us/	English	US	en-US
https://www.rebelytics.co.uk/	English	UK	en-GB
https://www.rebelytics.com/en/	English & default	Rest of the world	en, x-default

This way we let Google know that we want https://www.rebelytics.com/en/ to be the version of this URL that we want to be shown to users that we have not specified a website version for.

Now that you have defined all of the hreflang values you need, we can almost move on to the implementation! But before we do that, let us talk about one more very important topic: The implementation of hreflang on a URL level. As you probably already know, every set of URLs on your website receives its own hreflang annotations (so far, we have only assigned hreflang values to entire versions of your website). The implementation of hreflang on a URL level can be a bit of a challenge, so in step 6, we will talk about how to avoid the most common mistakes with this.

Step 6: Decide which pages to link with hreflang annotations

hreflang annotations have to be implemented on a URL level. This means that every set of URLs (different language and country versions of one URL) receives its own set of hreflang annotations. When implementing hreflang on a URL level, it is important to pay attention to the following details.

First of all, not all of your pages might exist in all language or country versions of your website. Make sure you do not use hreflang annotations to point to pages that do not exist. I have seen this go terribly wrong on several occasions.

Secondly, make sure that only pages that are supposed to be indexed by search engines receive hreflang annotations. hreflang is always an indexing signal, so you do not want hreflang annotations pointing to pages that you do not want in the index.

This second point is particularly important when you have a canonical tag solution implemented on your website (to solve a duplicate content problem). Make sure not to use hreflang annotations for non-canonical URLs (URLs that have a canonical tag pointing to another page). You can read more on how to use canonical tags and hreflang together here:

How to use hreflang and canonical tags together

Determining which pages receive hreflang annotations might be a bit tricky for you if there are big differences between your website versions or if you are a heavy user of canonical tags. Just make sure that you account for all of the exceptions and that only pages that are supposed to be linked with hreflang receive annotations.

If you are using separate mobile URLs, Google currently recommends to have one set of hreflang annotations linking the different country and language versions of your desktop URLs with each other and another set of hreflang annotations for your mobile URLs. The same is valid if you are using AMP: Desktop URLs are linked with their desktop equivalents and AMP URLs with their AMP equivalents in other languages or for other countries. Read more about this topic here.

Now that you have completed your hreflang structure, you just have to decide how you want to implement hreflang. Read on to learn more!

Step 7: Decide which hreflang implementation method to choose

There are three methods for implementing hreflang on your website that you can choose from:

• In the header section of the HTML code of each page
• In XML sitemaps
• In the HTTP header of each page

Let me walk you through the pros and cons of the three methods.

Implementing hreflang in the header section of the source code of each page

I am pretty sure that this is the most popular version across all websites that use hreflang, probably because it is the simplest one to implement for most developers.

Google normally processes the information included in the header section pretty well, so this is an option that I have had good experiences with in the past and that I can definitely recommend.

However, there are a couple of disadvantages of this method that I would like to share with you.

First of all, if you need an x-default value for a default home page that redirects users based on their location or browser language (see Scenario 1 in step 5), you will automatically generate a hreflang error if you opt for the source code variant: As the x-default version redirects to another URL and therefore does not have a source code, you will not be able to link back from the x-default version to the other language and country versions. Reciprocal links are a basic requirement of hreflang, so if your website has a home page that redirects users based on their browser language or location, you should probably choose one of the other two options to implement hreflang.

Also, if your website needs lots of hreflang annotations for different language and country versions (like in example 3 below), your hreflang annotations will get pretty long. Some might argue that including a lot of additional code in the header section of your pages will slow down your page load times, and they probably have a point. However, I believe that this also applies to the other methods: If you have lots of hreflang annotations, you always need a lot of code.

Let us have a look at how the hreflang annotations for some of our examples would look like, if implemented in the header section of each page.

Example 2 from above was a global website with English, French and Spanish website versions. The home pages of the three website versions would all receive the following set of hreflang annotations:

<link rel="alternate" hreflang="en" href="https://www.rebelytics.com/en/" />
<link rel="alternate" hreflang="fr" href="https://www.rebelytics.com/fr/" />
<link rel="alternate" hreflang="es" href="https://www.rebelytics.com/es/" />

If there was a “products” page on each of the website versions, this set of URLs would receive the following set of hreflang annotations (and so on for all other URLs that exist on more than one of the website versions).

<link rel="alternate" hreflang="en" href="https://www.rebelytics.com/en/products/" />
<link rel="alternate" hreflang="fr" href="https://www.rebelytics.com/fr/produits/" />
<link rel="alternate" hreflang="es" href="https://www.rebelytics.com/es/productos/" />

Example 3 from above was also a website with three different versions, but each of them was targeted at several countries. This would result in the following set of hreflang annotations for the three versions of the home page:

<link rel="alternate" hreflang="en-AT" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-BE" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-CH" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-CZ" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-DE" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-DK" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-FI" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-FR" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-GB" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-GR" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-HU" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-HR" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-IE" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-IS" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-IT" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-LU" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-NO" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-NL" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-PL" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-PT" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-RO" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-SE" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-US" href="https://www.rebelytics.com/" />
<link rel="alternate" hreflang="en-CA" href="https://www.rebelytics.com/" />
<link rel="alternate" hreflang="en-AU" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-CN" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-HK" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-IN" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-ID" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-JP" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-MY" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-NZ" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-PH" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-SG" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-TW" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-TH" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-VN" href="https://apac.rebelytics.com/" />

And, to complete this, let us have a look at the hreflang annotations for a possible set of “about us” pages on the three website versions:

<link rel="alternate" hreflang="en-AT" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-BE" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-CH" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-CZ" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-DE" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-DK" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-FI" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-FR" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-GB" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-GR" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-HU" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-HR" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-IE" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-IS" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-IT" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-LU" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-NO" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-NL" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-PL" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-PT" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-RO" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-SE" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-US" href="https://www.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-CA" href="https://www.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-AU" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-CN" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-HK" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-IN" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-ID" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-JP" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-MY" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-NZ" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-PH" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-SG" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-TW" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-TH" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-VN" href="https://apac.rebelytics.com/about-us/" />

I hope that these examples give you a good idea of what your hreflang annotations should look like if you decide to implement them as HTML link elements in the header section of your website’s source code. If not, just give me a shout and I’ll be happy to help.

Let us now have a look at another option of implementing hreflang: XML sitemaps.

Implementing hreflang in XML sitemaps

Let me tell you straight away: I have had very bad experiences with implementing hreflang in XML sitemaps and I have also spoken to other SEOs that have had similar problems.

Google does not crawl and process XML sitemaps as often as HTML pages and therefore has problems processing the information that is included in sitemaps on time. If you choose this option, you will probably experience lots of hreflang errors in Google Search Console and lots of pages being displayed to the wrong users in Google’s search results.

Developers often prefer implementing hreflang in XML sitemaps over implementing it in the HTML source code of each page when they are dealing with very big websites that have lots of different language and country versions.

I actually believe that a big amount of hreflang annotations causes a lot more trouble in an XML sitemap than it would in the header section of the source code of a page.

If you still want to implement your hreflang annotations in you XML sitemaps, go ahead and check out Google’s recommendations on the topic. I am now going to move on to the last (and probably best) method of implementing hreflang on your website:

Implementing hreflang in the HTTP header of each page

This is the option I have least observed out in the field and that I therefore have the least practical experience with. I honestly do not know why so few developers opt for this variant.

From a theoretical perspective, this option has all the advantages you can think of:

• Unlike XML sitemaps, the HTTP header is processed every time the page is crawled, so Google always receives the hreflang information associated with a page at the same time as it visits the page.
• HTTP headers can be set for every URL, including those that do not have their own source code (like the home page that redirects users based on their location or browser languages) and also non-HTML files such as PDFs.

One slight disadvantage might be that debugging and quality assurance are a bit more difficult with this option, as most common SEO tools do not really pay attention to HTTP headers. But I am sure this is going to change in the near future.

The code you need for implementing hreflang annotations in HTTP headers is very similar to the HTML header variant we saw above, with slight syntactical differences.

This is what the implementation in the HTTP header for the three home pages of Example 2 would look like:

Link: <https://www.rebelytics.com/en/>; rel="alternate"; hreflang="en",
<https://www.rebelytics.com/fr/>; rel="alternate"; hreflang="fr",
<https://www.rebelytics.com/es/>; rel="alternate"; hreflang="es"


Just like the HTML header option, this method requires an implementation on a URL level, so the code for HTTP headers of the three versions of the “products” page on this website would be the following:

Link: <https://www.rebelytics.com/en/products/>; rel="alternate"; hreflang="en",
<https://www.rebelytics.com/fr/produits/>; rel="alternate"; hreflang="fr",
<https://www.rebelytics.com/es/productos/>; rel="alternate"; hreflang="es"


That’s it! With this information at hand, you should be able to decide which option is the best and most feasible for you and your developers.

Continue reading to learn how to complete and debug your hreflang implementation!

Step 8: Implement hreflang on your website

If you are looking for instructions on how to actually get that hreflang structure you have developed onto your website, I am afraid I have to disappoint you (or maybe not? – keep reading!). This guide is mainly designed to help you understand what the hreflang annotations on your website are supposed to look like.

The exact way you implement hreflang on your website depends on lots of different factors, like the method you choose and also the content management or shop system you are using. If you are lucky, you will find a decent plugin, but in most cases you will need the support of a developer for the actual implementation.

There is one way of implementing hreflang that works for most websites, independent of their CMS or shop system. It is a bit experimental and not officially recommended, but if you really don’t find any other way to implement hreflang and if your are a DIY type of person, you should check this out (you should check it out anyhow, because it’s really interesting):

How to implement hreflang with Google Tag Manager

Step 9: Create a Google Search Console Property for each language and country version

Now that you’ve implemented hreflang on your website, you should create a Google Search Console property for every language or country version of your website, if you haven’t done so already.

Why do you need a separate property for every website version? The most important reason is that in some cases you can send additional signals to Google via Search Console that will help with the correct interpretation of hreflang. We will learn more about this in step 10. Another good reason is that having separate properties really helps with monitoring indexing issues or analysing search queries per language and country.

Just go to Google Search Console, click on the “ADD A PROPERTY” button, and add the exact URL of each of your country or language versions (including subdomains, directories, and the correct protocol).

For example 2 from above, the properties could look like this (one for the entire domain and one for each language version, on subdirectory level):

You will see that this structure really helps you analyse issues and performance of the different versions of your website separately. Let’s move on to the next very important setting you should take care of in Google Search Console: Country targeting.

Step 10: Align your international targeting options in Google Search Console with your hreflang implementation

Above (way above), we already talked about the fact that ccTLDs (country-specific domains such as .de, .fr or .co.uk), are automatically targeted at users from the countries they represent. If you are only using ccTLDs, you can skip this step.

gTLDs (and subdomains or subdirectories on gTLDs), on the other hand, can either be targeted at users from several countries, from all countries, or from just one or two countries.

Google Search Console allows you to target properties at one country or at all countries.

So how does this fit together?

If you have a country version that is hosted on a gTLD, make sure that you select the same country it is targeted at via hreflang in the country targeting settings in Google Search Console. Also, make sure that you don’t set the country targeting of a directory, subdomain or or entire domain to a certain country, if it is really meant for users from more than one country or from another country.

For your properties that are on a gTLD and that are targeted at users from exactly one country via hreflang, go to Search Traffic > International Targeting in Google Search Console and select the country. For all other properties, leave the country targeting option deactivated.

For example 1 from above, this is what the country targeting options in Google Search Console should look like:

Website version	Language	Countries	hreflang values	GSC country targeting
https://www.rebelytics.com/us/	English	US	en-US	United Stated
https://www.rebelytics.co.uk/	English	UK	en-GB	United Kingdom
https://www.rebelytics.com/en/	English	Rest of the world	en	None

(OPTIONAL) Step 11: Audit your hreflang setup with searchVIU

Once you have your hreflang setup up and running, you can use our advanced SEO reports and data to audit your hreflang annotations. Our hreflang report highlights the following problems that can arise with hreflang implementations:

• hreflang pointing to non-canonical URLs
• hreflang pointing to non-indexable URLs
• hreflang pointing to redirected URLs
• hreflang pointing to URLs that give back 404 or server errors
• hreflang pointing to URLs that are blocked via robots.txt
• Language marked up in hreflang annotation differs from language of the content on the URL it points to
• Country marked up in hreflang annotation differs from country of the ccTLD it points to
• URLs linked via hreflang are not linked with each other via HTML links (missing country or language switcher)
• Translations that are linked via hreflang are not semantically similar

The hreflang reports are part of our comprehensive SEO data solution. If you’d like to talk about how our product can help you, you can request a free trial here: Request a trial

That’s it! Any questions? Give me a shout.

If there are any questions that remain unclear about the implementation of hreflang, please don’t hesitate to get in touch or write a comment under this article. I will be happy to help.