Skip to content
Get your free SEO report→
Back to blogTechnical

hreflang 101: The Hreflang Tag Without Tears

hreflang is the most mis-implemented tag in international SEO. Learn the three rules, the mistakes that silently break it, and a validation loop that holds.

Piyush Rathod avatarPiyush Rathod11 min readUpdated October 8, 2026
Share:
On this page

hreflang is the most under-tested, most-mis-implemented tag in international SEO. Here’s how to get it right. At its core it is a routing instruction: hreflang tells Google which version of a page to show users based on language and region. Every other sentence in this post exists because that one simple idea breaks in five predictable ways — and because almost nobody validates it after launch.

This is the practical version of the tag: the format, the three rules that make a set valid, where to implement it, the mistakes that silently cancel each other out, and the validation loop that catches the rest before they cost a market its traffic.

Key takeaways

  • hreflang routes, it does not rank. It selects which URL Google shows which audience; it grants no ranking benefit on its own.
  • Three rules make a set valid: return tags, self-reference, and an x-default for unmatched users. Break one and the whole set can be discarded.
  • Missing return tags are Google’s most common hreflang error — the page you point to must point back.
  • Implementation has three homes: HTML link tags, HTTP headers for non-HTML files, and XML sitemaps for the largest sites.
  • hreflang and canonical must agree. A hreflang page that canonicalizes to a different target teaches Google two contradictory lessons, and it believes the canonical.
  • Validate before launch and after every CMS template change — the tag that shipped correctly can rot silently.

What hreflang actually does

hreflang tells Google which version of a page to show users based on language and region. Format: ISO 639-1 for language, ISO 3166-1 Alpha-2 for region. That gives you values like en for English anywhere, en-GB for British English, es-MX for Spanish in Mexico. Region is optional; language alone is a complete value — but the reverse is not true, which matters in the mistakes section.

What hreflang does not do: translate anything, force a redirect, or improve rankings. It is a hint to Google’s index about equivalence — “these URLs are the same page for different audiences.” Google uses it to route searchers to the right version and to stop treating your French and English pages as duplicates of each other. Between the hint and the outcome sits the same filtering machinery that decides all canonical selection, which is why the details in this post are about consistency, not syntax.

Do you need hreflang at all?

Only when equivalent content genuinely exists for different languages or regions. One language, one audience: hreflang is noise. English page for the UK and an English page for Australia with different prices or shipping copy: hreflang is the mechanism that keeps them out of each other’s way. Auto-translated machine pages with no editorial owner: hreflang will not make Google rank them, and it should not.

The decision table is short. Same page, different language → hreflang it. Same language, meaningfully different regional content → hreflang with region codes. Same product at different prices via a cookie-driven switcher that never changes the URL → fix the URL structure first; hreflang cannot point at states Google cannot crawl. And if your “international” site is one domain with no localized content worth indexing, the honest answer is to skip the tag and save the maintenance.

The three rules every hreflang set must obey

A hreflang set is the complete mutual declaration across all equivalent pages. It is valid only when three rules hold at once.

Rule 1: Return tags

If page A hreflangs to B and C, then B and C must hreflang back to A (and to each other). This bidirectional completeness is the rule sites break most: forgetting return tags is Google’s most common hreflang error, and the consequence is not partial — an incomplete set can be ignored entirely, sending all versions back to being interpreted as plain duplicates. One-way pointers are the tag equivalent of a phone that can call but never receive.

Rule 2: Self-reference

Each page must list itself in its hreflang set. It feels redundant — the page already knows what it is — but self-reference is what makes the set symmetric and machine-checkable. A page that declares three cousins and omits itself is, by definition, an incomplete set, and rule 1 catches it on the cousins’ side too.

Rule 3: x-default

Specify the catch-all variant for users who don’t match any language or region. In practice that is your language switcher, your global English page, or your currency picker — whichever URL you would want a shopper from an unlisted market to land on. The x-default participates in the set like any other URL: everything must hreflang to it, and it must hreflang back to everything.

Where to implement hreflang

