Google Storebot 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 pouvez tomber sur quelque chose d’inquiétant : des centaines de paniers sans nom de client, sans adresse, sans transporteur — juste un produit, un horodatage, et rien d’autre. Jour après jour, au goutte-à-goutte, sans jamais convertir. Votre premier réflexe sera de penser que quelque chose est cassé ou que vous subissez une attaque. Dans la plupart des cas, ce n’est ni l’un ni l’autre. Le responsable est un crawler Google appelé Storebot, et il fait exactement ce pour quoi Google l’a conçu : il fait littéralement ses achats dans votre boutique pour vérifier que vos annonces 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 bot que vous devriez réellement bloquer), pourquoi le bloquer coûte cher, et quoi faire à la place. Nous avons enquêté directement sur plusieurs boutiques PrestaShop en production en 2026, donc les chemins du back office, les formes de base de données et les étapes de vérification ci-dessous sont réels, pas théoriques.

Ce qu’est réellement Storebot-Google

Storebot est un crawler Google dédié, distinct du Googlebot qui indexe les pages pour la recherche organique. 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 réellement acheter l’article en l’ajoutant au panier et en avançant vers le checkout. Il rend le JavaScript comme un vrai navigateur, ce qui compte sur PrestaShop parce que le thème par défaut ajoute au panier via AJAX.

Vous pouvez le reconnaître à son user agent, qui contient le token 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 — le controller_class est cart, que votre URL localisée dise /cart, /panier ou /warenkorb), vérifie que le total du panier correspond au prix de la page produit, avance vers les étapes adresse et livraison pour lire les frais de port et les taxes, puis repart sans commander. Cette dernière étape explique pourquoi vous vous retrouvez avec une pile de paniers abandonnés d’une seule ligne. C’est de la vérification, pas de l’abandon au sens utile.

Pourquoi ces paniers ont cette forme dans PrestaShop

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

• id_customer = 0 — aucun client connecté
• id_guest = 0 — aucune ligne de session visiteur attachée
• id_carrier = 0 et id_address_delivery = 0 — jamais arrivé au choix de livraison
• secure_key = '' — vide

Il existe une raison spécifique à PrestaShop pour laquelle ces paniers sont créés. CartController::updateCart vérifie depuis longtemps $this->context->cookie->exists() avant d’autoriser un changement de panier — une garde destinée à limiter précisément ce type de panier fantôme (les branches récentes s’appuient davantage sur un contrôle Connection::isBot()). Sur les boutiques que nous avons étudiées, le bot passait quand même parce qu’une couche de full-page cache (l’ajout au panier AJAX dynamique qu’il utilise) lui donne un cookie sans id_guest. La ligne guest elle-même est normalement créée par un hook de statistiques dans l’en-tête de page ; avec le full-page cache, ce hook ne s’exécute souvent pas, donc le contrôleur front construit un panier avec id_guest = 0 et une secure key vide.

Qu’est-ce que cela signifie pour vous ? Deux choses. D’abord, la forme sans guest est un effet secondaire du cache, pas une preuve de bot — ce qui mène directement à la section suivante. Ensuite, comme aucune session guest n’est attachée, les propres mécanismes de récupération de panier et d’attribution visiteur de PrestaShop cassent silencieusement pour ces lignes : il n’y a personne à relancer, rien à rattacher à une session, et pourtant elles restent dans vos tables en gonflant tous les compteurs.

Commencez par confirmer que c’est vraiment Storebot — ne devinez pas

C’est l’étape que la plupart des conseils du type « supprimez simplement les paniers » ignorent, et c’est celle qui vous évite de supprimer de vrais clients. La forme de panier sans guest n’est pas un marqueur de bot fiable à elle seule. Sur une boutique PrestaShop avec full-page cache et une table ps_connections vide, un vrai visiteur sans cookie — par exemple un trafic payant arrivant avec un gclid et sans cookie préalable — produit un panier orphelin identique. Si vous purgez uniquement selon la forme, vous pouvez supprimer de vrais paniers abandonnés et fausser votre propre tunnel de récupération.

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, c’est généralement /var/log/nginx/access.log ; notez que les domlogs Apache excluent souvent le trafic proxifié, donc vérifiez le bon fichier). Les requêtes Storebot authentiques viennent des plages Google — nous avons confirmé des hits depuis 64.233.172.x, 66.102.8.x, 66.249.92.x, 72.14.199.x et 192.178.11.x.
• Reverse DNS confirmé en avant. Ne faites pas confiance à l’IP ou à la chaîne UA seule — les deux peuvent être usurpées. Lancez une résolution reverse DNS sur l’IP (les hits Google authentiques résolvent vers *.google.com / google-proxy-* / rate-limited-proxy-*.google.com), puis résolvez ce nom d’hôte en avant et confirmez qu’il retourne la même IP. Storebot-Google respecte robots.txt (voir la dernière section), et Google publie les plages IP de ses crawlers dans sa documentation officielle — vérifiez le fichier correspondant à la catégorie de crawler pertinente pour confirmer une IP Storebot vérifiée, au lieu de supposer qu’une seule liste couvre tout.

