Hreflang and International SEO

International SEO is the discipline of running a site across multiple languages and regions in a way that surfaces the right version to the right user. The technical centrepiece is hreflang, an attribute that tells Google which language and region each URL targets.

What does hreflang do?

When a site has multiple versions of substantially the same content (English for the UK, English for the US, French for France, French for Canada), Google needs a way to know which version to surface for which user. Without explicit signals it guesses, and often serves the wrong regional version.

Hreflang is primarily a serving signal: it tells Google which version to show which audience rather than pooling authority across versions. It is not entirely separate from canonicalisation, though, and the nuance is worth having straight because overstatements circulate in both directions.

Google does list hreflang clusters among its canonicalisation signals: “for canonicalization purposes Google prefers URLs that are part of hreflang clusters”, so a page left out of a cluster is likelier to lose canonical selection to one inside it.¹ What hreflang does not do is merge the ranking signals of your German and English pages into a single pot.

Separately, and often confused with the above, putting an hreflang attribute on a rel="canonical" tag does nothing at all. Google ignores those, stating that “rel="canonical" annotations with hreflang, lang, media, and type attributes are not used for canonicalization”, and directs you to declare alternates with link rel="alternate" instead.¹ The two mechanisms are declared separately.

One more claim worth heading off: translated pages are not a duplicate content problem in the first place, since “localized versions of a page are only considered duplicates if the main content of the page remains untranslated”.²

hreflang annotations declare the language and (optionally) regional targeting of each URL, and the relationships between language/region versions of the same content.

<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/" />
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

When is hreflang needed?

Hreflang is necessary whenever a site has multiple pages targeting the same topic for different language or regional audiences. The common scenarios:

• Multiple languages: English and French versions of the same content
• Same language, different regions: British English (en-GB) and American English (en-US)
• Language plus regional variants: French for France (fr-FR) and French for Canada (fr-CA)

The second and third cases carry a prior question that is easy to skip: should the variant exist at all? Near-identical same-language variants are the failure case for hreflang, not its showcase. Google commonly consolidates them onto a single canonical when the content is materially the same,³ and Bing puts the same point more bluntly, advising site owners to “avoid creating multiple pages in the same language that serve the same purpose” and warning that localisation “creates duplicate content when regional or language pages are nearly identical and do not provide meaningful differences for users in each market”.⁴

Country variants earn their place when they reflect real differences: pricing and currency, legal disclosures, availability and eligibility, shipping and returns, regulatory requirements. An en-IE page that differs from en-GB only in a flag icon is work you will maintain forever for no benefit. Decide the variant is justified before implementing hreflang for it.

Hreflang is not needed when the site operates in a single language for a single country, when pages in different languages cover genuinely different topics rather than regional variants of the same content, or when ccTLDs carry completely distinct content with no overlapping pages.

How do you implement hreflang?

Three ways to declare it. Google treats them as interchangeable: “the three methods are equivalent from Google’s perspective and you can choose the method that’s the most convenient for your site”.² Pick one and apply it consistently, but note the reason. Using more than one is not a conflict and does not create competing signals. Google’s point is that “while you can use all three methods at the same time, there’s no benefit in Search (in fact, it maybe be much harder to manage three implementations instead of just picking one)”.² The argument for picking one is maintenance cost, not risk.

HTML link tags. In the <head> of each page, list every language/region version. Most flexible, easiest for small to medium sites where the tags can be generated from templates, and most prone to drift on large sites because every page must list every other version.

HTTP headers. For non-HTML resources such as PDFs, declare hreflang via Link headers. Less common but valid.

XML sitemap entries. Each URL entry can include xhtml:link elements declaring its hreflang relationships. Best for very large sites, because every relationship is managed in one place rather than across thousands of page templates.

For most sites under 1,000 URLs, HTML link tags are simplest. Above that, sitemap-based hreflang is more maintainable. Note that this is a maintenance argument and not a speed one: Google processes hreflang during normal crawl cycles regardless of delivery method, and on a large site several weeks may pass before every annotation is discovered.

Hreflang rules

Self-reference. Every page must include an hreflang tag pointing to itself. Pages that only list alternate versions without self-reference are invalid.

