Storebot de Google fait ses achats dans votre boutique PrestaShop : ce que les marchands doivent savoir en 2026

Ouvrez la grille Clients → Paniers dans le back-office PrestaShop et vous pourriez tomber sur quelque chose d'inquiétant : des centaines de paniers sans nom de client, sans adresse, sans transporteur, seulement un produit, un horodatage, et rien d'autre. Jour après jour, à un rythme régulier, sans jamais convertir. Votre premier réflexe sera peut-être de penser que quelque chose est cassé ou que votre boutique subit une attaque. Ce n'est ni l'un ni l'autre. Dans la plupart des cas, le responsable est un robot d'exploration de Google appelé Storebot, qui fait exactement ce pour quoi Google l'a conçu : faire littéralement ses achats dans votre boutique afin de vérifier que vos fiches Google Shopping disent la vérité.

Cet article traite de ce phénomène précis sur PrestaShop : ce qu'est Storebot, comment confirmer que c'est bien lui qui remplit votre table ps_cart (et non un robot que vous devriez réellement bloquer), pourquoi le bloquer est une erreur coûteuse, et quoi faire à la place. Nous avons enquêté directement sur plusieurs boutiques PrestaShop en production en 2026 : les chemins du back-office, les formes de données en base et les étapes de vérification ci-dessous sont donc ceux du terrain, pas des suppositions vagues.

Dernière mise à jour : juin 2026.

Ce qu'est réellement Storebot-Google

Storebot est un robot d'exploration Google dédié, distinct du Googlebot qui indexe les pages pour la recherche naturelle. Son rôle est la vérification e-commerce : il charge une page produit, lit le prix et la disponibilité, puis teste si un vrai client pourrait effectivement acheter l'article en l'ajoutant au panier et en avançant vers le tunnel de commande. Il exécute JavaScript comme un vrai navigateur, ce qui compte sur PrestaShop puisque le thème par défaut ajoute les produits au panier via AJAX.

Vous pouvez le reconnaître à son user agent, qui contient le jeton littéral Storebot-Google :

Mozilla/5.0 (X11; Linux x86_64; Storebot-Google/1.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36

Lors d'une visite typique, il charge la page produit, déclenche la requête d'ajout au panier (un POST traité par le CartController de PrestaShop. La controller_class est cart, que votre URL localisée affiche /cart, /panier ou /warenkorb), vérifie que le total du panier correspond au prix de la page produit, sonde les étapes d'adresse et de livraison pour lire les frais de port et les taxes, puis repart sans commander. C'est cette dernière étape qui vous laisse avec une pile de paniers abandonnés d'une seule ligne. Il s'agit d'une vérification, pas d'un abandon au sens utile du terme.

Pourquoi ces paniers ont cette forme dans PrestaShop

La forme du panier fantôme est spécifique et reconnaissable. Lorsque nous les avons examinés sur des boutiques en production, chaque panier Storebot portait la même empreinte dans ps_cart :

• id_customer = 0, aucun client connecté
• id_guest = 0, aucune ligne de session invitée attachée
• id_carrier = 0 et id_address_delivery = 0, l'étape du choix de livraison n'a jamais été atteinte
• secure_key = '', vide

Il existe une raison propre à PrestaShop qui explique pourquoi ces paniers sont créés. CartController::updateCart vérifie depuis longtemps $this->context->cookie->exists() avant d'autoriser une modification du panier par ajout de produit, une protection destinée précisément à limiter ce type de panier fantôme (les branches plus récentes s'appuient davantage sur un contrôle Connection::isBot()). Sur les boutiques que nous avons étudiées, le robot passait tout de même parce qu'une couche de cache pleine page (l'ajout au panier AJAX dynamique qu'il utilise) lui fournit un cookie qui ne contient aucun id_guest. La ligne invitée elle-même n'est normalement créée que par un hook de statistiques dans l'en-tête de page ; avec le cache pleine page, ce hook ne s'exécute souvent pas, de sorte que le front controller construit un panier avec id_guest = 0 et une clé sécurisée vide.

