How to use Hreflang correctly (2018 edition)
Disclaimer: because of the complicated nature of hreflang, I deliberately decided that was better not using always a too “technical” or “academic” language or definitions. Therefore, I ask the purist of SEO to close an eye and forgive me because of my desire of seeking a better comprehension of this convoluted topic also by a wider and technically less educated public.
A few weeks ago, John Mueller of Google published a tweet that surprised quite many SEOs:
More recently, then, Rand Fishkin asked for help about a specific use of hreflang, and that tweet led to quite a storm of answers, questions and doubts during the day.
Inspired by the return of interest that hreflang has been having lately, and because I still see a lot of confusion about it and how to implement it correctly, I decided to return writing on my blog.
In this post, I will try to resume the most important things we know about how to use use the hreflang mark up, what are the most common error and answer to the most frequently asked questions, backing their answers with official communications by Googlers.
THE BASICS OF HREFLANG
Hreflang=”x” is an attribute that indicates to Google (and others search engines) what URL serves the users speaking a given language and – if explicitly indicated – a given country (hreflang=”x-X”).
For instance, if domain.es targets Spanish-speaking users in Spain and domain.co.uk targets English-speaking ones in Great Britain, then the following hreflang annotations will specify these intents to Google:
- <link rel=”alternate” href=”https://domain.es/” hreflang=”es-ES” />
- <link rel=”alternate” href=”https://domain.co.uk/” hreflang=”en-GB” />
The grammar of hreflang
Let see what elements compose an hreflang annotation:
<link rel=”alternate” href=”https://domain.es/” hreflang=”es–ES“ />
- The hreflang is a rel=”alternate”, which means that it always indicates an alternative URL to the one the same alternate annotation is implemented;
- The href element indicates the alternative URL;
- The hreflang attribute always presents the language or the language and country targeted by the page indicated in the href field;
- For indicating the targeted language, we must use the ISO 639-1 language codes;
- For indicating the country we target, we must use the ISO 3166-1 Alpha 2 country codes.
However, Google advises us that there is an exception to point 3: in fact, we can use the ISO 15924 for indicating that we are using a specific language script on our page and that we can use this ISO code in combination with a country one.
This means that it is totally correct having an hreflang like hreflang=”zh-Hans” for telling Google that we are using Simplified Chinese instead of Traditional Chinese (zh-Hant).
What does happen if we do not use the correct ISO codes in hreflang?
It will happen that Google won’t consider the hreflang with the wrong ISO code but still consider the correct ones in same hreflang annotations set (source).
Is there a limit with multiple hreflang tags on the same URL?
No, as John Mueller said here.
How to implement hreflang for mobile-first Indexing (and amp)
Aleyda Solís magnifically presented how to implement hreflang in m. mobile websites in desktop-first and mobile-first indexing:
The implementation of hreflang in multilingual / multi-country AMP website version, John Mueller confirmed as correct the schema that Sergio Redondo on Twitter;
When should we use hreflang?
Google is very precise in telling when we should use the hreflang:
- When our website has fully translation version (i.e.: www.domain.com is in English and www.domain.com/es/ is its Spanish version);
- When our website as different versions in the same language and targeting different countries, hence there are very slight difference mainly due to localization (i.e.: www.domain.com is the American-English version of our website and www.domain.co.uk is the British-English one);
- When we offer the same content to different audiences but:
- the main content is always in the same language despite the specific version is targeting an audience using a different one;
- the template is translated into the language used by the audience we are targeting;
- and/or the page has UGC content in the language used by the audience we are targeting;
This last case – as Google says – may happen in websites like forums… and it is a first clear example of how hreflang can be convoluted.
how to implement the hreflang annotations
Hreflang is a single URL based signal, therefore it must be implemented URL by URL.
In other words, we cannot simply tell Google “all the URLs under /es/ targets Spanish speaking users and, instead, all URLs under /de/ target German-speaking ones”.
There are 3 ways (+1) to implement the hreflang:
- In the <head> section of a page;
- Via Sitemaps.xml
- In the HTTP Header for non-HTML files like, for instance, PDFs.
If we have a very big set of hreflang annotations, then Google suggests using the sitemaps.xml implementation option to not overcharge the <head> section of our pages.
The (+1) option for implementing hreflang is doing it using Google Tag Manager, as it is well explained in this how-to post.
However, Google advises that this is a very fragile solution. If it is possible, it is better to implement hreflang in the HTML <head> section of the page or via sitemaps.xml.
What are the most common mistakes when implementing hreflang?
Mistake #1 – not using the self-referential hreflang annotation
When implementing hreflang, we must always implement the self-referral hreflang annotation and not only the ones pointing to the alternative language and country or only-language URLs.
- URLs: https://www.domain.com/ (en) with the alternative German version in https://www.domain.com/de/
- <link rel=”alternate” href=”https://www.domain.com/” hreflang=”en” /> [self referential hreflang]
- <link rel=”alternate” href=”https://www.domain.com/de/ hreflang=”de” [alternative URL for German-speaking users]
Some people say that the self-referential hreflang is not needed… Google explicitly says it must be used:
“If you have multiple language versions of a URL, each language page should identify different language versions, including itself.” (here, again).
Mistake #2 – forgetting the return hreflang annotation
If the Spanish URL A suggests URL B as its alternative German version, then URL B must suggest back URL A as its alternative version for Spanish-speaking users.
If this rule is not respected, Google will not consider the hreflang set as correct, hence it will ignore it.
Mistake #3 – Using URLs, which doesn’t respond with 200, in the href element of the hreflang annotation
Pay attention to the server response code of the URLs you are indicating in the hreflang set.
If they respond with 4XX, 5XX and 3XX server message, then we will be breaking the return rule, therefore the hreflang will be considered incorrectly implemented (no-return error).
Mistake #4 – Using URLs, which are blocked via robots.txt, in the href element of the hreflang annotation set
If the alternative URL is blocked via robots.txt, then Google won’t be able to access the code of the page, therefore won’t see the hreflang set implemented there. We will have – once again – a no-return error message.
Formally, if we did this kind of mistake, but implemented the hreflang via sitemaps.xml, we won’t see any error in Google Search Console. This doesn’t mean that this is something intelligent to do.
Mistake #5 – not using canonical URLs in the href element of the hreflang annotation set
mistake #6 – using rel=”canonical” across language/country versions
In the same Google+ post, John Mueller advised to not cross-canonicalize websites versions targeting different languages (i.e.: “es” & “en”), different language/countries (i.e.: “es-ES” & “en-US”) and (as logic tells) same language/different countries (i.e.: “en-AU” & “en-US”).
This kind of cross canonicalization will cause that Google won’t index the canonicalized website version, which probably is not an SEO consciously desire in the 99,99% of the cases.
Mistake #7 – using hreflang even if we only have one website in only one language or language/country version
If there is no alternative URL, then there is nothing to swap out. Hence, the hreflang has no sense and Google won’t take it into consideration.
Google officially confirmed the useless of this practice in this answer on Twitter.
Mistake #8 – targeting too many useless countries with hreflang
Google suggests avoiding what could end up being a potentially chaotic and catastrophic implementation.
It is better, Instead, to start implementing language/country hreflang annotations for targeting only those markets that really matter to our business.
If then, we want to target also other countries, which share the same language of a version we already have, then we can consider the opportunity to use the language only kind of hreflang annotation.
mistake #9 – Messing up with the language and country iso codes
Even if the ISO Code language and country pairs are maybe the easiest things to understand of hreflang, nevertheless there’s still a lot of people messing up with them and doing these mistakes:
- Using the incorrect country ISO Code (i.e.: hreflang=”en-UK” instead of hreflang=”en-GB”);
- Using the incorrect country ISO Code (i.e:: hreflang=”eng-GB” instead of hreflang=”en-GB”);
- Using both incorrect language and country ISO Codes (i.e.: hreflang=”eng-UK” instead of hreflang=”en-GB”);
- Using only the country ISO Code (i.e.: hreflang=”GB”);
- Inverting the order of the ISO Codes (i.e.: hreflang=”GB-en” instead of hreflang=”en-GB”):
Most recurring doubts about hreflang answered by Google(rs)
Is the hreflang a ranking factor?
No, absolutely not!
What the hreflang does is swapping out URLs in the existing rankings.
For instance, if www.lapepica.es was ranking in position 5 in Google Mexico for brand searches because of being a stronger domain than www.lapepica.com.mx, implementing the hreflang will make that the www.lapepica.com.mx URL will substitute www.lapepica.es in Google.com.mx, and not to miracously jump to position 1.
Is it having a ccTLD a guarantee that it won’t be outranked by the same version of the website but on generic (.com) domain name, if they have the same identical content and language?
No! Google may fold the versions together, especially because of the sites sharing the same identical content.
Hreflang (and creating unique localized content) will help local websites not being outranked by their global versions (or other local sites in the same language, but more relevant to Google’s eyes).
Is hreflang enough for geotargeting (aka: are they synonyms)?
No… and that’s a common misunderstanding.
Is it fine to cross-domain canonicalize pages in the same language and with the same content but targeting two different countries, and then using the hreflang as such?
No, Google highly discourages this.
If domain.com.au/content.html and domain.co.uk/content.html are identical, but obviously targeting 2 different countries, what does happen with the duplicate content issue?
If they are 100% identical, it may happen that Google folds them together for indexing, but hreflang will work still and show the .com.au URL in google.com.au and the .co.uk in Google.co.uk.
For this reason, localizing is a priority in International SEO.
Could geo meta tags be used as a substitute of hreflang?
Not at all.
Google doesn’t consider geo meta tags.
Use standard geotargeting procedures/options and implement hreflang if it is needed.
Is it relying on the locale-aware crawling ability of Google a good alternative to using hreflang and classic geo-targeting practices?
Theoretically, it could be an alternative, but if the same Google strongly suggest to use the classic geo-targeting practices and annotating the URLs with hreflang, then I would not use it at all:
Can IP-based redirects prevent Google from getting hreflang attributes right? (when a website has both)?
It all depends on how consistent are the canonicals.
If we implement hreflang via sitemaps.xml, does Google report all the errors the implementation may have?
Yes. The same way it does when hreflang is implemented in the code.
Be aware that this problem may affect also rel=”canonical”, as Gary Illyes stated here.
A practical solution for avoiding this problem – apart not using not allowed tags in the <head> section of the page – is presenting all the meta tags and annotations like rel=”canonical” and hreflang very high in the coding.
Can we use relative URLs in the hreflang (and rel=”canonical”)?
Google says that we can use relative URLs, but that using absolute URLs is a better solution.
However – alert: this is my interpretation of declaration John Mueller gave – we can use relative URLs only if previously we have declared the <base> URL in the same HTML <head> section of the page.
What is the hreflang “x-default” and how must we use it?
Google doesn’t say that much about the hreflang=”x-default” annotation, but to use it only:
- For the country selector page, if exists;
- For homepages that dynamically alter their contents based on a user’s perceived geolocation or the Accept-Language headers
However, and this is a classic example used by SEO to ask Google to update its Help Pages about International targeting and Hreflang, it is a very common practice to use the hreflang=”x-default” also to indicate what page Google must present to all those users that are not targeted by a specific language version.
For instance, we have a website in targeting the main European countries, but we want Google to present the English version URLs to those users living in countries like, for instance, Sweden, whose language we don’t serve in our website.
In this particular case, using hreflang=”en” would not be the correct solution neither hreflang=”en-SE” because: with any of those 2 solutions we are targeting Swedish-speaking users.
Instead, as it has been proved by many SEOs and with particular issues, annotating all the English URLs also with the hreflang=”x-default” seems to be the correct solution for targeting – following up with my example – the Swedish-speaking users with our English version URLs, which is important for branded searches.