Hreflangi. Jak prawidłowo oznaczać wersje językowe strony?

Table of contents:

1. What is a hreflang?
2. Implementation
3. Managing hreflangs and technical aspects
4. Useful tools
5. What to pay attention to – the most frequent mistakes
6. Conclusion

Thanks to a detailed analysis performed by SEMrush with its tool, it was possible to check whether 20 thousands of analysed pages have implemented the hreflang tag properly, according to Google standards. The results showed how many mistakes were made when it comes to hreflang implementation. The main conclusion coming from this research is that ¾ of the analysed websites used the attribute improperly, or didn’t use it at all.

What is a hreflang?

Hreflang tag serves to inform the search engine bots that a given website has various language versions, meant for the visitors who speak different languages or come from different regions – i.e. countries with the same official language, such as Germany and Austria. It is, therefore, one of the important aspects of international SEO services.

In HTML language, there’s a lang attribute that describes the content of a given site. It doesn’t mention the availability of other language versions, though – and this is precisely what hreflangs are for. In practice, we get two important benefits of using them:

1. Hreflangs can actually decrease the bounce rate since visitors are redirected to the most appropriate version of the website.
2. Pages linked to one another with hreflangs won’t be treated as a duplicated content. That could happen in the case of separate sites for visitors coming from the US and Great Britain – the content would be similar, with only a few differences such as currency or travel costs. Thanks to hreflangs, we can inform the search engine bots that it’s still the same content, but it’s meant for a different audience.

John Mueller himself, who is often named as “the link between Google and the rest of the world”, admitted that hreflangs are one of the most complex aspects of SEO in his opinion. He was even asked to record a video on that topic – but he explained that it would take a proper online course rather than a 5-minute movie to clarify it. Nonetheless, he added that basic use and implementation are not that difficult.

TBH hreflang is one of the most complex aspects of SEO (if not the most complex one). Feels as easy as a meta-tag, but it gets really hard quickly.

— John (@JohnMu) February 19, 2018

Search engines that support hreflangs

Hreflangs are interpreted “only” by three search engines. But, the fact that one of those three is Google makes it much more relevant. The other two engines are Yandex and Seznam. In other cases, we’ll have to count on the language tag (<meta lang=”xx”>). Still, only Google handles hreflangs implemented differently than in HTML code.

The way hreflang works

When implemented properly, the hreflang attribute will inform the search engine bots about all the language versions available. When the search engine user starts the research, Google will first determine which address to put where in the search engine results page, and then check whether there are other language versions of the website that might suit the user better.

Hreflang attribute vs. Google rank

As a result, hreflangs shouldn’t be treated as a ranking factor. Optimizing or building links to only one language version won’t affect the other versions of the site in terms of their position in SERP. Not directly, that is. Implementing such attributes properly will help you decrease the bounce rate and eliminate duplicated content, which can easily influence the rank of the website.

Implementation

Basically, hreflang implementation can be done in three different ways:

1. In the head section
2. In HTTP headers
3. In the XML sitemap

Hreflangs in the head section

The tag will have the following structure:

<link rel=”alternate” hreflang=”language_code-region_code” href=”website-url”>

The language code should be inserted accordingly to the ISO 639-1, format, whereas region code (according to ISO 3166-1 Alpha 2 format), is optional. Below you’ll find more details on when it’s worth using it. Still, the URL address should be absolute.

We have to add a proper hreflang tag to every language version of the website, as well as an additional URL that drives traffic to a given subpage. In order for the implementation to be correct, such a combination of hreflangs should be inserted on every version of the site.

For example, if our website is available in three language versions: Polish, English, and German (excluding the actual countries) – http://mywebsite.com (pl), http://mywebsite.com/en and http:/mywebsite.com/de, then on every site, we have to input the whole combination:

<link rel=”alternate” hreflang=”pl” href=”http://mywebsite.com”>
<link rel=”alternate” hreflang=”en” href=”http://mywebsite.com/en”>
<link rel=”alternate” hreflang=”de” href=”http://mywebsite.com/de”>

As can be seen, we always add the tag with a link to a website to which we add this combination.

