Hreflang Checker

Hreflang checker: check hreflang online, free

Hreflang is the most error-prone part of international SEO, and most faults are invisible on the page itself. Paste a URL and this hreflang checker reads its annotations, then fetches the pages they name to confirm each one links back. No account needed.

Instant and free. Checks self-reference, return tags, language codes, duplicates and x-default.

Every hreflang mistake, caught

We run 10+ products in 15+ languages, so we built deep hreflang validation most tools don't bother with.

Missing reciprocal tags

Page A links to B, but B doesn't link back - the #1 hreflang error.

Language mismatches

An hreflang declares a language the target page isn't actually in.

Broken hreflang URLs

Hreflang annotations pointing at dead or redirected pages.

Missing self-reference

Pages that forget to include an hreflang tag for themselves.

Non-canonical hreflang

Hreflang pointing at non-canonical URLs, confusing search engines.

html lang & group coverage

Missing html lang attributes and hreflang groups that aren't fully crawled.

Validate hreflang in 3 steps

1

Add & verify your site

Confirm ownership with DNS, a meta tag, or a file upload.

2

Run a crawl

We collect every hreflang annotation and build your full language graph.

3

Fix the flagged groups

Resolve missing reciprocals, mismatches, and broken targets, then re-run.

The 5 hreflang mistakes that break international SEO

Hreflang is the most error-prone area of technical SEO. Get these right and Google serves the correct language/region version to each user.

1Missing return (reciprocal) tags

If page A points to page B with hreflang, page B must point back to A. Google ignores one-way hreflang entirely. Every annotated page in a cluster must reference every other version, including itself.

2No self-referencing hreflang

Each page must include an hreflang tag pointing to its own URL with its own language code. Leaving out the self-reference is one of the most common reasons a whole cluster is silently ignored.

3Wrong or invalid language/region codes

Use ISO 639-1 language codes and optional ISO 3166-1 Alpha-2 region codes - e.g. en, en-GB, pt-BR. Common errors: using en-UK (it's en-GB), or a region code with no valid language. Add x-default for your fallback/selector page.

4Pointing hreflang at redirects or 404s

Every hreflang URL must return a live 200 - not a redirect, not a 404, and it must be the canonical version of that page. Hreflang pointing at a redirected URL breaks the mapping.

5html lang attribute mismatch

The page's <html lang="…"> should match the language you claim in hreflang. A mismatch sends conflicting signals to crawlers and assistive tech. Keep the markup, hreflang, and actual page content all in agreement.

Want the full background? Read our hreflang tags guide and the wider localization SEO guide.

How to read your hreflang check results

When you check hreflang online with Kalenux, every flagged issue tells you the page, the language group it belongs to, and exactly what to change. Here is how to act on the most common findings.

"Missing return tag" on a page

Open the alternate page it should link back to and add the reciprocal hreflang annotation. Both pages must reference each other and themselves. Re-run the check and the whole group clears at once.

"Broken hreflang URL" (redirect or 404)

The annotation points at a URL that no longer returns 200. Update it to the live, canonical URL of that language version. Never point hreflang at a redirect chain.

"Non-canonical target"

Your hreflang points at a URL that is canonicalised elsewhere. Point it at the canonical URL instead, so hreflang and canonical agree.

"Invalid language code"

Swap the code for a valid ISO 639-1 language (plus optional ISO 3166-1 region), e.g. change en-UK to en-GB. Add an x-default for your language selector or fallback page.

Validation rules, coverage and access

Return-tag (reciprocal) errors

A return-tag error happens when page A declares an hreflang link to page B, but B does not link back to A. Search engines require the references to be mutual, so a missing return tag invalidates the relationship and the annotation is discarded rather than corrected. It is the most common hreflang mistake by a wide margin, particularly on sites where locales are added one at a time and older pages are never revisited.

We flag every instance, naming both ends of the broken pair so you know which page to edit. Because the fault is a property of the group rather than of a single page, adding the missing annotation usually clears several flagged rows at once on the next run.

Self-referencing tags on every page

Each page in an hreflang group should include a tag pointing to itself with its own language code, alongside its alternates. Omitting the self-reference is a frequent reason search engines quietly ignore an entire cluster, even when every other annotation in it is correct. We flag pages that leave it out so a whole group is not lost to a single missing line.

Why hreflang must target canonical URLs

Hreflang must reference canonical, indexable URLs that return a live 200 status. Pointing it at a non-canonical variant or a redirected page sends conflicting signals, and the annotations are dropped rather than followed to their destination. We detect hreflang targeting non-canonical URLs so you can repoint each one at the canonical version and keep hreflang and canonical in agreement.

Checking hreflang across multiple languages

Add and verify your site, then run a crawl. We collect the hreflang annotations on every page, build the full language graph, and validate each group the way a search engine does, reporting missing reciprocals, language mismatches, and broken targets across all your locales at once rather than one page at a time.

Running the check without an account or an install

You can check hreflang online on any URL instantly with no account and nothing to download. The instant check runs against the page you paste and needs no crawler configuration. Create a free account to run a full-site hreflang check that validates every language group across your whole domain.

How this compares with validating hreflang by hand

Checking hreflang manually means opening every page, reading its annotations, and cross-referencing each alternate to confirm the references are mutual and the targets are live and canonical. The work grows with the square of the number of locales, so it becomes impractical well before a site feels large.

We build the full language graph for your site and validate every group automatically, so you find the one broken reciprocal among thousands of tags in seconds rather than hours.

Validating hreflang across a whole cluster

hreflang is the one area of technical SEO where checking a single page is close to meaningless, because correctness is a property of the group rather than of any page in it.

Why one page cannot be validated alone

An hreflang cluster is a closed set of mutual references. If the English page lists Turkish and German, then the Turkish page must list English and German, and the German page must list English and Turkish. Every page must also list itself.

Looking at the English page alone, you can confirm its tags are syntactically valid and that its self-reference is present. What you cannot confirm is the part that actually matters: whether the other two pages point back. A missing return tag on the German page invalidates the cluster, and nothing about the English page reveals it. This is why hreflang problems so often survive review by someone checking pages individually and finding nothing wrong with any of them.

What a cluster-level check looks at

Validating properly means fetching every URL in the cluster and building the reference graph, then testing it for reciprocity in both directions, a self-reference on each member, valid ISO language and region codes, exactly one x-default, and destinations that return 200 rather than redirecting or erroring.

It also means checking that hreflang agrees with the other signals on the same pages. A cluster member that canonicalises outside the cluster is contradicting itself, and a cluster member that is noindexed cannot serve as an alternate for anyone. These conflicts are common precisely because each signal is usually configured by a different part of the stack.

Why clusters break after they were working

The characteristic hreflang failure is a cluster that was correct and silently stopped being so. Adding a fourth locale means editing the three that already exist, and forgetting one leaves a partial cluster. Retiring a locale leaves every remaining page pointing at a URL that now 404s. A URL slug changed in one language and not updated in the annotations of the others produces the same result.

None of these are visible on the page that was edited, and all of them are visible in a cluster-level check. Re-validating after any change to your locale set is the only reliable defence, because the failure mode is specifically that the change looked complete from where the person making it was standing.

Related SEO tools

Get international SEO right

Free to start. Validate hreflang across your whole multilingual site.

Check hreflang now