MAY 20, 2016 BY BILL HUNT
HREFLang No Return tags errors are the most common errors given by Google for HREFLang. A no return tag error simply means that one or more of your pages does nothave a recprical link back. These errors are primarily caused by old or incomplete hreflang tags and outdated hreflang XML site maps. We will review the steps to identify the cause of the errors and ways to fix them and most importantly, how to prevent them in the future.
If you received this error in your International language report in Google Search Console (GSC) it means that Google found an HREFLang entry in either hreflang tags on the page or in the XML site map that referenced an alternate language version but when it went to that alternate (site map or page) that alternate version did not reciprocate and reference the original page as an alternate.
For HREFLang to work you need a page and designate all of the other language versions of that page as alternates. Then each of those alternates needs an entry for itself and all of the alternates. Let’s look at this example below:
You can check this quickly. Go to the alternate page or country HREFXML Site Map or page and look in the <head> 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 should have an entry like this on BOTH sites.
If on your Spanish site you only have the single entry for itself and not the reference to the English site it is incorrect
If the flagged URL’s are both referenced the next step is to start working through the following reasons to identify the problem.
Step 1 – Based on the error notice above, our “Originating URL” was found in the de-ch HREFLang XML site map we found an entry that told us the de-CH/drinks/jameson-whiskey-sour page has an alternate page in Bulgarian at de-CH/drinks/jameson-whiskey-sour as shown by the screen capture below. If we open the de-ch site map we can clearly see the <loc> file for the de-ch URL and directly below it there is the reference to the same URL on bg-bg.
Step 2 – Next we need to look for the Alternate URL listing. This error indicates that in the bg-bg file Google could not find a link back to the de-ch file as an alternate. Looking at the red box we do not see the de-ch entry. The de-ch URL is clearly not listed as an alternate to the bg-bg which breaks the reciprocation of the hreflang and effectively renders it useless.
You can work through some of the reasons below to try to understand why the CMS may not have added this URL to the HREFLang XML site map. Shameless Plug: With HREFLang Builder this type of problem cannot happen. The URL Mapping process matches all variations if the URLs are in the database and 200 indexable. If there is not a valid match the cross-mapping is not done in any file ensuring you would never have this problem.
Check to see if the return page is pointing to a correct AND non-blocked valid URL. If the page looks correct check the following scenarios that create different pages:
Based on our process above, we should look at both sites and confirm that they both have bi-directional HREF elements. But do they really? The screen capture below is an export of a client’s report with the URL changed to prevent embarrassment. You will notice that the URI for the Alternate URLs doesn’t match the Originating. In the HREFLang XML the Originating and Alternate URLs are exactly the same except for the country folder.
Why is Google showing different URL for these pages? In every case the matched alternate in the XML had a 301 redirect to the new URL.
The product team has changed product SKU’s which meant the URL had changed and they did a 301. As Google followed the 301 it found the exact same page as the original but a different product ID. These ultimately needed to be mapped and we did it using an upload of SKU’s for different markets.
We are seeing people mixing the canonical and the HREFLang elements which is INCORRECT for example this site got the following error.
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?
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. .
I have seen cases where the site is referencing 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.
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 an error.
Based on the troubleshooting process above, we should look at both sites and confirm that they both have bi-directional HREF elements. A quick look may seem like they are correct but are they really?
In the example below, we see on the Argentina site they are referencing the Ireland site with an _ and not a – which is a syntax error rendering the hreflang invalid and essentially ignored.
One of the first features we built into HREFLang Builder was 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
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 arobots blocked URL. If you have them in pages you can use a great HREF Testing tool from the guys at Merkel. The other option is to go over and set up an account with our HREF Builder and we can import the files and find the missing pages.