Pourquoi Google n'indexe-t-il qu'une seule langue si votre site switche via JavaScript ?

Pourquoi Googlebot ignore-t-il les language switchers JavaScript ?

Googlebot explore le web de manière radicalement différente d'un utilisateur humain. Quand un visiteur clique sur un sélecteur de langue, le site charge dynamiquement la nouvelle version via JavaScript ou stocke cette préférence dans un cookie. Le bot, lui, ne clique pas, ne change pas de préférence linguistique, et ne conserve pas les cookies entre deux sessions de crawl.

Concrètement, si votre site affiche le français par défaut et que l'anglais, l'espagnol ou l'allemand ne sont accessibles qu'en changeant un paramètre local dans le navigateur, Googlebot ne voit que la version française. Il n'a aucun moyen technique de découvrir que d'autres langues existent sur la même URL. Ce n'est pas un bug — c'est une limitation architecturale volontaire pour éviter les comportements imprévisibles et l'inflation du crawl budget.

Qu'est-ce qu'une URL distincte pour chaque langue ?

Une URL distincte signifie que chaque version linguistique possède son propre identifiant unique dans l'index de Google. Cela peut prendre trois formes principales : les sous-domaines (en.example.com, fr.example.com), les sous-répertoires (example.com/en/, example.com/fr/) ou les domaines de premier niveau géographiques (example.fr, example.de).

Cette approche permet à Google de crawler, indexer et servir chaque version indépendamment selon la géolocalisation et les préférences linguistiques de l'utilisateur. Les balises hreflang peuvent ensuite signaler les relations entre ces versions pour éviter les problèmes de contenu dupliqué et optimiser l'affichage dans les SERP locales.

Cette limitation affecte-t-elle uniquement les sites multilingues ?

Non. Le même principe s'applique à toute personnalisation de contenu gérée côté client sans URL distincte. Si votre site affiche des produits différents selon la géolocalisation détectée en JavaScript, ou si vous personnalisez les prix via des cookies sans modifier l'URL, Google indexera uniquement la version par défaut servie côté serveur.

C'est particulièrement problématique pour les sites e-commerce internationaux qui essaient de gérer plusieurs devises, stocks régionaux ou catalogues locaux sur une seule URL. Sans différenciation au niveau de l'URL, vous perdez le contrôle sur ce qui est indexé et pour quel marché.

• Googlebot n'exécute pas les actions utilisateur comme les clics sur les language switchers
• Les cookies ne sont pas conservés entre les sessions de crawl
• Une URL unique = une seule version indexée, quelle que soit la logique JavaScript derrière
• Les sous-domaines, sous-répertoires ou ccTLD sont les trois structures validées par Google
• Les balises hreflang nécessitent des URL distinctes pour fonctionner

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, et c'est même l'une des affirmations les plus stables de Google depuis des années. Les tests montrent systématiquement que les sites utilisant un switcher JavaScript sans changement d'URL ne voient qu'une seule langue indexée — généralement celle définie côté serveur pour le premier chargement. Aucune ambiguïté ici.

Là où ça devient intéressant, c'est que certains frameworks modernes (Next.js, Nuxt) permettent du rendering hybride avec détection de langue côté serveur mais navigation côté client. Si l'implémentation est propre et que le SSR sert des URL distinctes à Googlebot, ça fonctionne. Mais dès que tout repose sur du client-side routing avec une URL unique, on retombe dans le piège décrit par Mueller.

Quelles nuances faut-il apporter à cette règle ?

La déclaration est binaire, mais la réalité technique comporte quelques zones grises. Google peut exécuter du JavaScript moderne et indexer du contenu chargé dynamiquement — mais uniquement si ce contenu est découvrable via le crawl initial. Un language switcher qui modifie l'état local du DOM sans changer l'URL reste invisible.

