Hreflang Errors: How to Find and Fix Them

Hreflang errors mostly come from missing return tags or wrong language codes. Here is how to find every broken pair and fix them without breaking more.

By Ibrahem HelalAI-assisted, reviewed by Jeremy ZavaPublished 29 September 20266 min read

Hreflang errors are almost always a broken pair: a missing return tag, a wrong language code, or a page that canonicalizes away from itself while still carrying hreflang annotations. Find every pair, confirm each one points back, and fix the codes before touching anything else.

Hreflang is one line item on a longer technical SEO checklist, and it tends to break quietly, with no crawl error and no drop that looks obviously like a language problem.

On this page

What does a correct hreflang set actually look like?

A group of pages, each carrying a link to every other version, including itself. If your site has an English and an Arabic homepage, the English page lists both an en and an ar entry, and the Arabic page lists the same two, pointing at the same two URLs [1].

A correct two-language hreflang pair
On this page	hreflang value	Points to
/	en	https://example.com/
/	ar	https://example.com/ar/
/ar/	en	https://example.com/
/ar/	ar	https://example.com/ar/

Notice the symmetry: both pages list both entries, including the self-reference. Drop the self-reference, or list one direction and not the other, and the set is already broken.

Why is a missing return tag such a common failure?

Because the two pages are usually built and edited separately. Someone adds a new Arabic page and links it back to the English original, but forgets to add the matching entry on the English page, or a content management step only updates one side of the pair during a later edit.

Google is explicit about the result: if page A links to page B, but page B does not link back to page A, the annotation is not considered reliable and may be ignored [1]. Not "penalized" — ignored, which means you lose the signal entirely rather than getting a partial credit for getting half of it right.

This is why checking hreflang one page at a time misses the problem. You have to check pairs.

Large sites make this worse simply by scale. A site with five languages and a thousand translated pages each has roughly five thousand individual hreflang entries, and a single content management step that forgets to update one language's set on every new page can quietly break hundreds of pairs before anyone notices a pattern in the traffic data. The fix is never "go fix the broken tags" as a one-time task; it is building the check into however pages get published so a new page cannot go live with an incomplete set.

Export every hreflang tag on the site
Crawl the site and pull every hreflang attribute and its target URL into one sheet, one row per tag.
Group by URL pair
For every A-to-B relationship, look for the matching B-to-A row. Anything without a match is a missing return tag.
Check the language codes
Confirm each code is a real ISO 639-1 language code, and a real ISO 3166-1 region code if one is used. A typo here fails silently.
Confirm the target URLs resolve
A hreflang tag pointing at a URL that 404s, redirects, or is blocked by robots.txt is worse than no tag at all.
Re-crawl after the fix
Confirm every pair is now symmetrical before moving on to the next batch.

Which language and region codes trip people up?

Two mistakes repeat across almost every site we check. The first is using a region code where a language code would do, such as writing ar-AE when the content is not actually different for a visitor in one Arabic-speaking country versus another. That doubles the number of pairs to maintain for no gain.

The second is confusing the country with the language. en-UK is not a valid code; the correct region code is GB. fr-CA is valid but only useful if the French content genuinely changes for that audience, such as different pricing or a different domain. When in doubt, use the plain language code and add a region only when the content itself, not just the audience, differs.

Does the canonical tag have to match the hreflang tags?

Each page's canonical should point at itself, not at another language version. If the Arabic page canonicalizes to the English page, you are telling Google the English page is the real one to index, while the hreflang tag on the same page is telling it the opposite. One of those two signals loses, and it is rarely the one you wanted to win.

This mistake is common after a migration, when a canonical tag gets copied across locales along with the rest of the template and nobody notices it still points at the source language. If you are mid-migration, our site migration checklist covers the canonical audit that catches this before launch.

Where does rendering fit into hreflang bugs?

If the tags are added by a client-side script rather than rendered on the server, a crawler that reads the first response never sees them at all, no matter how correct the pairs are once the script runs. This is a rendering problem wearing a hreflang costume, and it is worth ruling out before you spend a day auditing pairs that are actually fine. Our guide to JavaScript SEO covers how to check what a crawler receives before your scripts run.

The x-default tag deserves its own mention here. It tells Google which version to show a visitor whose language does not match any of your listed pairs, and it is easy to leave pointing at a stale URL after a domain or path change. Treat it as one more pair in your audit, not as an afterthought.

How do I confirm the fix actually worked?

Use the URL Inspection tool in Search Console on a handful of representative pages from each locale, and read the rendered HTML it reports, not just the live test result [3]. That shows you what Google itself parsed, which is the only version of "correct" that matters here.

Give it time after that. Hreflang re-evaluation is not instant, and a set that was broken for months can take a few crawl cycles to settle once it is fixed. Recheck a sample of pairs every week for the first month rather than declaring victory the day you ship the correction.

If your site spans more than two languages, treat this as an ongoing check rather than a one-time project; adding a third language multiplies the number of pairs, and a technical SEO audit on a fixed schedule is the cheapest way to catch a broken pair before it costs a quarter of traffic in that language.

What should I check before I add a new language, not after?

Decide the URL structure first, and keep it consistent. A subdirectory such as /ar/ is simpler to maintain than a separate subdomain or a separate domain, because every hreflang pair lives under one root and one crawl covers all of them. If you are choosing between the three, weigh the hreflang maintenance cost alongside the more commonly discussed factors like hosting and content ownership, because it is the one that keeps costing you every time a page is added.

Before the first page of a new language goes live, write down exactly which existing pages it will pair with, generate the tags for both directions as part of the same publishing step, and add the new language to whatever crawl or script already checks the existing pairs. Treat the checklist as part of the release, not as a follow-up task for after launch, because the follow-up task is the one that never happens once the language has shipped and attention has moved elsewhere.

One more thing worth deciding upfront: who owns the translation once it exists. A hreflang pair that points at a page nobody is maintaining will drift out of date long before the tag itself breaks, and a stale translation does more damage to trust than a missing one, because a visitor who lands on it and finds outdated pricing or a dead feature blames the whole site, not just the translation.

Questions people also ask

What is the single most common hreflang mistake?
A missing return tag. If page A points to page B but page B does not point back to page A, Google treats both annotations as unreliable and may ignore the whole set for that pair.
Do hreflang errors cause a ranking penalty?
No. There is no penalty. A broken hreflang set simply stops working as a signal, so Google falls back to its own judgment about which page to show, which is often not the one you intended for that visitor.
Can I use hreflang without a canonical tag?
You can, but each localized page should still self-canonicalize to itself. A canonical pointing at a different language version tells Google to treat that other page as the real one, which contradicts the hreflang set on the same page.
Does Search Console show hreflang errors directly?
Not as a dedicated report by default. The URL Inspection tool shows what Google read for a single URL, and a crawler such as Screaming Frog or a sitemap validator is the practical way to check every pair at once.
Do I need a separate hreflang tag for every region, or is the language enough?
Language alone is enough unless you genuinely serve different content by region, such as different pricing or currency. Adding a region code you do not need multiplies the number of return-tag pairs you have to keep correct for no benefit.

Sources

Tell Google about localized versions of your page — Google Search Central (checked 22 September 2026)
Managing multi-regional and multilingual sites — Google Search Central (checked 22 September 2026)
URL Inspection tool — Search Console Help (checked 22 September 2026)

Think a language version of your site is losing traffic?

Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.

Book a free 30-minute consultation

Who wrote this

Ibrahem HelalCo-founder

Leads strategy and delivery.

Works on: SEO, GEO

Reviewed before publishing by Jeremy Zava, Co-founder.

Posts by Ibrahem Helal