In one paragraph
An invalid hreflang value can make a language or regional annotation unusable for its intended search-engine targeting. Correct the code and verify the alternate URL actually represents the corresponding content. This check validates a limited text pattern, not the whole multilingual relationship, so both its warnings and its passes need interpretation against Google's supported codes and reciprocal-link requirements.
Why it matters
Hreflang associates corresponding language or regional versions so search engines can better choose an appropriate URL. It does not translate content, force a particular ranking, or replace Google's language understanding. Different language versions are not automatically duplicates when the main content is translated.
For Google, use supported ISO language codes and optional region codes, with documented support for script variants. Examples include en, en-GB, cs-CZ, and zh-Hant. A syntactically possible general language tag is not automatically supported for Google hreflang: es-419, for example, is not a supported regional value under its documented rules.
The special x-default value identifies an unmatched-language fallback, often a useful selector destination. It is not a language code to combine with a country suffix. The page-level relationship and destination matter as much as the value itself.
How WebAuditOS evaluates this finding
The supplied rule reads served-HTML alternate links with hreflang and href on eligible HTML responses. It accepts two or three letters, optionally followed by a hyphen and two letters, or x-default, case-insensitively. Any other shape fails at low severity; no annotations are not graded.
This can accept nonexistent or unsuitable codes, including en-UK or an arbitrary two-letter string. It can reject supported script annotations such as zh-Hant because they exceed its narrow pattern. It does not validate return links, self-inclusion, target responses, or annotations delivered through HTTP headers or sitemaps.
How to fix it
- Identify each reported value and the system producing it. Internal locale identifiers such as en_GB need conversion for output; a database locale is not necessarily ready-made hreflang.
- Use a supported language and, only where needed, region. Use a hyphen rather than an underscore. For UK English, use en-GB rather than en-UK. A region alone does not specify the page's language.
- Keep legitimate script distinctions where needed. Google's documented zh-Hant and zh-Hans forms should not be replaced with less accurate content descriptions solely because this scanner's regex rejects them.
- Generate page-specific alternates, for example:
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/pricing">
<link rel="alternate" hreflang="en-US" href="https://example.com/us/pricing">
<link rel="alternate" hreflang="x-default" href="https://example.com/choose-region">Use actual equivalent destinations. A pricing page should not automatically identify every locale's homepage as its translation.
- Include each version itself and the intended other versions, with reciprocal links. Where a complete cluster cannot be maintained, review Google's guidance rather than assuming one-way declarations will work.
- Keep canonical signals coherent with the intended language pages and verify destinations are accessible and appropriate. Do not point all translated pages' canonicals to one language simply because content topics match.
- Choose a maintainable delivery method: HTML, HTTP headers, or sitemap annotations are supported by Google. Maintaining multiple methods without benefit can introduce contradictions. The scanner's HTML-only coverage is not a reason to abandon a sound sitemap implementation.
- Fetch and validate the actual alternate set, then rescan. Review known checker limitations separately and monitor international search traffic without interpreting intended redistribution between locale URLs as automatic traffic loss.
What the fix can break
Correcting a code makes a previously ignored annotation actionable. If its target is the wrong language or a redirect to an unrelated page, the now-readable declaration can still mislead search systems.
Global locale mappings can affect thousands of pages. Test content equivalence, not just homepage annotations, before deploying a shared configuration change.
Do not rename URLs or remove valid script codes just to satisfy a narrow pattern. Preserve accurate targeting and document the checker limitation where the search-engine-supported implementation is correct.
Questions
Is hreflang case-sensitive for Google?
No. Conventional casing such as en-GB improves readability, but Google accepts lowercase and uppercase codes.
Does en-UK work like en-GB?
Use en-GB. Google's supported region-code guidance does not treat the reserved UK value as the intended regional targeting signal.
Why did zh-Hant fail the scanner?
It falls outside the documented regex despite being explicitly supported by Google. Treat that as a checker limitation, not a reason to mislabel the content.
Which related checks help?
Review canonicals, cross-host canonicals, and sitemaps.