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, https://www.examplesite.com/sg/  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. 

 

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. 

 

$8 Million in Revenue from Correct HREFLang Implementation

$8 Million in Revenue from Correct HREFLang Implementation

Large multinational tech company implements HREFLang XML Site maps in English markets and increased their lead volume by 843% and Search Influenced Revenue by $8 million in less than 60 days.

While working on a keyword data mining project for a large company we found a couple of localized problems with the lack of conversions in a few markets. During that project we were mapping the customer journey and developed a series of “waterfall conversion models.” When presented to the local markets a few said their lead conversion rates were not even close to the numbers we presented. Something was strange as they were getting anywhere from 5 to 40 percent of the organic search clicks so why were they not filling out lead forms?

Assuming it was a problem with the lead process we called the local toll free number, we completed the eCRM forms and they all worked and could not find what the problem was. While the forms worked, the leads were not showing in the Saleforce accounts in Australia.

While the demand generation team checked that side of things we made an interesting discovery. I just happened to notice in the rank report that the page ranking was the global English page and not the Australian page. We scanned the rest of the rank report and found that nearly 90% of the URL’s ranking were from the US or UK and not Australia.

We took all the words from Google Search Console Search Analytics Report for Australia. We isolated a specific keyword phrases where they were ranking in the top 3 and had at least a 10% click rate. A number of the words, especially product and branded terms has click rates of over 40%. We ran a rank report and all the pages that had high click rates had US or UK pages ranking.

These ranking landing pages had US and UK phone numbers, the lead forms worked but we asked these teams and yes the leads came in but since they were from Australia they viewed them as junk and just moved them into the junk bin. We found the problem – the wrong page was ranking. Note, had they been using a PLP monitoring process they would have seen this but their agency just reported on the number of words ranking for each country at different levels.

They immediately updated Google Search Console and set the geographical targeting but that did not change anything. I also developed an HREFLang XML site map for all the English markets but we needed to wait until the next site update to load it.

Once the files were loaded we started noticing changes in URL's switching over as soon as 48 hours after posting the XML files. No rank changed just the pages were switched from US/UK to Australia. Within two weeks nearly all the pages switched over and the demand generation team in Australia and Singapore had their best lead generation month ever. In total, leads increased by 843% with a total search influenced revenue attribution of over $8 million dollars.

How much money is incorrect country pages costing you? If you have HREFLang Elements in place test them using our new HREFLang Testing Tool or get started with your own HREFLang XML today.

 

HREFlang No Return Tags Errors

These are one of the most common errors given by Google for HREFLang.

What does this error mean?

It means simply your pages are not cross-referencing each other.

If you received this Error it means that Google found a HREFLang Entry on one page referencing it as an alternate to another page. But when it went to that page it did not find When it looked at the page referencesdi it did

In order for the HREFLang to work you need to link page A to all the alternates and then all of the alternates back to A. We see this is the number 1 error that people make especially with home grown or some of the free mapping tools. (if page A links with hreflang to page B, there must be a link back from B to A as well).

Reason #1 - You DO NOT Have Bi-Directional Linking

You can check this quickly. Go to the alternate page or country HREFXML Site Map and make sure you actually have the reference to the other site

For example, if you have a Spanish and English Site. View the source of both pages and you shold have an entry like this on BOTH sites.

<link rel="alternate" hreflang="en" href="https://www.mysite.com/en/"/>
<link rel="alternate" hreflang="es" href="https://www.mysite.com/es/"/>

If on your Spanish site you only have the single entry for itself and not the reference to the English site it is incorrect

<link rel="alternate" hreflang="es" href="https://www.mysite.com/es/"/>

Reason #2 - Incorrect Syntax - using underscore and not dash

We are seeing site that are using the HREFLang element with an underscore and not a dash as the syntax requires.

ar_ie_syntax_incorrect

Based on our process above, we should look at both sites and confirmed that they both have bi-directional HREF elements. But do they really?

Int eh example below we see on the Argentina site they are referencing the Ireland site with an _ and not a - which is a syntax error.

