About the hreflang Checker

Growthack's free hreflang Checker tests whether your international annotations actually work, rather than whether they merely exist.

Most hreflang problems are invisible on the page you are looking at. A tag can be perfectly formed and still be discarded, because the page it names does not name it back, because a canonical tag contradicts it, or because the URL it points at now redirects. Checking a single page in isolation cannot find any of those.

This tool reads the annotations from the page you enter, then fetches every alternate in the set and reads theirs, so the relationships between pages can be checked rather than assumed. Annotations are read from HTML link tags, from the HTTP Link header, and from XML sitemaps that use xhtml:link alternates.

Results include a return-link matrix showing which declarations are reciprocated, a page-by-page breakdown of what each URL returned when it was fetched, a prioritised list of issues with the reason each one matters, and two CSV exports.

Everything is read live at the moment you run the check. Nothing is stored.

How does the hreflang Checker work?

The checker starts from one URL rather than from a crawl of your whole site, because hreflang is a property of a set of pages, not of a domain.

1. Your URL is fetched and its annotations are read from the HTML, the HTTP Link header, or the sitemap entry.

2. Every alternate URL named in those annotations is fetched in turn.

3. Each of those pages is read for its own annotations, canonical tag, robots directives, HTTP status and lang attribute.

4. The set is validated against itself, and each finding is reported as an error, a warning or a note.

Errors are problems Google acts on: the annotation is discarded and the page is not substituted for that market. Warnings and notes are worth resolving but will not, on their own, invalidate the set.

Language and region codes are validated against the published standards rather than a pattern match, so the tool can tell you which part of a code is wrong and what it should be.

What the hreflang Checker finds

Missing return links

hreflang only works as a mutual declaration. If page A names page B, page B must name page A. Where it does not, Google treats the relationship as unverified and ignores it in both directions.

This is the most common reason a correct-looking implementation does nothing, and it cannot be detected without fetching the other pages. The return-link matrix shows every declaration in the set and marks the ones that are not reciprocated.

Invalid language and region codes

Codes are validated against ISO 639-1 for languages and ISO 3166-1 Alpha 2 for countries. The tool reports which code is invalid, why, and in common cases what it should be instead.

It flags country codes used as languages, regions that are not countries such as en-EU, underscores in place of hyphens, and the single most frequent error in British implementations: en-UK, where the correct country code is GB.

Canonical tags that cancel the set

Each language version must be canonical to itself. A canonical pointing at another version tells Google not to index the page you are asking it to serve, which removes that page from the set entirely.

The annotations usually look perfect when this happens, which is why it survives so many audits. Every page is checked for its canonical target and whether that target is itself or another page in the same set.

Missing self-references

Every page in a set should include an annotation pointing at itself. Its absence is both a specification failure and a reliable sign that the list was assembled per page rather than generated once.

Alternates that do not resolve

Each alternate is fetched, so the tool reports URLs returning 404 or 500, URLs that redirect elsewhere, and hosts that do not respond at all. A named URL that cannot be verified cannot support the annotation that names it.

Pages excluded from indexing

Pages in the set are checked for noindex, in both the robots meta tag and the X-Robots-Tag header. Asking Google to serve a page to a market while telling it not to index that page is a contradiction Google resolves by ignoring the annotation.

Sets that disagree with themselves

The tool reports the same code used twice on one page with different URLs, and the same code pointing at different URLs on different pages in the set. Both make the group inconsistent and unverifiable.

It also flags mixed URL forms across the set, such as some annotations using https and others http, or a mixture of www and non-www hostnames. Two URL forms that do not match exactly will not produce a matching return link.

Missing x-default

Where a set has no x-default, the tool says so. Without it, visitors who match none of your declared languages or regions are served whichever version Google judges strongest rather than the one you would have chosen.

Who should use the hreflang Checker?

SEO teams running multi-market websites

Validate a market before and after launch, and confirm that the set a template generates is the set you intended.

Anyone replatforming or migrating URLs

Migrations break hreflang more reliably than anything else. URLs move, the annotations keep naming the old ones, and the symptom looks like a ranking problem rather than a tagging one. Check a representative page from each market after launch.

Agencies auditing an international setup

Produce a prioritised, evidenced list of what is broken and why, with a CSV of every annotation behind it.

Developers implementing hreflang

Confirm that return links, self-references and codes are correct before the work is signed off, rather than finding out when the wrong country's page keeps ranking.

How to use the hreflang Checker

1. Enter a URL. Any page that carries hreflang annotations, or an XML sitemap that declares them. For a sitemap, the tool checks the first annotated entry and the pages that entry names.

2. Choose how many pages to check. Up to 30, 60 or 150. A set is usually one page per market, so the default of 60 covers most. Very large sets can be checked in parts.

3. Read the verdict. It states how many problems will actually stop hreflang working, as distinct from problems worth tidying.

4. Work through the issue list. Each issue explains what it is, why it matters and how to fix it, and lists the URLs affected.

5. Check the return-link matrix. Pages run down, annotations run across. A lone mark in a column is a declaration nobody returns.

6. Review the page-by-page table. HTTP status, lang attribute, number of annotations, self-reference, canonical target and robots directives for every URL in the set.

7. Export the results. One CSV of every annotation with its return-link status, and one of the issue list for sharing or ticketing.

8. Re-check after the fix is live. Changes are picked up at recrawl, so test once the pages have been recrawled rather than immediately after deploying.

