Hreflang errors rarely look like errors. The tags validate, the crawler is happy, and Google quietly ignores the whole set and folds your country versions into one. The symptom shows up in Search Console as “not indexed” against the UK, Australian or Canadian storefront, and the report that used to explain it, International Targeting, was removed in 2022. This note is about where the errors are reported now, which mistakes cause Google to drop the annotations, and how I check a multi-country store without a crawler.
Why are my hreflang tags not working even though they validate?
Because validation checks syntax, and Google’s rules are about relationships. The localized versions documentation lists the conditions, and each one is a way for a perfectly well-formed tag to be thrown away.
The first row is the one Google calls out by name. “If page X links to page Y, page Y must link back to page X. If this is not the case for all pages that use hreflang annotations, those annotations may be ignored or not interpreted correctly.” The reason is stated too: without the return requirement, anyone could claim your page as an alternate of theirs. So a one-directional tag is not half-credit. It is zero.
The second and third rows are the same mistake in two forms. The value is language first, region second, and the region must be an officially assigned ISO 3166-1 code. “You can’t specify the country code by itself”, and codes reserved for other uses, Google names EU, UN and UK specifically, have no effect. The United Kingdom is GB. A European Union storefront gets a plain language code, or nothing.
The fourth row is the quiet one. Hreflang and canonical are separate systems, and canonical is the stronger of the two. The canonicalization documentation puts it as an instruction: “If you’re using hreflang elements, make sure to specify a canonical page in the same language.” If a country page declares another country’s URL as its canonical, Google follows the canonical, indexes that one, and the hreflang set on the loser is never consulted. Every version in a set needs to be self-canonical.
Does hreflang fix duplicate content between country sites?
Only if the content is actually different. The documentation is precise: “Localized versions of a page are only considered duplicates if the main content of the page remains untranslated.” Read that from the other side. If your US, UK, Australian and Canadian stores carry the same English product copy with a different currency symbol, they are duplicates by Google’s definition, and hreflang does not change that. Google may still show the right storefront to the right searcher, but it will pick one URL to index and mark the rest as alternates.
That is the condition I meet most, and it is the condition on the account I have run longest. A skincare brand I have worked with since 2024 sells through seven Shopify storefronts, on a .com, .co.uk, .com.au, .ca, .co.nz, a Singapore domain and a .eu, with more than 330 URLs under tracking and roughly 88 per cent of them indexed. The copy is English on six of them. Hreflang on that account is correct, and it still cannot make Google index seven copies of one product page as seven separate pages, because the documentation says it will not. What it can do is make sure the version that does rank in Australia is the .com.au one. The skincare brand case study has the rollout detail.
Where do I check hreflang errors in Search Console now?
Nowhere by that name. The International Targeting report, which used to list return-tag errors per URL, was retired after 22 September 2022. Google’s notice says the country-targeting half “was determined to have little value for the ecosystem”, and adds that “Google will continue to support and use hreflang tags on your pages”. The tags still work. The report about them is gone.
The Page indexing report is the hreflang error report now, and it takes some reading. Three statuses carry the signal:
- Alternate page with proper canonical tag is the healthy state for a country variant Google has consolidated. The page is known, it points at a canonical, Google agrees, and the storefront is served to its country from the canonical’s indexing. I explained the status on its own in alternate page with proper canonical tag.
- Duplicate, Google chose different canonical than user on a country URL means the set was overridden. You declared the country page self-canonical, Google consolidated it anyway. On near-identical content this is expected, and the Google chose different canonical note covers when to act.
- Duplicate without user-selected canonical on a country URL means the variant has no canonical at all, which on most platforms means a template bug.
None of those tells you which of the five mistakes above you made. For that you need the inspection.
Why are my alternate URLs showing as not indexed?
Because, in the ordinary sense, they are not. An alternate that has been consolidated is not a separately indexed page. Search Console reports it under one of the statuses above, the URL is not on Google verdict is technically true, and the storefront can still rank in its own country. Whether that is a problem depends on which URL Google chose, and the only first-party way to see that is the URL Inspection tool.
This is the check I run on every multi-country account, and it is the part no validator does. Take one product. Inspect its URL in each storefront’s Search Console property, and read the Google-selected canonical field on each. If the .co.uk product reports the .com URL as its selected canonical, Google is treating the UK page as a copy of the US page, and no amount of hreflang tidying will change that until the content differs. If each storefront reports itself, the set is being honoured. Because most multi-country stores are set up as one Search Console property per domain, this collapse is invisible from inside any single property. You have to inspect across all of them and line the answers up.
Doing that for one product by hand is seven inspections. Doing it for a catalogue is the reason I built the bulk URL inspection tool: the same product URL set through each property, with the selected canonical in one column, shows the consolidation pattern in a single sheet.
Should hreflang go in the HTML or the sitemap?
Google says the three methods, HTML link elements, HTTP headers and sitemap entries, “are equivalent from Google’s perspective”. The choice is about maintenance. Sitemap hreflang needs one <url> block per version, each listing every version including itself under the xhtml namespace, and on a platform that regenerates the sitemap it is the easiest to keep complete. HTML tags live in the theme, and on hosted platforms the theme is where a stale template quietly drops a storefront from the set. Whichever you use, use one. Two methods that disagree are a return-link error in disguise.
Do I need x-default?
You do not need it, and it is worth having when there is a language selector or an auto-redirecting home page. The documentation recommends it as “the fallback page for users whose language settings don’t match any of your site’s localized versions”, and says it works best on selector pages. One more line in the set, and it stops Google guessing where an unmatched visitor lands.
Fixing it, in order
- Pick one page and inspect it in every storefront’s property. Read the Google-selected canonical on each. That tells you whether the set is honoured or collapsed before you touch a tag.
- If it is collapsed on identical content, stop. The fix is content, not markup, and the collapse may be the right outcome for a store that only needs one version ranking per country.
- If the content differs and the set is still collapsed, check the five rows above in order: return links, language-first codes, assigned region codes, self-referencing canonicals, then whether the set is declared in one place or two.
- Fix in the template or the sitemap generator, not per page, or the mistake comes back with the next product.
- Re-inspect the same page across the properties a few weeks later. The canonical choice is the result you are waiting for, not a validator’s green tick.
Sources
- Google Search Central, tell Google about localized versions of your page, for the return-link rule, language and region code rules, the untranslated-content duplicate condition, the three equivalent methods, sitemap rules and x-default, checked 3 September 2026
- Google Search Console Help, International Targeting report deprecation notice, for the removal of the report and the statement that hreflang continues to be supported, checked 3 September 2026
- Google Search Central, consolidate duplicate URLs, for the instruction to specify a canonical page in the same language when using hreflang, checked 3 September 2026
- First-hand: seven-storefront Shopify skincare client, per-URL tracking since 2024, described in the skincare brand case study