Three options, in ascending order of maintainability:

  • HTML link tags in the <head> of each page. Most common, easiest to eyeball, worst at scale — a twelve-language site needs eleven tags plus self plus x-default on every page of every template, hand-synced.
  • HTTP headers (for non-HTML, like PDFs). Binary files cannot carry a head section, so the declaration rides in the response. Same rules, different plumbing.
  • XML sitemap (largest sites — most maintainable). The whole set lives in one generated file instead of N pages; a template bug cannot silently split it. If your sitemap ships URLs that disagree with live pages, though, the machinery fails the same way — which is why the sitemap feeding hreflang is the one you should run through our Sitemap Validator before launch.

Choose by template count, not by taste. Five pages: HTML tags. Five thousand: sitemap. PDFs and images-as-documents: headers, because they have no choice.

hreflang and canonical: signals that must not collide

The set can be perfectly bidirectional and still fail, because hreflang does not live alone — it lives inside the same duplicate-handling system as canonical. Google reads your canonical tag as the primary statement of equivalence; hreflang refines it for audience routing. When they disagree — hreflang says “these pages are the same, serve by market,” canonical says “these pages point somewhere else entirely” — the mixed signal usually costs the whole set its trust.

The working rule: every URL in a hreflang set should be the canonical version of its own content for its audience, should not be blocked in robots.txt, and should return a 200. Redirected or canonicalized-away hreflang targets are the technical equivalent of routing to a demolished building; the redirect-hygiene checklist in our redirect chains audit doubles as the underlying prerequisite. The deeper mechanics of when Google simply overrides both tags sit in duplicate content penalties, and the single most common self-inflicted version of this collision is its own post: canonical tag mistakes.

The five mistakes that break hreflang silently

Syntax is the easy part. These are the failures that ship with green checkmarks and dead routing.

1. Using en-UK instead of en-GB

The ISO 3166-1 Alpha-2 code for the United Kingdom is GB, not UK. en-UK is invalid — Google’s own documentation calls it out because it is what everyone types. Same trap: cn for Canada (that is China) and pt-PT-style assumptions wherever the language abbreviation collides with a country abbreviation. When in doubt, check the ISO list, not your muscle memory.

2. Forgetting return tags

As above — Google’s most common hreflang error. If B and C do not point back to A and each other, the set is incomplete and may be ignored entirely. Build sets as data, render them from one source, and never hand-edit one side of a reciprocal pair.

3. hreflang-ing only at the URL level but not the homepage

Product pages and articles get the full treatment while the homepage — the most-linked, most-visited page in every market — points nowhere. A set missing its entry page leaves Google to treat the entry pages as their own duplicate cluster, which is exactly the situation the tag exists to prevent.

4. hreflang-ing pages that canonical to different targets

A hreflang URL whose canonical tag points somewhere else contradicts itself: you are claiming equivalence while telling Google the page is a copy of something outside the set. Keep hreflang targets canonical-to-themselves, or canonical within the same set, always.

5. Region-only without language: hreflang="FR" is invalid

Region codes require a language prefix. A bare regional value leaves Google with an incomplete instruction — and note the trap in hreflang="FR": it looks like “France,” but a two-letter value is parsed as a language code, so what you wrote as a region reads as French, and what you meant as French needed a region partner. Language is the mandatory half; region is the optional refinement.

The validation workflow

Validation is not optional, because the tag fails silently — a broken set looks identical to a working one in Search Console until the international traffic tells you otherwise. The loop: use hreflang Tags Testing Tool by Merkle or Search Console’s International Targeting report. Validate before launch. Re-validate after every CMS template change.

Concretely: the Merkle-style checker parses reciprocal correctness across a URL list in minutes and catches the return-tag and en-UK family of errors mechanically; Search Console’s International Targeting report catches the same classes but only after Google has crawled and complained — a lag measured in weeks, which is why it is the monitor, not the gate. The audit-grade pass adds one more step: for each URL in the set, confirm HTTP 200, confirm the canonical agrees, and confirm the page is not blocked. Then automate the re-run; a CMS theme update has ended more hreflang implementations than any algorithm change. The International Targeting panel itself is one of the reports covered in our hidden Search Console reports breakdown — most teams never look at it until traffic is gone.

