HREFLang for Regional Sites

Many sites try to cover a large area of the world with a regional site like LATM for Latin America or APAC for all of Asia.  The problem is there is no country setting nor is there any provision with the HREF Language settings.  What has worked for a number of my clients is to set that regional site to represent the various countries in the region. For example, HP has a single home page to represent Spanish speaking countries in the Central/Latin America region   Which has resulted in a less than optimal search result for these markets. Using Costa Rica as an example – where the global page is the page that is ranking and the site links are for Latin America, Spain, Central America and even UK for flavor. regional Sort of creating a site specifically for Costa Rica HP only has two ways to try to improve this result:

Option 1 – Set the regional Site to Global Spanish

This option is not perfect but should at least tell Google this is our Global Spanish language version and this should replace the global home page. <xhtml:link rel="alternate" hreflang="es" href=""/> and that would make all of the non-included Spanish countries use the Latin American version. Since the major countries are covered this might be a better solution that using the x-default and setting English.

Option 2 – Make the Regional Site the Alternate for Each Country

As the bulk of Spanish speaking countries are in this region, it can be safe to set it as the global Spanish version as in Option 1.   However, to maximize the alignment to the specific countries we suggest mapping the regional page to the various markets using HREFLang XML site maps.   Note, I have vetted this with Google and they have confirmed there are no issues with implementing this approach.

Costa Rica <xhtml:link rel="alternate" hreflang="es-CR" href=""/>

Belize <xhtml:link rel="alternate" hreflang="es-BZ" href=""/>

Honduras <xhtml:link rel="alternate" hreflang="es-HN" href=""/>

Nicaragua <xhtml:link rel="alternate" hreflang="es-NI" href=""/>

Panama <xhtml:link rel="alternate" hreflang="es-PA" href=""/>

El Salvador <xhtml:link rel="alternate" hreflang="es-SV" href=""/>

Guatamala <xhtml:link rel="alternate" hreflang="es-GT" href=""/>

This is easy to do in our HREF Builder to map these to the various countries and build out the HREF XML.  


HREFLang Builder Benefits

Multinational companies have struggled for years to get the local versions of their site ranking in their respective countries.  Most rank reports have simply recorded any page ranking as a win without consideration to it being the correct page.  Not having the local version of the page ranking creates problems with language, currency

Benefits of HREFLang XML SIte Maps Builder

There are a number of key benefits to using our HREFLang Builder:

Time and Cost Savings: 

Without HREFLang Builder, a global company typically spends 20 to 50 hours to manually develop and implement HREFLang XML Site Maps.   Due the size of the files and number of URL’s it cannot be managed in Excel.  The alternative is to embed HREFLang elements in the pages which adds 3kb to 80kb of text depending on the number of entries slowing down pages.  Additionally, estimated development costs between $15k to $60k and 3 to 6 months to add into the CMS. 

For an organized site, using HREFLang Builder takes less than 1 hour to implement.   

Importing & Mapping Alternative Pages to Each Other

HREFLang Builder imports URL’s from existing XML maps, Excel, CSV, Deep Crawl and Screaming Frog segmenting them into countries and language.  The HREFLang element works by telling the search engine that pages B and C are alternative language versions of page A.  You then have to state that they are also alternates to each other.

We built a Regular Expression Engine that would detect the one of 127 different URL structure formats used to designate country and/or language.   By using regex rules, we can accommodate for the use of multiple variations and even parameters in the URL’s which makes this scalable for even the most dysfunctional web operations team.  

Error Detection and Management

Submitting hundreds of error laden XML site maps can be devastating to a site’s crawl budget.  Search engines will reduce their crawl rate significantly if even 1% of the submitted pages in a site map have errors resulting in significant missing pages.  URL’s are checked for robots, canonical, and header rules. By excluding pages with errors from the final XML exports we ensure that 100% of submitted URL’s can be indexed quickly maximizing crawl allocation.  These error reports can be exported and shared.

Dynamic Updates

Manual updates would labor intensive so once a job is created it can be refreshed automatically at a desired interval then export or upload new XML files.   

Missing Language Pages Monitoring

Our Missing Pages mapping function was originally developed to find gaps in country URL lists.   It has become a popular tool to monitor missing, non-localized and in some cases, rogue market pages.  As many CMS systems do not create a page if it has not been localized many pages may be missing from dynamic XML site maps. 