Ireland Site https://www.mysite.com/ie/
<link rel="alternate" hreflang="en-IE" href="https://www.mysite.com/ie/"/>
<link rel="alternate" hreflang="es-AR" href="https://www.mysite.com/ar/"/>

Argentina Site - https://www.mysite.com/ar/
<link rel="alternate" hreflang="en_IE" href="https://www.mysite.com/ie/"/>
<link rel="alternate" hreflang="es-AR" href="https://www.mysite.com/ar/"/>

Reason #3 - Incorrect Syntax - Combining HREFLang and Canonical

We are seeing people mixing the canonical and the HREFLang elements which is INCORRECT for example this site got the following error.

ar_ie_syntax_incorrect

Based on our process above, we should look at both sites and confirmed that they both have bi-directional HREF elements. But do they really?

Ireland Site https://www.mysite.com/ie/
<link rel="Canonical" hreflang="en-IE" href="https://www.mysite.com/ie/"/>
<link rel="alternate" hreflang="es-AR" href="http://www.mysite.com/ar/"/>

Argentina Site - https://www.mysite.com/ar/
<link rel="alternate" hreflang="en-IE" href="http://www.mysite.com/ie/"/>
<link rel="Canonical" hreflang="es-AR" href="https://www.mysite.com/ar/"/>

Reason #4 - One or More Sites Not Validated in Google Search Console

This is an interesting problem and we typically only see a site uses a HREFLang XML Site Map including multiple sites with different ccTLD's. Google does not give this as an error but when we have checked all the other possible problems we find this is the case when the site has a single XML file but not all of the local domain versions included and verified in Search Console. .

Reason #5 - HTTP and HTTPS References

I have seen cases where the site is selfreferenceing to itself with HTTPS but the element for the other sites are HTTP. This is incorrect as they are 2 different sites. This is a problem when the site has a canonical to the HTTPS as well as a 301 redirect.

Ireland Site https://www.mysite.com/ie/
<link rel="alternate" hreflang="en-IE" href="https://www.mysite.com/ie/"/>
<link rel="alternate" hreflang="es-ES" href="http://www.mysite.com/es/"/>

Spain Site - https://www.mysite.com/es/
<link rel="alternate" hreflang="en-IE" href="http://www.mysite.com/ie/"/>
<link rel="alternate" hreflang="es-ES" href="https://www.mysite.com/es/"/>

Reason #6 - XML Site Map Errors prevent Bi-Directional Linking

If you swear that you have all of your links set with A to B and B to A and you are using an HREFLang XML Site Map for each country then maybe Google cannot or will not update your XML files! I had a call this morning from a new customer that swore that they had them all mapped. We looked into their Webmaster tools account and there it We have seen this when people do not clean HREFLang XML Site Maps and load broken, redirected or URL's with canonical links to other pages. As in the example below, Google will slow or stop indexing XML Site Maps that have a lot of errors in them resulting in them not detecting the rel=alternate element and give and error.

not_index_site_maps

Shameless Plug - we build in error detection functionality into HREF Builder to catch the most common errors from redirects, 404 robots and canonical differences. The tool will not add any page with an error to the file ensuring you have 100% clean files. You can then export the list of errors and give them to the tech team to fix them.

Preventing Bi-Directional HREFLang Linking Errors

One of the first features we built into HREFLang Builder was the cross reference testing. This will detect all sorts of errors from redirects, 404 robots and canonical differences. The tool will not add any page with an error to the file ensuring you have 100% clean files. You can then export the list of errors and give them to the tech team to fix them.

Green - means that we found a match with that page between these countries

Red - means we did not find a match for that page between countries

missing_match_report

How to Fix Bidirectional Errors?

The Webmaster Console view for this error is fairly confusing but it will tell you which pages are missing the links or are missing a reference in XML Site Maps. If you have XML Site Maps then check for errors as I note above and make any fixes. Remove any that are redirects, 404 or robots blocked URL's. If you have them in pages you can use a great HREF Testing tool from the guys at Merkyl. The other option is go over and set up an account with our HREF Builder and we can import the files and find the missing pages.

 

