Docuboxer
By Sergio Alonzo Piña··7 min read

Hreflang mistakes that break international SEO

Missing return tags, wrong codes, no x-default: the hreflang mistakes that quietly break international SEO, and how to spot each one.

Broken hreflang almost always fails the same way: silently. The tags are in the HTML, the deploy went out, nothing errors — and Google quietly ignores the whole annotation because one page forgot to point back. Six mistakes cause most of it: missing return tags, invalid language codes, no self-reference, no x-default, canonicals that contradict the annotation, and relative or non-canonical URLs. Start by generating a correct block with the hreflang tag generator, which builds reciprocal sets in your browser, then use the list below as an audit checklist against what is actually live.

What hreflang does — and what it will never do

Hreflang is an annotation between equivalent URLs in different languages or regions. It does not pass authority between versions, it does not consolidate duplicate content, and it will not move you up the results page. Its single job is selection: when your page qualifies for a query, hreflang helps Google serve the version that matches the searcher's language and country.

That framing matters because it changes what you measure. If you expect rankings to jump after implementing hreflang, you will conclude it did nothing. The metrics that should move are country-level bounce rate and conversion: a US visitor landing on your en-GB pricing page in pounds sterling is the failure hreflang exists to prevent.

Mistake 1: missing return tags

This is the most common failure by a wide margin. Hreflang is reciprocal by specification: every page in a set must reference every other page in the set, including itself. If /us/ declares /uk/ but /uk/ never declares /us/, Google drops the annotation for that pair.

It usually happens through phased rollouts. You launch a new market, the new pages point at everything that already existed, and the older pages are never regenerated with the new return tags. Any deploy that adds a locale has to touch every page already in the set — which is the strongest argument for generating the tags from a single source rather than editing templates per market.

Mistake 2: invalid language and region codes

The value is language or language-region: ISO 639-1 for the language, ISO 3166-1 alpha-2 for the region, separated by a hyphen. Four invalid values show up constantly:

  • en_US — an underscore is operating-system locale syntax. Hreflang uses a hyphen: en-US.
  • en-UK — the country code for the United Kingdom is GB, so en-GB. UK is not in the standard.
  • english or spanish — names are never valid, only codes.
  • US on its own — region-only values do not exist. Language is required, region is optional.

One more distinction worth internalising: en-CA does not mean "English for Canadians" in the abstract, it means "English, for users located in Canada". If your content is not genuinely country-specific — different currency, shipping, legal terms — use the bare language code and avoid splitting your equity across near-identical pages. Plenty of sites run en-US and en-GB variants that differ by three words and a spelling.

Mistake 3: no self-referencing tag

Each page must include an hreflang tag pointing to itself. It feels redundant, but it is part of the specification, and validators treat a set without self-references as incomplete. Template-generated tags get this for free; hand-written tags almost never do.

Mistake 4: no x-default

x-default declares the fallback for users no declared version matches — someone searching in Japanese on an English and Spanish site. It is optional, and leaving it out does not invalidate anything, but it hands the fallback decision to Google instead of making it yourself. Point it at your default version or at a language-selector page. Never point it at a narrow regional variant.

Mistake 5: hreflang fighting your canonicals

This is the most expensive one. If the Spanish page carries a canonical to the English page — a classic copy-the-template accident — you have told Google the Spanish page should not be indexed. A non-indexable URL cannot be a valid hreflang target, so the annotation has nothing to resolve to and the set collapses.

The rule is short: every language version is canonical to itself. Cross-canonicals belong to real duplicates, such as one product reachable through two paths, not to translations. If you are not sure what each version is currently emitting, read the live head of both with the meta tag analyser before changing anything. The same applies to noindex: a staging locale left with a noindex directive quietly takes the whole set down with it.

Mistake 6: relative or non-canonical URLs

The href must be an absolute URL including the protocol and host — /es/pricing is invalid. It must also be the exact canonical destination. The usual slips: pointing at http:// when the site redirects to HTTPS, mixing www and non-www hosts, trailing-slash inconsistencies, and campaign parameters left glued to the URL. Every redirect hop between the declared URL and the real one is a chance for validation to fail.