The implmentation of HREFLang XML site maps has lead to significant opportunity recovery for clients, which is the reason this product should be used by every multinational to quickly and easily manage the inclusion and of their gloal XML site maps.   


Adding HREFLang Link Elements to Global Site Directories

Our testing tool was generating some incorrect errors from large sites that were using the HREFlang in the body of pages to designate different language versions in their country locator.  Note, this HREFLang element is NOT the same as the one for Search Engines.  This one was designed to help browsers and bots to detect if it should go into specific content types and language types.  

Hat Tip to Adobe Search & AEM Teams for pointing out the error in the testing tool. 

If you use this implementaiton on your site you MUST ALSO use one of the correct HREFLang Implementations

If you do use this ensure your team reads the HREFLang Link specification on W3C as it stipulates that the two letter ISO Language code be used.  In the two cases below they are using incorrect syntax of country and language and incorrect ISO Language codes. 

Here is another case where it was baked into the Country Locator that is in a pull down.  

I have seen a few of these lately so someone must have gave it as a suggestion to webmasters.   The HREFLang Element must either be in the response header, the <head> or in an XML site map – it CANNOT be anywhere else in the page.  

This is why we added this function to our HREFLang Testing tool

A secondary problem to this implementation is the incorrect use of country names, or countries rather than language elements. 

This would actually make a lot of sense as a way to implement.   I actually started working on a recommendation for Search Engines to adopt something like this where you can plug it into this page but unfortunately 99.99999% of sites only send people to the home page vs. to a local page and about 90% of these global locators are not updated. 


Incorrect Global Canonicals

Recently in Sydney I asked asked by one of the attendees to take a look at their HREFLang implementation.   They had spent hours looking at it but Google still gave errors saying they did not have alternatives set.   As we have identified before, one of the reasons the search engine cannot find your alternatives is you have set a global canonical on the local pages. 

I this example, if we review the source on the Singapore page,  we see the HREFLang Element is correct but look before and you will see that the Singapore page has a canonical set to the global site.  As such, search engines will not index the /sg pages resulting in a hreflang alternate "not found error".  

It is critical to test to ensure that the canonical on each page is correct and IS not another language page or a global page.   

Note:  We have added canonical checking to the HREF Testing Tool. 


Using Screaming Frog to Find In-page HREFLang Mark-up

Our HREFLang Checker is a great tool if you are checking a single page and its alternatives.  However, if you need to check your entire site and identify pages with hreflang mark-up there are not many options.   With the new release of Screaming Frog 6.0 it is amazingly easy to do.  You simply set it once and Screaming Frog will automatically add additional columns for the elements it encounters which is a huge time savings over the previous version. 

 You have been able to check some of your pages with earlier editions of Screming Frog but was a pain to set up and you could only check up to 10.  If you have not upgraded yet and want to do it you can set it up using a excellent step by step guide from Justin McKinney at WPromote.   You can also generate a similar report with DeepCrawl which I will profile shortly.

Setting UP Screaming Frog to Find HREFLang Mark-Up

Start wtih opening Screaming Frog and click the Configuration option in the top navigation then click Custom > Extraction and it will bring up the Custom Extraction Module.

Once you choose "Extraction" it will open a new screen.  Once open enable the following settings:

Step 1 -  Replace Extractor 1's title with one of your Own - I used "HREFLang" but you can name it anything you want. 

Step 2 - Choose "XPath"