Reciprocity. If page A declares page B as its French version, page B must declare page A as its English version. Google’s rule is that “if two pages don’t both point to each other, the tags will be ignored”.²

These two rules cause most production failures, and both get harder as a site grows, which is why template-driven or sitemap-based hreflang beats hand-maintained tags. The arithmetic is less brutal than it first appears, though, because Google permits a partial set: “if it becomes difficult to maintain a complete set of bidirectional links for every language, you can omit some languages on some pages; Google will still process the ones that point to each other”. It adds a priority worth following: “it is important to link newly expanded language pages bidirectionally to the originating/dominant language(s)”.² So when adding a tenth language, the requirement is not a full mesh across all ten. Linking the new market’s pages bidirectionally to your dominant-language pages is a documented, supported pattern and a far smaller job.

Use ISO 639-1 for language and ISO 3166-1 alpha-2 for region. en for English, fr for French. en-GB for English in the UK, fr-CA for French in Canada. Region codes are uppercase by convention (Google accepts either case but uppercase is the standard). Two traps: the language code always comes first, and “you can’t specify the country code by itself”; and only codes in those two standards work, so es-419 for Latin American Spanish is not supported.² For script variations, Google derives the script from the country where it can, but you can state it explicitly with ISO 15924, as in zh-Hant and zh-Hans.²

Provide a generic version of a language. Where you have several variants of one language, Google advises a catchall: “if you have specific URLs for English speakers in Ireland (en-ie), Canada (en-ca), and Australia (en-au), provide a generic English (en) page for searchers in the US, UK, and all other English-speaking locations”.² This is distinct from x-default, which is a fallback across all languages rather than within one.

One-to-one mapping. Each unique (language, region) combination should map to exactly one URL. Listing two URLs for the same hreflang value is invalid.

Match the page content. Hreflang declares targeting; the page itself should be in the declared language. Google determines language from the visible content rather than from your annotation,² so a mismatch means the annotation is describing something the page isn’t.

What does x-default do?

The x-default value specifies the fallback URL for users who do not match any specific hreflang, typically a language-selector page or the global version of a site:

<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Google notes that although “you can use the x-default value for any page, it was designed for language selector pages and so it will work best with those”.² A language-selector page is therefore the stronger choice where you have one; a global homepage is a reasonable substitute rather than an equivalent. Without an x-default, a user matching no declared hreflang gets a URL Google selects on other signals, which may not be the one you would pick.

How do hreflang and canonicals work together?

The two serve different purposes. A canonical tells Google which URL is the preferred version of a page within the same language. Hreflang tells Google which URLs serve the same content in different languages or regions.

If a page has a canonical pointing to a different URL, the hreflang on the canonicalised page may be ignored. Every page in a hreflang set should carry a self-referential canonical. Never canonicalise a page to another language version.

Two refinements. Where Google does consolidate near-identical variants, the swap may still happen, but performance data reports against the canonical URL,³ so flat per-market numbers in Search Console can reflect consolidation rather than an hreflang fault. And there is one case where Google explicitly tells you to canonicalise across international URLs: same-language content on different URLs, such as example.de/ and example.com/de/. There its advice is to “pick a preferred version and use the rel="canonical" element and hreflang tags”.⁵ The “never canonicalise across versions” rule holds for different languages; the same-language multi-regional case is the documented exception.

What about pages that exist in only some languages?

Apply hreflang only where genuine equivalents exist. A site might publish articles in English only while product pages exist in six languages: annotate the product pages across all six, and leave the English-only articles unannotated.

Applying hreflang to pages without genuine equivalents creates a mismatch between the annotation and the content, which Google ignores or treats as a quality concern.

Geo-targeting signals

Google removed the International Targeting report from Search Console in September 2022, including the manual country-targeting setting.⁶ Geo-targeting now relies on signals Google reads automatically, and its documentation lists hreflang as one of four groups alongside ccTLDs, server location and local market signals.⁵ The full set, including the vanity ccTLDs that carry no country association, is covered in geotargeting; the domain-level decision behind it is covered in international URL structure.

What matters here is hreflang’s place among them. For subdomain and subdirectory sites it is the strongest explicit lever, because a ccTLD is unavailable and server location barely registers. It is still not the only signal, and the page’s own content does real work alongside it.

