hreflang tells a search engine “this page exists in these languages, serve the right one.” It fails silently: nothing breaks, your pages just quietly never surface in their language.

Three things are worth getting straight before the rules, because most guides get them wrong.

It is not a ranking factor. Google’s documentation frames hreflang as a way to “point users to the most appropriate version of your page.” It swaps the URL that already ranks for the locale-appropriate one. It does not promote anything. John Mueller has said so repeatedly. Geotargeting promotes; hreflang swaps.

It does not declare your page’s language. Google is explicit: “Google doesn’t use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language.” hreflang says these pages are variants of each other, nothing more.

Search Console will not tell you when it breaks. More on that below, because it is the single most out-of-date thing in every hreflang article written before 2023.

The three methods, and why you should pick one

Google supports exactly three ways to declare alternates, and states they are “equivalent from Google’s perspective.” Crucially: “While you can use all three methods at the same time, there’s no benefit in Search” and it “may be much harder to manage three implementations instead of just picking one.”

HTML link elements in the <head>. The practical choice for a Framer site.

<link rel="alternate" hreflang="en" href="https://yoursite.com/en/about/" />
<link rel="alternate" hreflang="fr" href="https://yoursite.com/fr/about/" />
<link rel="alternate" hreflang="x-default" href="https://yoursite.com/en/about/" />

The tags must sit inside a well-formed <head>, and Google warns against combining hreflang with other attributes like media in a single tag.

An HTTP Link: header. Google’s stated use case is narrow: “This is useful for non-HTML files (like PDFs).”

An XML sitemap, using the xhtml namespace. The practical choice at scale, because it needs no page-template edits. Each <url> entry lists every alternate, including itself.

The five rules

1. It must be reciprocal. Google: “If two pages don’t both point to each other, the tags will be ignored. This is so that someone on another site can’t arbitrarily create a tag naming itself as an alternative version of one of your pages.” In its Common Mistakes section Google words it slightly more softly, “may be ignored or not interpreted correctly.” Either way, a one-way annotation is worthless. This is Google’s own number-one listed mistake.

2. Every version must reference itself. Google: “Each language version must list itself as well as all other language versions.” Not optional. Leave the self-reference out and the set is invalid.

3. URLs must be fully qualified. Google: “Alternate URLs must be fully-qualified, including the transport method (http/https), so: https://example.com/foo, not //example.com/foo or /foo.”

4. The codes must be valid, and Google’s rules are stricter than the HTML spec’s. The language is ISO 639-1, two letters. The region, if you need one at all, is ISO 3166-1 alpha-2. Google states plainly that “only language codes listed in ISO 639-1 and region codes listed in ISO 3166-1 Alpha 2 are supported; other codes that aren’t listed in those standards, such as es-419, aren’t supported.”

This is where a popular half-truth lives. SEO articles say hreflang follows BCP 47. The HTML standard does require a valid BCP 47 tag. But Google enforces a subset of BCP 47: it rejects the UN M.49 region codes that BCP 47 allows, es-419 being Google’s own example. Both statements are true at different layers. Do not conflate them.

Consequences worth memorising:

en-UK is invalid. The country code for the United Kingdom is GB. Google states that using EU, UN or UK “doesn’t have an effect on Google Search.”
Three-letter language codes fail. ISO 639-1 is the two-letter set.
A region alone is invalid. hreflang="us" means nothing. Google: “Specifying the region alone is not valid.”
fr-FR is usually a mistake. It targets French speakers in France. Unless you genuinely serve different content to Belgium or Canada, use fr.

5. hreflang and canonical must agree. Each language version is its own canonical URL. Google’s canonicalization doc says: “If you’re using hreflang elements, make sure to specify a canonical page in the same language.”

If your French page canonicalises to the English one, you have told Google the French page is a duplicate that should not be indexed. A page Google refuses to index cannot be swapped in, so the whole cluster collapses. Canonical is the indexing signal; hreflang is the localization layer applied on top of it.

x-default, briefly

Recommended, not required. Google: “the reserved x-default value is used when no other language/region matches the user’s browser setting.” It was introduced in 2013 specifically for language selector pages and homepages that auto-redirect. The language of the x-default page is irrelevant.

Google Search Console will not warn you

This is the part most articles, including an earlier version of this one, get wrong.

Search Console used to have an International Targeting report with an hreflang tab that listed errors like “no return tags.” Google deprecated it on 24 August 2022 and removed it the following month, stating that the country-targeting setting “was determined to have little value for the ecosystem” while “Google will continue to support and use hreflang tags on your pages.”

Nothing replaced it. As of 2026 there is no hreflang report in Search Console. It will not tell you that your reciprocity is broken or that your codes are invalid.

What you can still do inside GSC is indirect:

URL Inspection confirms a specific alternate returns 200, is indexable, and which canonical Google chose. It does not validate hreflang.
Page Indexing shows the downstream symptom, alternates excluded from the index, not the cause.

So the real tools are outside Search Console, and Google’s own documentation links two of them in its debugging section: Aleyda Solis’s hreflang generator and the Merkle hreflang testing tool at technicalseo.com, which validates both HTML tags and HTTP headers and catches reciprocity. For site-wide return-tag auditing, crawl with Screaming Frog or Sitebulb.

The check that catches almost everything

Pick one page. List every language version. For each one, ask two questions:

Does it point at all the others?
Does it point at itself?

If both answers are yes for every version, and every alternate returns 200, is indexable and self-canonicalises, the cluster is almost certainly healthy. That is the whole job.

One more, often forgotten: hreflang alternates must not point at redirects or noindex pages. Google’s localized-versions doc does not spell this out in a single quotable sentence, so treat it as reasoning rather than scripture: hreflang swaps in a URL that already ranks, and a 3xx or a noindex URL can never be that URL. Mueller has said separately that noindex and canonical are contradictory signals; the same logic applies here.

What about Bing

The stale claim that “Bing ignores hreflang” is out of date. In December 2025 Bing’s webmaster blog explicitly recommended it: “Use hreflang to define language and regional targeting.” Bing also renders less JavaScript than Google, which matters for the next section.

Where Page Translator fits, honestly

Page Translator injects hreflang link tags on Pro. It does so with a script that runs in the browser and appends the tags to document.head at runtime. It is not one of the three server-side methods above.

The reason is a platform constraint, not a shortcut. Framer renders the served lang attribute and hreflang tags from its own paid native Locales and locks them: Framer’s documentation states that third-party translation services cannot modify them or the site’s source code. A plugin’s only lever is custom code, which is site-wide and which the user can disable at any time.

What that means in practice:

Google renders JavaScript and can pick these tags up. That is not nothing, but it is weaker than tags present in the served HTML, and it depends on Google rendering every alternate page so reciprocity resolves.
Bing and other crawlers are less reliable at rendering, so assume they may not see them.
If plugin custom code is disabled in your Framer site settings, the tags vanish and the plugin cannot re-enable it.

If server-rendered hreflang is a hard requirement for your project, Framer’s native Locales is the correct answer, and so are Weglot and Linguana, all of which serve it from the server. We would rather tell you that than sell you a plugin that leaves you wondering why your alternates never got picked up.

Whatever you use: open the page source, run it through the Merkle tool, confirm the tags are there and reciprocal. Search Console will not do it for you.

Primary sources: Google Search Central, Tell Google about localized versions of your page (updated 22 December 2025); Consolidate duplicate URLs (updated 27 March 2026); The International Targeting report is deprecated; Bing Webmaster Blog, December 2025. Checked 9 July 2026.