Hreflang tags on a multilingual landing page: what they do, how to set them up

Published on 23 August 2026 · 8 min read

A landing page that works in English usually ends up existing in French too, sometimes in Spanish. Three URLs, the same structure, the same offer — only the language changes. To a search engine crawling all three, these are very similar documents, and it has to decide which one to index and, more importantly, which one to show to which user. That's what hreflang tags are for: declaring that these URLs are equivalent versions of the same content, aimed at different languages or countries. Set up correctly, they keep a Belgian prospect from landing on the US version with prices in dollars. Set up incorrectly, they're ignored.

What hreflang tells Google — and what it doesn't

An annotation looks like <link rel="alternate" hreflang="fr" href="https://example.com/fr/offre">: it declares a correspondence between two URLs and states the language audience of the page it points to. Google uses it to decide which version to display in results, based on the user's presumed language and location. It's a routing signal, not a visibility lever: it won't move a page up, it only determines which of the already-ranking versions gets served.

It isn't a redirect. A visitor who lands directly on the Spanish URL stays there. Redirecting by IP address is a separate mechanism, and often a counterproductive one, since it can stop crawlers from reaching the other versions.
It isn't a ranking signal. The fundamentals of getting a landing page to rank on Google still have to be handled, version by version.
It isn't a substitute for the canonical tag. Canonical says "which URL to index," hreflang says "which version to serve to whom." The two coexist.
It isn't a guarantee of indexing. Indexing delays apply to each version independently.
It isn't an answer to duplicate content within one language. Pages cloned city by city in English belong to multi-city local SEO: the language is identical, the search intent is different.

The reciprocity rule, the one that breaks everything

This is the strictest requirement, and the one most often overlooked: annotations must be reciprocal. If the English page declares the French version, the French page must declare the English version back. Every version also has to declare itself: all of them list exactly the same set of URLs, including their own. An annotation that isn't confirmed by the target page is treated as unreliable and dropped, sometimes for the entire group. In practice that rules out writing tags by hand page by page: the only maintainable approach is to describe the correspondences in a single source and generate the annotations from it.

Language codes, region codes and x-default

The value always starts with a two-letter language code (ISO 639-1), optionally followed by a two-letter region code (ISO 3166-1 alpha-2). en targets all English speakers, en-CA only those located in Canada. The classic mistake is writing a country code on its own while thinking of a market: hreflang="ca" doesn't mean Canada, it means Catalan, and hreflang="uk" means Ukrainian — the code for the United Kingdom is GB. A value made up of a region alone is never valid.

What each hreflang value actually declares
Value	Audience targeted	Trap to know about
`en`	All English speakers	Enough as long as there is one English version
`en-CA`	English speakers in Canada	Only makes sense if a generic `en` version exists too
`en-GB`	English speakers in the United Kingdom	The country code is `GB`, not `UK`
`ca`	Catalan speakers	Wrongly read as Canada, which is written `en-CA`
`x-default`	Cases not covered elsewhere	Should target a generic page, not the English version

The x-default value designates the page to serve when no version matches: a language selector, or the international reference version. It isn't mandatory, but it becomes useful as soon as the number of markets you reach exceeds the number of versions you publish. Without it, an Italian visitor facing a site available in English and French gets routed purely on Google's own judgment.

Three possible locations, one sensible choice on a static site

Annotations can be declared in three places, and one is enough: stacking them adds nothing and multiplies the chances of inconsistency.

<link> tags in the <head>. The most readable option: annotations are visible in each page's source and easy to check. The only cost is HTML weight, marginal as long as the number of versions stays reasonable. This is the default choice on a static site.
Link HTTP headers. The only way to annotate a non-HTML document, a PDF for instance. On a regular landing page this adds nothing and forces you to configure the server.
An XML sitemap. It centralizes the correspondences and keeps the HTML light, which becomes attractive past a few dozen versions. The trade-off is that the signal is no longer visible in the page and depends on the sitemap being crawled.

In a Next.js project, these alternates are declared at the metadata level of each route: the metadata object exposes an alternates.languages field that maps a language code to the matching URL, and the framework renders the tags in the <head>. As with the canonical, it's better to build those absolute URLs from the site's environment variable than to hardcode them.

Hreflang and canonical: two signals that must stay consistent

The rule fits in one sentence: every version carries a self-referencing canonical pointing to its own URL, never to another language's. A cross-language canonical tells Google "don't index this page, index that one instead": the version in question drops out of the index and the hreflang set collapses. A corollary: the URLs listed must be the canonical URLs, not variants with tracking parameters or addresses that redirect. Worth checking after a redesign that changes URLs.

The case of paid landing pages split by country

There's a very common setup in paid acquisition: the same page, in the same language, duplicated per country because the currency, the tax treatment or the legal notices differ. An en-US page, an en-GB page, an en-AU page where most of the copy is identical. This is the scenario region codes were designed for: hreflang keeps all three pages indexable and serves the right one based on location, where canonical alone would force you to sacrifice two. Two habits go with it: check that the difference really warrants separate URLs — showing prices in the local currency can sometimes be handled dynamically on a single page — and make sure internal linking stays coherent, with each version linking to pages in its own language.

That said, technical routing says nothing about the quality of the version being served. In a study published in 2003 in Electronic Commerce Research and Applications, Mathew Hillier draws on work in anthropology and systems design to show that there is a relationship between language, cultural context and the usability of a multilingual commercial website: how a visitor perceives and approaches an interface depends on their cultural context, not just on the words being translated (Hillier, 2003). Serving the right version to the right person is therefore only worth something if that version was genuinely adapted — arguments, proof, price formats — and not merely translated.

The mistakes that void the whole setup

Non-reciprocal annotations. The number one cause: a version left out of the URL set, or a page added without updating the others.
A declared URL that doesn't return 200. An address returning 404, redirecting, or carrying noindex makes the group inconsistent — the signal gets abandoned.
Relative URLs. Annotations expect absolute URLs, protocol and domain included.
Sloppy language/region mixing. A country code used alone, uk instead of en-GB, or a region declared with no generic version for that language.
A machine-translated version published without review. Translating a landing page for international markets is a decision to make before the technical layer, not after.
A set frozen in time. Adding a language or changing a URL path means revisiting every version in the group.

Hreflang tags are plumbing: barely visible, with no effect on rankings, but they prevent the scenario where a prospect lands on the wrong version of a page they found by searching in their own language. The 10 LanderKit templates (€89 each, €229 for the full pack) are standard Next.js projects: language alternates are configured in each route's metadata, in the same place as the canonical.

FAQ

Frequently asked questions

Do I need hreflang tags if my site only exists in one language?

No, they serve no purpose in that case. Hreflang annotations only describe a correspondence between several versions of the same content. On a monolingual site, a self-referencing canonical tag on each page is enough.

Do I need hreflang if the versions live on different domains?

Yes, and it's an expected case: annotations work across subdomains, subdirectories or separate country domains. The constraint is unchanged — reciprocity must hold from one domain to the next, with every version declaring the complete set of URLs, its own included.

What happens if I skip x-default?

Nothing breaks: the annotations stay valid and Google keeps routing visitors for the declared languages. But for a user whose language matches none of your versions, the search engine picks the page to display on its own. Declaring x-default is how you take that decision back.

How do I check that my annotations are actually being used?

The international targeting report in Search Console flags annotations with no return link and invalid language codes; that's the most reliable starting point. Beyond that, inspecting each version's source confirms that the declared URL set is identical from one page to the next. The official documentation in force remains the reference on accepted values.