How to measure whether hreflang is working

The tag earns no rankings, so measure routing, not positions:

  1. In Search Console, filter Performance by country for each market and compare impressions and CTR before and after implementation. Working hreflang shows up as the right country getting the right URLs.
  2. Spot-check the SERPs: search your money keywords from each target market. If the wrong-language version ranks there, the set is broken in that pair — inspect it directly.
  3. Watch the International Targeting report for annotations after every template deploy; the error count is your regression metric.
  4. For multi-language sites where the versions share one domain, check crawl logs for Googlebot hits per locale — the frequency pattern reveals which versions Google actually treats as indexable, before any traffic report has the courage to say so.

Frequently asked questions

Does hreflang affect rankings?

No. It affects which URL of your set Google shows to which audience and prevents your own versions from competing as duplicates. Positions come from relevance and authority; hreflang only decides who gets to earn them for a given searcher.

Is hreflang=“en” the same as hreflang=“en-US”?

No. en targets all English speakers regardless of country; en-US targets the United States specifically. A page can serve both roles — declare one value per URL. Using the generic code for your primary English page and region codes for localized variants is the standard pattern.

Can I put hreflang only in the sitemap instead of the HTML?

Yes — sitemap implementation is fully equivalent as long as it is complete and reciprocal, and it is the recommended choice for large sites because it keeps the whole set in one generated artifact. Mixing HTML tags and sitemap entries for the same cluster is where contradictions creep in; pick one home per site.

How long does hreflang take to work?

Expect Googlebot to pick up the tags on the next recrawl — days for frequently crawled pages — and routing to stabilize over a few weeks. If a locale is still misrouted after that window, the set is broken, not slow: run the validation workflow rather than waiting.

Does hreflang work for subdomains and ccTLDs?

Yes. The mechanism is language and region codes, not URL shape. Subfolders, subdomains, and ccTLDs all support the same three rules — which also means all three can fail them identically; a ccTLD is not an excuse to skip the tags.

Bottom line

hreflang is a routing instruction with three non-negotiable rules: complete return tags, self-reference, and an x-default for everyone you did not plan for. Every horror story in international SEO is one of those three breaking quietly — an en-UK, a homepage nobody tagged, a canonical pointing outside the set — and every one of them is caught by validating before launch and after every template change. Build the sets from one data source, keep the targets canonical and crawlable, and measure routing by country instead of hoping.

Start with a mechanical pass: run the Merkle checker on your top ten pages per market today, wire the same check into your deploy process, and if the International Targeting report lights up after a template change, fix the set before the next market launch — that report is the error log; the validation loop above is the prevention.

Run the 45-Point SEO Analyzer

Run 45-Point SEO Analyzer on your site — instant score. No signup, no server calls.

Stay updated on SEO changes

We send out a quarterly digest of search volatility and algorithm updates. No spam, ever.

Enter your email to subscribe to the quarterly SEO digest

Know someone who'd find this useful?

FAQ

Frequently asked questions

The questions readers ask before they put the playbook to work.

No. It affects which URL of your set Google shows to which audience and prevents your own versions from competing as duplicates. Positions come from relevance and authority; hreflang only decides who gets to earn them for a given searcher.
No. en targets all English speakers regardless of country; en-US targets the United States specifically. A page can serve both roles - declare one value per URL. Using the generic code for your primary English page and region codes for localized variants is the standard pattern.
Yes - sitemap implementation is fully equivalent as long as it is complete and reciprocal, and it is the recommended choice for large sites because it keeps the whole set in one generated artifact. Mixing HTML tags and sitemap entries for the same cluster is where contradictions creep in; pick one home per site.
Expect Googlebot to pick up the tags on the next recrawl - days for frequently crawled pages - and routing to stabilize over a few weeks. If a locale is still misrouted after that window, the set is broken, not slow: run the validation workflow rather than waiting.
Yes. The mechanism is language and region codes, not URL shape. Subfolders, subdomains, and ccTLDs all support the same three rules - which also means all three can fail them identically; a ccTLD is not an excuse to skip the tags.