Si l’UA prétend être Storebot mais que la confirmation reverse-DNS vers l’avant échoue, vous regardez un imposteur qui se fait passer pour Google — et ce trafic peut être traité différemment. Les hits vérifiés, eux, doivent rester.

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

La réaction tentante — une règle firewall, un Disallow dans robots.txt, un 403 sur la route panier pour cet UA — se retourne contre vous, 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 Google indique clairement qu’autoriser le crawler à atteindre vos pages est fortement encouragé. Si Storebot ne peut pas vérifier votre checkout, vos articles risquent des refus pour page de destination ou prix incohérent, et sortent des annonces Shopping et des listings gratuits.
• Ne ciblez pas non plus le POST panier. Autoriser la lecture des pages produit mais bloquer la soumission d’ajout au panier casse exactement ce que Storebot doit vérifier — la cohérence du prix dans le panier — qui est elle-même un déclencheur de refus.
• Ne bloquez jamais les plages IP au firewall. Les plages 66.249.* et 66.102.* sont partagées avec le Googlebot classique. Les bloquer désindexe aussi votre boutique de la recherche organique — une perte bien plus importante que quelques lignes de panier en plus.

Le cadrage honnête : la visite de Storebot est un audit gratuit qui confirme que vos listings sont exacts, et les listings exacts sont diffusés plus souvent. Vous voulez qu’il crawle. Le problème à résoudre n’est pas le crawler — ce sont les débris qu’il laisse derrière lui.

Le vrai coût : les paniers bot mentent à vos analytics

Les paniers fantômes ne sont pas seulement du désordre. Ils empoisonnent discrètement les chiffres sur lesquels vous prenez des décisions :

• Votre taux d’abandon devient fictif. Si Storebot crée sept paniers par heure et qu’aucun ne convertit, votre taux panier-commande dans le back office paraît bien pire que la réalité. Nous avons vu des périodes où les paniers bot dépassaient les paniers réels de plusieurs fois sur quelques jours.
• Les tables ps_cart et ps_cart_product grossissent sans fin, et sur les hébergements aux ressources base de données modestes, cette charge se voit dans la lenteur des requêtes panier et admin.
• Les automatisations de récupération gaspillent des efforts. Comme ces lignes n’ont pas de vrai client ni de session exploitable, tout processus de récupération de panier les saute (meilleur cas) ou consomme des cycles à tenter d’agir sur un contact qui n’existe pas.

Décider quels paniers sont des bots et lesquels sont réels, avant de faire confiance à un chiffre de conversion, relève de la même discipline que toute mesure en boutique — savoir quoi compter et quoi ignorer. Nous couvrons cet état d’esprit dans analytics for online stores: what to track and what to ignore, et la version spécifique GA4 de ce filtrage du bruit dans the GA4 metrics that actually matter.

Que faire à la place : garder le crawler, nettoyer les débris

1. Assurez-vous que Storebot trouve exactement ce que votre feed promet

Le geste le plus efficace est de donner au crawler une vérification propre, pour que sa visite passe sans rien déclencher. Feed, données structurées, page produit, panier et checkout doivent tous être d’accord sur le prix (taxes et devise incluses) et la disponibilité. Sur PrestaShop, cela signifie que votre module de feed lit les prix et stocks live, et que vos pages produit portent un balisage schema.org/Product correct avec price, priceCurrency, availability et brand. Si vous poussez les listings via Merchant API, confirmez que votre module de feed prend en charge v1 — l’ancienne Content API for Shopping est retirée en 2026, donc un module de feed obsolète devient une source de mismatches.

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

Google attend qu’une page produit en rupture affiche clairement son indisponibilité, empêche l’achat, et que cette disponibilité corresponde exactement au feed et aux données structurées. Un bouton d’achat visiblement désactivé (grisé, avec l’attribut HTML disabled) est une implémentation acceptable, tant qu’elle reste cohérente avec votre feed et la disponibilité schema. Beaucoup de thèmes PrestaShop masquent au contraire le bouton d’ajout au panier quand le stock tombe à zéro — vérifiez le product.tpl / template produit de votre thème. Storebot teste cela directement : il ne doit pas pouvoir ajouter un article en rupture, et il doit pouvoir ajouter un article en stock.

