Validating Hreflang, and the Mistakes That Break It Silently
Enter a URL and this fetches the page, pulls out its hreflang tags, and checks them against the rules that decide whether search engines use them at all — valid language and region codes, a self-reference, absolute URLs, no duplicated codes, and an x-default.
Hreflang is worth checking carefully because its failures are quiet. A broken set does not throw an error or show a warning anywhere. The tags sit in the source looking correct, search engines ignore them, and your translated pages carry on competing with each other as though the tags were never there.
At a glance
- Every page must list itself. A set without self-references is invalid, and this is the most common failure.
- en-UK is not a country code — the code for the United Kingdom is GB.
- The relationship has to be reciprocal: each alternate must point back.
- Hreflang is a suggestion about which version to show, not a ranking factor and not a redirect.
How to Use This Tool
Enter one page URL
Any page from your international set. The tool fetches it server-side, so it works on any public URL without an extension or login.
Check the tag list
Every hreflang found is listed with what it points at and where it was declared. The tag pointing at the page itself is marked, because its absence is the usual problem.
Work through the errors first
Errors break the set outright — an invalid code, a missing self-reference, duplicates pointing at different URLs. Warnings are worth fixing but do not invalidate anything.
Run it on the other versions too
A set is only valid when all its pages agree. Checking one page tells you that page is correct; it cannot tell you the French version points back.
What Hreflang Does, and What It Does Not
Hreflang tells search engines that several URLs are the same content in different languages or for different regions, and which one to show to which searcher. That is the whole job.
It does not redirect anyone. It does not boost rankings. It does not stop your pages competing in the sense of merging their authority — each URL still ranks on its own. What it does is stop the wrong one being shown: a British searcher landing on your American page with the wrong currency and spelling.
It also helps with a subtler problem. Near-identical pages in the same language — a US and a UK version of the same English article — look like duplicate content. Hreflang tells search engines they are deliberate regional variants rather than an accident.
Hreflang Is Not the Lang Attribute
These get confused constantly, and they do unrelated jobs.
The lang attribute on the html element tells the browser and assistive technology what language this page is in. Screen readers use it to pick the right pronunciation, and getting it wrong makes a page genuinely hard to listen to. It says nothing about other versions of the page.
Hreflang lives in link tags and tells search engines which other URLs are alternate versions. It says nothing to the browser and nothing to a screen reader.
You want both. They are not alternatives, and having one does not do the other's job.
The Failures That Break a Set
- No self-reference. Every page in the set must include a tag pointing at its own URL. Miss it and search engines discard the whole set for that page — this is the single most common hreflang mistake.
- No return tag. If your English page points at the French one, the French one must point back. A one-way declaration is ignored, because otherwise any site could claim to be an alternate of any other.
- Invalid language codes. The language must be ISO 639-1. Inventing one, or using a region code where a language belongs, means the tag is dropped.
- en-UK instead of en-GB. The UK's ISO 3166-1 country code is GB. This one is so common it deserves its own line, and this tool checks for it specifically.
- Relative URLs. Hreflang requires the full absolute address including the protocol.
- The same code declared twice pointing at different URLs. Search engines cannot resolve which is correct and may ignore the entire set rather than guess.
x-default, and What It Is Actually For
x-default names the page to show someone whose language and region match none of your versions. If you have English, French and German pages, a searcher in Japan matches nothing — x-default decides what they get.
It is not a default in the sense of a fallback that overrides your other tags, and it is not required. Leaving it out means search engines pick for you, which they will do reasonably but not necessarily the way you would.
The usual choice is a language-selection page if you have one, or your main international version if you do not. What it should not be is an arbitrary regional page — sending an unmatched visitor to your Australian site because it happened to be first is worse than letting search decide.
Pointing at Redirects or Dead Pages
A slower kind of breakage: the tags are valid, but the URLs they name have moved or gone. This happens naturally as a site changes, because hreflang is usually generated once and rarely revisited.
An hreflang pointing at a redirect is not fatal, but it is wasteful and ambiguous — you are naming a URL that is not the real page. Point at the destination instead.
An hreflang pointing at a 404 is worse, because the relationship cannot be verified: the alternate cannot point back if it does not exist, so the reciprocity that makes the set valid is broken. Our Broken Link Checker will test a list of alternate URLs, and the Redirect Chain Checker will find the destination of any that moved.
Where to Put Hreflang
There are three valid places, and you should pick exactly one. Declaring the same relationships in two places is how they end up disagreeing.
- In the HTML head, as link rel=alternate tags. The most common and the easiest to inspect — this is what the validator reads.
- In the XML sitemap, using the xhtml namespace. Better for large sites, because it keeps the markup out of every page and is far easier to generate correctly at scale.
- In HTTP headers, which is the only option for non-HTML files such as PDFs.
When You Do Not Need Hreflang At All
Most sites do not. If you have one version of your content in one language, hreflang has nothing to describe and adding it creates only the opportunity to get it wrong.
It also does not apply to a site that is simply available worldwide. Serving customers in several countries from one English site is not an international setup in this sense — hreflang is for when the same content exists at more than one URL.
It becomes worth the effort when you genuinely have parallel versions: translated pages, or regional variants with different pricing, currency or availability. Below that, effort spent elsewhere pays better.
If you do need it, our Hreflang Generator produces the tags with the right syntax, and this validator checks the result once it is live.
Frequently Asked Questions
What is the most common hreflang mistake?
A missing self-reference. Every page in a set must include an hreflang tag pointing at its own URL. Without it, search engines discard the whole set for that page — and nothing anywhere reports an error, so it can sit broken for years.
Is it en-GB or en-UK?
en-GB. The ISO 3166-1 country code for the United Kingdom is GB; UK is not a valid code and the tag is dropped. This is common enough that the validator checks for it by name.
What does hreflang x-default do?
It names the page to show a searcher whose language and region match none of your versions. It is optional — without it search engines choose for you. A language-selection page or your main international version are the sensible choices.
What is the difference between hreflang and the lang attribute?
The lang attribute tells browsers and screen readers what language the current page is in. Hreflang tells search engines which other URLs are alternate versions of it. They do unrelated jobs and you want both.
Do hreflang tags improve rankings?
No. Hreflang influences which version of a page is shown to which searcher, not how well any of them rank. Its value is in sending people to the right version rather than in ranking higher.
Should hreflang go in the HTML or the sitemap?
Either works, but pick one. HTML link tags are easier to inspect and fine for smaller sites; the sitemap is better at scale because the relationships are generated in one place. Declaring both is how they end up contradicting each other.
Can hreflang point at a redirecting URL?
It can, but it should not. You are naming a URL that is not the real page, and if the alternate 404s the reciprocity that makes the set valid is broken. Always point at the final destination.
Why does this only check one page?
Because hreflang is reciprocal, and one page can only show you its own half of the relationship. Run it on each version of the page — the set is valid only when all of them agree.
Related Tools
Hreflang Generator
Build hreflang tags with the right syntax, then validate them here once live.
Broken Link Checker
Check that the alternate URLs your hreflang names still resolve.
Redirect Chain Checker
Find the real destination of any alternate URL that redirects.
Advanced On-Page SEO Analyzer
Check the canonical and lang attribute alongside your hreflang set.