Site with Most HREFLang Errors

Most global companies build their XML site maps dynamically from their various CMS systems. This results in the potential for numerous errors from broken pages, redirected pages and canonical pages being added to the files. In some cases, the local market versions are not even updated after the first build.
Search engines have told the SEO community their crawl rate can be significantly impacted if even 1% of the submitted pages in a site map have an error.
We have has many cases where a client has imported their XML site maps into HREFLang Builder only to find that many of these have huge numbers of errors. In one case, a Fortune 100 company learned nearly 40% of their site maps had errors. This report allowed them to identify 26 different problems and once resolved resulted in an index rate of nearly 98% increasing their traffic from organic search by 86% in the first 60 days.
Once the source files are imported, traditioanally from existing XML site maps, the user can see a difference in the URL counts as well as the number of errors. In the case below, we see Argentina has 1,814 URL's that had some sort of header, canonical or robots directive error.
import_errors
Upon seeing a report shown above, HREFLang Builder allows a user to drill down into a specific country and see the errors. In the example below, for Japan there were a number of pages that had 301 redirects as well as 404 errors. In this case they found that the XML site map and the pages were rendered without closing the folder. This resulted in every page to require a 301 redirect to add the "/" and then reload. By identifying this error, fixing the site and rebuilding the XML site map they increased the number of pages indexed as well as reduced server overhead.
xml_site_map_errors
HREFLang Builder added a testing routine into the application so not to add any pages with these errors to the XML site maps. We also identified each page that we found with an error to make it easy for the user to delete or share a list with IT to be fixed. Back Azimuth’s HREFLang Builder was designed to simply make large scale HREFLang Element implementation easier but adding into the SEO workflow has resulted in significant gains in error reduction, productivity as well as traffic and sales. Making it a must use tool for any global website.

 

New Feature – Redirect Checker

This tool functions as it sounds but far better than tools that check a single URL or even indicate a redirect during crawl. There are two key functional uses

Redirect Strategy Implementation Verification

I have been using this function for a number of years to demonstrate the 99% guarantee that developers will screw up redirects on a site refresh or migration. Most SEO's give the dev team an Excel file with the from URL, the redirect code, typically 301, and the destination URL. This is loaded into .htaccess or their redirect manager in the CDN. As noted I have only had 1 site get this 100% correct in over 20 years. The key is to catch the errors as soon as possible after launch to not loose the link equity.

The tool goes to each of the original URL’s and gets the header status. If the header status does not match what was provided a fail message is recorded. If the header is correct and it was set to 301 redirect we will capture the destination URL and confirm that it is the destination page. If not it will not a fail and if the actual destination is a redirect will follow until gets a termination status of 200, 400 or 500. The user can also check 410 “Gone” status.

redirect_strategy_report

Redirect Detection

The second function is a simple redirect checker. Many webmasters will get a report from Screaming Frog or DeepCrawl showing they have pages with redirects and the show the first destination. Many times working with large companies I have seen as many as 6 to 8 hops from years or moving content around. I needed a tool that would allow a large volume of URL's and check all hops until a failure header status or a 200.

To use this feature, the user loads a list of URLs or an XML site map and the header is checked for all. The tool records the header status, and the destination URL for each hop it encounters. If not it will not a fail and if the actual destination is a redirect will follow until gets a termination status of 200, 400 or 500.

master_redirect_checker

Once both of these are created, the user can rerun any of these reports to confirm that any errors were corrected without having to reload the original source.

 

New Feature – Google Index Checker

Today we launched a new beta version of our Google Index Checker is used to monitor the inclusion of the pages in Google. To identify missing pages, a user can reference an XML site map, paste in a list of URL’s or upload a Excel or CSV file from your desktop. We will soon make this available as part of a HREFLang tool subscription as well as a standalone subscription.

The application uses the info: syntax to check each URL on the list and see if it is indexed. If the page is indexed, if will capture the cache date so you know when the pages were indexed. The user can see both indexed and non indexed URL’s. Any URL that is not indexed they can use the Fetch as Googlebot to index it.