Qu'est-ce que cela signifie pour vous ? Deux choses. D'abord, la forme « invité vide » est un effet secondaire du cache, pas la preuve d'un robot, ce qui mène directement à la section suivante. Ensuite, comme aucune session invitée n'est attachée, les propres mécanismes de relance de panier et d'attribution visiteur de PrestaShop se cassent silencieusement pour ces lignes : il n'y a personne à contacter par e-mail, rien à rattacher à une session, et pourtant ces paniers restent dans vos tables en gonflant tous les compteurs.

Commencez par confirmer qu'il s'agit bien de Storebot, ne devinez pas

C'est l'étape que la plupart des conseils du type « supprimez simplement les paniers » passent sous silence, alors que c'est elle qui vous évite de supprimer de vrais clients. La forme du panier invité vide n'est pas un marqueur de robot fiable à elle seule. Sur une boutique PrestaShop avec cache pleine page et une table ps_connections vide, un vrai acheteur sans cookie, par exemple un trafic d'annonce payante arrivant avec un gclid et sans cookie préalable, produit un panier orphelin identique. Si vous purgez uniquement sur la forme, vous pouvez supprimer de vrais paniers abandonnés et fausser votre propre tunnel de relance.

Vérifiez dans le journal d'accès, pas dans la table des paniers. Deux contrôles, dans cet ordre :

• User agent + source IP. Retrouvez les requêtes qui ont créé les paniers dans le vrai journal d'accès de votre serveur web (sur nginx, il s'agit généralement de /var/log/nginx/access.log ; notez que les domlogs Apache excluent souvent le trafic proxifié, vérifiez donc le bon fichier). Les requêtes Storebot authentiques viennent des plages de Google, nous avons confirmé des visites depuis 64.233.172.x, 66.102.8.x, 66.249.92.x, 72.14.199.x et 192.178.11.x.
• DNS inversé confirmé par résolution directe. Ne faites pas confiance à la seule IP ni à la seule chaîne UA. Les deux peuvent être usurpées. Lancez une recherche DNS inversée sur l'IP (les visites Google authentiques résolvent vers un nom d'hôte *.google.com / google-proxy-* / rate-limited-proxy-*.google.com), puis résolvez ce nom d'hôte en sens direct et confirmez qu'il renvoie la même IP. Storebot-Google respecte robots.txt (voir la dernière section), et Google publie les plages IP de ses robots dans sa documentation officielle sur les IP de robots d'exploration, consultez le fichier de la catégorie de robot concernée pour confirmer une IP Storebot vérifiée, au lieu de supposer qu'une seule liste les couvre toutes.

Si l'UA prétend être Storebot mais que la confirmation DNS inversé/direct échoue, vous avez affaire à un imposteur qui se fait passer pour Google, et ce trafic-là peut être traité différemment. Les visites vérifiées, elles, doivent être conservées.

Pourquoi bloquer Storebot est l'erreur qui coûte cher

La réaction tentante, une règle de pare-feu, un Disallow dans robots.txt, un 403 sur la route panier pour cet UA, se retourne contre vous, et via un système que vous ne contrôlez pas : Google Merchant Center.

• Bloquez l'UA et vos produits risquent d'être refusés. La documentation de Google indique clairement qu'il est « fortement recommandé » de laisser le robot accéder à vos pages. Si Storebot ne peut pas vérifier votre tunnel de commande, vos articles risquent des refus pour page de destination ou incohérence de prix, et disparaissent des annonces Shopping comme des fiches gratuites.
• Ne ciblez pas non plus uniquement le POST du panier. Autoriser la lecture des pages produit mais bloquer la soumission d'ajout au panier casse précisément ce que Storebot est censé vérifier, la cohérence du prix dans le panier, ce qui constitue en soi un motif de refus.
• Ne bloquez jamais les plages IP au pare-feu. Les plages 66.249.* et 66.102.* sont partagées avec le Googlebot classique. Les bloquer revient aussi à désindexer votre boutique de la recherche naturelle, une perte bien plus grave que quelques lignes de panier en trop.

La lecture honnête est la suivante : la visite de Storebot est un audit gratuit qui confirme que vos fiches sont exactes, et les fiches exactes sont affichées plus souvent. Vous voulez qu'il explore votre boutique. Le problème à résoudre n'est pas le robot. Ce sont les traces qu'il laisse derrière lui.

Le vrai coût : les paniers de robots faussent vos analyses

