Hreflang Validator
Enter any URL to validate its hreflang set. The tool checks self-referencing tags, ISO language codes, x-default and duplicates, then fetches the alternates to confirm they point back.
Short answer
Hreflang tags declare that a page has alternate versions in other languages or regions, so search engines serve the right one to the right person. They only work when the set follows four rules: every page lists itself, every relationship is reciprocal, every value is a valid ISO 639-1 language code optionally paired with an ISO 3166-1 region code, and exactly one x-default names the fallback. One missing return tag can invalidate the whole cluster, and nothing on your site looks wrong when it happens. If your site is one language for one country, you do not need hreflang at all.
What hreflang solves, and when you need it
If you publish the same page in more than one language, or a different version for a different country, search engines face a question your content cannot answer: which version should this particular person see. Hreflang is the tag that answers it.
Without it, Google decides for itself, usually from the language of the content and the signals around the URL. The three failure modes are consistent:
- The wrong version ranks. A Spanish page shows for a British searcher because it happened to accumulate more links.
- Versions compete. Two translations of the same article split the signals for a query and neither ranks as well as one would have.
- Versions get folded together. Google decides the regional variants are duplicates and indexes only one, which is common between en-GB and en-US where the text is nearly identical.
When not to use it
One language, one country, no regional variants: you do not need hreflang, and adding it introduces a maintenance burden with no upside. This is a tool for international sites only.
The four rules a hreflang set has to satisfy
Hreflang is unusually strict for an SEO signal. Most tags degrade gracefully when they are wrong. Hreflang gets discarded.
| Rule | What it means | What breaks when it fails |
|---|---|---|
| Self-reference | Every page in the set lists itself among its own alternates | The set is treated as incomplete and may be ignored |
| Reciprocity | Every relationship is declared from both sides | Google drops the unconfirmed relationship, and often the cluster |
| Valid codes | ISO 639-1 language, optional ISO 3166-1 Alpha 2 region, hyphen separated | The entry is invalid and ignored. en-UK and en_GB are both wrong |
| One x-default | Exactly one entry names the fallback for unmatched visitors | Visitors outside your declared regions get whichever version Google picks |
On top of those, every URL in a set has to be absolute, resolve with a 200, be self-canonical and be indexable. An hreflang pointing at a redirect or a noindexed page takes its relationship down with it.
How to validate a hreflang implementation
Six steps. Step five is where most implementations fail, and it is the only one you cannot check by reading a single page in isolation.
- 01
Confirm you actually need hreflang
One language for one country needs no hreflang, and adding it will not help. You need it when the same content exists in more than one language, or in more than one regional variant of the same language.
- 02
List every version of the page, including this one
A hreflang set is a complete list of alternates, and every page in the set must appear in it including itself. A page that omits its own self-referencing tag invalidates the set it belongs to.
- 03
Use valid ISO codes in the right format
Language is ISO 639-1 (en, es, de) and region is ISO 3166-1 Alpha 2 (GB, US, MX), joined by a hyphen: en-GB, not en_GB and not en-UK. Region alone is never valid; hreflang="GB" is an error.
- 04
Add exactly one x-default
x-default names the page to serve when no other alternate matches the user, typically an international or language-selector page. One per set, and it may point at a page already in the set.
- 05
Make every relationship reciprocal
If the English page declares the Spanish page as an alternate, the Spanish page must declare the English one back. Missing return tags are the most common hreflang error there is, and Google discards the whole cluster when it finds them.
- 06
Point at canonical, indexable URLs only
Every hreflang URL must be absolute, resolve with a 200, be self-canonical, and not carry a noindex. An hreflang pointing at a redirect or a noindexed page is dropped along with the relationship it declares.
Five hreflang mistakes that survive review
1. Using UK instead of GB
The region code is the ISO country code, and the United Kingdom's is GB.hreflang="en-UK" is invalid and silently ignored. It is probably the single most widespread hreflang error on the web.
2. Canonicalising translations to the original
A translated page with a canonical pointing at the English original tells Google not to index the translation at all, which defeats the entire exercise. Each language version must be self-canonical.
3. Adding a locale to one set and not the others
A new market launches, the new pages declare all the existing ones, and none of the existing ones declare the new pages. Every relationship is one-way, so none of them are confirmed.
4. Region without language
hreflang="mx" is not "Mexico": it is read as a language code, and there is no language mx. If you mean Spanish for Mexico, the value is es-MX.
5. Declaring hreflang in two places at once
Head links and sitemap entries that disagree give Google two versions of the truth. Pick one method. At scale the sitemap is usually easier to keep correct, because it is one generated file rather than a tag in every template.
Check the rest of the head too
Hreflang problems travel with canonical problems, because both come from the same templates. The canonical tag checker confirms each language version is self-canonical, which is the prerequisite for any of this working.
What this tool validates
Self-referencing tags
Whether the page includes itself in its own set
Return tags
Fetches each alternate to confirm it points back
x-default presence
Whether a fallback is declared, and only one
Language code validation
ISO 639-1 language and ISO 3166-1 region format
Duplicate detection
The same hreflang value declared twice in one set
URL consistency
Absolute URLs, consistent protocol and host patterns
Why the return tag check needs to fetch other pages
Frequently asked questions
What are hreflang tags?
Hreflang tags declare that a page has alternate versions in other languages or for other regions, and give the URL for each. They are written as link elements with rel="alternate" and an hreflang value such as es-MX. Search engines use them to serve the right version to the right person, rather than guessing from the content.
Do I need hreflang?
Only if the same content exists in more than one language, or in more than one regional variant of the same language such as en-GB and en-US. A single-language site serving a single country does not need hreflang, and adding it will not improve anything.
What happens without hreflang on a multilingual site?
Google chooses which version to show, and often chooses badly. The usual symptoms are a Spanish page ranking for British searchers, two language versions competing for the same query so neither wins outright, or Google treating the versions as duplicates and indexing only one of them.
What is a return tag, and why do they break?
A return tag is the reciprocal half of a relationship: if page A names page B as its Spanish alternate, page B must name page A as its English alternate. They break because the sets are usually generated per template, and a page added to one locale but not the others leaves a one-way relationship. Google discards relationships that are not confirmed from both sides.
What is a self-referencing hreflang tag?
Each page in a set must include an hreflang entry pointing at itself. The English page carries hreflang="en" with its own URL. This is easy to miss because it feels redundant, and omitting it is one of the most common reasons a set fails validation.
What is x-default?
x-default names the page to serve when none of the declared alternates matches the visitor's language or region. It is usually a language selector, or an international English version. Every set should have exactly one, and it may point at a URL that is already an alternate in the set.
What format do hreflang values take?
An ISO 639-1 language code, optionally followed by a hyphen and an ISO 3166-1 Alpha 2 region code: en, en-GB, es-MX, pt-BR. Underscores are invalid. A region on its own is invalid. And the region code is the country code, so the United Kingdom is GB rather than UK, which is a mistake that appears on a great many sites.
Can hreflang go somewhere other than the head?
Yes. Google accepts hreflang in three places: link elements in the HTML head, a Link HTTP header, or an xhtml:link entry in your XML sitemap. Use one of them, not several. Sitemap hreflang is often easier to maintain at scale because it lives in one generated file rather than in every template.
Does hreflang fix duplicate content between language versions?
It manages it rather than fixing it. Hreflang tells Google the pages are alternates of one another rather than duplicates competing for the same slot. It is not a substitute for canonical tags: each page should still be self-canonical, and pointing a translated page's canonical at the original is a common error that removes it from the index.
Can hreflang point at a page on a different domain?
Yes, and it commonly does. Country-code domains such as example.co.uk and example.de are a normal hreflang arrangement. The reciprocity rule still applies across domains, so each site has to declare the others, which means the two sites have to stay in sync through whatever process generates the tags.
How long does it take for hreflang changes to take effect?
Google has to re-crawl every page in the set before it can confirm the relationships, so the slowest page in the cluster sets the pace. Days for a large well-crawled site, weeks for a small one. There is no way to force it beyond requesting indexing on the individual URLs.
Why does this tool report an error Search Console does not?
Search Console retired its dedicated International Targeting report, so hreflang errors now surface only indirectly through indexing behaviour. That is precisely why validating the markup directly is worth doing: the tags either follow the rules or they do not, and you can check that today rather than inferring it from rankings months later.
Other on-page SEO tools
Canonical Tag Checker
Validate canonical tags for self-referencing, protocol mismatches, trailing slash conflicts, noindex conflicts, and og:url consistency.
Use toolSchema & JSON-LD Validator
Validate structured data markup: required properties, date formats, nested entities, and JSON syntax. Supports all major schema types.
Use toolMeta Tag Checker
Check title tags, meta descriptions, Open Graph tags, Twitter cards, canonical URLs, robots directives, and viewport settings.
Use toolMeta Tags Generator
Write the title, description, and social share tags every page needs. Live character counts plus previews of how it will look in Google and on social.
Use toolKeyword Density Checker
See which words and phrases your copy actually leans on. Single word, two word and three word counts with density and first-mention position.
Use toolValidate hreflang across your entire site
Hreflang is a cluster problem: one page out of step invalidates the group. CrawlRaven crawls every page, maps the full set of relationships, and reports the ones that are not confirmed from both sides.