Hreflang Checker

A hreflang checker shows whether the language and region tags on a page are set up in a way Google will actually use. If you run a UK site alongside an Irish, US or French version, hreflang is what stops the wrong page appearing in the wrong country. Our tool reads the hreflang links in the page head, validates every code, looks for a self-reference and x-default, then opens up to five alternate pages to confirm they link back.

How to use the Hreflang checker

1. 1 Pick a page with alternatesChoose a page that has versions in other languages or for other countries, such as your UK home page or a key product page.
2. 2 Paste the full URL and run the checkEnter the address including https://. We load the page, read every link element with a hreflang attribute and check the html lang value.
3. 3 Review the code and self-reference resultsInvalid codes, duplicate values, a missing self-referencing tag and a missing x-default are each listed with the values we found.
4. 4 Check the return linksWe fetch up to five of the alternate URLs and confirm each one points back to the page you tested. Any that do not are named by their language code.
5. 5 Fix and re-testCorrect the tags in your template, CMS or plugin, clear any cache, then run the check again on both the original page and one of its alternates.

What hreflang tags are and when a site needs them

Hreflang is an HTML attribute, used on a link element in the page head, that tells search engines a page has equivalents aimed at other languages or regions. Each tag names a language, optionally a region, and the URL of the version for that audience. Google uses the set to swap in the most suitable URL in its results, so a searcher in Dublin sees your en-ie page while a searcher in Manchester sees en-gb.

You only need hreflang when you genuinely have alternate versions. Typical cases are a UK and a US store with different prices and spelling, an English and Welsh version of a public service page, or a company with separate French, German and Spanish sections. A single English-language site serving British customers gains nothing from it, and adding tags that point nowhere useful just creates more to maintain.

Hreflang can also be declared in HTTP headers (useful for PDFs) or in an XML sitemap. Our hreflang checker reads the HTML link elements in the page head, which is the method most websites and CMS plugins use.

Why hreflang errors hurt international SEO

When hreflang is broken, Google falls back to guessing. Very similar pages for the UK and the US can be treated as near-duplicates, and only one of them may be shown in both countries. That leads to American prices and dollar signs appearing for British searchers, higher bounce rates and lost sales, even though the right page exists.

Hreflang is a signal rather than a directive, and Google drops any part of it that does not add up. A code it does not recognise is ignored. A pair where only one side links to the other is ignored. A tag pointing to a URL that redirects or returns an error is ignored. The result is often a set of tags that looks complete in the source code but is doing very little, which is exactly what an hreflang tag checker is meant to catch.

Reading the results of the hreflang tag checker

Each check comes back as a pass, a warning or a failure, with the values we found so you can see exactly which tag is at fault.

• Page language (html lang): the lang attribute on the html element. It is not part of hreflang, but it should match the content, for example en-GB on a British page.
• Language codes: every hreflang value must be an ISO 639-1 language code, optionally followed by a hyphen and an ISO 3166-1 alpha-2 region code. en, en-gb, cy-gb and fr-ca are valid. en-uk and uk are not what most people intend.
• Duplicate values: the same language-region pointing to more than one URL. Google cannot tell which one you mean.
• Self-referencing tag: the page should list its own URL in its own set. We compare addresses ignoring http or https, www, the trailing slash and any fragment.
• x-default: the fallback for searchers who match none of your versions. Recommended but optional.
• Return links: for up to five alternates we confirm the other page links back. A failure names each language code with no return link, or marks it as blocked if we could not load that page.

Hreflang language and country codes

Every hreflang value is built from two standards. The language comes first, as a two-letter ISO 639-1 code such as en, fr, de or es. The country is optional and comes second, as a two-letter ISO 3166-1 alpha-2 code such as GB, US, IE or CA, joined to the language with a hyphen. A country on its own is not valid, so gb or us by themselves are ignored. Codes are not case-sensitive, so en-GB and en-gb mean the same thing, but pick one style and use it consistently to keep templates easy to read.

The special value x-default is not a language at all. It marks the page to show when a searcher matches none of your listed versions, usually a global home page or a country selector. Use it once per cluster, and include it in the set on every page.

