1. What Hreflang Actually Does

If a site publishes the same page in English and Spanish at two different URLs, search engines have no built-in way to know those two pages are intentional alternates of each other rather than duplicate content or two unrelated pages that happen to be similar. Hreflang is the annotation that closes that gap. Google's own documentation on localized versions of a page describes it as a way to tell Google about these variations so that search results can link users to the version that matches their language and region, rather than showing everyone the same one.

The mechanism is a <link rel="alternate" hreflang="..." href="..." /> tag, one per alternate version, either placed in each page's <head>, declared in an HTTP header for non-HTML resources, or listed inside an XML sitemap. All three are equivalent from Google's perspective — the choice is about which is easiest to maintain on your specific site, not which one Google prefers.

It's worth being precise about what hreflang is not: Google has stated plainly that it does not use hreflang, or the HTML lang attribute, to detect what language a page is actually written in — that's determined algorithmically from the content itself. What hreflang controls is routing: which URL Google's results point a given searcher toward when multiple equivalent versions exist. Get it right, and a search in Madrid surfaces your /es/ page with a direct link a user can click to switch versions. Get it wrong, and you're relying on luck.

2. Why Hreflang Is All-or-Nothing

Most on-page SEO problems are forgiving in the sense that partial credit exists — a title tag that's slightly too long still communicates most of its value, a page missing a few internal links still ranks on the strength of everything else it has going for it. Hreflang doesn't work that way, and this is the single fact that explains most of the confusion around it. Semrush's breakdown of common hreflang errors is direct about the consequence: if the required conditions aren't met, search engines may ignore the hreflang annotations altogether — not degrade them, not apply them partially, ignore them, for every page in that language cluster, including the ones that were configured correctly.

That's a harsh failure mode for something that, on the surface, looks like it's working fine. The page loads. The content is correct. Nothing in a browser tells you anything is wrong. The only way most site owners discover a broken hreflang cluster is by noticing, months later, that the wrong language version keeps showing up in search results for the wrong country — by which point it's been quietly costing international traffic the entire time.

Hreflang tags are bidirectional by design. If your English page declares an alternate pointing at your Spanish page, the Spanish page is required to declare a matching alternate pointing back at the English page — and if there's a third language in the cluster, every page needs to reference every other page, including itself. Semrush calls this out as "Return Tag Errors" and describes it as one of the most common hreflang mistakes in practice, arising simply from a lack of cross-referencing between versions.

The scale of this quietly gets out of hand. A two-language page needs 2 tags per page, 4 total — manageable by hand. A three-language cluster needs 3 tags per page across 3 pages, 9 total. Add a fourth language and it's 4 tags across 4 pages, 16 total. The relationship is quadratic, not linear, and every one of those tags has to stay correct and synchronized as pages get edited, renamed, or migrated over time — often by different people, on different schedules, sometimes in different departments entirely if the localized versions are managed by regional marketing teams. A single missed return link anywhere in that set is enough to break reciprocity for the whole cluster.

This is precisely the failure mode our own Hreflang Tag Generator is built to eliminate at the source: because every page's output block is built from the exact same shared list of language/URL pairs, every block automatically includes every other page — reciprocity isn't something you have to remember to do correctly, it's a property of how the tags are generated.

Generate fully reciprocal tags with the Hreflang Tag Generator

Add your language/region pages once, and get a complete, self-referencing, fully reciprocal hreflang set for every version — plus a checker for hreflang you already have live.

Generate My Tags →

4. Mistake 2: No Self-Referencing Tag

Closely related to the return-link problem, and just as damaging on its own: every page in a hreflang cluster is required to list itself as one of its own alternates, in addition to listing every other version. It's an easy detail to skip because it feels redundant — why would a page need to link to itself? — but Semrush's guidance is explicit that skipping it can cause search engines to ignore the hreflang tags entirely for that page. A page that correctly references three sibling languages but omits itself is not "mostly right"; per the same rule that governs return links, it's broken.

5. Mistake 3: Wrong Language and Region Codes

The language portion of a hreflang value has to be a valid two-letter ISO 639-1 code — en, es, de — and the optional region portion has to be a valid ISO 3166-1 Alpha-2 country code, joined to the language with a hyphen, never an underscore. A region code can never appear without a language code in front of it — there's no such thing as targeting "just the US" independent of a language.

In practice, the errors that show up most are typos that go unnoticed for a long time (eng instead of en), underscores where hyphens belong, and — a specific one worth calling out — confusing a language code with a country code where they happen to look similar, such as treating uk as the code for "United Kingdom English" when the correct value is en-GB (the ISO country code for the United Kingdom is GB, not UK). None of these throw a visible error anywhere — a malformed code just quietly fails to match what Google expects.

6. Mistake 4: Canonical Tags That Fight the Hreflang Set

