Official statement
Other statements from this video 25 ▾
- 1:36 How can you effectively test JavaScript rendering before taking your site live?
- 1:36 Why has testing JavaScript rendering before launch become essential for Google indexing?
- 1:38 Why does a website redesign cause rank drops even without content changes?
- 1:38 Does migrating to JavaScript really affect SEO rankings?
- 3:40 Does Googlebot really see every localized version of your pages?
- 3:40 Does hreflang really group your multilingual content in Google's eyes?
- 4:11 How can you make your hyper-local content URLs discoverable without sacrificing traffic?
- 4:11 How can you structure your URLs to enhance the discoverability of hyper-local content?
- 5:14 Can user personalization trigger a penalty for cloaking?
- 5:14 Could personalizing content for your users lead to a cloaking penalty?
- 6:15 Are Core Web Vitals really measured on users or bots?
- 6:15 Are Core Web Vitals really measured from Google bots or from your actual users?
- 7:18 Why isn’t schema markup enough to ensure rich snippets appear?
- 7:18 Why don't rich snippets show up even with valid Schema.org markup?
- 9:14 Is dynamic rendering really dead for SEO?
- 9:29 Should we ditch dynamic rendering for SSR with hydration?
- 11:40 How does the JavaScript main thread block interactivity on your pages according to Google?
- 11:40 How does the JavaScript main thread affect the indexing of your pages?
- 12:33 Can Google really overlook your critical tags in the battle between initial and rendered HTML?
- 13:12 What happens when your initial HTML differs from the HTML rendered by JavaScript?
- 15:50 Is it true that Googlebot doesn't click on buttons on your site?
- 15:50 Should you really be concerned if Googlebot doesn't click on your buttons?
- 26:58 Should you prioritize JavaScript performance for your real users over optimization for Googlebot?
- 28:20 Are web workers truly compatible with Google's JavaScript rendering?
- 28:20 Should you really be wary of Web Workers for SEO?
Google maintains that hreflang remains the go-to tool for signaling the language variants of content and avoiding inter-local duplication. This statement implies that without this configuration, the engine cannot automatically group EN-US, FR-FR, DE-DE versions as a single semantic entity. In practical terms: a multilingual site without hreflang risks Google treating each version as competing content, with associated cannibalization penalties.
What you need to understand
Why does Google mention 'grouping' language variants?
When a site offers multiple versions of the same page — let's say example.com/en-us/product and example.com/fr-fr/produit — Google doesn’t automatically guess that it’s the same adapted content. Without an explicit signal, the crawler sees two distinct URLs with different text. It can therefore index them separately, make them compete against each other in the SERPs, or worse: ignore one in favor of the other.
The role of hreflang is precisely to avoid this ambiguity. The tag tells Google: 'These pages form a coherent set. Each variant targets a specific language and/or region. Display the right version according to the user's locale.' It's a mechanism of semantic consolidation that prevents the dilution of ranking signals between versions.
What does 'locale-adapted content' really mean?
Splitt's phrasing speaks of 'locale-adapted content' — not just translated, but adapted. This is a nuance that matters. A word-for-word translation of English text into French remains adapted content, but a FR-CA (Canadian French) page that mentions prices in Canadian dollars, local examples, and a different tone from FR-FR is even more adapted.
Hreflang operates on two axes: language (fr, de, en) and region (FR, CH, US). You can specify fr-FR (French from France), fr-CA (French from Canada), fr-BE (French from Belgium). Google will use these signals to serve the most relevant version based on the user’s location and language settings.
Without this granularity, a Quebec user might land on the French version from France, with inappropriate references and a high bounce rate. Hreflang corrects this misalignment.
When does hreflang become essential?
Not all multilingual sites critically need hreflang. If you have a monolingual site with automatic geolocation (a single URL serving dynamic content based on IP), hreflang does not apply. It targets architectures where each linguistic or regional version has its own indexable URL.
Typical cases: international e-commerce with country-specific catalogs, international media (BBC, The Guardian with regional editions), SaaS offering localized landing pages. Here, hreflang becomes non-negotiable. Without it, you risk your DE-DE version ranking in France, or worse: Google arbitrarily choosing one version and ignoring the others.
- Hreflang prevents inter-local cannibalization: each version maintains its own ranking space in its target region/language.
- It improves UX: the user lands directly on the relevant version, without any risky IP redirection.
- It consolidates SEO signals: backlinks, traffic, and user signals from each version are understood as part of a coherent set, not as competitors.
- It works in tandem with the XML sitemap: you can declare hreflang in the sitemap to simplify management on high-volume sites.
- It requires strict reciprocity: each page must point to all its variants, including itself. A reciprocity error breaks the whole system.
SEO Expert opinion
Is this statement consistent with observed practices on the ground?
Yes, but with a significant caveat: hreflang is notoriously fragile. Google has been saying this for years, and Splitt merely confirms the official doctrine. However, in real life, hreflang is a chronic source of errors — broken reciprocity, poorly formed ISO codes (en-fr instead of en-FR), and tags forgotten after a redesign.
The Search Console reports these errors, indeed, but with a delay that can extend up to several weeks. In the meantime, you're navigating in the dark. [To be verified]: Google claims to 'understand and group' variants, but the algorithm remains opaque about what happens when hreflang is partially implemented or contradictory. Sometimes, Google seems to completely ignore hreflang without explanation.
What nuances should be added to this official recommendation?
First point: hreflang is not a ranking factor. It does not boost rankings; it merely directs which version appears in which regional SERP. If your FR-FR content is mediocre, hreflang will not save it — it just ensures that it will be served to French-speaking users.
Second nuance: hreflang and canonical can conflict. If you set an inter-language canonical (for example, all versions pointing to EN-US), you sabotage hreflang. Google will prioritize the canonical and ignore the variants. This is a mistake still seen in audits, especially on misconfigured CMS.
Third point — and this is where it gets interesting — Splitt talks about 'grouping these variants as a single content'. But does Google really treat that as one consolidated signal on rankings? Not entirely. Each version continues to accumulate its own backlinks, own CTR, own Core Web Vitals. Hreflang semantically links them, but they remain distinct entities in the index.
When does this rule not apply or become counterproductive?
If you have a site with nearly identical content across multiple locales (for example, EN-US and EN-GB with just minor spelling differences), hreflang can become a trap. Google may consider these pages as near-duplicate and arbitrarily choose one as the canonical version, even with hreflang in place.
Another edge case: sites with hundreds of language variants (think Wikipedia with 300+ languages). Here, implementing hreflang becomes a technical nightmare: each page must list all the others, which blows up the HTML size. In these cases, Google recommends using an XML sitemap to declare hreflang, but the effectiveness remains uncertain compared to on-page implementation.
Finally — and this is rarely mentioned — hreflang only works correctly if all versions are indexable. If you block FR-FR from crawling or if it returns a 404, hreflang becomes useless. This seems obvious, but we still see sites with hreflang tags pointing to orphaned or non-indexed pages.
Practical impact and recommendations
What should be done concretely to implement hreflang correctly?
First step: audit the multilingual architecture of your site. Identify all existing variants, their URLs, and target locales. Document precisely which ISO codes you will use — en-US, fr-FR, de-DE, etc. Avoid fanciful abbreviations or language codes without regions when a region is relevant.
Next, choose your implementation method: HTML <link rel="alternate" hreflang="x"> tags in the <head>, HTTP headers, or XML sitemap. For most sites, HTML implementation remains the most reliable — Google crawls it directly, no need to generate and maintain a separate sitemap. But for high-volume sites (thousands of pages × multiple languages), the sitemap becomes the only viable option.
Third imperative: ensure absolute reciprocity. Each page must list all its language variants, including itself. If example.com/en-us/product declares FR-FR and DE-DE, then example.com/fr-fr/produit must declare EN-US, DE-DE, and FR-FR. Incomplete reciprocity renders hreflang ineffective.
What errors to avoid when configuring hreflang?
The classic mistake: mixing hreflang and inter-language canonical. If your FR-FR version has a <link rel="canonical"> pointing to EN-US, Google will ignore hreflang and treat EN-US as the unique version. Each variant should have a canonical pointing to itself, never to another language.
Second trap: poorly formed ISO codes. It's en-US (language-REGION in uppercase), not en-us, EN-US, or en_US. Google is strict on syntax. Incorrect casing or a wrong separator (underscore instead of hyphen) invalidates the tag.
Third frequent error: forgetting the x-default tag. This special tag indicates which version to serve by default when no locale matches the user. If you target EN-US, FR-FR, DE-DE, but a Japanese user arrives, x-default tells them which version to display (often EN-US). Without x-default, Google chooses arbitrarily.
How do I check if my hreflang implementation is working?
First line of defense: Google Search Console, 'Enhancements' → 'International Targeting'. You will see detected hreflang errors — missing reciprocity, invalid ISO codes, contradictory tags. But be careful: the Search Console takes weeks to report these errors. Don't blindly rely on the absence of alerts.
Complement with a Screaming Frog or Oncrawl crawl in 'Extract hreflang' mode. These tools test reciprocity in real-time and detect inconsistencies that the Search Console misses. Also check that each page properly lists all its variants, not just a few.
Finally, test manually in Google: force a locale in search settings (google.fr, google.com, google.de) and ensure the correct version appears in the SERPs. Use the URL Inspection tool in Search Console to see which version Google has indexed and which hreflang tags it has detected.
- Audit all language variants and document target ISO codes
- Implement hreflang via HTML
<head>, HTTP headers, or XML sitemap depending on volume - Ensure strict reciprocity: each page lists all its variants, including itself
- Add an
x-defaulttag pointing to the default version - Verify that each variant has a self-referential canonical, never inter-language
- Monitor Search Console for hreflang errors
- Crawl the site with Screaming Frog to validate reciprocity in real-time
- Test manually in regional SERPs to confirm the correct version is displayed
❓ Frequently Asked Questions
Hreflang fonctionne-t-il si je l'implémente uniquement sur certaines pages ?
Puis-je utiliser hreflang et canonical inter-langue en même temps ?
Quelle est la différence entre x-default et une balise hreflang classique ?
Combien de temps faut-il à Google pour prendre en compte les changements hreflang ?
Hreflang améliore-t-il le classement de mon site ?
🎥 From the same video 25
Other SEO insights extracted from this same Google Search Central video · duration 30 min · published on 11/11/2020
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.