Additionally, it’s worth adding an extra tag that will take into account the visitors who don’t speak any of those languages. In this case, the best solution is to redirect them to the English version of the site, therefore:

<link rel=”alternate” hreflang=”x-default” href=”http://mywebsite.com/en”>

You’ll read more about x-default hreflang below.

Hreflangs in HTTP headers

HTTP header is another piece of information attached to the requests sent to and by servers (“cookies” serve as a good example of such headers). This method is useful when it comes to files that have no HTML format – i.e. PDFs.

The header should have the following format:

Link: <url-1>; rel=”alternate”; hreflang=”language_code_1-region_code_1”, <url-2>; rel=”alternate”; hreflang=”language_code_2-region_code_2”, …

The language and region codes are corresponding to HTML tags. If we go back to our example, the headers will look as follows:

Link: <http://mywebsite.com>; rel=”alternate”; hreflang=”pl”,  <http://mywebsite.com/en>; rel=”alternate”; hreflang=”en”, <http://mywebsite.com/de>; rel=”alternate”; hreflang=”de”

To each language version of the website, there should be the same combination of headers used, in which specific parameters are separated with commas. The parameter redirecting to the current web page should be included in this set as well.

Hreflangs in the XML sitemap

Hreflangs can also be implemented with relevant tags in the XML sitemap. The template for two language versions of one subpage looks as follows:

<url>
<loc>url-1</loc>
<xhtml:link rel="alternate" hreflang="language_code_1-region_code_1"  href="url-1" />
<xhtml:link rel="alternate" hreflang="language_code_2-region_code_2"  href="url-2" />
</url>
<url>
<loc>url-2</loc>
<xhtml:link rel="alternate" hreflang="language_code_1-region_code_1"  href="url-1" />
<xhtml:link rel="alternate" hreflang="language_code_2-region_code_2"  href="url-2" />
</url>

It means, then, that in our case there should be the following code included in the XML sitemap:

<url>
<loc>http://mywebiste.com</loc>
<xhtml:link rel="alternate" hreflang="pl"  href="http://mywebiste.com" />
<xhtml:link rel="alternate" hreflang="en"  href="http://mywebiste.com/en" />
<xhtml:link rel="alternate" hreflang="de"  href="http://mywebiste.com/de" />
</url>

<url>
<loc>http://mywebiste.com/en</loc>
<xhtml:link rel="alternate" hreflang="pl"  href="http://mywebiste.com" />
<xhtml:link rel="alternate" hreflang="en"  href="http://mywebiste.com/en" />
<xhtml:link rel="alternate" hreflang="de"  href="http://mywebiste.com/de" />
</url>
<url>
<loc>http://mywebiste.com/de</loc>
<xhtml:link rel="alternate" hreflang="pl"  href="http://mywebiste.com" />
<xhtml:link rel="alternate" hreflang="en"  href="http://mywebiste.com/en" />
<xhtml:link rel="alternate" hreflang="de"  href="http://mywebiste.com/de" />
</url>

General rules for hreflang implementation

Apart from the above-mentioned guidelines, there are a few more rules we should take into account when implementing hreflangs.

• Always consider all language versions and a current subpage.
  

  We have two language versions – both are linked with hreflangs. As a result, there will be two hreflangs on each version – one for the alternative version, and one to the current version plus x-default. This doesn’t seem that complicated… Yet.

  

  Having three language versions means that each of them will be linked to others. Therefore, we should have three hreflangs on each subpage – one linking to the current subpage, two to other language versions, plus x-default on every one of them.

  

  Each subsequent language version (or one dedicated to a specific region) needs its own hreflang to be added.

