How to Implement Hreflang Tags Correctly
Hreflang tells search engines which language or country version of a page to show; how to add it, in the head or a sitemap, with a worked example.
Hreflang is an HTML attribute that tells search engines which language or country version of a page to show a given searcher, written as rel="alternate" hreflang="x" links between every version of that page, each one pointing at all the others plus itself.
That routing only matters once there is more than one version of a page to route between, which is the wider question multilingual SEO answers; this post covers the one tag that makes the routing actually work.
On this page
How does a hreflang tag actually work?
Each language or country version of a page carries a set of link tags pointing to every version, itself included, using a language code (en, ar, fr) optionally followed by a region code (en-US, en-GB, ar-SA). A search engine crawls any one page in the set, reads the whole list, and now knows every equivalent it can offer a matching searcher.
The codes come from two established standards: ISO 639-1 for language, ISO 3166-1 Alpha-2 for region [1]. Getting the code right matters more than it looks — en-UK is not a valid region code (the correct one is en-GB), and a typo like that silently drops that version from the set rather than throwing a visible error.
The order the codes go in also matters. Language comes first, region second, joined by a hyphen: fr-ca for French as spoken in Canada, not ca-fr. Reversing the two does not produce an error either — the tag simply describes a language and country pairing that nothing on your site actually matches, so the row sits in your sitemap or head doing nothing while looking correct at a glance.
It helps to think of hreflang as a many-to-many map rather than a single link. A three-market page is not "the English page with two translations attached" — it is three equal pages that each name the other two plus themselves, with no one version privileged as the source. That is also why a partial rollout, where only two of three markets carry the tags, produces an asymmetric set: the two tagged pages will name a third page that never names them back, which is the return-tag problem covered further down.
List every version, including the one you're on
A four-market page needs four hreflang links on each of its four versions: three alternates plus one link back to itself. Sixteen link tags in total, four per page.
Use absolute URLs
Relative paths are a common cause of tags that validate visually but fail to resolve. Every href should be the full https:// address.
Add x-default
One extra tag, `hreflang="x-default"`, names the page to show a visitor who matches nothing on your list — usually your global or English homepage.
Match tags to canonical
A page's canonical tag and its place in the hreflang set should agree. A page that canonicalizes to a different URL than the one hreflang is claiming for it sends a contradictory signal.
Where do the tags actually go: head, header, or sitemap?
Any of three places, and Google treats them as equivalent once implemented correctly [1]. Most sites use the HTML <link> method because it is the easiest to audit page by page; large sites often move to a sitemap because one file can hold thousands of relationships without bloating every page's HTML.
| Method | Best for | Trade-off |
|---|---|---|
| `<link>` tags in `<head>` | Small to mid-size sites, a handful of markets | Adds weight to every page's head; easy to spot-check with view-source |
| HTTP header | Non-HTML files: PDFs, other downloadable documents | Invisible in the page source; needs server config access |
| XML sitemap | Large sites, many market combinations | One file to maintain centrally; errors are less visible per page |
A sitemap entry lists the URL once and nests an xhtml:link line for every alternate version underneath it, repeated once per URL in the set — the same fifteen relationships as the <link> method, just stored in one file instead of scattered across fifteen page heads. It is filed the same way any other sitemap is, through Build and submit a sitemap [2].
What does a correct hreflang set actually look like?
Three markets sharing one product page — English (global default), English (United Kingdom), and French (France) — need this on every one of the three pages:
<link rel="alternate" hreflang="en" href="https://example.com/product" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/product" />
<link rel="alternate" hreflang="fr-fr" href="https://example.com/fr-fr/product" />
<link rel="alternate" hreflang="x-default" href="https://example.com/product" />
Notice the self-reference: the English global page lists itself as hreflang="en" alongside the other two, and each of the other two pages carries the identical four lines, adjusted only for which one is now "self." That symmetry is the part that is easiest to get wrong by hand and easiest to verify with a hreflang testing tool [3], which flags a missing return link immediately.
What breaks hreflang most often?
Four mistakes account for most of the errors Search Console reports, and all four are silent: nothing crashes, the page still loads, and the only symptom is the wrong country seeing the wrong version.
Missing return tags
Page A lists Page B, but Page B never lists Page A back. Google requires the relationship to be confirmed from both sides, or it ignores the link entirely.
Wrong or invalid codes
A region code that isn't real ISO 3166-1, or a language code used where a region code was meant, drops that version silently rather than erroring loudly.
Noindex on one version
A page with a noindex tag can't be reliably swapped in as a hreflang target — the two signals contradict each other and noindex generally wins.
Relative or inconsistent URLs
Mixing http and https, or www and non-www, across the tag set creates versions that look distinct to a crawler even when they're the same page to a human.
Do you actually need x-default?
Not strictly, but leave it out and you are betting that every real visitor matches one of your listed languages and countries exactly. x-default is the page shown to everyone else — a Portuguese visitor on a site with only English and French versions, for instance.
Most sites point x-default at their global English page or a language-selector page. The country versus region site-structure decision affects which one makes sense for you, because a business running fully separate country sites often wants a neutral selector page here rather than defaulting quietly into one market.
Skipping x-default is not an error Search Console flags, which is exactly why it gets left out of real implementations more often than any other part of the tag set.
There is one case where x-default earns its keep even on a small site: a paywall, login screen, or region-blocked page that some visitors cannot reach at all. Pointing x-default at whichever version is actually open to the widest audience keeps a search engine from routing someone into a wall they cannot get past, which is a worse outcome than routing them to a slightly mismatched language.
How do you know it's actually working?
Two checks, both free. First, Google Search Central's international targeting report inside Search Console surfaces hreflang errors directly — missing return tags, invalid codes, and conflicting canonicals all show up there [1]. Second, search the exact same query from two locations (a VPN is enough for a spot check) and confirm the right version actually appears.
Neither check is instant. Give a fresh implementation one to two crawl cycles before treating a mismatch as a real failure rather than a page that simply has not been re-crawled yet.
A third, slower check is worth adding once the first two look clean: watch organic traffic to each country or language segment in your analytics for a genuine shift, not just a technical pass. A hreflang set with zero errors and unchanged traffic per market usually means the tags are correct but something upstream — thin content, missing internal links, or a market with too little search demand to move — is doing the real damage instead.
If keyword targeting across those same markets still needs work once the routing is solid, international keyword research is the next piece — hreflang only routes a visitor correctly once you know which query belongs on which page in the first place. For everything platform plugins get right and wrong about generating these tags automatically, Weglot versus WPML compares the two most common ways WordPress sites handle it.
If the audit above turns up structural questions rather than tag-level ones, that is usually a sign the technical SEO service conversation is the more useful next step than another round of manual fixes.
Questions people also ask
Does hreflang help a page rank higher?
No. It is a routing signal, not a ranking factor. It tells search engines which version of a page to show a given searcher; it does nothing for how well that version ranks against competing pages.
Do I need hreflang if I only have one language?
No. Hreflang exists to choose between two or more equivalent versions of the same page. A single-language, single-country site has nothing to route between, so it adds tags that do nothing.
Can I put hreflang tags in the page head and the sitemap at the same time?
You can, but pick one as the source of truth. Google reads whichever it finds, and the two methods contradicting each other (one listing a page the other omits) is a common cause of hreflang errors in Search Console.
Does every page need a self-referencing hreflang tag?
Yes. Each page in a set must list itself, at the same country and language code it lists elsewhere, alongside every alternate version. Leaving a page out of its own set is one of the most common hreflang mistakes.
How long does it take Google to pick up new hreflang tags?
Once the pages are crawled and the tags are error-free, days to a couple of weeks for the routing to visibly change in search results, similar to any other crawlable signal.
Sources
- Tell Google about localized versions of your page — Google Search Central (checked 23 September 2026)
- Build and submit a sitemap — Google Search Central (checked 23 September 2026)
- Hreflang Tags Testing Tool — technicalseo.com (checked 23 September 2026)
Get your hreflang set audited before it costs you a market
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.
Who wrote this
Ibrahem HelalCo-founder
Leads strategy and delivery.
Works on: SEO, GEO
Reviewed before publishing by Jeremy Zava, Co-founder.
- Multilingual SEO: a complete guide for 2026How multilingual SEO works: URL structure, hreflang, translation, keyword research and redirects, with what each decision costs and how to check it is working.
- International Keyword Research: How to Do ItTranslating your keyword list is not international keyword research. Here is how to build one per market, including markets with thin volume data.
- Single global site vs. country sitesOne global site works when pricing, legal terms and fulfillment don't change by market. Country sites earn their cost only once those genuinely differ.
- Weglot vs WPML: which is better for SEO?Weglot is a translation proxy that works with any site; WPML is a WordPress plugin storing each language as native content. How they compare on cost and SEO.