3. Nettoyez les paniers bot selon un planning — mais protégez la suppression

Le nettoyage périodique est le correctif pratique contre le gonflement de la base, et les paniers sont identifiables : id_customer = 0, id_guest = 0 (ou une ligne guest 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 le match : avant de supprimer, confirmez que le panier n’a pas de commande associée, pas de client, pas d’adresse, et (comme expliqué plus haut) qu’il a été créé par une IP Storebot confirmée en reverse DNS — jamais uniquement par sa forme.

Piège très spécifique à PrestaShop si vous écrivez votre propre SQL ou cron de nettoyage : 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 diffère de celui de PHP, un filtre d’âge basé sur NOW() / DATE_SUB(NOW(), ...) peut considérer chaque panier comme fraîchement actif et ne rien purger silencieusement (ou purger les mauvaises lignes). Calculez le cutoff depuis l’horloge applicative, et supprimez toujours les lignes ps_cart_product correspondantes avec les lignes ps_cart pour éviter des lignes d’articles orphelines.

4. Sortez les paniers bot de vos rapports et récupérations

Votre vrai chiffre d’abandon est celui calculé uniquement sur les paniers avec un vrai client ou une session guest identifiée. Excluez les paniers anonymes de bots vérifiés de votre funnel de conversion, et assurez-vous que toute automatisation de récupération les filtre pour ne pas agir sur des lignes qui n’ont jamais représenté une personne. Cette même séparation vous permet enfin de reporter un vrai taux panier-commande au lieu d’un taux gonflé par Storebot — le genre de chiffre propre, utile au propriétaire, qui appartient à votre reporting avancé de boutique.

5. Réduisez le crawl non commercial avec robots.txt (sans toucher aux produits ni au panier)

Vous pouvez réduire le crawl inutile sans mettre en danger la vérification en éloignant Storebot 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: / pour que tout le reste, pages produit et route panier incluses, reste crawlable.

Faire tout cela sans développeur : Spam Cart Blocker

Le workflow vérifier-puis-purger-en-sécurité ci-dessus est correct, mais le faire à la main — parsing de logs, confirmation reverse-DNS vers l’avant, cron sûr côté fuseau horaire, 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 de ce type bloquent les paniers bot (ce qui, comme vu plus haut, peut suspendre vos produits dans Merchant Center) ou font des suppressions brutes par âge sans savoir si un panier venait d’un bot ou d’un vrai visiteur sans cookie.

Qu’est-ce que cela fait pour vous ? Il classe les paniers en vérifiant l’identité du crawler avec un reverse DNS confirmé en avant — donc un Storebot vérifié est reconnu et un imposteur qui usurpe l’UA ne l’est pas — puis marque et purge par TTL les vrais paniers bot tout en laissant intact tout ce qui contient une commande, un client, une adresse ou une vraie session. Il ne bloque jamais Google, donc vos listings restent en sécurité. Il répare la création de guest cassée sous full-page cache pour que votre vraie attribution panier recommence à fonctionner. Et il affiche la vérité dans le back office : une ventilation bot versus humain de vos paniers et votre vrai taux de paniers abandonnés, plus de l’intelligence panier par visiteur — le tout configurable depuis l’admin, sans override core, donc compatible avec les upgrades. En bref, il transforme l’enquête manuelle de cet article en un réglage à cocher une fois.

Et ensuite : Storebot n’est que le début

Le crawl de Storebot augmente, il ne disparaît pas, parce que Google avance vers des agents d’achat IA qui agissent pour le compte d’un client — vérification des prix, contrôle du stock et potentiellement finalisation d’achats via votre checkout. Quelle que soit votre opinion sur cette direction, l’implication pratique pour un marchand PrestaShop reste celle défendue dans tout cet article : les boutiques dont le feed, les données structurées, les pages produit et le panier racontent tous la même histoire cohérente sont celles qu’un crawler — piloté par un humain ou par un agent — peut croire. Celles avec des mismatches de prix, des boutons rupture de stock cachés et une table ps_cart pleine 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 ». C’est : confirmez ce qu’ils sont, accueillez la vérification qui garde vos listings en ligne, et nettoyez après elle selon les règles de PrestaShop — suppressions protégées, cron correct côté fuseau horaire, et analytics qui comptent des personnes au lieu de crawlers. Faites cela correctement et Storebot cesse d’être un mystère dans votre base de données pour devenir ce qu’il devait être depuis le départ : un audit gratuit et continu qui confirme que votre boutique est prête à vendre.