Make a Business Case for HrefLang Implementation

April 6, 2021

Hreflang Challenges for International SEO

May 20, 2021

Hreflang’s Biggest SEO Misconceptions

Hreflang is extremely effective for SEO when implemented correctly. Done wrong, it can be costly. Beware of these eight common hreflang implementation misconceptions. Recently, Motoko Hunt published an article about the key decisions necessary to use SEO to reach overseas markets. She offered a number of excellent tips on how to effectively geotarget websites and stated the hreflang element was a very effective method to indicate the target market of your web pages.

In this article, I will attempt to explain some of these misconceptions that need clarification and hopefully will not create more confusion.

Misconception 1: We Only Need Hreflang on the Home Page of the Site

This is not very common, but a few sites have only used hreflang tags on their home pages.

Unfortunately, Google’s sample code only shows the home page version of a URL resulting in some interpreting that to mean you only need them on home pages.

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 version or included in an xml site map and not just home pages.

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

I have heard this excuse from many dev 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. (For more on ccTLDs and their benefits check out Eli Schwartz’s excellent SEJ article.)

Unfortunately, search engines’ interpretation of ccTLDs is not perfect, and 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, then great! But if other market pages are ranking, then you should make the case to implement on all domains.

Clarification

It is strongly recommended that you use the hreflang element for any page that has an alternate no matter what domain it is on.

The challenge is most CMSs cannot map alternate URLs that are on their own ccTLD. This is actually one of the best reasons to manage your hreflang elements with XML sitemaps. The XML can be developed externally and submitted and not require tags to be added to the page.

You can also host the XML sitemaps for all of the different sites in the same location using cross-domain hosting. This makes maintaining the files much easier and does not require assistance from IT.

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 a selector 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 their site. Since these pages do double duty, to make them both the preferred “rest of the world page” and set it for the U.S., they need to add a double entry to your hreflang to set the same page as both x-default and U.S. English, similar to the example below.

Misconception 4: Regional Sites Cannot Use an Hreflang Element

Regional sites are the budget-constrained approach to targeting multiple same language countries in a geographical region like Latin America 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.

The confusion comes from the very nature of hreflang. The hreflang is for designating a language and/or a language for a specific region.

Clarification

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

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

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

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.

For more information about leveraging hreflang for regional sites we have a number of options.

Misconception 5: To Save Lines of Code Add Multiple Codes to the Hreflang= Syntax

I saw this interesting application for the first time this week. The site owner told me the SEO provider who implemented it was told by Google they can cut down on the number of XML sitemap entries 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 is clear on this: you must create a separate URL element for each URL.

Misconception 6: 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 and not block the U.K. site which 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,

Misconception 7: You Can Combine Hreflang and Canoncial Tags

This is another mistake I am seeing more and more 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.

Clarification

The rel=canonical must be its one 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.

Misconception 8: 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. More than half of the hreflang implementations we have fixed had some sort of problem with the code implantation most due to lack of understanding of hreflang fundamentals. I have spoken with a number of site owners that were confused by implied and literal statements, in the somewhat dated support guidance from Google and interpretations of them by popular SEO bloggers.

When we see a lot of self-referencing errors in Google Search Console, it is caused by site owners trying to use a canonical for the self-referencing element. This is an example of this mistake when referencing the Argentina Spanish page.

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

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

Clarification

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

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

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

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

Conclusion

Google has repetdly stated that the hreflang is one of the most complex technical issues SEO pros must deal with. The misconceptions detailed in this post supports their claim. Unfortunately, a lot of these challenges come from incorrect interpretations of how things actually work. Before you tackle your hreflang implementation, take a moment to think about what problems you are trying to solve and if making any of these changes causes any new problems.

Make a Business Case for HrefLang Implementation

Hreflang Challenges for International SEO

Make a Business Case for HrefLang Implementation

Hreflang Challenges for International SEO

Misconception 1: We Only Need Hreflang on the Home Page of the Site

Clarification

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

Clarification

Misconception 3: The X-Default Can Only Be Used on the Home Page with a Country Selector

Clarification

Misconception 4: Regional Sites Cannot Use an Hreflang Element

Clarification

Misconception 5: To Save Lines of Code Add Multiple Codes to the Hreflang= Syntax

Clarification

Misconception 6: You Should Set Your Rel=Canonical to the Global Site

Clarification

Misconception 7: You Can Combine Hreflang and Canoncial Tags

Clarification

Misconception 8: The Rel=Canonical Can Serve as the Self-Referencing Entry

Clarification

Conclusion

Bill Hunt

Related posts

Website Migrations and Hreflang Integration