Is Google really able to index localized content loaded via JavaScript?

Why does this statement differentiate between cloaking and indexing?

The distinction made by Mueller is fundamental. Cloaking is a violation of guidelines that involves showing different content to bots and users. Here, Google clearly states: if your JavaScript detects the browser's language and displays French to a French visitor and English to an American, this is not cloaking.

But here's the trap. No cloaking does not mean indexing. Google can crawl your page, see the initial empty HTML shell or the default English version, and may never execute the JavaScript that switches to other languages correctly. As a result, your localized variants simply do not exist in the index.

What prevents Google from indexing this dynamic content?

JavaScript execution at Google is neither instantaneous nor guaranteed. Rendering occurs in a second wave of crawling, sometimes hours or days after the initial pass. If your script waits for a user event (scroll, click) or relies on slow external APIs, Google may simply give up.

Crawl budget also comes into play. Google does not systematically execute JavaScript on all pages, especially on mid-sized or low-authority sites. A page that loads content after the initial onLoad risks having that content completely ignored.

What does it really mean to "use distinct URLs"?

Mueller recommends the classic approach of domain.com/fr/ vs domain.com/en/ or subdomains such as fr.domain.com. Each URL serves content directly in the target language, server-side, without waiting for JavaScript to do the work.

This is the structure that Google has always preferred. Hreflang works better with distinct URLs, crawling is more efficient, and when a user shares a link, they share the correct linguistic version. JavaScript can still enhance the UX (switching languages without reloading), but the base content is already there in the initial HTML.

• No cloaking: displaying localized content client-side based on the browser's language is not a penalty
• Indexing risk: Google may not execute the JS or do so too late to index the variants
• Distinct URLs recommended: one URL per language ensures indexing and proper functioning of hreflang
• Crawl budget and rendering: JS rendering is not systematic, especially on low-authority sites
• Social sharing: with pure JS switching, it's impossible to directly share a specific linguistic version

Is this recommendation consistent with what is observed in the field?

Absolutely. Sites that rely on JavaScript to display localized content systematically suffer from indexing problems. I've seen dozens of cases where the French version of a site never appeared on Google.fr because all the content was injected client-side after detecting navigator.language.

Despite Google's improvements in rendering, it remains fundamentally slower and less reliable than server rendering. The Search Console often shows only one linguistic version indexed (usually the default English), and hreflang tags are useless if the target URLs are never crawled.

Why doesn't Google guarantee the indexing of JavaScript content?

Because JavaScript execution is resource-intensive. Google needs to render billions of pages, and running Chrome headless on each one blows up the infrastructure budget. The solution: prioritize high-authority sites and limit rendering elsewhere.

Mueller never explicitly states this, but it is the reality. [To be verified] Google has never published figures on the percentage of pages actually rendered with JavaScript. Empirical testing shows that small sites and deep pages are often crawled only in raw HTML.

In what cases can this JavaScript approach still work?

If you are a web giant with an unlimited crawl budget (Amazon, Wikipedia), Google will likely execute your JavaScript. But even then, it's a risky bet. Best practice remains server-side rendering or static generation with Next.js, Nuxt, or equivalent.

For traditional multilingual sites, there is no valid reason to load localized content client-side. All modern frameworks offer SSR or pre-rendering. If your tech stack does not allow it, that’s a signal that your stack is outdated for international SEO.

What should you do if you already have localized content in JavaScript?

First, audit the actual indexing of your linguistic variants. Perform site:votredomaine.com on each local Google (google.fr, google.de, etc.) and check if your localized pages appear. Also, use the URL Inspection Tool in Search Console to see what Googlebot actually sees after rendering.

If the localized content does not appear in the rendered HTML, you have confirmation of the problem. The long-term solution: migrate to distinct URLs with server-side rendering. Yes, it’s a technical project, but it’s the only reliable approach for international SEO.

How should distinct URLs by language be correctly implemented?

Choose a structure: subdirectories (/fr/, /de/), subdomains (fr.domain.com) or ccTLDs (.fr, .de). Subdirectories are generally the best compromise: they concentrate authority on a single domain and are easier to manage technically.

Serve localized content directly in the initial HTML. Correctly configure your hreflang tags to link the versions together and indicate to Google which URL to display based on the user's language/region. Check in Search Console that Google understands your hreflang annotations.

What mistakes should absolutely be avoided in this migration?

Do not automatically redirect users based on their IP or browser language without giving them a choice. Google may get stuck on a single version. Instead, offer a visible language selector and respect user preferences.

Do not forget about 301 redirects if you change your URL structure. A poorly managed international migration can drop your traffic by 40-60% for months. Precisely document the old/new mapping and monitor Search Console vigilantly.

• Audit the current indexing of each linguistic variant via site: and the URL Inspection Tool
• Choose a clear URL structure (recommended subdirectories: /fr/, /en/, /de/)
• Implement server-side rendering or static generation for each language
• Configure hreflang tags on all pages with their linguistic equivalents
• Set up 301 redirects if migrating from existing URLs
• Check in Search Console that Google detects and understands the hreflang