12 common hreflang errors and how to detect them
Most hreflang errors are systemic rather than page-level. The 12 most common ones, and a three-layer method for catching them in production.
By Roozbeh Nazari · CEO
hreflang is one of the most frequently misconfigured areas of technical SEO. The reason is not its complexity; it is how quietly it fails. A badly configured hreflang setup throws no errors, the page looks normal, and nobody notices. The problem only surfaces months later, when the page in the wrong language starts ranking in the wrong country.
We covered how to build a multilingual architecture in the clinic vertical in our multilingual SEO architecture playbook. This piece is the companion to it: the 12 concrete errors most often seen in production once the architecture is in place, and the method for catching them.
Reciprocity and grouping errors
The first four errors come back to the basic logic of hreflang: it is not a page tag, it is a group declaration.
1. One-way declaration. The TR page points to the EN page, but the EN page does not point back to TR. Google's documentation requires declarations to be reciprocal; declarations that are not reciprocal may be ignored. This is the most widespread error on the list.
2. Missing self-reference. Every page must list itself alongside the other pages in the group. A page without a self-reference behaves like an outside observer rather than a member of the group.
3. Missing member. The group has four languages, but some pages list only three. This usually comes down to template differences: the blog template prints four languages while the service template stopped at three.
4. Group membership that is inconsistent from page to page. Page A points to B and C, page B points to A and D. No consistent set emerges, and the whole group becomes unreliable.
The common source of these four errors is almost always the same: hreflang is produced template by template rather than from a single source of truth.
Code and URL errors
The next four errors are more mechanical, but no less common.
5. Invalid language code. The most frequent cases are invented region codes and confusion between language and country. For Arabic, "ar" is a language code; "ar-AE" is a language-region combination. "uk" means Ukrainian, not the United Kingdom.
6. Using a region code on its own. An hreflang value cannot carry a country code without a language code. This is a declaration that gets silently ignored.
7. Using relative URLs. hreflang values must be absolute URLs, protocol included. Setups that write relative paths have usually carried them over unchanged from staging to production.
8. Pointing to redirected or unreachable URLs. The address hreflang points to must be the final address. A declaration that points to a redirect, a 404, or a page blocked by robots.txt breaks the group.
Conflicting signals
The last four errors are the hardest to spot, because the hreflang markup itself looks correct. The problem is that the page says something different somewhere else.
9. Canonical conflict. The page says "I am the Arabic version" through hreflang, while its canonical points to the English version. At that point the Arabic version stops being a page in its own right. Every locale has to be self-canonical.
10. Automatic redirection. Even when hreflang is set up correctly, a forced redirect based on IP or browser language locks the crawler onto a single version. We described the mechanism and a fifteen-minute test procedure in our piece on locale auto-redirects.
11. Page language that does not match the declaration. hreflang says "fa" while the body of the page has largely stayed in English, usually as the result of a half-finished translation. When the declaration and the content contradict each other, the content wins, not the declaration.
12. Misusing x-default. x-default marks the default page for users whose language has not been matched; it does not mean "the most important language". Giving x-default to more than one page, or never setting it at all, are different situations, but both need fixing.
Why Search Console is not enough on its own
Most teams' first reflex is to track hreflang status in Search Console. That is reasonable, but it has two structural limits.
The first is coverage: the reports are based on the pages Google has crawled and processed. A systematic error in a new language version that has not been crawled yet may stay invisible in the report for weeks. Waiting to validate a newly launched locale means missing the period in which the error spreads most expensively.
The second is resolution: the reports tell you that there is a problem, not which template produced it. Most of the twelve errors are template errors, not errors in individual pages. When you cannot see the template, you start fixing pages one by one and the same error comes back with the next release.
That is why it is more accurate to treat Search Console as a post-validation monitoring tool rather than a validation tool. Your own crawl finds the error; Search Console shows over time whether the fix has registered on Google's side. The two do not replace each other.
There is also the sitemap side: delivering hreflang declarations through an XML sitemap instead of page tags reduces template sprawl, especially on sites with many pages. Changing the method does not resolve the errors by itself, but it makes a single source of truth easier to establish, and the root cause of the errors on this list is very often exactly the absence of that source.
Detection in production: three-layer validation
None of these errors can be found reliably by opening pages and looking at them. Repeatable validation takes three layers.
Layer one: crawling the rendered HTML. Crawl the whole site and extract the hreflang declarations of every URL. The critical point is to take the rendered HTML rather than the source HTML, because hreflang tags added client-side do not appear in the source. The output should be a list of declared locales for each URL.
Layer two: graph validation. Treat the crawl output as a directed graph and check the following programmatically: does every edge have its counterpart, does every node include itself, is the size of every component equal to the expected number of languages, are the language codes on the valid list, do the target URLs return 200. These five checks automatically catch most of the twelve errors on the list.
Layer three: conflict checking. For every URL, compare the hreflang declaration against the canonical, the page lang attribute, and the entry in the sitemap. Every mismatch between those three sources is a finding.
The output of these three layers should be a regime, not a list. hreflang is not something you fix once and leave behind; every new page template, every new language and every migration creates a new breaking point. Putting validation inside the release flow is both cheaper and more effective than an audit run six months later.
We treat continuous validation setups like this as a standard part of our technical SEO work; if you would like to go through your own setup together, you can get in touch.
One last note on sequencing: once you have found these twelve errors, do not try to fix them all at the same time. Resolve the conflicting signals (9-12) first, then the code and URL errors (5-8), and the group structure (1-4) last. Taken in reverse order, a corrected group structure still fails because of conflicting canonicals, and the fix looks as though it was never made.