HREFLang and Canonical Tags are not the Same Thing

I see a number of questions and best practice posts every day that seem to think these tags are and do the same thing.  They ARE NOT the same and DO NOT do the same thing. 

Repeat after me… they are not the same and I cannot treat them as the same. 

Repeat after me… Just because I can do something with Canonical Tags does not mean that I can do the same thing with HREFLang tab…

Good – now I feel better that you have that out of your system. 

What does a correct Canonical and HREFLang Entry Look like in view source? 

This is the most common question I see and the one that has the most incorrect answers on Global SEO Expert sites. 

I have a global site and a UK version of that site at  

My SEO consultant tells me I need to use canonical tags and HREFLang tags, how do I know if they are implemented correctly?   Viewing the source on the my UK home page what should my canonical tag and HREFLang tags look like? 

The correct application is

<link rel="canonical" href="" />

<link rel="alternate" hreflang="en" href="" />

<link rel="alternate" hreflang="en-GB" href="" />

Why: You are on the site and it should canonical to itself.  If you added a tracking tag to it you would want that canonical to tell Search Engines that the “preferred” canonical URL is the root  Remember what you repeated above, they are not the same and do not do the same thing. 

So what does an incorrect implementation look like:

INCORRECT application

<link rel="canonical" href="" />

<link rel="alternate" hreflang="en" href="" />

<link rel="alternate" hreflang="en-GB" href="" />

If you see it coded this way, you might as well not even have the UK home page as it will disappear from the search results because you are telling it to USE the global version and NOT the /uk version. 

If I use HREFLang tags on a page MUST I HAVE a canonical? 


Why Not.  Not saying you cannot use them but they are NOT required.  See below for when and how to use them correctly.

Can I use Canonicals on my site if I have HREFLang Elements?


Why?  If you have any of the conditions that require or benefit from using a canonical tag.  Using them because you have different language versions of your pages IS NOT a valid reason to use them. Using them to remove duplicate pages due to tracking tags, paramters, http and https versions then use use them. 

Do I make the canonical on my country pages point to the master site? 

NO – Never

Why Not:  Ask the question again out loud…  If you add a canonical to a global or master page on a local page that page will be dropped from the search engine because you are saying you prefer the master to global site over this local page.    This screen capture shows a site owner on all of their local versions misunderstood how to use the canonical and added a canonical pointing to the global site to all pages.   When used the canonical must point to the canonical version of itself. 

This was the Australian English page but the canonical says use the global version of the site.  In less than a week, ALL pages except for the global site disappeared from Google. 

Do my hreflang URL’s have to be full path URL’s? 


Why?  Unlike canonical tags where Google lets you be lazy, you CANNOT do so on HREFLang elements. The full path accounts for any variations in URL’s and root domains. There is a tweet going around that says it is ok but not documented and in cases where they were relative or protocol-neutral they generated errors in Search Console. 

Can I use Protocol-Neutral Links on my HREFLang Elements?

NO –

Why Not:  Think about it for a moment, then answer your own question.  Protocol-Neutral URL’s tell a browser or search engines this URL works with both HTTP and HTTPS protocols.  Protocol-neutral URL's are what all the cool kids are doing in apps and are adapting them to pages there is nto a http or https reference but just the // and the requestor takes their pick.  Google will typically take their pick of the https but not guaranteed.

Google specifically instructs you not to use the http version in hreflang if you want the https version to be the canonical.  If you use this format who knows which they will pick as you are staying both are correct. 

Google specifically instructs you not to use the http version in hreflang if you want the https version to be the canonical.  If you use this format who knows which they will pick as you are staying both are correct. 

You are trying to map a page to another alternate and this creates duplicate references.  If that was not good enough reason we have been told a million times to ONLY use 1 version and NEVER use both http and https.

Can the HREFLang Element be used as a canonical to tell search engiens which is the preferred version of the page?  

NO, as mentioned they are two different tags and have different purposes yet people try to do it. Here is an example of a page that thought they could use the local language HREFLang as a canonical.  It resulted in thousands of errors in Search Console.  

Is there a way to check my Canonical Tag and HREFLang Tags to make sure they are correct? 


We have integrated this into both the HREFLang Checker and or core HREFLang XML site Map builder. 


Complete Guide to Using the Using X-Default HREFLang Element

Back in 2013 Google announced the introduction of the X-Default hreflang to designate interenational landing pages.  Unfortunatly we se a lot of people confused on how and when to use it. 

What is the X-Default HREFLang Element?

When you use the X-Default tag for a specifc URL annotations you are telling Search Engines that this page does not target any specific language or location AND is the page to be shown to users when a more appropriate language or local page is not available

X-Default Syntax

<link rel="alternate" href="" hreflang="x-default" />

When should I use the X-Default HREFLang? 

The definition is pretty clear but here are some specific scenarios:

1.  If you use IP detection to serve a specific country or language experience to your users. 