Each localized version of a page should carry its own self-referencing canonical tag — the Spanish page's canonical should point at the Spanish URL, not the English one. A mistake Semrush flags specifically is pointing every language version's canonical at one "main" version, often the original language the site launched in. Doing that tells Google the other versions aren't really separate pages worth indexing on their own, which directly contradicts what the hreflang annotations are claiming, and undermines the entire setup even when every hreflang tag is otherwise perfect.

7. Mistake 5: Relative URLs

Hreflang href values need to be complete, absolute URLs, including the protocol — https://example.com/es/pagina, not /es/pagina. This is easy to get wrong when hreflang tags are generated by a templating system that otherwise handles internal links as relative paths by convention — the template author has to remember that this one attribute is an exception to the site's normal linking pattern.

8. Mistake 6: Hreflang Pointing at Blocked or Broken Pages

A hreflang tag that points at a URL blocked by robots.txt, set to noindex, or returning a 404 creates a problem that's easy to miss because the mistake lives on a different page than the one you're looking at. If a crawler can't access the target page, it can't read that page's return link back to the original — which means the entire reciprocal relationship breaks, for every page pointing at that blocked URL, not just the blocked one. This is a common side effect of staging environments accidentally left in robots.txt, or a language version that was quietly deprecated without also removing it from every other page's hreflang set.

Worth knowing Google's guidance also notes that hreflang and the HTML lang attribute serve different purposes and Google does not use either to determine the actual language of a page's content — that's inferred algorithmically. Hreflang controls which version search results point users toward; it doesn't describe what language the page is written in for indexing purposes.

9. Mistake 7: Missing or Wrong x-default

The special value x-default tells Google which version to show a visitor whose language or region doesn't match any of the versions you've explicitly listed — a visitor in Brazil hitting a site that only has English and Spanish versions, for example. Skip it, and Google decides on its own which version that visitor sees, with no input from you. It's optional in the sense that hreflang will still function without it, but any site with more than one or two language versions benefits from explicitly controlling that fallback rather than leaving it to an algorithm.

10. How to Generate a Correct Set From Scratch

Open the free Hreflang Tag Generator and add one row per language or region version of the page — its code and its full, absolute URL. Because the tool builds every page's output block from that same shared list, reciprocity and self-reference happen automatically: every block includes every URL in the set, including its own. Turn on the x-default option and pick which version should serve as the fallback if you want that control (recommended for most sites with three or more versions).

The tool then gives you a per-page view — select any URL from the dropdown to see exactly the block that page needs — plus a combined reference copy labeling every block by page, and a downloadable version of both. Paste the matching block into each page's own <head>; every page gets a block with the same content but framed from a different self-reference.

11. How to Check an Implementation You Already Have

If hreflang is already live on your site and you're not confident it's correct, the generator page also includes a reciprocity checker built specifically for the failure mode covered in this guide. Paste the <head> source — or just the relevant <link> tags — for each language version, and it checks, across every page you provide: whether each page references itself, whether every outbound reference has a matching link back, whether any code is malformed, whether any href is relative instead of absolute, and whether the same destination URL gets claimed by two conflicting language codes.

Be aware of one real limitation, stated plainly rather than glossed over: the checker can only verify reciprocity between the pages you actually paste in. If a site has ten language versions and only three get pasted, the tool will correctly report that those three look fine to each other without being able to confirm the other seven. For a full-site audit rather than a spot-check, a crawler built for the job — Screaming Frog's hreflang audit is a widely used option — will catch issues across an entire domain in one pass.

12. Head Tags vs. Sitemap-Based Hreflang

Per-page <link> tags in the <head> are the most common implementation, but Google treats a sitemap-based declaration as equally valid — each <url> entry in an XML sitemap can carry its own set of xhtml:link alternates instead of the page needing to declare them itself. This is genuinely useful for large sites where editing every page template is impractical, or for content types like PDFs where there's no <head> to edit at all — the generator's sitemap output covers exactly this case. The one rule that matters: pick one method per URL and stick to it. Declaring hreflang both in the page head and in the sitemap for the same URL, with any discrepancy between the two, adds ambiguity rather than redundancy.

13. Quick Answers

Does a small hreflang mistake really break the whole set? For the two most common mistakes — a missing return link or a missing self-reference — yes. Google's documented behavior is to disregard the annotations for the affected cluster rather than apply them partially.

Do I need hreflang if my site has one language but multiple country versions (like en-US and en-GB)? Yes. Hreflang isn't only about language — it also resolves regional targeting within the same language, which is exactly the en-US vs. en-GB case.

Can I use hreflang without x-default? Yes, it's optional. Without it, Google chooses which version to show visitors who don't match any listed language/region on its own, rather than following your preference.

Does hreflang help rankings directly? Not in the sense of a ranking boost. It's a routing signal that determines which of your already-ranking pages gets shown to which searcher — its business value is preventing the wrong-language version from surfacing to the wrong audience, and avoiding duplicate-content confusion between versions.

Is sitemap-based hreflang worse than head tags? No — Google treats the three implementation methods (head tags, HTTP headers, and sitemap entries) as equivalent. Pick whichever is easiest to maintain reliably on your platform.