Cheap VPS & Xen Server

Residential Proxy Network - Hourly & Monthly Packages

Case study: JavaScript blocking Google’s view of hreflang

Case study: JavaScript blocking Google’s view of hreflang

The hreflang attribute has been an important part of the SEO toolkit for webmasters and digital marketers for a good many years.

In order for Google to best understand your multilingual or multinational website, it is integral that your hreflang implementation is correct and that Google fully understands it.

If you’re new to the hreflang attribute, then you may find the following resources useful:

  • Yoast’s hreflang ultimate guide
  • Sistrix’s hreflang Guide to International SEO

This case study looks specifically at an issue that some may have experienced before, or you may come across it in the future: Google not recognizing your hreflang markup and not reporting the true number of hreflang tags in Google Search Console (GSC).

As recently reported on SEO Roundtable, John Mueller said the following in a recent Google+ Hangout:

So it might just be that we don’t recognize the hreflang markup at all on those pages.

For example, what might happen is we can crawl and index those pages, but when we render those pages, something in the head section of the pages is added early on, and that kind of breaks everything within the head, which includes the hreflang markup.

So that might theoretically be happening. And if we can’t find the hreflang markup at all, we won’t flag it as an error, because we think there is nothing wrong with a page that doesn’t have hreflang.

So that might be something worth double checking. So what you can do there is open the page in a browser and use Inspect Element to see what the rendered view of the page actually looks like. And then double check to make sure that within the head section there is actually nothing like non-meta tag type that’s actually listed there.

Before Mueller’s recent comments were made, I was planning on testing this theory, as I believed I was seeing firsthand issues with Google failing to “see” my client’s hreflang markup.


To set the scene, my client, an online retailer, launched a new website 12 months ago, with multiple English language subdirectories targeting different countries. A review of the hreflang values and syntax appeared correct, but Google was not recognizing anywhere near the number of tags they should have been.

Separate Search Console profiles were set up under each country subdirectory so I could monitor each individually. By doing this, I could tell that this issue was not specific to one subdirectory but across all.

Out of potentially thousands of pages that included the hreflang tag, only a very low number were being reported in Google Search Console:


Early this year, the number of hreflang tags detected rose as high as 100, but this number was gradually fluctuating over time and would eventually reach zero again. This trend continued and never rose above 150 for the entire site, which was well below the total number of accessible pages.


As well as checking for any obvious signs of broken code within the <head> section, I used Google’s Fetch and Render tool within Search Console to double-check exactly what Google was seeing.

The source code view revealed that Google was grouping the Page Title, Meta Tags and hreflang as part of the inline JavaScript block (notice, below, how Google groups these using the same color). It also indicated that Google was treating the closing tag of the third inline block as the closing tag for the entire block (lines 26–49).


In theory, this could be caused by a missing closing </script> tag, from the JavaScript that sits just above, but you’ll notice that it’s not the case in this instance:


I decided to check some historic Fetch and Render pages within Search Console for comparison purposes. I managed to find one from 10 months earlier, so I compared old versus new.

My main observation was that the inline JavaScript, which I believed was affecting the hreflang tags, had significantly increased in size when compared to the old version. The old snapshot of the page showed 25 lines of JavaScript, and the new one showed over 100 lines.

Not only that, but Google was displaying the source code differently in the older version, without the grouping of the JavaScript and HTML tags underneath:


Notice how, in this old Fetch and Render page, Google is paying attention to the closing <script> tag at the end of line 25. This meant that Google was viewing the HTML (including hreflang) underneath the inline JavaScript properly before this code was expanded.


Based on what I’d seen, I was confident that the second JavaScript block was causing the main issue, so much so that Google was ignoring the closing </script> tag — and this, in turn, was making the hreflang markup invisible to them.

The test

Knowing I had little or no influence over the inline JavaScript (It is third party-provided), I decided to come up with a solution to ensure that Google would read hreflang first and would not be affected by JavaScript.

The test was simple: Move the hreflang markup to the very top of the <head> section.

If the JavaScript was the cause of the issue, then I would expect to see a big increase in the number of reported tags.

The results

Once the site was updated, I used Fetch and Render to submit each country-specific subdirectory to Google’s index. Within a couple of days, Search Console reported the following:


The results were immediate! Once Google started to re-crawl the website, they detected the hreflang tags. The number reported in the Search Console increased from approximately 120 to over 1,200 — and now it’s reporting over 7,000.

It’s early days, but I expect this number to rise further as the entire site is crawled and Google starts to update its index.

You are probably wondering what impact this has had on the performance of the website internationally. Although there hasn’t been any overall traffic increase as of yet, Google is clearly starting to serve users the most relevant URL based on their location.

Using Google Analytics to look at Organic Landing Page Traffic and segmenting by user location shows hreflang at work.

Organic landing page traffic — UK subdirectory URL


Google has stopped serving the UK site to the majority of users in the United States, and this has resulted in a big drop in traffic for this part of the website. Given a little more time, I expect Google to be sending little or no traffic from the US to the UK subdirectory.

The good news is the loss in traffic to the UK site has been made up by the increase in traffic to the more relevant US site.

Organic landing page traffic — US subdirectory URL


The US subdirectory is gaining much more exposure in the US because Google now understands that this site is the most relevant to the user; Google has greatly reduced the number of UK URLs appearing in US search results.

A similar trend can be found across other English-language versions of the website. Where the UK used to show, the relevant Language/Country subdirectory or subfolder is showing in its place.

It’s still in the very early stages, but I hope the fact that Google is serving a more relevant website to the user will help increase the CTR from search results — and that this, in turn, will have a positive impact on the website’s conversion rate.

Other issues with implementation

Referencing hreflang within the <head> section of each page is only one of the ways you can implement this on your website. You can also use XML sitemaps to specify your Country/Language URLs, or return hreflang values within your HTTP header response.

Whichever way you choose to implement your hreflang preferences, there are some issues and mistakes that are commonly made. To gain more insight on these, I recommend reading “Auditing Hreflang Annotations: The Most Common Issues & How To Avoid Them,” published last year by Aleyda Solis on Search Engine Land.


In summary, I was able to prove John Mueller’s recent statement to be true: that if your header section is broken, it could “theoretically” affect Google’s ability to see your hreflang code.

In my client’s case, some inline JavaScript was causing Google issues and prevented them from detecting the hreflang referenced in the <head> section.

I found the Fetch and Render tool within Google Search Console extremely valuable to help troubleshoot the issue I was experiencing.

Moving the hreflang markup to the very top of the <head> section resolved the issue and was enough for Google to detect sitewide hreflang tags.

The results from Google detecting the hreflang tags have been very positive. Google quickly understood the correct Country/Language subdirectory to serve to UK and International users, creating a better user experience.

Good luck with troubleshooting any similar hreflang issues that you may be experiencing!