Hreflang Best Practices
Last updated
Getting hreflang working in production is less about the syntax than about a handful of decisions that determine whether it keeps working as a site grows: whether a regional variant is worth creating at all, which delivery method suits your scale, how to keep annotations reciprocal across markets, and how to catch the errors that creep in over time.
For a full reference covering syntax, ISO codes, and all three delivery methods, see Hreflang and International SEO, which is the place to start if you need the underlying mechanics first.
When is hreflang needed?
Hreflang is necessary whenever a site has multiple pages targeting the same topic for different language or regional audiences. The most 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,1 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”.2
Country variants earn their place when they reflect real differences: pricing and currency, legal disclosures, availability and eligibility, shipping and returns, regulatory requirements. A 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
- Pages in different languages cover genuinely different topics (not regional variants of the same content)
- The site uses ccTLDs with completely distinct content and no overlapping pages
The two rules that cause most failures
Self-reference: every page in a hreflang set must include an annotation pointing to itself. A page declaring other language versions without including itself is invalid and the annotations may be ignored.
Reciprocity: if page A declares page B as its French equivalent, page B must declare page A as its English equivalent. Google’s rule is that “if two pages don’t both point to each other, the tags will be ignored”.3
Both rules create a maintenance problem at scale, which is why template-driven or sitemap-based hreflang beats hand-maintained HTML 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”.3
What it asks in return is a sensible priority: “it is important to link newly expanded language pages bidirectionally to the originating/dominant language(s)”.3 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.
HTML tags vs sitemap delivery
HTML link tags placed in the <head> of each page work well for small to medium sites where hreflang can be generated from templates. Every page must list every language equivalent including itself:
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/page/" />
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page/" />XML sitemap entries declaring hreflang relationships in a sitemap rather than per-page HTML are better for large sites. All hreflang relationships are managed in one place, reducing the risk of drift.
Choose one method and apply it consistently, but understand why. Declaring hreflang in both HTML and the sitemap is not a conflict and does not create competing signals. Google’s position is that “the three methods are equivalent” and 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)”.3 The case for picking one is that three implementations are three things to keep in sync, not that combining them causes harm.
x-default
The x-default value specifies the fallback URL for users who do not match any specific hreflang. This is typically the 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”.3 A language-selector page is therefore the stronger choice where you have one; a global homepage is a reasonable substitute rather than an equivalent. If no x-default is set and a user matches no declared hreflang, Google selects a URL on other signals, which may not be the one you would pick.
Hreflang and canonicals
Hreflang and canonical tags work together but serve different purposes:
- 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 have a self-referential canonical (pointing to itself). 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,1 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”.4 The “never canonicalise across versions” rule holds for different languages; the same-language multi-regional case is the documented exception.
Partial hreflang
Some sites do not have all content available in all languages. A blog might publish articles only in English while product pages exist in six languages. Hreflang should only be applied where genuine language equivalents exist. Product pages in all six languages: annotate them all. Blog posts available only in English: do not annotate them.
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.
How do you audit hreflang?
Not in Search Console. Google removed the International Targeting report in September 2022,56 and that report’s Language section was the hreflang error monitor. Nothing replaced it, so Google now reports hreflang errors nowhere in Search Console. Its Page Indexing documentation says directly that “alternate language pages are not detected by Search Console”,7 and its URL Inspection documentation makes no mention of hreflang at all.8 Guidance suggesting you audit hreflang in either place is out of date.
Crawler tools (Screaming Frog, Sitebulb) crawl the full site and map hreflang relationships. They identify missing self-references, broken target URLs, and inconsistencies between the declared hreflang and the actual page content. For any site large enough to need this page, crawlers are the audit.
The tools Google names. Google’s own hreflang documentation points to third-party tools for debugging, noting they “are not maintained or checked by Google”, and links the Merkle hreflang tags testing tool and Aleyda Solis’s hreflang tags generator.3
Spot-checks: manually inspect the source of several pages after any CMS update or template change that affects the <head>. Hreflang is commonly the first element to break when site templates are modified.
Common errors and their effects
| Error | Effect |
|---|---|
| Missing self-reference | Full annotation set may be ignored |
| Non-reciprocal annotations | Non-matching side is ignored |
| Hreflang on noindex pages | Annotations weakened or ignored |
| Hreflang pointing to redirected URLs | Annotations may be followed one hop; unreliable |
Invalid region code (e.g. en-UK) | The region part is ignored, so it silently degrades to en |
| Multiple URLs for same hreflang value | Invalid; may confuse Google’s processing |
| Near-identical variants in the same language | Commonly consolidated to one canonical, so the variants stop appearing separately |
Frequently asked questions
Does hreflang improve rankings?
No. Hreflang ensures the right version of a page is served to the right audience; it does not make a page rank where it otherwise would not. Motoko Hunt’s framing is the clearest: hreflang “has always been a switcher, not a booster”, and adding an en-au attribute will not improve rankings in Sydney for a brand with no authority in Australia.9 Getting it wrong does actively damage international performance, which is the real reason to implement it carefully.
How long does hreflang take to be processed?
Google processes hreflang during normal crawl cycles. For large sites, several weeks after implementation may pass before all annotations are discovered and processed. Don’t expect one delivery method to be faster than another: Google states the three methods are “equivalent from Google’s perspective”.3 The case for sitemaps at scale is maintainability, not speed.
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”.9 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 above: “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.”2
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 the same conclusion the “should this variant exist” question above arrives at.
Does Google always follow hreflang?
No. Google treats hreflang as a hint, not a directive. If the declared page content does not match the declared language, the annotation may be ignored. Hreflang is also ignored for noindexed pages, pages blocked by robots.txt, and pages that return errors.
Footnotes
-
Google reminds that hreflang tags are hints, not directives — Search Engine Journal ↩ ↩2
-
Does duplicate content hurt SEO and AI search visibility? — Bing Webmaster Blog ↩ ↩2
-
Tell Google about localized versions of your page — Google Search Central ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Managing multi-regional and multilingual sites — Google Search Central ↩
-
The International Targeting report is deprecated — Google Search Console Help ↩
-
Google Search Console to remove International Targeting report — Search Engine Land ↩
-
AI search, market relevance and hreflang — Search Engine Land ↩ ↩2
