Pourquoi Googlebot ignore-t-il vos cookies et comment cela impacte-t-il votre stratégie multilingue ?

Que signifie concrètement « Googlebot ne gère pas les cookies » ?

Lorsque Googlebot crawle une page, il se comporte comme un navigateur extrêmement basique. Il effectue une requête HTTP standard, récupère le HTML, mais ne stocke aucun cookie renvoyé par le serveur dans l'en-tête Set-Cookie.

Lors de ses requêtes suivantes, même sur le même domaine, aucun cookie n'est transmis dans l'en-tête Cookie. Le bot arrive donc systématiquement comme un visiteur totalement vierge, sans historique, sans préférence, sans session.

Pourquoi cette limitation pose-t-elle problème pour les sites multilingues ?

Nombreux sont les sites qui détectent la langue du visiteur via l'IP ou le navigateur, puis stockent cette préférence dans un cookie pour les visites ultérieures. L'utilisateur français qui arrive une première fois voit la version FR, et un cookie « lang=fr » est posé.

Mais si votre logique de redirection s'appuie sur ce cookie pour afficher systématiquement /fr/ plutôt que /en/, Googlebot ne verra jamais cette redirection. Il crawlera toujours la version par défaut (souvent /en/ ou la racine), créant une indexation incomplète ou erronée de vos contenus localisés.

Quels sont les risques d'une redirection linguistique basée sur les cookies ?

Le premier risque est l'invisibilité pure et simple de vos variantes linguistiques. Si Googlebot accède toujours à /en/, les versions /fr/, /de/, /es/ ne seront jamais crawlées sauf si vous les soumettez manuellement ou qu'elles sont liées depuis d'autres pages.

Ensuite, même avec des balises hreflang correctement implémentées, Google peut rencontrer des incohérences entre le contenu crawlé et les déclarations hreflang. Si hreflang pointe vers /fr/ mais que Googlebot n'y accède jamais car redirigé vers /en/ en l'absence de cookie, le signal se dilue.

• Googlebot n'enregistre aucun cookie renvoyé par le serveur dans Set-Cookie.
• Aucun cookie n'est transmis dans les requêtes ultérieures, même sur le même domaine.
• Les redirections basées sur les cookies sont invisibles pour le bot et créent des problèmes d'indexation multilingue.
• Les variantes linguistiques non crawlées disparaissent de l'index ou ne sont jamais découvertes.
• Utiliser des signaux détectables côté serveur (Accept-Language, paramètres d'URL, sous-domaines) est la seule approche fiable.

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

Totalement. Les tests techniques confirment depuis des années que Googlebot arrive sans cookies et n'en stocke aucun. Les logs serveur montrent des requêtes vierges de tout en-tête Cookie, même après plusieurs passages successifs sur le même site.

Certains développeurs ont tenté des redirections 302 basées sur la présence d'un cookie de session, pensant que le bot suivrait le parcours utilisateur. Résultat : indexation de la mauvaise version linguistique, confusion dans les SERPs, et remontées d'URL en anglais pour des requêtes françaises.

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

Mueller dit « ne comptez pas sur les cookies », mais il ne dit pas que toute utilisation de cookies est toxique. Vous pouvez parfaitement utiliser des cookies pour améliorer l'UX des visiteurs humains, tant que votre logique de crawl n'en dépend pas.

L'idéal : un double mécanisme. Détectez la langue via Accept-Language ou IP pour Googlebot (qui envoie un Accept-Language basique mais exploitable), et stockez la préférence utilisateur dans un cookie pour les humains. Ainsi, le bot voit la bonne version dès le premier hit, et l'utilisateur bénéficie d'une navigation fluide.

Dans quels cas cette règle ne s'applique-t-elle pas ou devient-elle secondaire ?

Si votre site est monolingue ou utilise des sous-domaines strictement séparés (fr.example.com, de.example.com) avec un DNS géolocalisé, la question des cookies ne se pose pas. Chaque bot régional crawle son propre sous-domaine.

De même, si vous implémentez une négociation de contenu HTTP propre (Vary: Accept-Language, retour de contenus différents sur la même URL selon l'en-tête), Googlebot s'adapte automatiquement. Mais cette approche est rare et techniquement exigeante.

Que faut-il faire concrètement pour éviter les pièges liés aux cookies ?

Première action : auditer votre logique de redirection linguistique. Testez manuellement en désactivant les cookies dans votre navigateur, ou utilisez un outil comme cURL sans transmettre de cookie. Si vous êtes redirigé systématiquement vers une seule langue, Googlebot vivra la même chose.

Ensuite, déplacez la logique de détection côté serveur. Analysez l'en-tête Accept-Language (envoyé par Googlebot selon le datacenter d'origine), l'IP, ou implémentez un sélecteur de langue visible et crawlable en HTML. Les liens vers /fr/, /de/, /es/ doivent être accessibles sans JavaScript ni cookie.

Quelles erreurs éviter absolument dans une architecture multilingue ?

Ne redirigez jamais automatiquement un utilisateur vers une version linguistique sans lui laisser le choix. Google déteste les redirections forcées qui enferment le bot dans une boucle ou le bloquent sur une version non pertinente.

Évitez également les redirections 302 permanentes basées sur l'IP sans alternative. Si Googlebot US crawle votre site depuis la Californie, il sera toujours redirigé vers /en-us/, rendant /fr/ ou /de/ invisibles. Proposez un sélecteur de langue visible en footer ou header, crawlable, et déclarez hreflang proprement.

Comment vérifier que mon site est conforme et que Googlebot voit les bonnes versions ?

Utilisez Google Search Console et inspectez l'URL de chaque variante linguistique. L'outil « Inspection d'URL » vous montre exactement ce que Googlebot a crawlé, y compris les redirections suivies. Si /fr/ renvoie systématiquement vers /en/, vous verrez la redirection dans le rapport.

Complétez avec un test cURL sans cookies : curl -I https://example.com/fr/. Si vous obtenez un 200 avec le bon contenu, c'est bon. Si vous voyez un 302 vers /en/, vous avez un problème. Enfin, validez vos balises hreflang avec un validateur externe ou le rapport d'internationalisation de GSC.

• Auditer la logique de redirection linguistique en désactivant les cookies dans le navigateur.
• Déplacer la détection de langue côté serveur (Accept-Language, IP, paramètres d'URL).
• Implémenter un sélecteur de langue HTML crawlable, sans JavaScript obligatoire.
• Déclarer correctement les balises hreflang sur chaque variante linguistique.
• Tester chaque URL avec l'outil Inspection d'URL de Google Search Console.
• Valider les redirections avec cURL sans transmettre de cookies.