Earlier this week, Google announced on Twitter they were finally sunsetting their International Targeting tool and hreflang reports.
If you go to the Legacy Tools & Reports and click on International Targeting, you will see the headline noting depreciation on September 22, 2022. There is a link to a similar statement as the tweet. There are two parts to this depreciation
Google has confirmed that they are NOT eliminating hreflang elements. They will continue to process hreflang as normal.
This feature allowed those using global top-level domains (gTLD) like www.mysite.com to designate a section of the site, typically a folder /de, to create a separate account in GSC and then designate just that folder to a country. For example, users create an account for www.mysite.com/de, then use Country Targeting to set it to Germany. Note if you use a country-specific domain (ccTLD) like www.mysite.de you could not use this report since the ccTLD implied market targeting.
In my opinion, this was a “feel good” feature for large multinationals using gTLDs and folders for their market sites, as I never saw any changes once it was set. Of course, I would set it just in case. My challenge has been thinking of this application as a programmer; if I set up a market account in GSC and then set it to “Target Users in Germany,” was Google applying that setting to all pages with a /de folder? Would/could they appear in other markets?
I had tested turning this on for clients that were not using it and saw no decline in cannibalization and/or pages for that market having any improvement in ranking or pages getting indexed or not being identified as canonical variations. In my opinion, if it was truly working, the feature depreciated further in value once Hreflang elements were introduced, as they provide a specific designation of the language and region for a site.
The main alternative to the International Targeting feature is to use hreflang elements on your site. Hreflang is a bit more flexible as it allows you to set either a language or language and region. For those that only had a German language site but wanted to target other German language, markets would often not set this as it sounded too explicit to Germany.
Some of the tweets related to this change seem to indicate, this could be disastrous for some sites. But, as s already stated, I disagree that it will not be catastrophic. Still, If you saw improvements from using it, that just confirmed that Google struggled with identifying that folder as being targeted to a market, meaning you need to use another method to ensure Google knows that it is, in fact, content for a specific market. You can do this with hreflang elements, better localization, or even a ccTLD.
This report serves two key purposes
This report confirmed that Google had found your hreflang tags or XML sitemaps and was processing them. It would show you how many total tags were found and if there were any errors. This is an important feature and report when you initially deploy hreflang. We have noticed that lately Google has not been showing confirmation of deployment for new implementations and we are using one or more of the workarounds below.
The second purpose of this report was to flag “no return errors” and list alternate pages that did not reciprocate to one or more markets. More simply stated – one version of your site listed a URL as an hreflang alternate, and the alternate page not did not contain a return link back, closing the circuit Google would show an error.
One of the most queried phrases related to hreflang was how to read the Hreflang Report, so we created a detailed explanation of the most common reason. If your hreflang tags or XML are implemented correctly, this report should show no errors as in the example below. This screen capture shows the results of implementing our Hreflang Builder service that enables automatic and frequent updates rather than manual quarterly updates.
This reports when the URL page/XML says there is an alternate in France, but the France page/XML does not have a reciprocating entry back to the US page.
Clicking into any specific market segments in the report will return a breakdown shown below. This lists the specific pages that are milling their return tag. For many sites, you can go to the alternate page or XML and add the return tag or submit the page or XML sitemap via GSC to get Google to review the tags. For some sites, the problem is bigger as noted below.
The good news is these errors don’t happen when you use our Hreflang Builder except in rare occasions when a source file is updated to remove the URL, and Google hasn’t reindexed all the alternates yet.
For this error, Google lumped it in with the same “no return tag” bucket. However, upon researching we find the URL alignment is present in both directions BUT the URL does not load due to a canonical or redirect to another page and the new page does not link back. I believe the increase in these error types is why they decided to depreciate this report.
We took over this project from an agency. When we imported the hreflang XML sitemaps into Hreflang Builder and ran our diagnostic routine on them, we identified the problem immediately. The agency team did a good job of mapping the URLs to the alternates (green cells), but many of the mapped URLs had problems and were not indexable. As we checked the above-flagged URLs as a “no return tag” error, they all had a defect. These defects ranged from canonical issues, redirects, or 404 status. There is no easy way for Google to flag these. Since the clients’ system of using Excel and v-lookup did not validate the URLs, they simply appended all market versions assuming they were valid URLs. With Hreflang Builder, we not only flag them in an error report but EXCLUDE them from being added as alternates. Since the XML is updated weekly, Google is always refreshing the mappings.
I had never seen anyone write about this specific nuance of the error until I did for our guide on how to read and fix no return tag errors. This is more typical with eCommerce sites dealing with frequent inventory and product changes.
Google has confirmed in this thread and in a few others that they are NOT eliminating hreflang elements. They will still process them as they have been. This means if you depended on the Hreflang Error report to monitor your hreflang you will need to use another solution to detect your return tag errors.
The obvious alternative is to use Hreflang Builder. Hreflang Builder, when used effectively, will only match URLs that meet your criteria AND are 200 indexable. Since it is dynamically updated, there is a smaller chance for errors and staleness.
The screen capture below shows one of the most common issues with the hreflang reporting in GSC. The yellow cells with the exclamation point represent URLs where Hreflang Builder identified an alternate for a market, but that alternate URL is NOT 200 indexable. Since the URL is not valid, Google would give an error in the hreflang report and typically note it in the main coverage report but without any reference to a hreflang impact.
We no longer offer public diagnostic tools. We did have testing tools for both tags and XML sitemaps, but many users also assumed that meant free consulting on fixing their errors and got quite vocal and in some cases threatening when they did not like the result and/or we would not spend hours helping them fix the problems.
Hreflang Builder will test your hreflang XML sitemap implementation, but it is an automated HREFLang sitemap builder that runs on a regular schedule and checks that there are no errors.
If you are just looking to test your hreflang implementation, there are dozens of hreflang checking tools listed in a Google search for them. Most of them are inadequate replacements for Google’s site-wide testing. The tools do a great job checking a single page but not the entire site. To check the entire site, you must use one of the larger SEO Diagnostic tools. These tools can do both alternate testing and the detection of non-indexable URLs. For checking hreflang deployed with HTML or HTTP headers, my personal favorite is Screaming Frog. You can follow their directions on Editing Hreflang with Screaming Frog
If you have XML sitemaps the only option to Hreflang Builder is to use Merkle’s Hreflang Testing Tool where you can add your hreflang XML sitemaps, and it will test them for alternates.
Another way to tell if you have a hreflang problem or pages are not correctly mapped is to look at the current cannibalization rates for specific keyword phrases. The team at Rank Ranger is the only solution I have that does a specific test for “brand family cannibalization”. Using this solution, you can test for cannibalization from your other market sites and identify specific pages.
The screen capture result from their article is very powerful, indicating that EasyJet has a massive cannibalization problem in the UK. For the set of keywords tested in the UK SERPS, 97.67% of the time, the EasyJet.com domain ranked over the UK ccTLD. Note: The ccTLD version of the site does not seem to be used but the report is still a valid representation of what hyper cannibalization looks like.
I believe on the 23rd of September; there will be some SEOs celebrating the sunset of this report since clients will not be able to see the level of errors that their outdated or poorly constructed hreflang projects created.
I also think that this will set hreflang deployment back a bit as I have already heard two agencies tell clients that Google depreciated hreflang so they did not have to worry about it. My hope is that pressure from multinationals and especially high ad spending eCommerce sites will push Google to integrate something into the coverage report similar to the canonical error reporting.
For now, companies will need to up their monitoring game and make sure that their systems for managing hreflang are working correctly. For those that don’t have the ability to monitor we would love to have you on board with Hreflang Builder.