hreflang: Step-by-step implementation guide

Last updated on Jan 4, 2017

Important note: This article will be updated and completed over the course of the next few days.

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.

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:

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

Steps 9 to 12 will be added in the next days. Stay tuned!

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
Step 11: Check for hreflang errors in Google Search Console
Step 12: Monitor your impressions in Google Search Console

hreflang

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 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 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 Netherlands
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 will be looking at in this guide is typical for e-commerce players that operate across several countries. While B2B companies tend to choose global language version 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 examples, 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?

International targeting options in Google Search Console

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 11. 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 Netherlands
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 Netherlands
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-PO, 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 indexation 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.

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-PO" 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-PO" 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. This guide is 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.

If you’ve managed to read everything up to here, you deserve a break! Check back in a couple of days for the next steps. Why don’t you follow me on Twitter, Linkedin or Google+ so that you don’t miss anything?

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

This step will be added in the next days. Stay tuned!

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

This step will be added in the next days. Stay tuned!

Step 11: Check for hreflang errors in Google Search Console

This step will be added in the next days. Stay tuned!

Step 12: Monitor your impressions in Google Search Console

This step will be added in the next days. Stay tuned!

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. I will be happy to help.

Say thanks by sharing this:

45 Comments

  1. Sungod
    10. August 2016

    Yo,

    We have almost implemented hreflang and the site structure because of your help.

    For every page hreflang is implemented in such manner
    ink rel=”alternate” href=”https://domain.tld/us/test-phone” hreflang=”en-us”
    ink rel=”alternate” href=”https://domain.tld/gb/test-phone” hreflang=”en-gb”
    ink rel=”alternate” href=”https://domain.tld/test-phone” hreflang=”x-default”
    ink rel=”alternate” href=”https://domain.tld/test-phone” hreflang=”en”

    Whenever a visitor manually writes domain.tld then we detect his country and he gets redirected to correct sub directory.

    Also we give manual drop down in each page to select a particular supported country.

    We have two ways to implement this; with cookie and without cookie.

    1) Without cookie to store country
    Behavior each time a page is requested country will be detected and redirected to correct sub directory if that country is supported
    Expected behavior of google indexing is as follows.
    1.1) Google will be able to index and display correct URL with correct sub directory for particular country
    Thus user will always get correct URL and redirection wont be needed in google search results.
    1.2) When user manually enters domain.tld he will get auto redirected to correct country and URL will change with correct sub directory

    2) Cookie with country is set in first load.
    Behavior, first time country is detected and set in cookie.
    So when domain.tld is entered for first time the user e.g lands of domain.tld/us/
    Next user closes the browser and manually enters domain.tld and he gets the content shown to ‘us’ . But URL in address bar doesn’t changes.
    Thus he will continue to browse the correct language but URL will not change with sub directory.
    In this each time country value is not checked and not redirected to change the URL structure.

    Which is correct way?
    In which way google will have trouble to index correct variation of data since hreflang is used so that prices shown is correct according to country.

    Reply
    • Eoghan Henn
      12. August 2016

      Hi Sungod! Welcome back and thanks for the update 🙂

      The cookie solution will not affect how Google crawls your pages, so don’t worry too much about it and pick the option that’s best for your users.

      The only thing I’m wondering about is why you don’t want to make the URL change in option 2? Why don’t you redirect the user to the right county version based on the cookie? Check out how https://sedo.com/ does it (the language selction menu is located at the top of the footer area of the page). When you change the language, your selection is stored in a cookie and when you access https://sedo.com/ again (without language directory) you are redirected to the language directory you had previously selected.

      Reply
      • Sungod
        14. August 2016

        Option 2 is what my development team had suggested and I was more inclined towards Option 1, and Google also confirmed that option 1 will be best.

        Once we are launched properly, it will be my Honor to have you visit the project.
        I will share the details once we are launched 🙂
        Thank you for you guidance.

        Regards
        Sungod

        Reply
        • Eoghan Henn
          18. August 2016

          Great, I’m looking forward to that! Good luck with your launch!

          Reply
  2. Isa
    5. August 2016

    Hi Eoghan,
    Thanks for your great articles about hreflang!
    We implemented the hreflang tag for our products directory (www.example.de, http://www.example.at, http://www.example.ch and fr.example.ch) 2 months ago, but can’t see any changes – the .de shop still appears in AT and CH rankings. Can you say within your experience how long it takes to see any impacts of hreflang?
    I know that hreflang is more a signal than directive, but didn’t expect that the implementation doesn’t show no impact at all. The Google Search Console also discovered a few errors (about 10), so Google must have noticed our hreflang tags.
    Other thoughts are that maybe we have to implement the hreflang on every directory (sitewide) to see more impact?
    Thank you!

    Reply
    • Eoghan Henn
      9. August 2016

      Hi Isa,

      Thanks a lot for your comment.

      Normally it does not take that long for Google to process hreflang annotations, so if your hreflang implementation does not show any impact at all, there must be other factors that make Google ignore your hreflang annotations.

      I would definitely support your first idea: It is advisable to implement hreflang on the entire website, so every URL that has an equivalent on one of the other domains should receive hreflang annotations. Make sure your hreflang implementation is as complete and as clean as possible.

      On the other hand, with an incomplete implementation like this, make sure you measure the impact correctly: Changes will obviously only show for URLs that have hreflang, so you should check if the right version appears in the different country versions for the specific URLs you worked on. Other URLs will not be affected, so you might still see lots of pages ranking in the wrong countries.

      I will send you some additional information via email.

      Reply
      • Isa
        10. August 2016

        Hi Eoghan,
        thanks for your detailed answer and your email in German 😉 We found a few sites where the DE version ranks in AT also when the AT hreflang link exists. But we will definitely implement the hreflang tag on the entire website. It’s just a question of time.

        Reply
        • Eoghan Henn
          12. August 2016

          OK, let me know how it goes and don’t hesitate if you have any additional questions!

          Reply
  3. Alessandro
    2. August 2016

    Thanks once again!
    Last question… What about 302 not passing link juice?
    Most of the legacy links go to the root… and if the crawler finds that 302 would it be lost?

    Reply
    • Eoghan Henn
      9. August 2016

      Hi Alessandro,

      There are two reasons why you don’t have to worry about this issue:

      1. By linking the x-default home page to the different language and country versions of the homepage, you let Google know that these pages are variants of each other. If you want to express it in these terms, the link juice is passed on via the hreflang annotations.
      2. Different Google employees have said in the past few months that 302 redirects do pass link juice, pagerank, or whatever you want to call it. Here are two sources:
      https://plus.google.com/u/0/+JohnMueller/posts/PY1xCWbeDVC
      https://twitter.com/methode/status/757923179641839616

      I hope this helps!

      Reply
      • Alessandro
        9. August 2016

        Thank you very much indeed!
        Yet… I am not linking the x-default hp to the country versions of the hp… Currently I am redirecting the crawler with a server-side 301 (I’ll soon switch to 302)
        In the root hp there are neither the links, nor the the hreflanfg annotation… there isn’t event the page itself, actually.
        At present, Google takes as hp only the US version even for searches from elsewhere. Only in the sitelinks do appear the local versions.
        If only Google guidelines were clear… I would not abuse your time and patience!

        Reply
        • Eoghan Henn
          12. August 2016

          Don’t worry about my time and patience 😉

          Things should get better when you switch to 302. Look, I will show you two websites that do it exactly the same way (Geo-IP / browser language based 302 from x-default to subdirectory, hreflang implemented in the source code) and the results are great. It’s really not a problem if your x-default version does not link back (although it would obviously be better if it did). Check out these two examples:

          https://www.ecom-ex.com/
          https://www.nfon.com/

          Let me know how it goes for you after changing your redirect from 301 to 302.

          Reply
  4. Alessandro
    27. July 2016

    Hi, Eoghan

    your blog is very helpful.
    I’ve implemented the hreflang tags on all urls of my website, that has many local versions on subfolders. For the root homepage the server gives a 301 to the subfolder based on the location of the IP of the client.
    How can I put the “x-default” on the homepage if it does not exist?
    Also, is it always preferrable to have a default version of the website? What if all the local versions are equally important? Will Google take the US version as the default? Thank you!
    Alessandro

    Reply
    • Eoghan Henn
      2. August 2016

      Hello Alessandro,

      I’m glad you found my blog helpful. Thanks for you kind words!

      You’re right, this is an error in the system that I have also encountered several times in the past. You cannot add hreflang annotations to a URL that redirects when you choose to implement hreflang annotations in the section of each page. So you are forced to break the rules by not linking back from the “x-default” URL.

      One solution would be implementing hreflang annotations in sitemaps, although I would generally advise to avoid this option, if possible. I have seen several scenarios like the one you described that worked perfectly, although the link from the “x-default” version to the other versions of the home page was missing.

      Your second question was whether it is always necessary to define a default version. I do not think so. From my point of view, “x-default” is overused, as it was originally only intended for two cases: 1. The scenario you describe above, where the default website redirects based on location or language and is literally not targeted at users from any specific location or language. 2. Country / language selection home pages.

      Google will try to show the most relevant version to every user (not necessarily the US version). My advice: Make sure you cover your most important target audiences with the right language versions, mark it up correctly and let Google figure out the rest. You can always go to your Search Console and Google Analytics data to check if there are users that entering through the “wrong” versions and then fix the problems you find.

      I hope this helps! Feel free to ask additional questions.

      Reply
      • Alessandro
        2. August 2016

        Thank you very much!

        Meanwhile I found this post from the official blog, that says something quite different from the official website introducing a 302 redirect instead than 301

        https://webmasters.googleblog.com/2014/05/creating-right-homepage-for-your.html

        It reads as follows:

        A third scenario would be to automatically serve the appropriate HTML content to your users depending on their location and language settings. You will either do that by using server-side 302 redirects or by dynamically serving the right HTML content.
        Remember to use x-default rel-alternate-hreflang annotation on the homepage / generic page even if the latter is a redirect page that is not accessible directly for users.

        Do you think that, possibly, a server could be configured to serve at the same time a 302 redirect AND a body with html containing the x-default annotation?

        Reply
        • Eoghan Henn
          2. August 2016

          Hi Alessandro,

          About the 301 / 302 question: You should definitely use a 302 in this case. A Geo- or language-based redirect is not permanent, but temporary, so 302 is a better choice than 301. Sorry I didn’t point that out in the first place, it escaped my attention.

          I do not know of a way to implement a 302 redirect AND an HTML body with hreflang annotation. But you can certainly annotate an “x-default” page that redirects to another homepage version by implementing hreflang in the XML sitemaps (although this will most likely lead to other problems). I guess this is what they mean in the article you linked to (or maybe also the third option of implementing hreflang in the http header, which I do not have any experience with). I can’t think of any other explanation.

          But, as I said, it normally works out perfectly without the “x-default” page linking back.

          Reply
  5. Sungod
    30. June 2016

    Thank you

    Reply
  6. Sungod
    25. June 2016

    https://example.com/in/
    https://example.com/us/
    https://example.com/uk/ or /gb/

    I couldn’t find any where if the there is any standard of sub folder
    /in/ us/ /uk/ or /gb/

    Also my prime confusion is uk or gb 🙂
    If there is a good guideline to follow could you point it to me.

    Regards
    Sungod

    Reply
    • Eoghan Henn
      30. June 2016

      Hi Sungod,

      it doesn’t really matter which country codes you use for your URL directories, but I would suggest to stick to ISO 3166-1 alpha-2 country codes: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

      These are the codes you have to use in hreflang, and it’s really nice from a technical point of view if you use the same ones for your URL directories.

      So for the UK this would be /gb/.

      Reply
  7. Sungod
    15. June 2016

    If user searches http://example.com
    he is be redirected to https://example.com/countrycode/ if his country has separate content that is supported by us.

    If he belongs to a country which we dont support he will be shown
    https://example.com/
    This page will have content in english.
    Thus anytime if country is not detected he will be redirected to default website.

    I am wondering
    1)If we assign a page “x-default” with ” hreflang=”en”> will it help or harm?
    Will it stop non ‘en’ users from getting to land to our website ?
    3)Or in any case non ‘en’ users will never come to know our website?
    3)Will it have any impact positive?

    Reply
    • Eoghan Henn
      15. June 2016

      Hi Sungod,

      In this case I would definitely recommend to set “en” for this default version. The value “en” here is the standard, because it tells the engines that this is a version in English for users in the whole world. The value “x-default” is optional, because you just tell the engine that you also want this version to show to users that search in a different language that you don’t support.

      I recently saw a case of a website that did exactly what you were planning (assigning only “x-default” to one of their versions) and Google completely ignored the hreflang implementations in this case (although I am not sure if this was the only reason they were ignored).

      Reply
      • Sungod
        15. June 2016

        I will also do some study about this and get back to you 🙂

        Reply
      • Sungod
        15. June 2016

        Can you check
        https://support.google.com/webmasters/answer/189077?hl=en
        At bottom go to this example
        Example hreflang configuration: Annotations in action

        If i understand that,
        http://www.example.com/ Default page that doesn’t target any language or locale; may have selectors to let users pick their language and region.

        For us we have selector in each page of website, its just for region.
        maybe x-default alone might do.

        Regards
        Sungod

        Reply
        • Eoghan Henn
          17. June 2016

          Hello Sungod,

          Google’s specifications do leave a lot of room for interpretation. That’s the root of the whole problem from my point of view.

          The original idea of “x-default”, as I interpret it, was for URLs that either redirect users based on their IP or browser language, or for country/language selector home pages like this one: http://www.britax.com/

          These two cases are the only ones in which I would assign the value “x-default” on its own, without any language value. I would do this because these URLs basically don’t have any content in a language.

          When your default URL does have content, it makes sense to assign it the corresponding language value. In any case, it won’t do any harm.

          I hope this helps!

          Reply
  8. Mark
    6. June 2016

    Hi Eoghan,

    Does a 301 redirect have influence on the HREF language tags? For some reason the English version of my site is showing above the Dutch version in Google.nl.

    Please let me know what you think.

    Reply
    • Eoghan Henn
      9. June 2016

      Hello Mark,

      Yes, a 301 redirect will certainly affect the interpretation of hreflang annotations by Google. For example, your hreflang annotations should not point to a URL that redirects to another URL. Instead, it should point to the final URL. Google would probably just ignore your hreflang annotations in this case.

      If you give me more info on your problem, I will be happy to check it out and help.

      Reply
  9. Sungod
    29. March 2016

    Consider this too

    example.com/en-us/test1.html has 5000 hits
    example.com/en-in/test1.html has 10000 hits
    vs

    example.com/test1.html has 15000 hits with 5000 from US and 10000 from India
    Does such page becomes better

    Then does it main same.
    Which page configuration will have chance to rank more higher?

    I am confused.
    🙁

    Regards
    Sungod

    Reply
    • Eoghan Henn
      30. March 2016

      Hi Sungod,

      When you link two or more pages with hreflang, they are considered as variants of one of the same page, so together they have good chances of ranking.

      One page for the entire world on the other hand has very good chances of ranking too, as it bundles the entire relevance on just one URL. The only problem here could be that Google has difficulties figuring out that there is dynamic content depending on the user location. The Google bot would have to come with an IP from every country you are serving and then understand that the changes it encounters every time it visits are due to the IP change. There might be some new markup for this in the future. Right now, the only really good solution I can think of would be having different URLs for different countries and linking them with hreflang annotations. But as you have already pointed out, this would be too much work for you. So you should probably just stick with the solution you have, test how well it works and see if Google has problems with it.

      Reply
      • Sungod
        15. June 2016

        Can we do hreflang tag like below

        Reply
      • Sungod
        15. June 2016

        Hi,
        I am back xd
        We will be doing like this

        ink rel=”alternate” href=”https://example.com/in/mobiles” hreflang=”en-in”
        link rel=”alternate” href=”https://example.com/us/mobiles” hreflang=”en-us”
        link rel=”alternate” href=”https://example.com/mobiles” hreflang=”x-default”

        And in google webmaster can we geo target like
        https://example.com/in/ India
        href=”https://example.com/us/ USA
        href=”https://example.com/mobiles” Not targeted?

        Should we geo restrict or not?

        Sungod

        P.S.
        You and another expert convinced me and we are going for hreflang from start 🙂

        Reply
        • Eoghan Henn
          15. June 2016

          Hello Sungod,

          Welcome back 🙂 This looks good! Just one question:

          Does your “x-default” version redirect to one of the others based on the user’s IP or does it have content? If it has content, you should assign it a language value (“en”, I assume) in addition to the “x-default” value.


          <link rel="alternate" href="https://example.com/in/mobiles" hreflang="en-in">
          <link rel="alternate" href="https://example.com/us/mobiles" hreflang="en-us">
          <link rel="alternate" href="https://example.com/mobiles" hreflang="x-default">
          <link rel="alternate" href="https://example.com/mobiles" hreflang="en">

          You can read more about assigning two hreflang values to one URL here: http://www.rebelytics.com/multiple-hreflang-tags-one-url/

          Reply
  10. Sungod
    29. March 2016

    Dear Eoghan,

    I need some help regarding our case.

    We have same URL for all countries which we are targeting.Its a global site in English and on single domain.
    We aim to detect ip and change the Prices . Also give users drop down to change country and have a default country ,

    Apart from price, sidebar content will change for different country.
    The main article and comment section remains same for all countries.

    So in our case does hrelang tag matters?

    The concern is e.g.
    The google indexes website from USA
    and the USA prices gets indexed.

    So will this hamper our users in UK or India where the primary variation is prices.
    I never considered this tag , but since launch is nearing I am worrying over this.

    Regards
    Sungod

    Reply
    • Eoghan Henn
      29. March 2016

      Hello Sungod,

      Thanks a lot for your comment and your interesting question.

      If you keep the solution with one URL for all countries, you do not need hreflang tags on your page. However, you have a point asking yourself whether it might be a problem that Google will only index US prices.

      You could consider a solution where you have different URLs for the different currencies / countries and link the different versions with hreflang annotations. This way you could make sure that Google indexes all of your prices (and also the additional content) and shows the right version to the right user in the SERPs.

      When implemented correctly, hreflang works very well and Google serves the right results based on the user’s location very reliably.

      How many country versions are we talking about? Do you target users in the whole world or just in a limited number of countries? A solution for the countries you mentioned above could look like this:

      <link rel="alternate" href="http://www.yourwebsite.com/en-us/" hreflang="en-us">
      <link rel="alternate" href="http://www.yourwebsite.com/en-gb/" hreflang="en-gb">
      <link rel="alternate" href="http://www.yourwebsite.com/en-in/" hreflang="en-in">

      This list could be expanded, of course. Feel free to ask more questions if things remain unclear!

      Best regards,

      Eoghan

      Reply
      • Sungod
        29. March 2016

        Your reply means a lot for someone who has limited resources.
        And you replied so swiftly, that’s very unexpected in a good way.

        Currently it is 10-15 countries and it could be raised on demand.
        Having one URL is the most logical for me.
        It is easier to manage, easy to share for users etc.

        Whereas having separate URL for each country for minor changes is added burden.
        But I am asking myself does it help us 🙂

        The more I think, the more trouble it is for us, since we not only have website generated pages by in-house publishers like myself.
        But users can create pages and save them, and thus having a different URL per country is tough to manage.
        In fact it has no use for me and looks more harmful.

        Although google says it is going to do locale aware crawling
        https://support.google.com/webmasters/answer/6144055

        Just talking with you is helping me a lot 
        What is your view, since we can start handling more countries etc down the line .
        And also consider pages created which can be saved by user from any region under the domain,

        Regards
        Sungod

        Reply
        • Eoghan Henn
          29. March 2016

          Hi Sungod,

          If having a separate URL for every currency or every country would require additional efforts, you should just stay with the solution you have – one URL for all countries. This is obviously a bit more difficult for search engines to crawl and interpret, but as the link you shared above shows, Google is already trying to figure out this kind of content serving.

          I hope this helps! Feel free to ask more questions 🙂

          Best regards,

          Eoghan

          Reply
  11. Jerry
    15. February 2016

    Hi Eoghan, in hope that you still answer questions here. i have .co.uk and .com cctld with same content, only difference is price symbol. Should i use hreflang on both cctld even though cctld is country specific? will google consider it as duplicate?

    Reply
    • Eoghan Henn
      15. February 2016

      Hi Jerry,

      Yes, I do still answer questions here. I’ve just had trouble keeping up with the questions lately because I’ve been very busy. Thanks for rubbing it in my face 🙂 It motivated me to reply to all unanswered questions right away.

      So, about your question: Yes, you should definitely use hreflang here! You can tag the .com version as “en” (English language version without specific country) and the .co.uk version as “en-gb” (English language version for users in the UK). That way Google will show your .co.uk version to users in the UK and your .com version to all other users that search in English.

      Google will not consider your content versions as duplicates if you mark them up with hreflang.

      Let me know if you have any further questions.

      Reply
  12. Johan
    7. February 2016

    how use hreflang when not have a same or similar page in another language and domain, example a blog or a specific article about that country. Can you point hreflang to index page in cases when not have a same page on another domain.
    I still want users go to there language domain on all pages between my domains.

    Reply
    • Eoghan Henn
      15. February 2016

      Hi Johan,

      When you don’t have a version of a page in another language or for another country, you should not use hreflang on that page.

      You cannot point to the home page of another language version. The reason is simple: hreflang annotations are bidirectional, so a page that is linked to with hreflang has to link back. This means that pages with hreflang annotations always come in pairs or groups and that one page (like a home page) cannot be the target of hreflang links from many different pages in another language or country version, but only from one equivalent page in every other version (the home page in this case).

      I hope this helps!

      Eoghan

      Reply
  13. Mluci
    8. January 2016

    It’s necessary to put hreflang code on all web pages(english page, french page) or only one page?

    Reply
    • Eoghan Henn
      15. February 2016

      Hello! hreflang annotations are always bidirectional, so each poage that you link to has to link back to the page it is linked from. This means that hreflang annotations have to be placed on all language and country versions of your website.

      Reply
  14. Tim
    3. November 2015

    I already think this is a dumb question.
    I have a .com and a .ie site.
    Should I include the hreflang tags on both my .com site as well as my .ie site?
    Thanks!

    Reply
    • Eoghan Henn
      3. November 2015

      Hi Tim, hreflang would be perfectly suited in your case to show search engines that the content on your .ie website is intended for Irish users while the content on your .com website is intended for international users. The tags should be included on both sites, each one of them pointing to the other. If you have any further questions I will be happy to help.

      Reply
  15. Daniel
    27. August 2015

    Hi Eoghan~

    Thanks for this and the related article about hreflang with canonicals!

    I have a couple technical hreflang questions I hope you could help with:

    1) Is it ok to use hreflang when rewriting a LOT of an article (eg: all new title, adding sections, major editing, etc)? What about when changing the url as well?

    2) Do you know what factors may cause google to rank a global or international version of a page instead of the current version (eg: ranking global or /in-en/ in the usa when a hreflang /us-en/ version exists?)

    3) Do you know how google treats backlinks in regards to hreflang variations of an article? eg: does a link pointing to /us-en/ also help the global / version as well as a /in-en/ version? Do links “trickle down” from a global version to /us-en/ and /in-en/?

    Thanks and kind regards!
    Daniel

    Reply
    • Eoghan Henn
      28. August 2015

      Hi Daniel, thanks for your questions. Here are my answers:

      1) Let’s say you have an article about cell phones for US users and you decide to rewrite it for UK users. So you talk about mobile phones instead of cell phones, you change the title, the URL and the language and spelling. You might replace a passage about AT&T with a paragraph about BT, a British provider. But you are still talking about the same thing, portable phones, so it is absolutely correct to link the articles with hreflang.

      2) This sounds like hreflang is being ignored by Google. This normally doesn’t happen when hreflang is implemented correctly, so something might be wrong with your implementation. Or, in rare cases, there might be other ranking signals that outweigh hreflang, like lots of UK links pointing to your US version and vice versa, or contradicting ccTLDS. Make sure hreflang is implemented correctly and that it is in line with all other ranking signals.

      3) Yes, backlinks to one version of an article definitely help the other versions that are connected with hreflang.

      I hope this helps! I typed this on my mobile so sorry for the brief response.

      Eoghan

      Reply

Leave a Reply