Google conserve-t-il vraiment les cookies entre chaque rendu de page ?

Que signifie exactement « rendu sans état » ?

Googlebot active bien les cookies au niveau du navigateur pendant qu'il exécute le JavaScript d'une page. Si votre code définit un cookie durant cette phase, Google le détecte et peut l'utiliser le temps de ce rendu spécifique.

Le hic ? Chaque passage de Googlebot démarre une session navigateur vierge. Les cookies créés lors d'un premier crawl n'existent plus au second. Le bot oublie tout entre deux visites, comme un navigateur en mode navigation privée perpétuelle.

Pourquoi cette approche pose-t-elle problème en SEO ?

Nombre de sites modernes s'appuient sur des cookies pour gérer l'affichage conditionnel de contenus. Pensez aux systèmes de paywalls progressifs, aux messages de bienvenue pour nouveaux visiteurs, ou aux barres d'urgence qui disparaissent après acceptation.

Si votre logique repose sur « l'utilisateur a-t-il déjà vu ce contenu ? », Googlebot répondra toujours non. Chaque visite ressemble à la toute première. Résultat : le bot peut indexer une version qui diffère de celle vue par vos visiteurs récurrents.

Cette limitation s'applique-t-elle à tous les types de cookies ?

Oui, sans distinction. Que ce soit un cookie de session classique, un cookie HttpOnly, ou un cookie défini côté client via JavaScript, aucun ne survit au-delà du rendu en cours.

La seule exception théorique : les mécanismes qui ne reposent pas sur des cookies (localStorage, sessionStorage) — mais Google a déjà précisé que le stockage local suit la même logique d'isolation totale entre rendus.

• Les cookies fonctionnent durant un rendu, mais ne persistent jamais d'une visite à l'autre
• Chaque crawl démarre avec un état navigateur complètement vierge
• Les contenus conditionnés par des cookies multi-sessions restent invisibles ou incohérents pour Googlebot
• Aucune différence de traitement entre cookies serveur et cookies JavaScript

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

Sur le papier, oui — et les tests en environnement contrôlé le confirment. Un bot qui simule Googlebot (via Puppeteer ou Selenium configuré en headless) montre bien cette isolation totale des sessions.

En pratique, certains sites ont rapporté des comportements étranges : Google semblait « se souvenir » d'interactions précédentes sur des propriétés complexes avec redirections multiples. [À vérifier] — il pourrait s'agir d'artefacts liés au cache DNS ou à des headers HTTP spécifiques, pas à une persistance réelle des cookies.

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

Zoe Clifford parle de « session de navigateur complètement nouvelle ». Techniquement exact. Mais elle n'évoque pas le cas des cookies définis côté serveur via Set-Cookie avant même le rendu.

Si votre serveur envoie un cookie dans les headers HTTP lors du premier hit, puis que Googlebot revient une seconde fois dans la même séquence de crawl (refresh rapide, pagination), ce cookie pourrait théoriquement être renvoyé — si le bot maintient une session TCP/HTTP2 ouverte. Soyons honnêtes : Google ne documente pas ce niveau de granularité, et les tests montrent que même ce scénario reste aléatoire.

Dans quels contextes cette limitation devient-elle critique ?

Trois cas typiques où l'absence de persistance des cookies casse tout :

• Paywalls et systèmes freemium : si vous offrez 3 articles gratuits avant de bloquer, Googlebot voit toujours « article 1 sur 3 » — ou pire, le mur complet si la logique est mal codée.
• A/B testing côté client : Google peut indexer tantôt la variante A, tantôt la B, créant du contenu dupliqué involontaire.
• Bannières légales (RGPD, cookies) : si elles masquent du contenu principal tant que l'utilisateur n'a pas cliqué « Accepter », et que ce clic pose un cookie… Googlebot ne cliquera jamais et indexera la version obstruée.

Que faut-il faire concrètement pour éviter les problèmes ?

Première étape : auditer toute logique conditionnelle pilotée par des cookies. Listez les scripts qui lisent ou écrivent des cookies avant d'afficher du contenu. Identifiez ceux qui bloquent, masquent ou modifient des sections entières.

Ensuite, remplacez ces mécanismes par des alternatives compatibles avec un environnement sans état. Typiquement : détecter Googlebot via le user-agent (imparfait mais utile en complément), utiliser des paramètres d'URL pour tracer l'état, ou mieux, conditionner l'affichage côté serveur en fonction de headers HTTP plutôt que de cookies.

Quelles erreurs éviter absolument ?

Ne cachez jamais du contenu stratégique derrière un cookie de « première visite ». Google ne verra que la version initiale, potentiellement vide ou tronquée.

Évitez aussi de rediriger conditionnellement en fonction d'un cookie — par exemple, renvoyer les « nouveaux » vers une landing spéciale. Googlebot, éternellement « nouveau », bouclera sur cette page sans jamais explorer le reste du site. Et c'est là que ça coince : votre maillage interne devient invisible.

Comment vérifier que mon site gère bien ce cas ?

• Testez votre site en navigation privée, fermez et rouvrez l'onglet entre chaque page — simulez l'amnésie de Googlebot
• Utilisez la Search Console et l'outil « Inspection d'URL » pour comparer le HTML rendu par Google vs. celui vu par un visiteur classique
• Auditez vos scripts : repérez tous les document.cookie, setCookie(), et vérifiez leur impact sur l'affichage
• Implémentez une détection serveur de Googlebot (via user-agent + reverse DNS) pour servir une version sans dépendance aux cookies
• Loguez les requêtes de Googlebot côté serveur : vérifiez qu'aucun cookie n'est renvoyé d'une visite à l'autre