HREFLang Builder Innovations

We recently HREFBuilder was Shortlisted or the US Search Awards and wanted to share some of the key innovations that helped us with the nomination:  

Innovation 1 – Mapping and Managing Large Scale Websites

For most websites using available scripts or WordPress plugins to add HREFLang tags to the page work just fine.  However, for larger sites and companies with many language versions, on-page tags add to much code and their complex URL structures often require significant logic for scripts and 100+ hours of coding to integrate.

Consulting with hundreds of global clients, Back Azimuth has identified, and developed logic to accommodate 600+ different pattern match variations of country language statements.   Our user interface allows self-help users to select from 280 of the most common variations during setup.  All other tools force you to use standard structures which do not exist in most enterprise companies, making these tools unusable.   

Innovation 2 – Ability to Match different language URL’s

A recent survey on HREFLang challenges indicated the #1 reason companies struggle with implementing HREFLang on their sites, requiring them to code it in-house and/or only submit top level categories, is due to the inability of commercial tools to map localized URL’s.   HREFLang Builder has developed multiple methods of matching different language URLs.   

  • Method 1 – Translated Directories/URL’s - the user selects one or multiple local directory names/URL’s and assigns them to a master classification.
  • Method 2 – SKU, Product Code, Parameter – Sites that use a unique product parameter in the URL representing a SKU or a category word can map variable across languages to all equivalent pages. 
  • Method 3 -  Local/Global ID Mapping – We upload a data table from client’s backend mapping using a global product ID and the local product IDs.  During page validation, we grab the ID token from the meta data and assign in the database.  The ID’s are mapped and parsed out into HREFLang alternate blocks in the XML site maps. This spans different URL structures and languages very efficiently.

Innovation 3 – Change Monitoring

The most recent innovation allows a user to upload a before and after rank report for each market and receive a “change report.”  By comparing the country and language code of the pages ranking before implementation and them after, the user can quickly see when and how many URL’s are swapped for the correct version.  This is not currently any other way other than a manual review to determine how many pages have converted and those that have not.

Innovation 4 – Ongoing Management

Other than incorrect language ID’s and missing alterative pages, the biggest mistake companies make is take a one and done approach to HREFLang.  The site is always changing pages for many reasons.  For many companies, the HREFLang XML is not current a week later.  We have added a number of options to keep them current.

Innovation 1 -  Period Cron Updates – the user can set the frequency of refresh and the source and we will rebuild the files dynamically at those intervals.  We can FTP to a server, email or save to Dropbox the files for security check and uploading by the client.  

Innovation 2 -  Change Monitoring – unfortunately XML site maps as a source is like whack a mole.  One week it is there and the next it is not as well as the number of URL’s included.  After each update, the HREFLang Builder emails an update with the before and after number of URL’s and errors for each market as well as any increase or decrease in markets.   


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.


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.


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. 


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.  


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 that a page is also in the 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="">


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. 


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 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 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.