One clarification that catches people out: hreflang does not tell Google what language a page is in. “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”,² working from the visible content.⁵ Hreflang declares who a page is for; the content determines what language Google thinks it is.

Common hreflang errors and their effects

Error	Effect
Missing self-reference	Full annotation set may be ignored
Non-reciprocal annotations	Ignored on the non-matching side
Wrong region code (e.g. en-UK instead of en-GB)	The region part is ignored, so it silently degrades to en
Region code with no language (e.g. de intended to mean Germany)	Invalid; the first code is always the language
Relative or protocol-relative URLs in annotations	Invalid; URLs must be fully qualified including https
Hreflang pointing to noindexed URLs	Annotations weakened or ignored
Hreflang pointing to redirected URLs	May be followed one hop; unreliable
Multiple URLs for the same language/region	Invalid
Hreflang on pages that aren’t in the declared language	Ignored; possible quality concern
Near-identical variants in the same language	Commonly consolidated to one canonical, so the variants stop appearing separately

How do you audit hreflang?

Start from the fact that catches most people out: Google no longer reports hreflang errors anywhere in Search Console. The International Targeting report was the hreflang monitor, and it went in September 2022.⁶ Nothing replaced it. Google’s Page Indexing documentation states plainly that “alternate language pages are not detected by Search Console”,⁷ and its URL Inspection documentation does not mention hreflang at all.⁸ Advice telling you to audit hreflang in the Pages report or URL Inspection is out of date, however commonly it is repeated.

Google’s own answer is to use third-party tools. Its hreflang documentation has a “Debugging hreflang errors” section that says “there are many third-party tools available that you can use to debug hreflang annotations”, and names two, with the caveat that “these tools are not maintained or checked by Google”.²

Crawler audits. Screaming Frog, Sitebulb, and similar tools crawl the site and map the full annotation graph, reporting missing self-references, non-reciprocal annotations, broken target URLs, and mismatches between the declared hreflang and the actual page content. For any site large enough to need hreflang, crawlers are the audit.

Hreflang tags testing tool (Merkle) and Aleyda Solis’s hreflang tags generator. Both are the tools named in Google’s documentation.² Useful for spot-checking or generating annotations for specific pages.

Spot-checks after template changes. Inspect the source of several pages after any CMS update or template change affecting the <head>. Hreflang is commonly the first element to break when templates are modified.

Search Console, indirectly. You can’t see hreflang errors, but you can see their consequences: regional variants consolidated onto a single canonical, for instance. Where that happens, performance data reports against the canonical URL, so flat per-market numbers may reflect consolidation rather than an hreflang fault.³

Read the Page Indexing report carefully, though, because one alarming signal in it may not be a fault. In August 2026 Gary Illyes described how alternates are stored: when Google canonicalises a URL, the others in its duplicate cluster “may become so called alternate names”, and “hreflang alternates become such alternate URLs: they’re not in fact indexed in the proper sense”.⁹ The alternate stays mapped to the canonical that is indexed and can still be served when a query calls for it, so a URL sitting under “Alternate page with proper canonical tag” is not automatically broken.

The scope is narrower than that sounds, and it is the part most reports of this left out. Asked directly whether the behaviour applies to multi-language sets or only same-language ones, Illyes answered “it’s largely same languages I reckon”.⁹ So the not-indexed status is the expected resting state for same-language regional variants, en-GB against en-US, which is also the case Google consolidates most readily. A page in a genuinely different language reading as not indexed is not covered by that explanation and should still be diagnosed as you would any other exclusion. Note the hedge in “largely” and “I reckon”: this is an off-the-cuff clarification in a comment thread, not documentation.

Does hreflang affect AI search?

There is no confirmed mechanism, and it is worth being straight about that. Google has published nothing on how hreflang interacts with AI Overviews or AI Mode, and its guidance on AI features contains no international or multilingual section at all.

What can be said is structural. Hreflang is a serving signal: it operates at the point where Google decides which URL to show a user who is already going to see your page. AI answers are assembled differently, selecting and synthesising sources before any question of which regional URL to serve arises. Motoko Hunt’s assessment is that in AI-mediated retrieval, “content selection can occur before hreflang signals are evaluated or without consulting them at all”, with the blunt consequence that “a market-specific page can be indexed, valid, and hreflang-correct and still never appear in AI Overviews or AI Mode”.¹⁰ That is practitioner analysis rather than documented platform behaviour, and should be read as such.