Les paniers fantômes ne sont pas qu'un encombrement. Ils empoisonnent discrètement les chiffres sur lesquels vous prenez vos décisions :

• Votre taux d'abandon est fictif. Si Storebot crée sept paniers par heure et que presque aucun ne convertit, le taux panier-commande affiché dans le back-office paraît bien pire que la réalité. Nous avons observé des périodes où les paniers de robots étaient plusieurs fois plus nombreux que les vrais paniers sur quelques jours.
• Les tables ps_cart et ps_cart_product grossissent sans fin, et sur les hébergements aux ressources de base de données modestes, cette charge se manifeste par des requêtes panier et admin plus lentes.
• Les automatisations de relance gaspillent leurs efforts. Comme ces lignes n'ont pas de vrai client ni de session exploitable, tout processus de relance de panier les ignore (dans le meilleur des cas) ou dépense des cycles à tenter d'agir sur un contact qui n'existe pas.

Décider quels paniers sont des robots et lesquels sont réels, avant de faire confiance à un chiffre de conversion, relève de la même discipline que toute mesure sérieuse en boutique : savoir quoi compter et quoi ignorer. Nous abordons cet état d'esprit dans les analyses pour boutiques en ligne : quoi suivre et quoi ignorer, ainsi que la version spécifique à GA4 du filtrage de ce bruit dans les métriques GA4 qui comptent vraiment.

Que faire à la place : garder le robot, nettoyer les traces

1. Assurez-vous que Storebot trouve exactement ce que votre flux a promis

La mesure la plus efficace consiste à offrir au robot une vérification propre, pour que sa visite passe sans rien déclencher. Le flux, les données structurées, la page produit, le panier et le tunnel de commande doivent tous indiquer le même prix (taxes et devise comprises) et la même disponibilité. Sur PrestaShop, cela signifie que votre module de flux lit les prix et les stocks en direct, et que vos pages produit portent un balisage schema.org/Product correct avec price, priceCurrency, availability et brand. Si vous envoyez vos fiches via l'API Merchant, confirmez que votre module de flux prend en charge v1. L'ancienne Content API for Shopping est en cours de retrait en 2026, donc un module de flux obsolète devient une source d'incohérences prête à exploser.

2. Gérez correctement les pages produit en rupture de stock

