What Is Hreflang?
Hreflang is a link annotation that tells search engines which language or regional version of a page to serve to a given user. It is not a translation instruction.
Hreflang is a link annotation that tells search engines which language or regional version of a page to serve to a given user. It is not a translation instruction, and it is not a ranking input. It decides which of your existing versions gets shown; it never decides whether any of them deserve to be shown at all.
Why hreflang matters once you run more than one version
Without it, Google picks a version for you. Usually it picks one, indexes that, and treats the rest as near-identical alternatives worth little attention. Your Australian buyers land on the US page, see the wrong currency and the wrong shipping promise, and leave. The traffic looks fine in aggregate; the conversion rate quietly is not.
The second failure is slower. Three English versions of the same product page compete for the same queries, so the version that happens to win in one market is the one Google keeps surfacing everywhere. You cannot fix that with content, because the content is already correct. You fix it by telling Google who each version is for.
Scope this before you scope anything else. Multi-market implementation is engineering work priced by URL count, not a content task, so it pays to know what that work costs up front rather than after the templates are built.
How hreflang is implemented
- Map every equivalent page, one to one. Each URL needs a counterpart in every market you annotate. A page with no equivalent gets no annotation. Mapping a product page to a category page because the product is unavailable in that market breaks the cluster.
- Pick one delivery method and stay with it. Annotations can sit in the HTML head, in HTTP headers, or in the XML sitemap. Mixing methods across the same set of pages is how conflicting instructions get shipped without anyone noticing.
- Use valid codes. Language uses ISO 639-1 two-letter codes, and the optional region uses ISO 3166-1 Alpha 2. Language alone is valid. Region alone is not, which is why a value meant to target Austria has to be written as German-in-Austria rather than the country code by itself.
- Include a self-reference on every page. Each version lists itself alongside its alternates. Omit it and the set is incomplete, which is one of the two errors that make Google ignore the whole group.
- Make the return links reciprocal. If the UK page points to the German page, the German page must point back. Hreflang is confirmed from both ends, so a one-way declaration is treated as unconfirmed and dropped.
- Keep canonicals self-referencing. Every version must canonicalise to itself. Point the US page’s canonical at the UK page and you have told Google the US page should not be indexed, which cancels the annotation you just added, so it is worth being precise about what a canonical actually declares.
- Add x-default for everyone else. This is the fallback served to users whose language and region match nothing in your set. A global selector page or your primary market both work.
| Delivery method | Use it when |
|---|---|
| HTML head link elements | Small sets of pages, or templates you can edit directly |
| HTTP response headers | Non-HTML files such as PDFs, where there is no head to edit |
| XML sitemap entries | Large catalogues, where head bloat and template edits are the constraint |
The blunt version
Hreflang is not a ranking tool. It swaps which version shows; it does not make any of them rank higher. If your German page sits at position 30 in Germany, correct annotations move it to position 30 in Germany with the right URL displayed. That is the entire mechanism.
Which gives you a clean decision rule. Use hreflang when you already rank in a market and the wrong version is showing. Do not use it as the plan for entering a market where you rank nowhere, because there is nothing to swap. In that second case the work is links, local relevance, and content, and the annotations are just the plumbing you add afterwards.
The reason it gets oversold is that it is measurable work. It produces a spreadsheet, a validation report, and a satisfying drop in errors, none of which is the same as revenue. Where it genuinely earns money is conversion: the right currency, the right delivery times, the right legal copy in front of the right buyer. Say that out loud when you scope it, and judge the result on market-level conversion rather than rankings. It is also the first thing to break when you change platforms, because the new template rarely carries the old annotations across.
Example
Say a homewares retailer runs three English storefronts for Australia, the UK, and the US, with identical product copy and different pricing. Australian searchers keep landing on the US store, which quotes dollars and a two-week delivery estimate. Nothing is broken technically, and every page is indexed. Annotating the three versions reciprocally, with each page canonicalising to itself and an x-default pointing at the country selector, changes which URL appears for Australian queries. Rankings for those queries stay roughly where they were. Cart abandonment on Australian sessions falls, because the page finally quotes the right currency. That is what a correct implementation buys.
FAQ
Does hreflang fix duplicate content across country sites?
Not in the way people mean. Localised versions of the same page are not treated as spam, so there is nothing to be forgiven. What hreflang does is stop Google consolidating those versions into one and showing that single winner everywhere. It clarifies audience, not originality.
Do I need hreflang if my sites are in completely different languages?
It helps less than you would think. Google can usually tell Japanese from Portuguese without being told. The annotation earns its keep on same-language variants, where an Australian, British, and American page look near-identical to a crawler and only differ in currency, spelling, and shipping terms.
What breaks hreflang most often?
Missing return links and missing self-references, in that order. Both make Google discard the entire cluster rather than the single bad entry. After those, the common ones are relative URLs instead of absolute, invalid region-only codes, and canonicals pointing across versions instead of at themselves.
Related terms
- Canonical Tag — the directive that will silently cancel your annotations if it points at the wrong version.
- Product Variant URLs — the same one-to-one mapping discipline, applied inside a single market.
- Redirect Mapping — what you build when those country URLs move, and the annotations have to move with them.
If someone proposes hreflang as the fix for weak rankings in a new market, they are selling you a display setting as a growth plan. Rank first, then decide which version deserves the click.