Step 3 - Copy or type (//*[@hreflang])/@hreflang into the box - if you added it correctly you will get the green check mark.  If not a red X

Step 4 - Click OK.   

Set the rest of your crawl configurations and run the report.  Once complete, you can view your results by clicking "Custom" in the subnavigation area.   As noted, the HrefLang2, HrefLang3, etc are added for you.  Before we had a limit of 10, but in this case I was able to get all 24 different elements. 

Like most results in SF, you can export the results.  Click "Export" and choose export format of Excel or CSV

Bonus Steps: 

While a fast and easy way to gather all of your HREFLang elements in a single export it does not check them for accuracy.  As you can see in some of the rows above there are errors.  Suggest you take a random sample of the pages and put them into our HREFLang Validation Tool which tests 30 different variables. 

Some of the errors that we see in this result are: 

1.  All pages seem to have a "en" setting but none of the other languages and those pages do not reciprocate with alternate tags.

2.  The country/region code for the UK is incorrect it should be GB

3.  The language code for Japan should be "ja" and not "jp" which is the country code

4.  A big error that Screaming Frog did not detect, nor its it designed to detect, the site is using the same country/language URL for all HREFLang entries on a page.  While it has 24 HREFLang rows all of them used the same URL. This can be ok to use the same URL for regional URL's but not every country and every language in this case.  This would tell the search engien that the Spanish language Latin America page is the page for Japan which is not correct.   

Note:  While there is no limit to the number of HREFLang Elemets you can add to a page we suggest keepig it under 5.  If you start adding too many the code adds up.  For more information read our Help Guide on Too Many HREFLang Elements


HREFlang Error Pointing to Same URL for Each Reference

We are starting to see more and more of these errors where the site uses the same alternate URL for each of its entries.  Teh image below will help make the problem clearer.   We beleive it is one of the free tools that is causing the problem but not sure which one.  While developing the screen captures for using Screaming Frog to test HREFLang mark-up it appeard the pages for each country were correct.   They all had 24 sets of markup. Once I put the URL's into HREFLang Checker we find that while we find HREFLang markup on each page it all of them point to the same URL. 

When we look at the source code we see they have set used the same URL for every entry.  Essentially telling search engines that the /jp version of the page is the page for all 24 countries. 

Going to the French language France page, we find the same thing, the /fr page has been used as a reference for all entries. 

Even stranger, we check one more and go to the German page and find that it is correct.  Each country is referenced correctly. 

This is why we suggest taking a sampleing of the pages and test them to make sure there are not other errors that Screaming Frog or other tools are not catching. 


HREFLang Fix Results in 58% Increase in Local Traffic

Business Need:

Client approached Back Azimuth with a problem that they were not ranking well AND getting much traffic from their local markets assumed duplicate content or lack of indexation might be a problem.   They put an interesting contraignt on the project to not significantly cannibalize US and Global Site Traffic. 

Project Goals:

  1. Increase pages indexed in local markets
  2. Increase organic search traffic to local markets
  3. Ensure local page is ranking in local markets


Back Azimuth reviewed the 45 countries and found that most of the XML site maps were missing or outdated.  New XML files were created for each country and loaded into HREFLang Builder.   Using the Index Checker functionality found that globally 74% of the pages were not indexed in some cases over 90% were not indexed.


Since the implementation in March, all three  business problems were solved and even stayed within the cannibalization constraignts.  

Local Market Traffic Increase - All markets experienced at least a 20% increase in organic traffic a 75% global increase. 

The 8 critical markets colelctively had a 58% increase.  All markets had an increase with the least of 21% (due to getting a large share already) up to 99% for South Africa and 86% for Australia.  This was over a 3 month period.

As a result of increased indexing there was no traffic cannibalization with both the global and US site traffic increasing 22% and 48% respectively. 

Local Site Index Rates - All markets experienced a significant increase in the number pages indexed and in total from only 26% to 98% indexed.   


HREFLang Management for Regional Sites

We first wote about HREFLang and Regional Site Management last year when we saw a number of incorrect implementations around Asia Pacific.  We have had a rash of questions as our HREFLang Checker is flagging this as a possible warning to ensure that you have not set this incorrectly.   

In a perfect world, a site would have unique local language content for each market they target.  For those in the real world, they often lump similar language regions into the same site.  The most common are South and Central America wraped into a single Spansh language "LATAM site and and Asia covered by a English language "APAC" site. 

Since these are in Spanish and English they are often duplicates of another single market site.  As they can be perceived as duplicates by search engines we need to integrate them into our HREFLang strategy. 

Option 1 -  Regional Site set for Single Market


Eliminates the potential of duplicate content


Search engines will assign this site to the single local market and you may not get exposure in other countries in the region.

With this option, you would just make the regional site equal to a country in the region and add it to the rest of the local market tags or HREFLang Site Map. 

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

Option 2 - Regional Site Set For Multiple Local Markets 


Eliminates the potential of duplicate content & does not isolate the regional site to a single market


Additional effort to maintain

Increased text in HTML page unless you manage with XML site map

A great example of this implementation is Outbrain.  They have a single site for Latin America and the Caribbean region.  They also have a /es Spanish langauge site that they are reserving for Spain.  They have mapped each of the countries they want to target in the area to the regional page.  

    <link rel="alternate" hreflang="es-AR" href="">

    <link rel="alternate" hreflang="es-BO" href="">

    <link rel="alternate" hreflang="es-CL" href="">

    <link rel="alternate" hreflang="es-CO" href="">

    <link rel="alternate" hreflang="es-CR" href="">

    <link rel="alternate" hreflang="es-CU" href="">

    <link rel="alternate" hreflang="es-DO" href="">

    <link rel="alternate" hreflang="es-EC" href="">

    <link rel="alternate" hreflang="es-GT" href="">

    <link rel="alternate" hreflang="es-HN" href="">

    <link rel="alternate" hreflang="es-HT" href="">

    <link rel="alternate" hreflang="es-MX" href="">

    <link rel="alternate" hreflang="es-NI" href="">

    <link rel="alternate" hreflang="es-PA" href="">

    <link rel="alternate" hreflang="es-PE" href="">

    <link rel="alternate" hreflang="es-PR" href="">

    <link rel="alternate" hreflang="es-PY" href="">

    <link rel="alternate" hreflang="es-SV" href="">

    <link rel="alternate" hreflang="es-US" href="">

    <link rel="alternate" hreflang="es-UY" href="">

    <link rel="alternate" hreflang="es-VE" href="">


<link rel="alternate" hreflang="es-LA" href="">


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.  


Are HREFLang XML Site Maps Effective?

Over the past few days on Twitter there have been some comments on the lack of effectivness of HREFLanguage XML site maps.  In my experience, having used them on over 500 different projects, they are extreamly effective when they are used correctly.  

I have written previously on some of our success stories including a client that generated $8 million in incremental revenue and another receiving a 58% increase in local market traffic or this newest case where the average traffic to South American Sites increased over 200% after fixing and implementing HREFLanguage XML site maps. 

We have already noted that the #1 reason they fail and create No Return Tag Errors is that the XML files are not fully indexed due to errors.  I mentioned on Twitter that the majority of the sites I have worked on all had significant errors in their XML files and people could not believe that International SEO agencies could or would make such a simple mistake.  

The following are some actual projects where we imported final and live HREFLanguage XML site maps that were full of URL's that did not produce 200 status codes when requested.  Note, all of these projects were/are previously managed by some of the top global agenices in the world. 

This first example, is one of the most recent and they came to us last month and asked me if I could take a look since their agency could not find the reason they had nearly 100k No Return errors.  We imported all of the current HREFLanguage XML site maps into HREF Builder and immediatly started to see problems.  These problems were also validated once we were given access to Google Search Console. 

The red numbers indicate the number of pages in the current XML site maps that did not generate a 200 header status and/or had a redirect or a robots exclusion. 

Nearly every country has multiple errors with most clearly more than the 1% search engines has said was an acceptable error rate.  Clicking into their global site we can see how the 1,018 errors were distributed across the various types of problems. 

They had nearly every type of header error you can imagine with the majority being 301 redirects.  The agency told us that Google would follow the redirects so no need to remove them - WRONG.  In another language, we had a case where 214 pages had a 301 redirect to pages that had a canonical tag back to the original page that redirected sending search engines into a loop.  

Google clearly showed these as a problem in Search Console flagging each XML site map with hundreds of errors.   Once these were removed from the XML site maps, Google quickly reindexed the pages and nearly all of the HREFLanguage errors went away.  

Another example is from a Fortune 100 company that used an agency that told them they spent over 60 hours developing the HREFLang XML files manually in Excel.  They have a site targeting over 100 counties but we only showed a sampling of the problems.  Out of 2 million pages nearly 300k had errors.  

Imaging the waste of effort to the search engines, hitting nearly 300,000 pages that did not give them a positive result.  This is why when we checked the server logs a number of these XML site maps had not been requested in a few months. 

Here is another case for a midsized global site where the agency that used one of the free "upload your CSV tools" to build a HREFLang XML site map.   They did not check the pages to make sure they load, did not redirect or have a canonical to another language site or any quality for that matter.   Same process, we imported them into HREF Builder which checked each page and generated this report. 

Every country XML had more than the 1% that Search Engines have told us is acceptable.

This should be unacceptable to the site owners to have this level of junk submitted to the search engines wasting requests on pages that are broken or redirect.   There are some consultants that are advocating the use of in page HREF Langage Tags.  This is a great option for sites that only have a few country versions and can implement the code to do it.   Unfortunatly, for many companies with a large global footprint in page is not practical.    The main reason to use XML site maps vs. in page coding is the amount of code added to each page.  In all of these cases it would be from 50 to 100 extra lines of code to ever page.  I would also be a large development process to parse pages that did not exist in the local markets etc.

XML Site Map versions for HREFLanguage management is a very powerful tool but they must be managed effectively.  This is exactly why I created this tool and why a number of large companies are coming to use to have us managing this mission critical process for them. 


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.


Who Does/Should Own HREFLang Management?

For any multinational company, the HREFLang (HREFLang) element is an extremely powerful tool to ensure that the correct page is represented in the local market versions of search engines.  While we have demonstrated the immense value of the HREFLang it is not really taken seriously nor given the attention and respect that it deserves.  This is most obvious inthe high error rates and mistakes with impletation significantly higher than any other SEO element. 

For those unfamiliar with the HREFLang element, it is a method for you to tell search engines which specific regional language version of each localized page to present in a market.  For example, due the similarity in language, a UK page may appear in the search results in Australia.  If a user encounters the wrong country page they may not buy due to different currency, tax or shipping cost.    

Given that HREFLang implementation touches many stakeholder responsibilities, who should own and maintain the HREFLang element?

SEO Team & Digital Agency

This is the typical owner as it is primarily related to performance in Search Engines and they are the direct beneficiaries in terms of the correct page ranking in a local market.   Many internal teams have a decentralized role with each market handled independently or by different agencies.   If there is a global SEO Manager they are often the driver of HREFlang.  In some cases, markets that are negatively impacted by the wrong page ranking will start the process. 

Ecommerce Team

We have started to encounter a new player with a number of requests for assistance from the global or local eCommerce teams.  In the big picture, they care the most about sales and local market performance.  It is critical to them that the best page for a product show up in each market.  We have had the most contact from eCommerce mangers in Latin America trying to get their local market page to appear vs. Argentina or Spain.

We actually had one manager from Peru that wanted to find a way to implement that did not require assistance from the SEO or his Dev team since neither of them thought this was a problem.  In most cases another country page was the one ranking.  The SEO team showed him a rank report that showed they were ranking well for most of the products in Peru but would not generate one with the URL’s to show what was actually ranking.    These are interactions you would never believe if you had not seen them directly. 

Localization Team & Agency

The localization team would seem to be the next obvious candidate as they are responsible for the local language versions of the site.  Interestingly, we have had a few subscribers that have introduced the tool, for its Cross-Language Mapping Report to the SEO agency as they use HREFLang Builder to detect missing or non-localized versions of pages on the site.  

I have spoken to internal localization teams and a handful of agencies and many were not aware of the functionality and others indicated it was the responsibility of the SEO agency to develop them.  Lionbridge’s Global Technical SEO Brendan Walsh has been one of the main advocates for this audience for making the HREFLang element part of the localization process.

IT & Dev Ops Team

The Web or Dev Operations team is typically tasked the implementation of either the page-level code or loading the XML site maps.  They are also the people the SEO team goes to find out how many pages are in each localized version and to correct the errors identified during the process.

We could argue that IT is a strong candidate for ownership, as they manage the infrastructure it represents and where it is implemented.   Some of our HREFLang Management Service clients have found our error reporting to be a excellent addition to their own diagnostics.   As we are detecting redirects, broken URL’s or canonical problems during the import process this report gives them a market by market list of all the errors detected. 

It Takes a Village

Hopefully our arguments for assigning ownership to one of the stakeholders has helped identify the best candidate in your organization of this effective tool to the right owner but as you may have determined it does take a village to create and manage your HREFLang process effectively.   If you need help with developing a process and training your team let us know and we would be happy to work with you. 

To help us understand more broadly who manages the process and what challenges companies have we have created this HREFLang Management Survey.   We will post the details as we get reliable sample sizes.  Take a moment and provide your insights.