How Docuboxer implements it

This site serves Spanish at the root and English under /en, with reciprocal hreflang between them and x-default always pointing at the Spanish version, which is the site default. The interesting part is the blog, where the two languages deliberately do not share slugs. You are reading /en/blog/hreflang-mistakes-international-seo; its counterpart is /blog/hreflang-errores-comunes, because each is written against its own market's search intent rather than translated line by line.

That rules out the usual shortcut of assuming the same path with a language prefix. Instead each post declares its counterpart explicitly in a central registry, and the tags are generated from it. On this page that produces:

<link rel="alternate" hreflang="en"
      href="https://www.docuboxer.com/en/blog/hreflang-mistakes-international-seo" />
<link rel="alternate" hreflang="es"
      href="https://www.docuboxer.com/blog/hreflang-errores-comunes" />
<link rel="alternate" hreflang="x-default"
      href="https://www.docuboxer.com/blog/hreflang-errores-comunes" />

With one deliberate rule: when a post has no counterpart in the other language yet, we emit no hreflang at all — just its own canonical. An annotation pointing at a translation that does not exist is worse than no annotation; it is mistake number one, self-inflicted. Generating the tags from the same registry that feeds the XML sitemap is what keeps the two sources from drifting apart, and drift is where most reciprocity problems begin.

Auditing it without paid tools

Search Console no longer ships a dedicated international targeting report, so there is no dashboard that will tell you a return tag went missing. The manual check still works: open one page's source, collect every hreflang URL, visit each one, and confirm it returns the same set. With two or three locales this takes minutes and catches the overwhelming majority of real faults.

Add three checks while you are there. Each URL should return 200 with no redirect hop. None should be disallowed in robots.txt, because a blocked page cannot serve as an hreflang target. And the lang attribute on <html> should agree with what you declare — it does not replace hreflang, but a mismatch usually means the template is confused about which locale it is rendering.

Finally, an honest expectation: even with a perfect implementation, Google may still serve a different version than you intended. Hreflang is a strong signal, not a directive. What a correct setup buys you is the elimination of the cases where the wrong version shows because of your own markup — and that is most of them.

Frequently asked questions

Does hreflang improve rankings?

No. Hreflang does not pass authority or lift positions. It tells search engines which language or regional version to serve for a query you already rank for. The gain is indirect: users land on a page they can actually read, so bounce rate drops and conversion improves.

What is a return tag and why does a missing one break everything?

Hreflang annotations must be reciprocal: if page A points to page B, page B has to point back to A. That link back is the return tag. When it is missing, Google ignores the annotation for that pair, and nothing visibly breaks, which is exactly why the mistake survives for months.

Is en-UK a valid hreflang value?

No. The ISO 3166-1 alpha-2 code for the United Kingdom is GB, so the correct value is en-GB. Other frequent invalid values are locale-style codes with underscores such as en_US, language names like english, and region-only values like US, which are not allowed because the language part is mandatory.

Do I need x-default if I only have two languages?

It is optional, but useful even with two. x-default declares which version to show when none of the declared ones matches the user, for example a visitor searching in German on an English and Spanish site. Without it the search engine picks on its own, and you lose control of the fallback.

Should the English and Spanish versions share a canonical URL?

Never. Each language version must be self-canonical. Pointing the Spanish page's canonical at the English one tells Google not to index it, and a non-indexable page cannot be a valid hreflang target, so the whole annotation collapses. Cross-canonicals are for genuine duplicates, not translations.

Head tags, HTTP headers or XML sitemap: which should I use?

All three are equivalent to Google and you only need one. Head tags are simplest when a framework renders your pages, HTTP headers are the only option for non-HTML files such as PDFs, and sitemap annotations scale better across thousands of URLs. Mixing methods is the risky part, because two sources drift apart.

Generate your hreflang tags

Reciprocal sets with self-references and x-default, built in your browser. Free.

Open the hreflang generator →

Related tools

You might also like: free SEO tools that work without an account and what a URL slug is and how to choose one.