For example IBM, they have 65 language/country versions of their site.   Depending on where you come from you will get pointed to a version of the site.  This works in cases where they have a site but what happens when a user comes from Uzbekistan looking for cloud computing information?  Since they don't have a Uzbekistan site they may want them to see the "master global page" for cloud computing.  However, if a person comes from the United Kingdom they want them to see the UK specific page   By setting  the global page to X-Default, Google would serve that global cloud page to those from Uzbekistan. 

2.  You force users to select a Country or Languge Before entering the site. 

This is the case with When a user visits the site they have to pick their country or language of preference which then sets a cookie to get then back to the original page.  This selector is not tied to any specific country so it should be tagged with x-default. 

3.  You use a global site for any market where there is not a local version. 

Same as reason #1.  When you want the global version of the site to show up when you don't have a local language version.    This is not for a regional site like LatAM where you are trying to cover multiple countries and languages with the same site.  For specifics on using HREFLang for regional sites please review our guide. 

Huawei is an example of this.  While they offer 107 individual country and language versions of the site, they have a Global English version that is the default site to show when they do not have a local version.  

Can I use the X-Default HREFLang to designate the page is also a target language?


Yes, you can pair an X-default and maybe "en-US on a page if your global page is also the preferred page for the United States AND you do not have a specific page. 

For example, Dropbox has set their core domain to both X-Default and to Global English

<link href="" rel="alternate" hreflang="x-default" />

<link href="" rel="alternate" hreflang="en" />
<link href="" rel="alternate" hreflang="en-gb" />

Another variation is where they map the global site to both X-Default and to en-US

    <link rel="alternate" hreflang="x-default" href="" />
    <link rel="alternate" hreflang="en-us" href="" />

What are the most common X-Default errors? 

The X-Default error we see the most is when the x-default is set for multiple counties and regions.   For example, Samsung, on the US site they have set /us as the X=Default and also as the en-US version.  If you go to Samsung UK you see they have also set /uk version of the site to be the X-Default and teh page for en-gb which is incorrect and confusing to search engines.  

       <link rel="alternate" hreflang="en-us" href="">
       <link rel="alternate" hreflang="x-default" href="">

UK site is also set as X-Default

<link rel="alternate" hreflang="x-default" href="">
<link rel="alternate" hreflang="en-gb" href="">
<link rel="alternate" hreflang="en-ie" href="">


Even Great HREFLang Implementations Have Problems

At a recent Search Conference a site was identified on Twitter as haveing a “Great Implementation of HREFLang tags” which just begs for someone to test it using a HREFLang Checking tool which I did. as did @thisislobo using his HREFLang Testing tool which found similar problems.   

The site is a large ecommerce site with 34 country versions, which is a decent size global site.  I am blocking out the domain name out of respect to the person who gave the presentation who I have known for a number of years.  Overall the implementation is really good with one specific error and two other issues that require review. 

Issue #1 – Incorrect country or language codes

This is one of the most common problems I see with HREFLang tags.  People just don’t invest the time to make sure they are correct which is why it always pays to use a tester to ensure compliance.  

In the HREFLang element they are using at-AT but unfortunatly there is no AT language code.  This is the Austrian site and the primary language in Austria is German.  Looking at the page source code, the XML Language code it is set for <html  xml:lang="de-DE" lang="de-DE" xmlns=""> which means the page is actually Germany German and not Austrian German.  Note, this is the #1 reason why Google does not use this tag since most of them are wrong.  

 Issue #2 – Local Sites Not Mapping Back

When there are a lot of tags we often see one or more markets not linking back to the original page, which is the case on this site, and I identified three reasons:

Local site set incorrectly to x-default 

Looking at the pages with the problem they had made the local page the x-default and mapped the local page to x-default rather to the actual global page. 

For example, the Finnish site the page has 34 rows of HREFLang which is the correct number of alternate tags.  However, the script they used mapped the Finnish page to the x-default as the 34th match and did not map back to the Global page whicis set on the home page as the x-default page.  Do you really want the Finnish page to be the default page or the global page? For more informtion on the correct use of x-default please view our guide.  

Local Page Does Not have HREFLang Tags 

In this case with Australia and also New Zealand these pages are missing all of the HREFLang tags.  They are on the product pages but were not on the home page and seemed to be left off for some reason.  Assumption is that they have cloned the site and using it for both countries so an error on one will generate an error on another.

Local Page is Missing  

Some of the internal product pages had links to missing pages.   These are either products not available in that market or for some reason they assumed the country had that page.  While not an incorrect HREFLang implementation, mapping to the incorrect or broken page does reduce your crawl budget.   This is a very common problem with dynamic settings especially using in page elements as they incorrectly assume you have that page for every country.   This is one that we have added to our HREFLang XML Builder tool to map all of the pages and find missing pages.

Issue #3 – Too Many in page HREFLang Tags