• All the URL addresses have to be full (with the http/https protocol).
• We can also mix the addresses coming from different domains and subdomains, not only language catalogues (i.e. http://pl.mywebsite.com and http://en.mywebsite.com, or http://mywebsite.pl and http://mywebsite.en)
• In order for the hreflang to be taken into account by the search engine bots, both subpages have to link to one another. It’s for security reasons – basically, no one else can tag your website as an alternative version of theirs.
• Hreflangs should be added on every subpage, with accurate URL paths. Linking only your main pages won’t be enough!
• There’s no difference when it comes to the sequence in which we add subsequent versions of the website. The version that is tagged the most accurately, with the language code and region code, will be indicated first – then, the one that has the language code, whereas the last one will include x-default parameter.
• It’s always worth to set up the x-default parameter for those users who we didn’t specify the language for, redirecting them to the most popular language version.
• In order for Google to take hreflangs into account, all connected pages have to be in the index.

Expert Comment

If I had to point out one piece of advice for anyone planning to start implementing different language versions to the website it would be: don’t rush. It’s a step that can really weigh on the effectiveness of your SEO, so it can’t be an impulsive choice. Take your time and consider your options, possible technical solutions to make sure that implementation of the new language version will be effective & will be working for your business

Matt Calik

Head of SEO & SEM

BONUS: Google Tag Manager

Google Tag Manager provides another opportunity to implement hreflangs. This method, however, is not included in the official Google documentation. Their authors claim that it works, though. Some of the elements listed might seem debatable, but many specialists say that GTM gives a lot of possibilities when it comes to SEO.

The whole concept is based on the usage of “Element DOM” variable. Thanks to this variable, it’s possible to build a tag which will dynamically generate hreflangs for every subpage. This method might seem complicated for someone who doesn’t have experience with Google Tag Manager or JavaScript – but all you have to do is to set it all up once and you can be sure that GTM will automatically generate the right set of hreflangs for every page.

You can find a detailed instructions on how to set up the tag on the SearchVIU blog. At the end of this blog post, you’ll find an example that proves that this method works. Theoretically – it should, but using JavaScript might raise doubts whether Google bots will manage to render such a code fragment in every case.

Managing hreflangs and technical aspects

Choosing the implementation method

The implementation of hreflangs with HTML tags or HTTP headers can be inconvenient, especially if we have more than a few language versions. It’s mostly due to the fact that it increases the number of database requests that has to generate those links. Additionally, for 20 language versions, the code needed for proper hreflang implementation will weigh approximately 1,5 KB. It doesn’t seem like much, but it will influence the page load speed, which is currently one of the important ranking factors. Basically, every second counts – which is why we should always stick to as few hreflangs as possible.

Adding the hreflang attribute to the XML sitemap, on the other hand, seems like the best solution for complex, multilingual sites. We don’t burden the subpages, which affects their speed. Simplicity is another benefit – it’s easier to implement and manage hreflangs from one place, rather than editing every single subpage.

Language and region codes

Hreflangs make it possible to link not only different language versions of the website but also the same language versions that are meant for visitors from different countries. It’s especially important when we address the visitors coming from multilingual countries.

For example: if our website is in English, but we have two different versions for the visitors coming from the US and Great Britain, then we should add relevant tags: “en-US”, or “en-GB”. The website, however, can also be visited by Australians, Canadians, or any other English-speaking users. T

For example: if our website is in English, but we have two different versions for the visitors coming from the US and Great Britain, then we should add relevant tags: “en-US”, or “en-GB”. The website, however, can also be visited by Australians, Canadians, or any other English-speaking users. There’s no need to specify the hreflang for each country because you can add only the language code “en” and determine which versions should be displayed to those who are not from the US or Great Britain.

Another example: We operate in Switzerland, which is why we maintain the website in two languages: German and French. We should then have four different language versions:

• A French version of the website for Switzerland  (hreflang=”fr-ch”)
• A German version of the website for Switzerland (hreflang=”de-ch”)
• General French version (hreflang=”fr”)
• General German version (hreflang=”fr”)

We’re not limited in any way by the official languages of a given region. We can mix languages and regions however we want to. For example, if we wish to create a subpage for German-speaking users in France, we would use hreflang=”de-fr”.

In some cases, the language tag can be extended with subtags, i.e. Extended Language Tag (according to the ISO 339-3 classification) or Script (ISO 15924). Such a situation can occur when our website is, as an example, in Uzbek – but in the Latin alphabet. Then, we would use “uz-Latn”. This example shows exactly how rare such cases are.

X-default attribute

At the very beginning, the x-default variable in hreflangs was meant to redirect the visitors to the international version of the website. Currently, however, it aims to serve the users whose language and location are not related to any hreflangs. Coming back to the US-Great Britain example: technically, we could replace the “general, English-speaking” URL with an address including x-default, because both of them would redirect to the same website. Still, it’s better to keep both, since a URL with “en” tag would make it easier for the crawlers to understand the content of the website.

Hreflangs vs. canonical addresses

Hreflangs don’t replace canonical links in any way – they should complement each other. In fact, a hreflang tag added to a site without a canonical tag simply won’t work. We should then add the canonical tag to every subpage. Therefore:

1. On the website http://mywebsite.com we should add:

<link rel=”cannonical” href=”http://mywebsite.com”>
<link rel=”alternate” hreflang=”pl” href=”http://mywebsite.com”>
<link rel=”alternate” hreflang=”en” href=”http://mywebsite.com/en”>
<link rel=”alternate” hreflang=”de” href=”http://mywebsite.com/de”>

2. On the website http://mywebsite.comen:

<link rel=”cannonical” href=”http://mywebsite.com/en”>
<link rel=”alternate” hreflang=”pl” href=”http://mywebsite.com”>
<link rel=”alternate” hreflang=”en” href=”http://mywebsite.com/en”>
<link rel=”alternate” hreflang=”de” href=”http://mywebsite.com/de”>

3. On the website http://mywebsite.com/de:

<link rel=”cannonical” href=”http://mywebsite.com/de”>
<link rel=”alternate” hreflang=”pl” href=”http://mywebsite.com”>
<link rel=”alternate” hreflang=”en” href=”http://mywebsite.com/en”>
<link rel=”alternate” hreflang=”de” href=”http://mywebsite.com/de”>

Additionally, if our site has separate mobile (f.ex. AMP) and desktop versions, there will be some modifications needed. On the iloveseo.net we can find a chart that shows how such an implementation should look like. These guidelines were actually inspired by John Mueller and his recommendations.

Source: https://www.iloveseo.net/how-to-use-hreflang-correctly/

Managing hreflangs:

If we manage to implement hreflangs properly, it’s not the end of the road. In order not to waste our time and effort spent on the implementation, we should make sure that everything works properly at all times. Keep in mind that:

1. If we erase a subpage in one language version, we should also update the hreflangs of its equivalents in different languages;
2. If we set up some redirections, however, we should add hreflangs to the new address.

It’s also worth to keep in mind that when we publish other language versions of our website after Google crawls it, we have to wait for the effects of the hreflang implementation – till its crawlers visit our site again. Before that, Google will only see hreflang coming from the translation to the original, but not the other way round. In this case, when we add hreflangs to a number of subpages (or many language versions), the process of indexing those subpages with hreflangs might take a while.

Useful tools

In order to manage hreflangs properly, we might want to use dedicated tools. As already mentioned, we can take advantage of Google Tag Manager to implement hreflangs and keep an eye on them. There are many tools that are meant exactly for the management of this attribute, though.

Hreflang Tags Generator

When implementing hreflangs, it’s worth using Hreflang Tags Generator. It’s simple: we indicate the addresses of all language versions of our website, we choose what language they are in (from the list provided) or choose “default” if we want to generate the x-default attribute, and optionally select a region. Then, we have to specify whether we want the code exported to the HTML file or XML sitemap, and click on “Generate the hreflang tags for these urls”. You can also upload your CSV file (with up to 50 addresses) into the form, which makes the whole process even more straightforward.

Hreflang Sitemap Tool, Flang

Hreflang Sitemap Tool works quite similarly. Thanks to this tool, we can generate a sitemap with hreflangs, based on the URLs collected in the .csv file. In this case, we’re not limited to 50 addresses – but we do have to provide our email address. Flang is also a simple tool which allows us to check whether all hreflangs on our website work properly.

Polylang

For website managed with WordPress CMS, we can use Polylang plug, which will let us translate various elements of the website (along with media, categories, tags, menu, and or own taxonomies). It will also be possible to add hreflangs into the head section. The plug is available for free with limited functionality.

OnCrawl

If we need something slightly more advanced, it’s worth giving OnCrawl a try. Thanks to this tool, we’ll be able to check whether hreflangs have been implemented properly – when they link to sites on different domains,  as well as when the attribute was added to the HTTP headers or XML sitemap. OnCrawl will also spot the most common mistakes with language and region codes and will check if all subpages have the right hreflang tags. Not to mention that the interface is really intuitive. We can take advantage of the 14-day free trial to check if we want to invest in the tool in the long run.

Screaming Frog

Screaming Frog is also quite useful if we want to check how hreflangs were implemented. In the free version, we can scan up to 500 websites. The software will let us know whenever there’s a hreflang attribute or x-default missing, as well as to what subpages the existing hreflangs refer to, and if there are any errors. In the paid version, apart from the lack of the limit, the tool also checks hreflangs added into HTTP headers and sitemaps.

What to pay attention to – the most frequent mistakes

1. Wrong language/region codes

Language and region codes comprise of two letters, which are often closely related to the country names. Yet, it’s easy to make mistakes, such as “eng” instead of “en” and “UK” instead of “GB”, or simply mix up the order of these codes. Plus, there are various standards when it comes to language codes – for example, Facebook might use similar letters, but applies underscores (“_”) instead of dashes (“-”).

2. Lack of hreflang referring to the current webpage

When Google visits a certain subpage and sees some links with the hreflang attribute, it will immediately know what’s going on. Yet, the official documentation says that the link to the current webpage itself is necessary in order for hreflangs to be implemented properly.

3. Hreflang implemented only for one language version of the site

Since we implemented the hreflang attribute on a given subpage, remembering about the link to the current website, then everything should work properly, right?

Only when we added the same combination of hreflangs on every language version of this subpage. Taking into account that we can link to the URLs coming from different domains – it’s a simple, yet effective guarantee that no one will tag our website as their own.

4. Using the URLs which can’t be indexed anymore, or return the server response code that is different than 200

Similarly to the mistake mentioned above – in order for the hreflang attribute to be implemented properly, the search engine has to see him on both (or every) connected subpages. It won’t work if the search engine bot is unable to display the content of one of the pages, no matter the reason (i.e. due to 4xx or 5xx errors).

5. Hreflang only on the main page

The main page and its language versions are often highlighted to show an exemplary hreflang implementation. It might give us the impression that the attribute on the main page is everything we need, and the search engine will connect all the remaining subpages by itself.

The problem is that It won’t. Hreflangs connect specific addresses with their equivalents in other languages, and the links have to be clear for the search engine. If the main page was enough, it would be much easier. It’s also wrong to connect subpages that are not equivalent.

6. No hreflangs implemented on the sites with national domains

If we have a site with a domain, for example, .com – then adding hreflang tags seems natural. But, if we have translated versions of the site on national domains (such as “.pl”, “.de”, “.fr”), then we might be under the impression that the search engine would know exactly which version to display in the search results.

Now, it might work in certain cases. But if we’re serious about running our own website and implementing hreflangs properly, then we shouldn’t assume that “the Google bot will probably guess which site is the best in a given case”.

7. Canonical link redirecting to the default version of the website

Since our website has a couple of language versions, then one of them is probably treated as the main, aka default version. Therefore, it might be a good idea to set the rel=canonical tag to it, coming from the remaining versions of the site.

It’s a serious mistake that would eventually make those versions disappear from the search results. It’s due to the threat of duplicated content, which is a serious problem for SEO. Nonetheless, hreflangs are a sufficient piece of information for the search engine, indicating that the connected addresses have the same content, but should be displayed differently depending on the language and location of every web visitor.

Clearly, the list of mistakes can go on. If you’re not sure whether a certain case of hreflang implementation is right, let us know in the comment section below.

Conclusion

There might be some complexities revolving around hreflangs – but all it takes is to stick to a few simple rules and implement them gradually in order to improve the rank in search results. Choose the method of implementation (such as HTML headers or XML sitemap) that suits your needs best. Remember about having the right combination of hreflangs on every subpage, including the links to a current page.

Also, always stick to the lowest number of hreflangs possible. Check the correctness of language and region codes thoroughly, keep an eye on the implemented hreflangs, and make changes if needed. Remember that there are certain tools that can help you with that.

Thanks to proper hreflang implementation, you can beat even 75% of other websites around the globe. It seems to be worth the effort, don’t you think?