Diagnosing hreflang errors
hreflang annotations tell search engines which language and regional URL to show to which users. They are easy to get subtly wrong: return tags that are not reciprocal, invalid language or region codes, hreflang pointing at non-canonical or redirecting URLs, or a missing self-reference. These errors cause search engines to ignore the cluster, so the wrong-language page can surface for users.
What hreflang does
hreflang annotations — placed in the HTML head, HTTP headers, or an XML sitemap — map a piece of content to its language and optional regional variants. Google uses them to choose which URL to surface for a given user's language and country. The codes follow ISO 639-1 for language and, optionally, ISO 3166-1 Alpha-2 for region (for example en, en-GB, es-MX), plus the special value x-default for an unmatched fallback.
They are a hint about equivalence between URLs, so they only work when every page in the set agrees with every other.
Common hreflang errors
The most frequent error is missing return links: if page A points to page B with hreflang, B must point back to A. Without reciprocal tags, Google ignores the annotation. Invalid codes are next — using a country code where a language is expected (such as 'uk' for the United Kingdom instead of 'en-GB'), or mistyped values.
Other common faults are hreflang URLs that redirect or are non-canonical, pages that omit a self-referencing hreflang, and mixing the signal with a canonical that points elsewhere. Each undermines the cluster.
- Non-reciprocal return tags between paired URLs
- Invalid language/region codes (e.g. 'uk' instead of 'en-GB')
- hreflang pointing at redirecting or non-canonical URLs
- Missing self-referencing hreflang on each page
- Conflicting canonical and hreflang signals
How to diagnose and fix
Start by confirming every URL in the set is canonical, returns 200, and is itself indexable. Then verify reciprocity: each language URL references all the others plus itself. Validate the codes against ISO 639-1 / 3166-1, and add x-default where you have a generic fallback.
Search Console reports hreflang issues such as 'no return tags', which is a fast way to find broken pairs. Fixing the markup and re-fetching lets crawlers pick up the corrected cluster.
How it appears in analytics and logs
Broken hreflang means search engines cannot trust your language/region mappings and may fall back to showing one URL to everyone, or the wrong locale to a user. It is an indexing-quality signal, not a hard error page, so it often goes unnoticed without an audit.
Diagnostic use case
Audit an hreflang cluster for reciprocal return tags, valid ISO codes, self-references, and canonical targets so search engines honour the language/region mappings.
What WebmasterID can help detect
WebmasterID records which localized URLs crawlers fetch, helping you confirm that the language/region pages in your hreflang cluster are actually being crawled and returning healthy 200s.
Common mistakes
- Pointing hreflang at a URL that 301-redirects instead of the final canonical.
- Forgetting the self-referencing hreflang on each page in the set.
- Using a region code in the language position (e.g. 'uk' rather than 'en-GB').
- Setting a canonical that contradicts the hreflang cluster.
Privacy and accuracy notes
hreflang auditing uses page markup and the URLs crawlers fetch, not visitor data. WebmasterID records crawler page fetches without attaching them to any person.
Frequently asked questions
- Do hreflang tags need to be reciprocal?
- Yes. If page A declares an hreflang link to page B, page B must declare a matching link back to A. Without reciprocal return tags, search engines ignore the annotation.
Related pages
- Canonical mismatch diagnosis
A canonical mismatch happens when your rel=canonical tag points one way while redirects, sitemaps, internal links, or hreflang point another. Conflicting signals confuse which URL should represent a piece of content, so crawlers may pick a canonical you did not intend. Aligning the signals fixes it.
- HTTP 300 Multiple Choices: crawler handling
HTTP 300 Multiple Choices signals that the requested resource has more than one representation and the client (or user) should pick one, optionally guided by a Location header pointing at a preferred choice. It is defined in RFC 9110 but is almost never used in practice for web pages, because there is no standard machine-readable format for the choices. For SEO and crawling, a 300 is ambiguous: most crawlers cannot reliably follow it, so a concrete redirect is preferable.
- Duplicate content diagnosis
Duplicate content is the same or very similar content available at multiple URLs. It is not a penalty — Google says so — but it does split signals and waste crawl budget, and search engines must pick one URL to show. Canonical tags, consistent linking, and parameter handling consolidate duplicates onto a preferred URL.
- Website observability
Confirm localized URLs are crawled and return 200, recorded server-side.
Sources and verification notes
- Google Search Central — Tell Google about localized versions
- Google Search Central — Common hreflang mistakes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.