In the screen capture from the session it shows a lot of HREFLang tags. As mentioned above, there are 34 country sites represented meaning 34 lines of HTML embedded into the page.  This IS a completely valid method to implement HREFLang but that is a lot of code to add to a page unnecessarily.   Using we find that the HREFLang text is 4.08kb of the total HTML weight. Using Web Page Testing tool we calcuated the total HTML code is 31.5kb making the HREFLang tags nearly 13% of the overall HTML load of the page.   That is a lot of extraneous code that can be shifted off the pages into XML site maps.  We have some additional information on page weight increases caused by HREFLang attributes.

Again a good implementation of the HREFLang but a few things to consider during the process to ensure that it is 100% correct to reduce the errors in Webmaster tools but more importanlty allow it to correctly map the local pages.  


HREFLang XML results in 200% Increase in Traffic to South American Sites

Many companies cut corners trying to cover the 19 countries and territories from Mexico into the Caribbean and down into Central and South America by lumping them into a "Latin America" go to market strategy.   This is done typically with a single regional site or by using copy and paste of an existing Spanish language site into country folders and wait for traffic from this fast growing region to roll in. 

This second option, cloned individual market sites, is where we see the most performance problems.   In the majority of the cases there is no way to distinguish these cloned sites from any another Spanish version of the site.   Yes, some of them have added local currencies; different address and phone number and maybe some of the more professional have adjusted for the linguistic differences.   The more effort you make the better you will perform not just with SEO but in sales.

Our most recent HREFLang implementation success story did many things correct.  They had 7 different sites for the region plus the standard "LatAm" regional catch all site and a site dedicated to Spain.  They did have unique currencies, contact information in schema tags in the footer, HTML Country and Language Tags in the header, and most of the sites had some level of language localization for the market.  They thought all was good which is why they did not know they had a problem.  

This belief was further compounded by their global Search agencies use of a enterprise SEO management tool to provided them rank reports.  The local market reports showed they were ranking well in these markets especially for branded and product name terms.   What the agency did not report was that in most cases, it was the wrong country page that was ranking.  

The client first started working with Back Azimuth using DataPrizm to catalog and mine keyword opportunities.   As part of the DataPrizm onboarding process, we set Preferred Landing Pages to all of the key product keywords.  We had an alert that a different country page is ranking for the key products.    We dug deeper and found that in most markets an Argentina pages or regional page was ranking vs. the local pages and the following additional challenges. 

Fixing Incorrect Country Page Problems

We imported all of the XML site maps into HREFLang Builder and created the HREFLang XML site maps and immediately encountered a few problems:  

Problem 1 -  301 Redirects to Regional Pages 

We had a number of product pages for products that were not yet sold in the region or no longer sold in the market so the redirect was correct but you should update the xml site maps to remove these URLs. 

Problem 2 -  Different Country Canonical Tags

For Peru, the pages were cloned and the dev team left the canonical tag to the old site.  For example, the new pages were copies and added to /pe/es but the canonical tag still had a reference to /ar/es so Google was not indexing the pages from Peru.  A simple crawl of the site post launch should have detected this.  Also, a simple check of local page index rates would have identified this problem. 

Problem 3 - Missing Pages

Similar to problem 2, but not because of a new product or a sunset product, but due to the page not actually being localized.  Since it was not localized their CMS did not build a page but the tool that was building XML site maps was automatically adding a page.  By using our "Missing Page" feature we were able to quickly identify which pages had not been added to XML site maps and set them for localization. Note, we do not add a entry in the HREFLang XML unless there is a matching page. 

We could spot most of these problems in less than 1 hour with the error detection and "Missing Pages Report" that are native to HREFLang Builder.  It took a few hours to clean up the easier issues and reload the HREFLang XML site Map.   Once uploaded to the server and refreshed in Google Search Console, we started seeing some changes as early as the next day and within a month, the correct country page was ranking for many of the products.  We did a recheck 3 months later and the entire region as a whole had a traffic increase of over 200%.  

Problem 4 - Agency Resistance

The global Agency in this case was another detractor.  They were against using XML site maps as they had a propsal to build a feature for their CMS to generate the tags in the page.  Note, this company has 72 market sites so adding that much code to the page was crazy.  Second, they argued that by altering the pages ranking we would severely impact traffic to Argentina and Spain.  Argentina was getting a lot of traffic due to it ranking in many countries but the orders were low due to different country, currency and shipping costs. 

Significant Improvements in Performance

We then broke down the traffic to the individual country sites and that is where we saw even more improvement.  Peru, where the canonical was pointing to another country, had an increase of traffic of nearly 600%.  


Spain traffic did not decline as the agency predicted, in fact it was the second largest increase with 430% as many of the pages that were ranking were for the regional site. 

Argentina traffic also increased by 160% as did revenue as more of the local people entered the site vs. from other markets. 

It was not that much effort to make this improvement.  Yes, it identified many problems with the site and the workflow but for each problem that was fixed more improvement was realized.   No fancy SEO techniques were required just making sure all the signals were correct.  By using XML site maps for the HREFLang management we get a lot of flexibility in tuning them, as well as ensuring that they are correct, maximizing overall indexing and market identification.