What makes this hreflang checker different?

It fetches the other pages

Validators that inspect a single page can only tell you whether its tags are well-formed. Reciprocity, canonical conflicts and dead alternates are properties of the set, and finding them requires fetching every page in it. This tool does.

It reads all three implementation methods

HTML tags, HTTP Link headers and XML sitemap annotations are all valid. Checkers that read only the HTML will report a correctly annotated PDF, or a sitemap-driven implementation, as having no hreflang at all.

Codes are validated against the actual standards

Language codes are checked against the ISO 639-1 list published by the Library of Congress, the registration authority for the standard, and country codes against ISO 3166-1 Alpha 2. The tool names the invalid part rather than marking the whole value as malformed.

It separates what breaks hreflang from what is merely untidy

Findings are graded. A missing return link and a three-letter language code are not the same severity, and a list that treats them identically is harder to act on than no list.

It does not report what it has not checked

Where annotations are declared in a sitemap too large to read in one pass, the pages concerned are reported as unchecked rather than scored as having no annotations. A checker that calls a correct implementation broken is worse than no checker.

Frequently asked questions

What is hreflang?

hreflang is an annotation that tells search engines several URLs are the same page in different languages or for different countries, and which version to show to which audience. It can be implemented in HTML, in an HTTP header, or in an XML sitemap.

What does an hreflang checker do?

It validates those annotations. A useful one checks the relationships between pages rather than the syntax of a single page, because most hreflang failures are relationship failures: a missing return link, a contradictory canonical, or a URL that no longer exists.

Why is my hreflang not working?

In order of how often it is the cause: the other page does not point back; a canonical tag points at a different version; the URLs named have changed, usually in a migration; a page in the set is noindex; or a code is invalid and the annotation cannot be parsed. This tool checks all five.

What is a return link, and why does it matter so much?

A return link is the matching annotation on the page you named. Google only accepts an hreflang relationship when both pages declare each other, because otherwise any site could claim to be the alternate version of any other. Where the return link is missing, both directions are discarded.

Do I need x-default?

Not strictly, but it is usually worth having. It names the page to serve when a visitor matches none of your declared languages or countries. Without it Google chooses for itself, which for a visitor outside your markets tends to mean your largest market rather than your global page.

Is it en-GB or en-UK?

en-GB. The country code comes from ISO 3166-1 Alpha 2, in which the United Kingdom is GB. UK is not a valid country code, so en-UK is discarded. It is the most common error this tool finds on British websites.

Can hreflang be declared in an XML sitemap?

Yes, and for large sites it is often the better choice: the annotations live in one file rather than on every page. The tool accepts a sitemap URL and checks the first annotated entry together with the pages that entry names. Do not implement in both the sitemap and the HTML unless they are generated from the same source, because two lists that drift apart will contradict each other.

Does hreflang improve rankings?

No. It changes which of your own URLs is shown to a given audience, at roughly the position the page would have had anyway. The commercial gain comes from visitors landing on the version in their language, with their currency and their delivery options, rather than from a higher position.

Does hreflang fix duplicate content between countries?

It helps with near-identical pages in the same language, such as en-GB and en-US versions that would otherwise compete. Translated pages were never duplicates to begin with, so there is nothing to fix there.

How does canonical interact with hreflang?

Every page in an hreflang set must be canonical to itself. Using canonical to consolidate language or country versions cancels the hreflang, because you are telling Google that the page you asked it to serve should not be indexed. If you need both, canonical handles parameters and duplicates within a market, and hreflang handles the relationship between markets.

Why does the tool say some pages could not be assessed?

Because their annotations are declared further down a sitemap too large to read in a single pass. Those pages have not been judged either way. To check them, enter one of them directly and the annotations will be read from the page itself.

Does it check hreflang added with JavaScript?

No. The tool reads the HTML as it is served, which is also the most reliable way for Google to see hreflang. Annotations injected client-side are not dependably used, so this limitation reflects a real risk rather than hiding one.

How many pages can it check at once?

Up to 150 in a single run, with 60 as the default. Most sets are one page per market and fall well inside that. Where a run is capped, the tool says so rather than presenting a partial set as complete.

Is the hreflang Checker free?

Yes, and no signup is required. There is no email gate on the results or the CSV exports.

Is my data stored?

No. The tool reads publicly accessible pages at the moment you run the check and nothing about your site is stored. Responses are briefly cached so that repeating the same check does not re-fetch every page.

Does this replace Search Console?

No. Search Console reports the sets Google itself has resolved, which is the final word on what Google has accepted, but it reports after the fact. This tool tests what your pages are saying right now, which is what you need while you are fixing them. Use both.

Related free SEO tools

Website Migration Risk Checker
Identify technical SEO risks before a migration and compare what changed after launch.

SEO Forecasting Tool
Forecast organic traffic, conversions and revenue from your existing keyword rankings.

AI Visibility Check
Explore your brand's visibility across AI-powered search platforms.

Getting international SEO right is more than the tags

Correct hreflang makes sure the right version of a page is shown. It cannot tell you whether a market is worth entering, whether your URL structure gives each market a chance to compete, or whether the content in each language is good enough to rank in the first place.

At Growthack, we work on international SEO from the structure down: market selection, URL architecture, localisation that goes beyond translation, and the technical layer that holds it together.

Explore our SEO services or contact Growthack to talk through your international setup.