Why does Google only index one language when your site switches through JavaScript?

Why does Googlebot ignore JavaScript language switchers?

Googlebot crawls the web fundamentally differently than a human user. When a visitor clicks on a language selector, the site dynamically loads the new version via JavaScript or stores this preference in a cookie. The bot does not click, does not change language preference, and does not retain cookies between crawl sessions.

Specifically, if your site displays French by default and English, Spanish, or German are only accessible by changing a local setting in the browser, Googlebot only sees the French version. There is no technical way for it to discover that other languages exist on the same URL. This is not a bug — it is a deliberate architectural limitation to prevent unpredictable behavior and inflation of the crawl budget.

What does a distinct URL for each language mean?

A distinct URL means that each language version has its own unique identifier in Google’s index. This can take three main forms: subdomains (en.example.com, fr.example.com), subdirectories (example.com/en/, example.com/fr/) or geographic top-level domains (example.fr, example.de).

This approach allows Google to crawl, index, and serve each version independently based on the user’s geolocation and language preferences. Hreflang tags can then signal the relationships between these versions to avoid duplicate content issues and optimize display in local SERPs.

Does this limitation only affect multilingual sites?

No. The same principle applies to any client-side content customization without distinct URLs. If your site displays different products based on geolocation detected via JavaScript, or if you customize prices via cookies without changing the URL, Google will only index the default version served server-side.

This is particularly problematic for international e-commerce sites trying to manage multiple currencies, regional inventories, or local catalogs on a single URL. Without URL differentiation, you lose control over what gets indexed and for which market.

• Googlebot does not execute user actions like clicking on language switchers
• Cookies are not retained between crawl sessions
• A unique URL = one indexed version, regardless of the JavaScript logic behind it
• Subdomains, subdirectories, or ccTLDs are the three structures validated by Google
• Hreflang tags require distinct URLs to function

Is this statement consistent with observed practices in the field?

Yes, and it’s actually one of Google’s most stable assertions for years. Tests consistently show that sites using a JavaScript switcher without URL change see only one language indexed — usually the one set server-side for the initial load. There’s no ambiguity here.

Where it gets interesting is that some modern frameworks (Next.js, Nuxt) allow for hybrid rendering with server-side language detection but client-side navigation. If the implementation is clean and SSR serves distinct URLs to Googlebot, it works. But as soon as everything relies on client-side routing with a single URL, you fall back into the trap described by Mueller.

What nuances should be added to this rule?

The statement is binary, but the technical reality has some gray areas. Google can execute modern JavaScript and index dynamically loaded content — but only if that content is discoverable via the initial crawl. A language switcher that alters the local DOM state without changing the URL remains invisible.

Also, be cautious about timing: even if you implement distinct URLs, if your JavaScript automatically redirects users based on their detected browser language without allowing Googlebot to access all versions, you recreate the problem. 302 redirects based on the Accept-Language header are acceptable if they include a crawlable fallback mechanism for the bot.

In what cases might this rule seem not to apply?

Some sites appear to bypass this limitation by serving multilingual content on a single URL while appearing in several local SERPs. In 99% of cases, this is a fluke or misunderstanding. Google indeed indexes only one version, but it may rank in multiple countries if the content is neutral enough or if backlinks originate from different geographic areas.

The other apparent exception concerns sites with automatic translation enabled by Google (via Google Translate in SERPs). It is not your multilingual site that is indexed — it’s Google providing a translation of your unique version. You have no control over quality or precise targeting. This is not a viable SEO strategy for a serious site.

What should you concretely do if your site switches through JavaScript?

First, audit the current architecture. Test using the URL inspection tool in Search Console: submit your homepage and check what language Google sees in the HTML rendering. If you have 5 languages but only one appears, you’re in the scenario described by Mueller.

Next, plan the migration to distinct URLs. This is a non-trivial technical project: you need to choose between subdomains, subdirectories, or ccTLDs (each has its SEO and budget implications), refactor routing, implement hreflang tags correctly, manage redirects from the old structure, and avoid duplication errors. Timing and method matter greatly to avoid losing traffic during the transition.

What mistakes should be avoided when implementing multilingual URLs?

The classic mistake: using URL parameters (example.com?lang=fr) instead of clean structures. Technically, this is a distinct URL, but Google explicitly recommends not using this method as it complicates hreflang management, dilutes ranking signals, and poses canonicalization issues.

Second pitfall: implementing distinct URLs but allowing JavaScript to automatically redirect based on browser language without offering a static version to Googlebot. The bot must be able to freely access all versions without being forced into just one. Use 302 redirects with a visible link to other languages, or better, serve the appropriate version server-side via the Accept-Language header while keeping all URLs crawlable.

How to verify that the implementation works correctly?

After migration, use Search Console for each language version (set up a property for each subdomain or subdirectory). Check that each version is indexed independently, that hreflang tags appear correctly in URL inspection, and that organic traffic comes from the right geolocations.

Also, monitor Core Web Vitals by language: one version may perform very differently from another if resources (fonts, images) are not uniformly optimized. Coverage reports should show an indexing volume proportional to the actual content of each language — if English has 500 pages but only 50 are indexed, investigate.

• Audit the current architecture using the URL inspection tool in Search Console
• Choose an appropriate URL structure (subdirectories recommended for most cases)
• Implement hreflang tags correctly between all versions
• Avoid JavaScript automatic redirects that block bot access
• Set up a separate Search Console property for each language version
• Verify indexing and performance of each version independently