Determine Which Pages are Not Indexed

In the screen capture below we can see that most of the XML site maps have 549 pages. Many of the versions only have a few pages indexd. It is great that Google tells is that only x are indexed but we don't know which ones are not indexed.

site_map_inclusionNoIndex Report Results

In the case of Brazil, where only 42 of the URl's were indexed, we enter the URL for the Brazil XML site map and run the tool. It checks each URL and then develops the report which the user can review on the screen or export as Excel. They can see which page is not indexed as well as those that are and the cache date. no_index_report

Site Refresh Reindex Reporting

The original reason for this tool was to check sites that had been refreshed to ensure the new pages were indexed. Once you deploy the new site load the new XML site map or a crawl list and then monitor the inclusion and refresh rate. If you are interested in this tool please let us know.

 

Use HREFLang Builder to Detect Errors in XML Site Maps

Most global companies build their XML site maps dynamically from their various CMS systems. This results in the potential for numerous errors from broken pages, redirected pages and canonical pages being added to the files. In some cases, the local market versions are not even updated after the first build.
Search engines have told the SEO community their crawl rate can be significantly impacted if even 1% of the submitted pages in a site map have an error.
We have has many cases where a client has imported their XML site maps into HREFLang Builder only to find that many of these have huge numbers of errors. In one case, a Fortune 100 company learned nearly 40% of their site maps had errors. This report allowed them to identify 26 different problems and once resolved resulted in an index rate of nearly 98% increasing their traffic from organic search by 86% in the first 60 days.
Once the source files are imported, traditioanally from existing XML site maps, the user can see a difference in the URL counts as well as the number of errors. In the case below, we see Argentina has 1,814 URL's that had some sort of header, canonical or robots directive error.
import_errors
Upon seeing a report shown above, HREFLang Builder allows a user to drill down into a specific country and see the errors. In the example below, for Japan there were a number of pages that had 301 redirects as well as 404 errors. In this case they found that the XML site map and the pages were rendered without closing the folder. This resulted in every page to require a 301 redirect to add the "/" and then reload. By identifying this error, fixing the site and rebuilding the XML site map they increased the number of pages indexed as well as reduced server overhead.
xml_site_map_errors
HREFLang Builder added a testing routine into the application so not to add any pages with these errors to the XML site maps. We also identified each page that we found with an error to make it easy for the user to delete or share a list with IT to be fixed. Back Azimuth’s HREFLang Builder was designed to simply make large scale HREFLang Element implementation easier but adding into the SEO workflow has resulted in significant gains in error reduction, productivity as well as traffic and sales. Making it a must use tool for any global website.

 

Incorrect hreflang Implementation Error Notice

This past week Google has sent out a large number of notices for sites that have Incorrect HREFlang Implementations. The notice looks like this one below references two of the most common errors. Both of these errors are described below.

href_error_notices

Error 1 - Problem with incorrect language and region codes

About 1/3 of the errors I received calls and email about are related to incorrect country and language coded. I recently detailed a number of these common errors and how to fix them as well as preventing them in the article Preventing Unknown Language Code Errors which should cover most of your problems. This is a very common problem caused by people not paying attention to detail. In many cases the developer or SEO just mirrors the structure of the site using jp/jp or as nearly every site aligns to the UK as /uk and not GB it is not surprising that is one of the largest errors.

A quick search in NerdySearch for the incorrect country and language en-uk we find that there are nearly 8,000 sites including some very large sites that should know better. The correct code is actually en-GB. Japan is another common problem as are others that I will detail in some research I am doing on the prevalence of these incorrect codes.

incorrect_hreflang_uk

Shameless Plug - we have fixed settings so it is impossible to ever set the wrong country or language code in your XML developed with our HREFLang Tool.

How to Fix these errors?

If you log into Webmaster Console Google will tell you which ones are in error. If you are using the HREfLang Meta Element you will need to change the code you are using to generate them to set the correct country or language. Look at the language codes you are using and match them to the ISO Language Code list and do the same with your countries using the ISO Country/Regional Code List.

