Despite being introduced by Google ten years ago, many site owners still struggle with getting hreflang correct. Often, this is due to common misconceptions and the wishful thinking of developers.

In 4 Reasons International SEO Fails, I highlighted the common challenges of duplicate content from websites across the portfolio and recommended leveraging hreflang to complement existing geo-targeting methods.

It can also help you combat traffic cannibalization by dominant market sites.

Despite the fact that it is extremely effective when implemented correctly, there still seems to be a lot of confusion around hreflang.

Misconceptions can result in sites being paralyzed on how to implement; we see this in recent research that shows 40% of the top multinational websites were not using hreflang elements and of those, 58% used it for the homepage only.

Worse, many go ahead and implement with serious errors.

Site owners are confused by implied and literal statements in the somewhat dated support guidance from Google and interpretations of them by popular SEO bloggers.

So in this article, I will attempt to explain some of these misconceptions that need clarification – and hopefully, will not confuse things even more.

Misconception 1:  We Only Need Hreflang On The Home Page Of The Site

More and more sites have only implemented hreflang for their home pages, in many cases due to using multiple CMSs to manage their sites. However, this makes cross-tagging impossible.

In one case, the SEO pro implementing it only on the home page told me that, “Google is smart enough to figure it out – we just need to give them the template and they will understand.”

Unfortunately for the client, Google did not understand it and was showing the incorrect page in local markets.

Clarification

The hreflang element must be added to any and all pages that have an alternate language version or included in an XML sitemap and not just home pages.

Misconception 2: We Only Need Hreflang On Dot-Com Domains

I have heard this excuse from development teams that cannot develop a solution to map pages across different top-level domains.

They assume since they use ccTLDs like .co.uk, the search engine should understand what country they are targeting. (Check out Eli Schwartz’s excellent article on ccTLDs and their benefits for more.)

Unfortunately, search engines’ interpretation of ccTLDs is not perfect, and in markets like Switzerland and Belgium that have multiple languages, Google may show any of the different language variations.

Clarification

I recommend doing a test to make sure it is understood and that no other local sites are ranking in the market.

If it is working great but other market pages are incorrectly ranking, then you should make the case to implement it on all domains.

Use the hreflang element for any page that has an alternate, no matter what domain it is on. While ccTLDs are a strong geolocation signal, they do not indicate language making ccTLD and hreflang the perfect combination to remove ambiguity.

This is actually one of the best reasons to manage your hreflang elements with XML site maps. Enterprise hreflang XML tools can map the URLs no matter what domain they are on.

You can also host the XML site maps for all of the different sites in the same location. This makes maintaining them much easier.

Misconception 3: The X-Default Can Only Be Used On The Home Page With A Country Selector

A few SEO pros have written that the x-default is only to be used when you have a home page that has a country selector and should only be used on this page. This is only partially true.

There are two specific applications of the x-default.

Clarification

The first applies to sites with forced language/location selectors like FedEx or Ikea. These sites present a splash page with a language and/or country selector asking the visitor to choose which location and/or language version of the site they want to visit.

Since this page does not target any specific language or country the x-default tells search engines to present this page in any market that does not have an assigned page.

Where the SEO pros are incorrect is how to handle older and large multinationals, especially those in the United States, which often use the main dot-com site as both their global site and their U.S. site.

In this situation, they should also use the x-default.

A good example is Cisco, which does not have a dedicated U.S. version of its site. Since these pages do double duty, to make them both the preferred URLs for the rest of the world and set them for the U.S., they need to add a double entry to their hreflang to set the same page as both x-default and U.S. English, similar to the example below.

<link rel=”alternate” hreflang=”x-default” href=”https://www.mysite.com”/>

<link rel=”alternate” hreflang=”en-us” href=”https://www.mysite.com.com”/>

<link rel=”alternate” hreflang=”pt-br” href=”https://www.mysite.com/pt-br/index.html”/>

Misconception 4: EU, LA, and ME are Not Valid Regional ISO Codes for hreflang elements

There are some sites that have set their LatAm regional site to “es-la” hoping Google would interpret “la” as Latin America when it is actually the country code for Laos.

Similarly, Macedonia’s “me” country code is incorrectly being used for the Middle East regional sites.

Your entry is indicating the sites are for those specific language regions.

Clarification

Unfortunately, there are no options where you can use a country code to represent a region, or the code for an “economic region” represent the group of countries and languages represented by their membership.

Your only option is to use the recommendation below for managing regional sites.

Misconception 5: Regional Sites Cannot Use an Hreflang Element

Regional sites are the budget-constrained approach to targeting multiple countries in a region using a single language site.

The most common of these regions are APAC for Asia Pacific countries, LatAM for South and Central American countries region or MENA covering Arabic speaking Middle East countries and North Africa.

Clarification

The hreflang can be used on a regional site in a couple of ways.

The first is by setting the regional site to a common language in the region.

This is commonly done with an Arabic language site targeting MENA. In the example below they set the regional site as the preferred for Arabic language markets.

<link rel=”alternate” hreflang=”ar” href=”https://www.mysite.com/meana-ar/index.html”/>

Another way companies are using the hreflang element is to tag the same page for multiple countries.

Sites will often do this when they already have a designated language site, multiple local sites in the same language, and want this version to appear in specific markets rather than the x-default or language version.

In this approach, the element would be listed for each of the language markets you are targeting. Google has indicated it is ok to reference the same site multiple times for different language markets, but don’t go crazy with it.

<link rel=”alternate” hreflang=”es-ar” href=”https://www.mysite.com/latam-es/index.html”/>

