Why your Custom HREFLang Implementation Does not Work

I get a lot of emails and tweets from site owners that have implemented HREFLang on their site only to not have it work.  Most of them are the contributing factors match those found by SEMRush in their 13 Most Common HREFLang Mistakes research report.   Working through some of the problems I have found these break down into these categories:

Reason – Incorrect/Incomplete Specification

This is the catch all category for most of the reasons that follow – no prior planning.  In most cases a ticket is put into the system to “Implement HREFLang” and the developers are left to fend for themselves.    

Reason – Free Scripts and Code from the Interwebs

A few developers told me that they got the code from a repository or downloaded it from a blogger that is an authority on HREFLang so it must be correct.   One one cases the code was 100% correct but the source was incorrect.  It was using the country language tag on the page and that was not converting it to the correct ISO codes.  This is common with many sites that use UK for their /uk site or JP for the language code for Japan.  

Reason –  Developers Blended Concepts 

Developers may assume the same code they use to add canonical tags will work and/or they read that HREFlang is like a canonical so they use the canonical tag in place of the self-referencing tag on the page.   In XML site maps we see them add in image and video information making the files far too large. They may use relative URL’s because it is allowed for canonical tags or other links.

Reason – No or Bad QA Testing

This follows the main reason – if you don’t have good specifications and acceptance testing then you run a high chance of getting something that does not work.  Since there is not solid QA testing or Acceptance testing your developers did not test it before they deployed it. We see this a lot with incorrect tags and partial implementations.

Reason – Partial Implementation

I see this one a lot with automated systems that add the tags to the pages and don’t include some countries or languages or just set it up for the home pages and/or category pages.  In some cases the sites are on different servers or have localized URL’s which is why they are not integrated. Our HREFLang Implementation research found that 14% of the most localized sites only had HREFLang implemented on the home page.

Following point 1 bad specifications, half the implementation requirements docs we have reviewed or the Jira ticket only said to ‘Implement HREFLang” and the requester was not explicit that it was set up for all pages.  It was only implemented on the home page.   The developers responded that in their research, they only saw examples of home pages so they only implemented it on the home pages.

Upon further challenge, they said adding to the home page would be enough for Google to understand the relationships and apply them to all pages.    This is why you need solid specifications that indicate it should be on all pages as well as testing to ensure it is not only on the pages but on them correctly. 

Reason – Developers assume Search Engines are forgiving or smarter than they are

For a long time WordPress sites were having a problem with HREFlang since the plugins were using the country/language codes from the HTML header.  In WordPress they were using underscores for these tags.  While browsers are more forgiving, the HREFLang standard expects the syntax to be a dash.   Since the plugin was taking the value as is and not converting it many of these were wrong.   Of course, rather than fix the root cause, WPML simply told users to add a workaround script to change them to lower case.    

We see this when the specifications clearly state to use a dash, developers, often those who are experts in multiple coding languages, insists that the underscore and dash do not matter.  In nearly all cases, we often find that it is actually ignored.  The specification from W3C is pretty clear why can’t we just follow it.   Another we get is with a lot of the Angular and node based scripts extraneous code to the element.  This can be written out so make sure that there is not any clutter in the tags.  

In the case able where it was only on the home page, further challenge of the developers they told me that they assumed adding to the home page would be enough for Google to understand the relationships and apply them to all pages.

Reason –  Developers Did not Validate Countries and Languages

 
This was one of the biggest problems found in the SEMRush HREFLang Error research.
We are seeing a lot of developers adopt the codes from their SAP or Microsoft builds that still use outdated language or country codes.   The most common of these are Indonesia and Israel.  While these work in closed applications they do not work for HREFLang and Google and Yandex will give errors.  You must use the ISO codes.  This is a critical step in the QA process that cannot be skipped and should be assigned to multiple people to get as many eyes on the problem as possible. 

Reason – You have a JavaScript Problem in the header 

This one has been around for a while and finally Google indicated that it is a problem especially if you are using a lot fo tag manager scripts that are loaded in the head.   Everyone wants their scripts to load first and as with many things the browsers are lenient to bad code but Google will skip over these problems.   If you have a lot of scripts in the <head> and the developers won’t put HREFLang tags first, we suggest you review one of the other options for implementing to ensure that you don’t run into problems.

If it has been a while since you checked your implementation go back and look at it and make sure all the key elements are working correctly. We have seen some custom implementations rolled back effectively eliminating their HREFLang deployment completely without the SEO team even being aware of the change.