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 sites.
One of the best methods is to use the hreflang element.
While extremely effective when implemented correctly, the confusion around hreflang has resulted in many sites either paralyzed on how to implement or implementing them with serious errors.
As previously reported from SEMrush’s research,75 percent of hreflang implementations had serious errors with their implementation.
More than half 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.
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.
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 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 are 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.
It is strongly recommended that you use the hreflang element for any page that has an alternate no matter what domain it is on.
This is actually one of the best reasons to manage your hreflang elements with XML sitemaps. Enterprise hreflang XML tools can map the URLs no matter what domain they are on.
You can also host the XML sitemaps 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.
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 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.
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.
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.
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.
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.
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.
In the majority of cases where a site has a lot of non-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/
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/
John Mueller of Google recently 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 that statement.
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 cause any new problems.
We will continue to drill down into hreflang over the next few articles so stay tuned.