If you are using XML Site Maps that makes it easier to simply go in and do a Search and Replace and then upload the files. Once Uploaded go in and resubmit to the search engines for indexing. Make sure that you monitor the indexing.

Error 2 - Incorrect Bi-directional linking

In order for the HREFLang to work you need to link page A to all the alternates and then all of the alternates back to A. We see this is the number 1 error that people make especially with home grown or some of the free mapping tools. (if page A links with hreflang to page B, there must be a link back from B to A as well).

Correct Bi-Directional Linking

If you swear that you have all of your links set with A to B and B to A and you are using an HREFLang XML Site Map for each country then maybe Google cannot or will not update your XML files! I had a call this morning from a new customer that swore that they had them all mapped. We looked into their Webmaster tools account and there it We have seen this when people do not clean HREFLang XML Site Maps and load broken, redirected or URL's with canonical links to other pages. As in the example below, Google will slow or stop indexing XML Site Maps that have a lot of errors in them resulting in them not detecting the rel=alternate element and give and error.

not_index_site_maps

Shameless Plug - we build in error detection functionality into HREF Builder to catch the most common errors from redirects, 404 robots and canonical differences. The tool will not add any page with an error to the file ensuring you have 100% clean files. You can then export the list of errors and give them to the tech team to fix them.

Preventing Bi-Directional HREFLang Linking Errors

One of the first features we built into HREFLang Builder was the cross reference testing. This will detect all sorts of errors from redirects, 404 robots and canonical differences. The tool will not add any page with an error to the file ensuring you have 100% clean files. You can then export the list of errors and give them to the tech team to fix them.

Green - means that we found a match with that page between these countries

Red - means we did not find a match for that page between countries

missing_match_report

How to Fix Bidirectional Errors?

The Webmaster Console view for this error is fairly confusing but it will tell you which pages are missing the links or are missing a reference in XML Site Maps. If you have XML Site Maps then check for errors as I note above and make any fixes. Remove any that are redirects, 404 or robots blocked URL's. If you have them in pages you can use a great HREF Testing tool from the guys at Merkyl. The other option is go over and set up an account with our HREF Builder and we can import the files and find the missing pages.

 

 

 

Ensuring the Right Page is Ranking for the Right Country

I recently had an interesting project that helps illustrate the power of the HREFLang Element. A Fortune 50 company had significant traffic from organic search to English language markets Australia, India and UK as well as Spanish Markets of Colombia and Mexico. While traffic was high, conversions were not and most had 80 to 90 percent bounce rates. They hired a CRO expert that tuned the pages but still received few to no conversions.

I was already working with one of their business units and this came up in a global planning meeting. Upon hearing the symptoms I did a quick check in those markets with a couple of the products and immediately found the problem. In every case for the English countries, the global or US versions of pages were ranking and not the local market versions. In the Spanish Markets it was the pages from Argentina

Note: Why Argentina and not another Spanish country? In 99% of the cases where I have worked with this it is because Argentina is the first Spanish language site that is listed on the Country List of the site and the Site Map. Since it is the first, any often a duplicate of other Spanish Google gives it a dominate position.

When a user came into the page in Australia or UK all pricing, product availability and offers for the US or there were no offers as it was the global site. In addition, all the contact information was for the US. Not seeing the ability to buy in their currency or country they simply left the page.

Solution:

HREFLang Builder was used to develop HREF XML site maps for the countries. Within 10 days of the new HREFLang XML site maps submission the bounces rates were reduced, conversion rates increased and company enjoyed a 300% increase in sales to these pages.

Root Causes:

    1. Most of the link equity was to these other pages so Google felt they were more relevant
    2. The SEO agency simply checked ranks and not Preferred Landing Pages (PLP's). Had they had a process of checking to ensure the right page was ranking they would have tried to fix this long before.
    3. The CRO expert was focused only on making the landing pages better and being from the US and using IP detection most likely did not ever see the local pages.

The local markets did not even notice or necessarily care or they would have seen that it was not their page ranking.

Your Performance?

How are you performing in your key markets? Do you ahve a similar problem? If you do contact us to help you solve it.