Google s'attend à ce qu'une page produit en rupture de stock affiche clairement son indisponibilité, empêche l'achat, et que cette disponibilité corresponde exactement à votre flux et à vos données structurées. Un bouton d'achat visiblement désactivé (grisé, avec l'attribut HTML disabled) est une implémentation acceptable, à condition de rester cohérente avec la disponibilité dans le flux et le schéma. De nombreux thèmes PrestaShop masquent plutôt entièrement le bouton d'ajout au panier lorsque le stock tombe à zéro, vérifiez le product.tpl / modèle produit de votre thème. Storebot teste cela directement : il ne doit pas pouvoir ajouter un article en rupture de stock, et il doit pouvoir ajouter un article disponible.

3. Nettoyez les paniers de robots selon un planning, mais protégez la suppression

Le nettoyage périodique est la solution pratique à l'encombrement de la base de données, et les paniers sont identifiables : id_customer = 0, id_guest = 0 (ou une ligne invitée portant un UA Storebot), id_carrier = 0, id_address_delivery = 0, créés depuis une IP Google vérifiée. La partie protégée compte autant que la correspondance : avant de supprimer, confirmez que le panier n'a aucune commande associée, aucun client, aucune adresse, et (comme expliqué plus haut) qu'il a été créé par une IP Storebot confirmée par DNS inversé/direct, jamais par sa seule forme.

Un piège très spécifique à PrestaShop si vous écrivez votre propre SQL de nettoyage ou votre propre cron : PrestaShop écrit ses valeurs date_add avec l'horloge PHP, pas celle de MySQL. Sur un hébergement où le fuseau horaire de la base de données diffère de celui de PHP, un filtre d'âge construit sur NOW() / DATE_SUB(NOW(), ...) peut juger tous les paniers comme fraîchement actifs et ne rien purger en silence (ou supprimer les mauvaises lignes). Calculez votre seuil à partir de l'horloge applicative, et supprimez toujours les lignes ps_cart_product correspondantes en même temps que les lignes ps_cart afin de ne pas laisser d'articles orphelins.

4. Excluez les paniers de robots de vos rapports et relances

Votre vrai taux d'abandon est celui calculé uniquement à partir des paniers avec un vrai client ou une session invitée identifiée. Excluez les paniers anonymes de robots vérifiés de votre tunnel de conversion, et assurez-vous que toute automatisation de relance de panier les filtre afin qu'elle n'agisse pas sur des lignes qui n'ont jamais correspondu à une personne. Cette séparation vous permet enfin d'obtenir un vrai taux panier-commande au lieu d'un chiffre gonflé par Storebot, le type de métrique claire, utile au marchand, qui a sa place dans les rapports avancés de votre boutique.

5. Réduisez l'exploration non commerciale avec robots.txt (sans toucher aux produits ni au panier)

Vous pouvez réduire l'exploration inutile sans compromettre la vérification en orientant Storebot loin des URL sans valeur commerciale, jamais des pages produit ni de la route panier elle-même :

User-agent: Storebot-Google, puis Disallow: /*?order=, Disallow: /*?utm_, et enfin Allow: / afin que tout le reste, pages produit et route panier incluses, reste explorable.

Faire tout cela sans développeur : Spam Cart Blocker

Le flux de travail « vérifier puis purger en sécurité » ci-dessus est correct, mais le faire à la main, analyse des journaux, confirmation DNS inversé/direct, cron compatible avec les fuseaux horaires, suppressions protégées qui ne touchent jamais une vraie commande, demande beaucoup de maintenance. Nous avons construit Spam Cart Blocker pour nos propres boutiques précisément parce que les alternatives disponibles se trompaient dangereusement : les rares modules sur ce sujet bloquent les paniers de robots (ce qui, comme expliqué plus haut, peut faire suspendre vos produits dans Merchant Center) ou suppriment brutalement par ancienneté sans savoir si le panier venait d'un robot ou d'un vrai acheteur sans cookie.

Concrètement, que fait-il pour vous ? Il classe les paniers en vérifiant l'identité du robot par DNS inversé confirmé en résolution directe. Ainsi, un Storebot vérifié est reconnu et un imposteur qui usurpe l'UA ne l'est pas, puis il marque et purge avec TTL les vrais paniers de robots tout en laissant intacts ceux qui ont une commande, un client, une adresse ou une vraie session. Il ne bloque jamais Google, donc vos fiches restent protégées. Il répare la création d'invité cassée sous cache pleine page afin que l'attribution de vos vrais paniers recommence à fonctionner. Et il fait apparaître la réalité dans le back-office : une répartition robot-versus-humain de vos paniers et votre vrai taux de paniers abandonnés, plus une intelligence panier par visiteur : le tout configuré depuis l'administration, sans override du cœur, donc compatible avec les mises à jour. En bref, il transforme l'enquête manuelle de cet article en un réglage à cocher une seule fois.

Questions fréquentes

Pourquoi ma table de paniers PrestaShop se remplit-elle de paniers vides qui ne convertissent jamais ?

Dans la plupart des cas, c'est Storebot-Google, un robot Google dédié, distinct du Googlebot qui indexe les pages, qui vérifie que vos fiches Google Shopping disent la vérité. Il charge une page produit, ajoute l'article au panier pour vérifier que le prix correspond, sonde les étapes de livraison pour lire les frais de port et les taxes, puis repart sans commander. Chaque visite laisse un panier d'une seule ligne avec id_customer = 0, id_guest = 0, id_carrier = 0 et une clé sécurisée vide. C'est de la vérification, pas de l'abandon.

Dois-je bloquer Storebot pour arrêter les paniers fantômes ?

Non, c'est l'erreur coûteuse. La documentation de Google indique clairement qu'il est fortement recommandé de laisser le robot accéder à vos pages. Bloquez le user agent, le POST du panier ou, pire encore, les plages IP, et vos produits risquent des refus pour page de destination ou incohérence de prix dans Merchant Center, avec disparition des annonces Shopping et des fiches gratuites. Les plages 66.249.* et 66.102.* sont partagées avec le Googlebot classique : un blocage au pare-feu vous désindexe donc aussi de la recherche naturelle. Gardez le robot ; nettoyez les traces.

Comment confirmer qu'un panier a été créé par le vrai Storebot et non par un vrai acheteur ?

Vérifiez dans le journal d'accès, pas dans la table des paniers, la forme « invité vide » seule n'est pas un marqueur de robot fiable, car un vrai acheteur sans cookie arrivant avec un gclid sous cache pleine page produit un panier orphelin identique. Contrôlez le user agent et l'IP source dans le journal d'accès de votre serveur web, puis lancez une vérification DNS inversée confirmée par résolution directe : l'IP doit résoudre vers un nom d'hôte *.google.com / google-proxy-* qui, une fois résolu en sens direct, renvoie la même IP. Si ce n'est pas le cas, c'est un imposteur qui prétend être Google.

Quel est le piège propre à PrestaShop quand on écrit du SQL de nettoyage pour les paniers de robots ?

Le fuseau horaire. PrestaShop écrit date_add avec l'horloge PHP, pas celle de MySQL. Sur un hébergement où le fuseau horaire de la base de données diffère de celui de PHP, un filtre d'âge basé sur DATE_SUB(NOW(), ...) peut mal juger chaque panier et ne rien purger en silence, ou supprimer les mauvaises lignes. Calculez votre seuil à partir de l'horloge applicative, supprimez toujours les lignes ps_cart_product correspondantes en même temps que les lignes ps_cart, et protégez la suppression pour qu'elle ne touche jamais un panier associé à une commande, un client ou une adresse.

Puis-je réduire l'exploration de Storebot sans compromettre la vérification ?

Oui, éloignez-le uniquement des URL non commerciales, jamais des pages produit ni de la route panier. Un bloc robots.txt sûr cible les URL à paramètres sans valeur commerciale :

User-agent: Storebot-Google
Disallow: /*?order=
Disallow: /*?utm_
Allow: /

N'oubliez pas que Disallow empêche l'exploration de ces URL, pas l'indexation de pages liées ailleurs, c'est un outil de budget d'exploration, pas un contrôle d'indexation. Gardez les pages produit et la route panier entièrement explorables afin que la vérification continue de passer.

Le faire en sécurité sans développeur

Le flux « vérifier puis purger » ci-dessus, analyse des journaux, DNS inversé confirmé par résolution directe, cron compatible avec les fuseaux horaires, suppressions protégées, demande beaucoup de maintenance manuelle. Spam Cart Blocker classe les paniers en vérifiant l'identité du robot (un Storebot vérifié est donc reconnu, un imposteur qui usurpe l'UA ne l'est pas), purge avec TTL les vrais paniers de robots tout en laissant intacts ceux qui ont une commande, un client ou une vraie session, ne bloque jamais Google, et affiche votre vrai taux de paniers abandonnés dans le back-office. Si votre boutique est déjà ensevelie sous les paniers de robots, notre Cleanup Revolution gère le nettoyage planifié de la base de données, et Google Analytics GA4 garde vos chiffres de conversion fiables une fois le bruit des robots filtré.

Et demain : Storebot n'est que le début

L'exploration par Storebot augmente, elle ne disparaît pas, car Google avance vers des agents d'achat IA capables d'agir pour le compte d'un client, vérifier les prix, contrôler le stock et potentiellement finaliser des achats dans votre tunnel de commande. Quelle que soit votre opinion sur cette direction, l'implication pratique pour un marchand PrestaShop reste celle défendue tout au long de cet article : les boutiques dont le flux, les données structurées, les pages produit et le panier racontent tous la même histoire sont celles auxquelles un robot, piloté par un humain ou par un agent, peut faire confiance. Celles qui présentent des incohérences de prix, des boutons de rupture de stock masqués et une table ps_cart remplie de déchets non examinés sont filtrées avant même qu'un acheteur les voie.

La conclusion n'est donc pas « supprimez les paniers bizarres ». Elle est : confirmez ce qu'ils sont, accueillez la vérification qui garde vos fiches en ligne, et nettoyez derrière elle selon les règles de PrestaShop, suppressions protégées, cron correct sur les fuseaux horaires, et analyses qui comptent des personnes plutôt que des robots. Faites cela correctement et Storebot cesse d'être un mystère dans votre base de données pour devenir ce qu'il devait toujours être : un audit gratuit et continu qui confirme que votre boutique est prête à vendre.