Bing has said more about the adjacent mechanism, and it reinforces the differentiation point made earlier: “LLMs group near-duplicate URLs into a single cluster and then choose one page to represent the set. If the differences between pages are minimal, the model may select a version that is outdated or not the one you intended to highlight.”⁴

The practical position: keep hreflang, because classic search still dominates volume worldwide and hreflang still does its job there. Don’t expect it to buy AI visibility. What appears to determine whether a market-specific page gets used is whether it says something genuinely different for that market, which is where the “should this variant exist” question above ends up too.

Frequently asked questions

Do I need hreflang if I only have one language?

No. Hreflang is for managing multiple language or regional versions. A single-language site doesn’t need it.

Does hreflang improve rankings?

No, and there is no indirect mechanism either. Hreflang determines which version is served to which user; it does not make you rank where you otherwise would not. Motoko Hunt puts it well: hreflang “has always been a switcher, not a booster. If your brand lacked organic authority in Australia before implementing the tag, adding the en-au attribute wouldn’t magically improve your rankings in Sydney.”¹⁰ Getting it wrong, however, does actively damage international performance, which is why it is worth doing properly.

Why do my hreflang pages show as not indexed in Search Console?

Often because that is how Google stores them. Alternates are held as “alternate names” of a canonical rather than indexed in their own right, which is why they surface in the Page Indexing report under “Alternate page with proper canonical tag”. Gary Illyes put it directly: hreflang alternates “are not in fact indexed in the proper sense”.⁹ The URL still resolves to an indexed canonical and can be served when a query calls for it. Check the scope before relaxing, though: asked whether this covers multi-language sets, Illyes said “it’s largely same languages I reckon”.⁹ Treat the status as expected for same-language regional variants such as en-GB and en-US; for a page in a genuinely different language, diagnose it as you would any other exclusion.

Does Google always follow hreflang?

No. Google treats hreflang as a hint rather than a directive. It is ignored for noindexed pages, pages blocked by robots.txt, and pages that return errors, and where the page content does not match the declared language.

Can the same content rank in multiple regions?

Often, but not guaranteed. Where variants are genuinely different, each version becomes eligible to rank in its declared region. Where they are near-identical and in the same language, Google commonly groups them and picks one as canonical. This came up in a May 2025 exchange in which John Mueller addressed Belgian French (fr-be) pages appearing in France, clarifying that hreflang is a suggestion rather than a guarantee, that canonical selection can override it, and that same-language pages may be grouped.³ A practical consequence: don’t assume hreflang alone will produce separate performance data per region, since reporting follows the canonical.³ If you want separate regional versions to persist, give them genuinely different content.

Footnotes

1. How to specify a canonical URL with rel=“canonical” and other methods — Google Search Central. Carries both the hreflang-cluster canonicalisation preference and the statement that rel="canonical" annotations bearing hreflang, lang, media or type attributes are ignored. ↩ ↩²

2. Tell Google about localized versions of your page — Google Search Central ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³

3. Google reminds that hreflang tags are hints, not directives — Search Engine Journal ↩ ↩² ↩³ ↩⁴ ↩⁵

4. Does duplicate content hurt SEO and AI search visibility? — Bing Webmaster Blog ↩ ↩²

5. Managing multi-regional and multilingual sites — Google Search Central ↩ ↩² ↩³

6. The International Targeting report is deprecated — Google Search Console Help ↩ ↩²

7. Page Indexing report — Google Search Console Help ↩

8. URL Inspection Tool — Google Search Console Help ↩

9. Gary Illyes on hreflang alternates — LinkedIn, August 2026, replying to Faiez Javaid and, on the same-language scope, to Richard Hearne. Also reported as Google: hreflang URLs not indexed in the proper sense — Search Engine Roundtable, which predates the same-language clarification and does not include it. ↩ ↩² ↩³ ↩⁴

10. AI search, market relevance and hreflang — Search Engine Land ↩ ↩²