Googlebot conserve-t-il vraiment les cookies entre les sessions de crawl ?

Pourquoi Googlebot refuse-t-il de jouer le jeu des cookies persistants ?

Le fonctionnement de Googlebot est fondamentalement différent de celui d'un navigateur classique. Un utilisateur humain navigue, clique, revient, et son navigateur stocke des cookies qui maintiennent l'état de session d'une visite à l'autre. Googlebot, lui, ne fonctionne pas comme ça.

Chaque page crawlée est traitée comme une session isolée et éphémère. Le bot arrive, charge la page, exécute le JavaScript si nécessaire, rend le DOM, puis repart sans conserver la moindre trace de cookie. La prochaine URL crawlée — même sur le même domaine, même deux secondes plus tard — repart de zéro.

Qu'est-ce que ça change pour le rendu côté serveur ou client ?

Si votre site sert du contenu conditionnel basé sur des cookies — par exemple un mur de consentement qui cache le contenu jusqu'à validation, ou un système de géolocalisation qui affiche des variantes selon une préférence stockée — Googlebot va voir la version "première visite sans cookie".

Côté rendu JavaScript, c'est encore plus critique. Beaucoup de frameworks SPA (React, Vue, Angular) utilisent des cookies ou le localStorage pour gérer l'état applicatif. Si votre logique de rendu attend un token de session ou un flag stocké, le bot verra une page vide ou incomplète. Le serveur doit donc délivrer un HTML complet et autonome dès la première requête, sans dépendre d'un état préalable.

Cette limitation s'applique-t-elle aussi aux autres bots de Google ?

Oui. Tous les crawlers Google — Googlebot Desktop, Googlebot Smartphone, Google-InspectionTool (utilisé par la Search Console), Storebot pour Google Shopping — partagent ce comportement. Aucun ne persiste les cookies entre requêtes.

Cela signifie que même si vous testez avec l'outil d'inspection d'URL de la Search Console, vous simulez une visite sans session. Si le rendu est cassé, c'est ce que Google voit réellement dans son index.

• Googlebot ne stocke jamais de cookies entre deux requêtes, même successives sur le même domaine.
• Chaque page crawlée doit être autonome et complète dès la première visite, sans état de session préalable.
• Les sites qui utilisent des cookies pour afficher du contenu (consentement, géoloc, préférences) risquent un rendu incomplet pour le bot.
• Cette règle s'applique à tous les crawlers Google, y compris l'outil d'inspection d'URL.
• Le rendu JavaScript doit être totalement indépendant du localStorage ou des cookies pour être indexé correctement.

Cette déclaration est-elle cohérente avec les observations terrain ?

Totalement. Sur des milliers d'audits SEO, on constate systématiquement que les sites qui cachent du contenu derrière un consentement cookie — RGPD oblige — se retrouvent avec des pages crawlées mais vides ou partielles dans l'index. Google voit la bannière, mais pas le contenu en dessous.

Les logs serveur confirment : chaque hit de Googlebot arrive sans en-tête Cookie, même quand le bot crawle 50 URLs du même domaine en rafale. Aucune persistance. C'est un comportement documenté, stable depuis des années, et Mueller le rappelle ici sans détour. Pas de surprise, donc — mais un piège classique pour les sites mal configurés.

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

Attention : Googlebot accepte et lit les cookies lors d'une session unique. Si votre serveur envoie un Set-Cookie dans la réponse initiale, et que votre JavaScript fait ensuite une requête AJAX pour charger du contenu sur la même page, le bot renverra ce cookie dans cette même session. C'est documenté dans les specs de rendu.

Le problème, c'est la persistance entre sessions de crawl distinctes. Si Googlebot crawle votre homepage aujourd'hui, puis revient dans 3 jours, il n'aura aucun souvenir du cookie reçu la première fois. Chaque visite est un clean slate. [A verifier] en revanche : le comportement exact de Googlebot face aux cookies SameSite=None ou Secure dans un contexte HTTPS multidomaine reste peu documenté côté Google.

Dans quels cas cette règle pose-t-elle des problèmes réels ?

Les murs de consentement RGPD mal implémentés sont le cas numéro un. Si votre site bloque tout le contenu tant que l'utilisateur n'a pas cliqué "Accepter" (et que ce clic écrit un cookie), Googlebot ne verra rien. Même chose pour les paywalls qui stockent un compteur d'articles gratuits en cookie.

Les sites e-commerce avec sélection de devise ou de langue via cookie rencontrent aussi des soucis. Si le contenu varie selon une préférence stockée, le bot verra toujours la version par défaut — parfois la mauvaise langue, parfois une page vide si le serveur attend un cookie pour savoir quoi afficher. Il faut passer par des URL distinctes ou du header Accept-Language, pas des cookies.

Que faut-il faire concrètement pour garantir un rendu optimal ?

D'abord, auditez vos bannières de consentement. Si elles cachent le contenu via CSS ou JavaScript jusqu'à validation, c'est un red flag. La bonne pratique : afficher le contenu complet en HTML, et superposer la bannière en overlay sans bloquer le rendu sous-jacent. Googlebot ignore les overlays visuels, mais crawle le DOM complet.

Ensuite, testez systématiquement avec l'outil d'inspection d'URL de la Search Console. Il simule exactement le comportement de Googlebot : aucun cookie, aucun état. Si le rendu live diffère du rendu HTML brut, vous avez un problème. Comparez aussi avec un navigateur en mode navigation privée, cookies désactivés — c'est un bon proxy du comportement du bot.

Quelles erreurs éviter absolument ?

Ne stockez jamais de logique de rendu critique dans localStorage ou sessionStorage côté client. Ces APIs sont persistées dans un navigateur classique, mais Googlebot ne les maintient pas entre requêtes. Même chose pour les cookies : si votre app React attend un token JWT en cookie pour afficher les produits, le bot verra une page vide.

Évitez aussi les redirections ou variantes de contenu basées uniquement sur des cookies. Si vous devez géolocaliser, utilisez le header Accept-Language ou l'IP, mais servez toujours un HTML complet par défaut. Ne partez jamais du principe que le bot "se souviendra" d'une préférence stockée lors d'un crawl précédent — il ne le fera pas.

Comment vérifier que mon site est conforme à cette contrainte ?

Mettez en place un monitoring des logs serveur filtré sur le user-agent Googlebot. Vérifiez que chaque requête arrive sans en-tête Cookie, ou avec uniquement les cookies que vous envoyez vous-même dans la réponse initiale. Aucun cookie ne doit persister d'une session à l'autre.

Ensuite, crawlez votre site avec un bot simulant Googlebot (Screaming Frog, Oncrawl, Botify) en désactivant la gestion des cookies. Comparez le rendu obtenu avec celui d'un crawl classique. Toute différence indique une dépendance problématique. Automatisez ce test dans votre CI/CD pour détecter les régressions avant mise en prod.

• Auditez vos bannières de consentement : le contenu doit rester visible en HTML même sans validation cookie.
• Testez chaque page critique avec l'outil d'inspection d'URL de la Search Console pour vérifier le rendu sans état.
• Ne stockez jamais de logique d'affichage dans localStorage, sessionStorage ou cookies côté client.
• Évitez les redirections ou variantes de contenu basées uniquement sur des cookies — privilégiez les URL distinctes.
• Monitorez vos logs serveur pour vérifier que Googlebot arrive toujours sans cookies persistés.
• Automatisez un crawl sans cookies dans votre pipeline de tests pour détecter les régressions.