<link rel=”alternate” hreflang=”es-pe” href=”https://www.mysite.com/latam-es/index.html”/>

<link rel=”alternate” hreflang=”es-cl” href=”https://www.mysite.com/latam-es/index.html”/>

Misconception 6: To Save Lines of Code, Add Multiple Codes To The Hreflang=Syntax

I have seen this a few times especially in hreflang tags added to pages.

The site owner told me that the SEO pro who implemented it was told by Google they could cut down on the number of XML site map entries or lines of code by adding multiple country and language codes to the syntax.

<xhtml:link rel=”alternate” hreflang=”es-ES;fr;fr-BE;fr-CH;pt;it;it-CH;de-CH;de-AT;de;en-GB;en;en-IE”

Clarification

No, this does not work.

Google’s documentation is very clear that you must create a separate hreflang element for each URL. If hreflang is not deployed properly, it will just be ignored.

Misconception 7: You Should Set Your Rel=Canonical To The Global Site

This is a huge misunderstanding and doing so will remove your local language pages almost as fast as blocking them with a robots.txt entry.

This is one of the biggest mistakes I see companies making related to hreflang other than incorrect country and language codes.

Most make this suggestion in the context of removing duplicate content. The hreflang element essentially does this for you.

If you have an e-commerce site for the U.K. with prices in British pounds that is a content duplicate of the U.S. site in U.S. dollars, you should use the hreflang to separate them.

Do not block the U.K. site as this may have a significant impact on sales in the local market.

Clarification

The rel=canonical must point to the local language page it is on and never point to any other page unless you want the page to be blocked.

If that is the goal, then there is no need for an hreflang tag to be on the page.

For example,

<link rel=”canonical” href=” https://www.mysite.com/pt-br/index.html “/>

<link rel=”alternate” hreflang=”pt-br” href=”https://www.mysite.com/pt-br/index.html”/>

Misconception 8:  You Can Combine Hreflang And Canonical Tags

This is another mistake I see frequently, where developers try to combine the canonical and the self-referencing hreflang element into a single tag.

In this case, it was the page for Ireland English.

<link rel=”Canonical” hreflang=”en-IE” href=”https://www.mysite.com/ie/”/>

<link rel=”alternate” hreflang=”es-AR” href=”http://www.mysite.com/ar/”/>

Clarification

The rel=canonical must be its own entity, as must the hreflang element for the page.

You cannot combine them under any conditions. A correct entry would look like the code below.

<link rel=”canonical” href=” https://www.mysite.com/ie/”/>

<link rel=”alternate” hreflang=”en-IE” href=”https://www.mysite.com/ie/”/>

<link rel=”alternate” hreflang=”es-AR” href=”http://www.mysite.com/ar/”/>

Misconception 9: The Rel=Canonical Can Serve As The Self-Referencing Entry

I have not been able to find the source for this little gem of information, but it is completely incorrect. Even so, many SEO pros are still using it.

If your site has a large number of non-self-referencing errors in Google Search Console, it is typically caused by site owners trying to make the canonical do double duty as the self-referencing element.

Here is an example of this mistake when referencing the Argentina Spanish page.

Argentina Site – https://www.mysite.com/ar/

<link rel=”alternate” hreflang=”en-IE” href=”http://www.mysite.com/ie/”/>

<link rel=”Canonical” hreflang=”es-AR” href=”https://www.mysite.com/ar/”/>

Ireland Site – https://www.mysite.com/ie/

<link rel=”Canonical” hreflang=”en-IE” href=”https://www.mysite.com/ie/”/>

<link rel=”alternate” hreflang=”es-AR” href=”http://www.mysite.com/ar/”/>

Clarification

This is incorrect, and you must use a hreflang element for the self-referencing element.

For example, if the hreflang tags are on the local pages they should look like this.

Argentina Site – https://www.mysite.com/ar/

<link rel=”alternate” hreflang=”en-IE” href=”http://www.mysite.com/ie/”/>

<link rel=”alternate” hreflang=”es-AR” href=”https://www.mysite.com/ar/”/>

Ireland Site – https://www.mysite.com/ie/

<link rel=”alternate” hreflang=”en-IE” href=”https://www.mysite.com/ie/”/>

<link rel=”alternate” hreflang=”es-AR” href=”http://www.mysite.com/ar/”/>

Misconception 10: You Cannot Use HREFLang With Both ccTLD And Dot-Com Domains

This is a relatively new misconception that occurs with fast-growing multinational e-commerce sites.

They have been told that implementing hreflang was not possible due to using multiple domain configurations including ccTLDs, Dot-Com domains, and language folders or subdomains to represent specific market or language sites.

Clarification:

While it is true that your CMS or e-commerce platform may not be able to add hreflang tags to pages outside of the main configuration, that does not mean hreflang is not possible.

Companies have solved this challenge using hreflang XML sitemaps generated independent of the system and hosted on a central location, then used the cross-site XML validation method via Google Search Console to authenticate ownership.

Conclusion

John Mueller of Google has stated that the hreflang is one of the most complex technical issues SEO pros must deal with. The items addressed in this article help support the statement that hreflang is complex but it does not have to be.

Unfortunately, a lot of hreflang’s perceived complexity comes from incorrect interpretations of how hreflang actually works and overly complex global website infrastructures.

Before you tackle your hreflang implementation, take a moment to think about what problems you are trying to solve and whether making any of these changes will cause new problems.

Start with small sections of your site, especially those with the same language, and work from there. Even partial implementation of hreflang can reduce traffic cannibalization, cart abandonment and increase local market revenue.

More resources:

Featured image: Shutterstock/Minerva Studio