Attention aussi au timing : même si vous implémentez des URL distinctes, si votre JavaScript redirige automatiquement les utilisateurs selon leur langue navigateur détectée sans que Googlebot puisse accéder à toutes les versions, vous recréez le problème. Les redirections 302 basées sur l'Accept-Language header sont acceptables si elles incluent un mécanisme de fallback crawlable pour le bot.

Dans quels cas cette règle peut-elle sembler ne pas s'appliquer ?

Certains sites semblent contourner cette limitation en servant du contenu multilingue sur une URL unique tout en apparaissant dans plusieurs SERP locales. Dans 99% des cas, c'est un accident ou un malentendu. Google indexe bien une seule version, mais elle peut ranker dans plusieurs pays si le contenu est suffisamment neutre ou si les backlinks proviennent de plusieurs zones géographiques.

L'autre exception apparente concerne les sites avec traduction automatique activée côté Google (via Google Translate dans les SERP). Ce n'est pas votre site multilingue qui est indexé — c'est Google qui propose une traduction de votre version unique. Vous n'avez aucun contrôle sur la qualité ni sur le ciblage précis. Ce n'est pas une stratégie SEO viable pour un site sérieux.

Que faut-il faire concrètement si votre site switche par JavaScript ?

D'abord, auditer l'architecture actuelle. Testez avec l'outil d'inspection d'URL dans la Search Console : soumettez votre page d'accueil et vérifiez quelle langue Google voit dans le rendu HTML. Si vous avez 5 langues mais qu'une seule apparaît, vous êtes dans le scénario décrit par Mueller.

Ensuite, planifier la migration vers des URL distinctes. C'est un chantier technique non trivial : il faut choisir entre sous-domaines, sous-répertoires ou ccTLD (chacun a ses implications SEO et budgétaires), refondre le routing, implémenter les balises hreflang correctement, gérer les redirections depuis l'ancienne structure, et éviter les erreurs de duplication. Le timing et la méthode comptent énormément pour ne pas perdre de trafic pendant la transition.

Quelles erreurs éviter lors de la mise en place d'URL multilingues ?

L'erreur classique : utiliser des paramètres d'URL (example.com?lang=fr) au lieu de structures propres. Techniquement, c'est une URL distincte, mais Google recommande explicitement de ne pas utiliser cette méthode car elle complique la gestion des hreflang, dilue les signaux de ranking et pose des problèmes de canonicalisation.

Deuxième piège : implémenter les URL distinctes mais laisser du JavaScript rediriger automatiquement selon la langue du navigateur sans offrir de version statique à Googlebot. Le bot doit pouvoir accéder librement à toutes les versions sans être forcé vers une seule. Utilisez des redirections 302 avec un lien visible vers les autres langues, ou mieux, servez la version appropriée côté serveur via l'Accept-Language header tout en gardant toutes les URLs crawlables.

Comment vérifier que l'implémentation fonctionne correctement ?

Après la migration, utilisez la Search Console pour chaque version linguistique (configurez une propriété par sous-domaine ou sous-répertoire). Vérifiez que chaque version est bien indexée indépendamment, que les hreflang apparaissent correctement dans l'inspection d'URL, et que le trafic organique provient bien des bonnes géolocalisations.

Surveillez aussi les Core Web Vitals par langue : une version peut performer très différemment d'une autre si les ressources (fonts, images) ne sont pas optimisées de manière homogène. Les rapports de couverture doivent montrer un volume d'indexation proportionnel au contenu réel de chaque langue — si l'anglais a 500 pages mais que seulement 50 sont indexées, creusez.

• Auditer l'architecture actuelle avec l'outil d'inspection d'URL de la Search Console
• Choisir une structure d'URL adaptée (sous-répertoires recommandés pour la plupart des cas)
• Implémenter les balises hreflang correctement entre toutes les versions
• Éviter les redirections JavaScript automatiques qui bloquent l'accès du bot
• Configurer une propriété Search Console distincte par version linguistique
• Vérifier l'indexation et les performances de chaque version indépendamment