The fix, in one snippet
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/">
<link rel="alternate" hreflang="x-default" href="https://example.com/">Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
We collect every <link rel="alternate" hreflang="..."> annotation and validate the code against the expected shape: a two-letter ISO 639-1 language, optionally followed by a two-letter ISO 3166-1 region, or the literal x-default. Values that do not match are reported.
Sites with no hreflang at all are skipped rather than failed, since the annotation only applies to multilingual or multi-regional sites.
Why it matters
The commonest mistakes are invalid by specification and therefore discarded without warning. hreflang="uk" means Ukrainian, not the United Kingdom, which is en-GB. hreflang="en-UK" is not a valid region code at all. hreflang="es-mx" is fine; hreflang="spanish" is not.
When the annotation is dropped, the consequence is that the wrong regional version is shown: a British visitor sent to a US store with the wrong currency, or a Spanish reader sent to the Mexican page. The pages still rank; they rank in the wrong market.
Language first, region second, and region alone is never valid. The region is optional; the language never is.
Note that the codes are case-insensitive by specification, so en-GB and en-gb are equivalent, and neither is the cause of a problem. What matters is that both halves exist in their respective standards.
How to fix it
Use valid codes, and include a self-referential annotation on every page in the set:
<link rel="alternate" hreflang="en" href="https://example.com/">
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/">
<link rel="alternate" hreflang="es-mx" href="https://example.com/mx/">
<link rel="alternate" hreflang="x-default" href="https://example.com/">Use absolute URLs, point at the canonical version of each page, and add x-default for the fallback shown to everyone else. For large sites the same annotations can go in the XML sitemap instead, which is easier to keep consistent than per-page markup.
Where this fits
hreflang annotations invalid is check 2 of 3 that the seo & site health audit runs under international targeting, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Language declarations disagree (medium), where pages declaring different languages with nothing connecting them leaves search engines guessing which version belongs to whom. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
hreflang annotations invalid closes one route in. The next one down is hreflang return links missing, where hreflang must be reciprocated.
Found in the same scan
The seo & site health audit reports this alongside checks from other categories that are at least as serious, including Broken internal links, where an internal link that returns an error is a dead end for the reader and a wasted request for the crawler, and Crawl errors (4xx / 5xx), where uRLs reached during the crawl that returned a client or server error. A single run of seo & site health audit answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: hreflang annotations invalid (medium severity)
Scanner check id: seo-hreflangThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.