You can also use a language without a country. hreflang="en" covers English speakers anywhere you have not targeted more specifically, which is a sensible catch-all next to en-gb and en-us. Our hreflang checker validates each value against both lists and names any code it does not recognise.

• en-UK instead of en-GB: the ISO country code for the United Kingdom is GB, so en-uk is not a valid region. Use en-gb.
• uk on its own: uk is the language code for Ukrainian, so hreflang="uk" tells Google the page is in Ukrainian.
• A country code used as a language: se for Swedish (the language is sv), jp for Japanese (ja), dk for Danish (da), cz for Czech (cs) and gr for Greek (el).
• Underscores instead of hyphens: en_GB is how many CMSs store locales internally, but hreflang needs en-GB with a hyphen.
• Groups of countries: values such as en-EU or es-419 (Latin America) are not ISO 3166-1 alpha-2 country codes, so they fall outside the format Google documents. Use a language-only code, or list each country separately.
• Mixing up language and audience: a page in English for customers in Germany is en-de, not de-de. The first part always describes the language of the content.

How to fix hreflang problems step by step

Start by writing down the full cluster: every URL in the group and the code each one should carry. Every page in the cluster must output the same complete list, including itself, plus x-default if you use one. Missing return links almost always come from one template or one language section being set up differently from the rest.

Then work through the fixes in this order, re-running the hreflang checker after each change.

• Correct invalid codes in the template or plugin settings, replacing en-uk with en-gb and checking any country code used as a language.
• Make sure each alternate URL is the final, canonical address: https, the preferred www or non-www version, and a 200 status, not a redirect.
• Add the missing self-referencing tag so each page lists itself.
• Add the same set of tags to every alternate page so the return links exist.
• On WordPress, multilingual plugins such as WPML or Polylang output hreflang automatically once translations are linked; most problems come from translations that were never connected to each other.
• On Shopify, hreflang is generated when you use Shopify Markets with subfolders or domains for each market; check that each market is active and its languages are published.
• Purge any page cache or Cloudflare cache so search engines and our tool see the new head.

Hreflang best practice for UK businesses

Keep hreflang and canonical tags in agreement. Each page should have a self-referencing canonical, not a canonical pointing to another language version, otherwise you are telling Google to index one page while asking it to show another. Only include URLs that are indexable: no noindex pages, no URLs blocked in robots.txt and no redirects.

Translate or localise the content properly. Hreflang does not make thin duplicates rank; a UK page and a US page with identical text apart from a currency symbol may still be grouped together. Use local spelling, prices, delivery details and contact information so each version earns its place.

Finally, check after every site change. New templates, a CMS migration or a switch from subdomains to subfolders are the moments hreflang usually breaks, and Google Search Console no longer has a dedicated international targeting report, so a regular hreflang check is the quickest way to know the tags still work.

Examples you can copy

<link rel="alternate" hreflang="en-gb" href="https://www.example.co.uk/" />
<link rel="alternate" hreflang="en-ie" href="https://www.example.com/ie/" />
<link rel="alternate" hreflang="en-us" href="https://www.example.com/us/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

<!-- On https://www.example.co.uk/contact/ -->
<html lang="en-GB">
<link rel="alternate" hreflang="en-gb" href="https://www.example.co.uk/contact/" />
<link rel="alternate" hreflang="cy-gb" href="https://www.example.co.uk/cy/cysylltu/" />

<!-- On https://www.example.co.uk/cy/cysylltu/ -->
<html lang="cy-GB">
<link rel="alternate" hreflang="en-gb" href="https://www.example.co.uk/contact/" />
<link rel="alternate" hreflang="cy-gb" href="https://www.example.co.uk/cy/cysylltu/" />

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.example.co.uk/</loc>
    <xhtml:link rel="alternate" hreflang="en-gb" href="https://www.example.co.uk/" />
    <xhtml:link rel="alternate" hreflang="en-us" href="https://www.example.com/us/" />
  </url>
  <url>
    <loc>https://www.example.com/us/</loc>
    <xhtml:link rel="alternate" hreflang="en-gb" href="https://www.example.co.uk/" />
    <xhtml:link rel="alternate" hreflang="en-us" href="https://www.example.com/us/" />
  </url>
</urlset>

Common mistakes to avoid

Frequently asked questions