Hreflang cluster errors are unusual among technical SEO problems because hreflang works as a connected set rather than page by page. If a return link is missing or incorrect, Google may ignore or misinterpret the affected annotations across the cluster—not only on the page containing the error. This leaves little room for inconsistency in hreflang implementation.
Reciprocity is the requirement, not a nicety
If your English page declares a German alternate, the German page must declare the English one back. Every page in a cluster must reference every other page, including itself.
When a return link is missing, Google cannot confirm the relationship is intentional, and unconfirmed annotations are ignored. The cluster reverts to being treated as unrelated pages, competing with each other.
This is why hreflang problems present as “nothing happened” rather than as an error. The markup is there. It is simply not being used.
This is also why our validator fetches the alternates rather than only parsing the page you enter. A tool that reads one page can confirm you declared six annotations. It cannot tell you whether the six pages agree, and disagreement is the entire failure mode.
The mistakes that break clusters
In rough order of how often we encounter them.
- Missing return links — page A points to B, B does not point back
- Missing self-reference — every page must include itself in the set
- Invalid codes —
en-UKis wrong; the country code isGB - Pointing at redirects — the alternate must be the final URL
- Pointing at noindexed pages — you cannot serve an alternate you have excluded
- No x-default — not required, but without it unmatched visitors get an arbitrary choice
Checking It Properly Means Fetching the Alternates

Reading the source code of one page only tells you what that page declares. It may confirm that the page includes six hreflang annotations, uses valid syntax, and references the expected language versions. However, it cannot confirm whether those six alternate pages return the relationship correctly, reference the same URL set, or remain accessible to search engines.
Proper hreflang validation therefore requires checking every URL within the cluster. Each alternate should be fetched and tested to confirm that it:
- Returns a successful
200status code - Includes a self-referencing hreflang annotation
- Links back to the original page
- References the other intended language and regional versions
- Uses valid language and country codes
- Points directly to the final URL without a redirect
- Remains indexable and is not blocked from crawling
- Uses a canonical URL that is compatible with the declared language version
For example, an English page may correctly point to German, French, and Spanish alternatives. That implementation can still be incomplete if the German page does not link back to the English page, the French URL redirects, or the Spanish page is marked noindex. None of those problems can be identified by inspecting the English page alone.
Our hreflang validator fetches the alternate URLs instead of only parsing the page entered into the tool. It compares the declarations across the cluster, checks whether reciprocal links exist, and validates the language and region codes used in each annotation. This wider validation is important because errors often appear on an alternate page rather than on the original URL being tested.
The result is a more accurate view of the cluster. Instead of simply confirming that hreflang tags are present, the validator checks whether the connected pages support the international targeting relationship those tags are intended to communicate.
What hreflang does not do
It does not make a page rank in a new market. It tells Google which version to serve to someone who was going to see one of your pages anyway.
If your German page has no authority in Germany, correct hreflang will not create any. It will only ensure that when a German searcher does reach you, they land on the German page rather than the American one.
Annotations solve the wrong-version problem. Market authority is a separate and much larger piece of work.
Getting the codes right
Invalid language and region codes are one of the most common causes of a cluster being ignored, and one of the easiest to avoid. The format is a language code, optionally followed by a region.
- Language — ISO 639-1, two letters:
en,de,fr - Region — ISO 3166-1 Alpha 2, two letters:
GB,US,IN - Together —
en-GB,en-US,de-AT
The mistakes recur predictably. en-UK is wrong; the country code for the United Kingdom is GB. Region alone is invalid — there is no hreflang="US". And a region cannot be used without a language.
One nuance worth knowing: the language code is required, the region is optional. If your German page serves all German speakers rather than one country, de alone is correct and more accurate than picking de-DE arbitrarily.
Three places to put it, and how to choose
hreflang can live in the HTML head, in HTTP headers, or in your XML sitemap. All three are equally valid and you should use exactly one.
- HTML head — simplest to inspect, but every page carries the full set, so a twelve-market cluster means twelve tags on every page
- XML sitemap — keeps pages clean and is far easier to maintain at scale, at the cost of being harder to spot-check
- HTTP headers — the only option for non-HTML files such as PDFs
Mixing methods is where clusters break silently. If some pages declare in the head and others in the sitemap, the sets rarely stay synchronised, and an out-of-sync set is worse than no set at all.
Diagnosing a cluster that is being ignored
When annotations are present and nothing is happening, work through these in order.
- Does every page reference itself? A missing self-reference invalidates the set.
- Does every page reference every other? Partial sets are frequently discarded.
- Do the alternates return 200, or do they redirect?
- Are any alternates noindexed? You cannot serve a version you have excluded.
- Are the codes valid, including the region?
- Are you mixing declaration methods across the cluster?
Our hreflang validator checks the first five directly by fetching the alternates rather than trusting the page you entered. The sixth needs a human, because it requires knowing what the rest of the site does.
Fix Hreflang Errors Before They Affect International Visibility
A hreflang implementation can look correct on one page while failing across the wider set of language and regional URLs. Missing return links, invalid country codes, redirects, noindexed alternates, or conflicting declaration methods can prevent Google from understanding which version should appear for each audience.
MoxSEO can audit the complete hreflang cluster instead of checking URLs individually. You can request a free technical SEO audit to identify broken return links, incorrect language-region codes, missing self-references, non-indexable alternates, and inconsistent annotations.
After identifying the errors, the next step is to rebuild a consistent cluster and validate every alternate URL before deployment. For a structured review of your international website setup, you can schedule an SEO consultation and receive recommendations based on your existing site structure.
Sources and further reading
Frequently asked questions
Do I need hreflang for two English sites?
Yes, if they target different countries. Use en-GB and en-US so the right one is served rather than one cannibalising the other.
Can hreflang go in the sitemap instead of the page?
Yes, and for large clusters it is often easier to maintain. The reciprocity requirement is identical either way.
What does x-default do?
It names the fallback for visitors who match none of your declared locales. Usually your primary or international version.
Will hreflang fix duplicate content across markets?
It stops the versions competing, which is usually what people mean. It is not a canonical and does not consolidate them into one.

Sakshi Kumari is an SEO Specialist at MoxSEO with expertise in keyword research, on-page SEO, content optimization, technical SEO, and link-building strategies. She focuses on improving organic visibility, strengthening website performance, and creating search-focused content that attracts relevant traffic. Through data-driven analysis and practical SEO execution, Sakshi helps businesses build stronger search presence and achieve sustainable digital growth.



