Google Storebot fa acquisti nel tuo negozio PrestaShop: cosa devono sapere i commercianti nel 2026

Apri la griglia Clienti → Carrelli nel back office di PrestaShop e potresti trovarti davanti qualcosa di allarmante: centinaia di carrelli senza nome cliente, senza indirizzo, senza corriere, solo un prodotto, una data e ora e nient'altro. Giorno dopo giorno, con un flusso costante, senza mai convertirsi in ordini. Il primo istinto è pensare che qualcosa non funzioni o che il negozio sia sotto attacco. Non è così. Nella maggior parte dei casi il responsabile è un crawler di Google chiamato Storebot, e sta facendo esattamente ciò per cui Google lo ha progettato: fare letteralmente acquisti nel tuo negozio per verificare che le inserzioni di Google Shopping dicano la verità.

Questo articolo riguarda proprio questo fenomeno su PrestaShop, che cos'è Storebot, come verificare che sia davvero lui a riempire la tabella ps_cart (e non un bot che invece dovresti bloccare), perché bloccarlo è un errore costoso e cosa fare al suo posto. Abbiamo analizzato il problema in prima persona su diversi negozi PrestaShop attivi nel 2026, quindi i percorsi del back office, la struttura del database e i passaggi di verifica qui sotto sono quelli reali, non indicazioni vaghe.

Ultimo aggiornamento: giugno 2026.

Che cos'è davvero Storebot-Google

Storebot è un crawler dedicato di Google, separato dal Googlebot che indicizza le pagine per la ricerca organica. Il suo compito è la verifica e-commerce: carica una pagina prodotto, legge prezzo e disponibilità, poi testa se un cliente reale potrebbe effettivamente acquistare l'articolo aggiungendolo al carrello e avanzando verso la procedura d'acquisto. Esegue JavaScript come un vero browser, cosa importante su PrestaShop perché il tema predefinito aggiunge i prodotti al carrello via AJAX.

Lo riconosci dal suo user agent, che contiene il token letterale 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

In una visita tipica carica la pagina prodotto, invia la richiesta di aggiunta al carrello (un POST gestito dal CartController di PrestaShop. Il controller_class è cart, indipendentemente dal fatto che il tuo URL localizzato dica /cart, /panier o /warenkorb), controlla che il totale del carrello corrisponda al prezzo della pagina prodotto, si spinge verso i passaggi di indirizzo e consegna per leggere spedizione e imposte, poi se ne va senza effettuare l'ordine. È quest'ultimo passaggio il motivo per cui ti ritrovi con una pila di carrelli abbandonati a riga singola. È verifica, non abbandono in un senso realmente significativo.

Perché questi carrelli appaiono così su PrestaShop

La forma del carrello fantasma è specifica e riconoscibile. Quando li abbiamo esaminati su negozi in produzione, ogni carrello di Storebot aveva la stessa impronta in ps_cart:

• id_customer = 0, nessun cliente autenticato
• id_guest = 0, nessuna riga di sessione ospite associata
• id_carrier = 0 e id_address_delivery = 0. Non è mai arrivato alla selezione della consegna
• secure_key = '', vuota

C'è una ragione specifica di PrestaShop per cui questi carrelli vengono creati. CartController::updateCart controlla da tempo $this->context->cookie->exists() prima di consentire a un'aggiunta al carrello di modificare il carrello, una protezione pensata proprio per limitare questo tipo di carrello fantasma (i rami più recenti si affidano maggiormente a un controllo Connection::isBot()). Nei negozi che abbiamo analizzato, il bot passava comunque perché un livello di cache a pagina intera (l'aggiunta dinamica al carrello via AJAX che utilizza) consegna al bot un cookie privo di id_guest. La riga ospite, normalmente, viene creata solo da un hook statistiche nell'intestazione della pagina; con la cache a pagina intera quell'hook spesso non viene eseguito, quindi il front controller costruisce un carrello con id_guest = 0 e una secure key vuota.

Quindi cosa significa per te? Due cose. Primo, la forma con ospite vuoto è un effetto collaterale della cache, non la prova di un bot, e questo porta direttamente alla sezione successiva. Secondo, poiché non è associata alcuna sessione ospite, il recupero carrelli e l'attribuzione visitatori nativi di PrestaShop si rompono silenziosamente per queste righe: non c'è nessuno a cui inviare email, nulla da ricondurre a una sessione, eppure continuano a restare nelle tabelle gonfiando ogni conteggio.

Prima conferma che sia davvero Storebot, non tirare a indovinare

Questo è il passaggio che la maggior parte dei consigli del tipo "basta eliminare i carrelli" salta, ed è quello che ti protegge dall'eliminare clienti reali. La forma del carrello con ospite vuoto non è, da sola, un indicatore affidabile di bot. Su un negozio PrestaShop con cache a pagina intera e tabella ps_connections vuota, un acquirente reale senza cookie, per esempio traffico da annuncio a pagamento in arrivo con un gclid e nessun cookie precedente, produce un carrello orfano identico. Se elimini solo in base alla forma, puoi cancellare carrelli abbandonati reali e compromettere il tuo funnel di recupero.

Verifica sul log di accesso, non sulla tabella dei carrelli. Due controlli, in questo ordine:

• User agent + origine IP. Trova le richieste che hanno creato i carrelli nel vero log di accesso del server web (su nginx di solito è /var/log/nginx/access.log; nota che i domlog Apache spesso escludono il traffico proxy, quindi controlla il file corretto). Le richieste genuine di Storebot provengono dagli intervalli di Google, abbiamo confermato accessi da 64.233.172.x, 66.102.8.x, 66.249.92.x, 72.14.199.x e 192.178.11.x.
• Reverse DNS confermato in avanti. Non fidarti solo dell'IP o della stringa UA. Entrambi possono essere falsificati. Esegui una ricerca reverse DNS sull'IP (gli accessi Google autentici risolvono verso *.google.com / google-proxy-* / rate-limited-proxy-*.google.com), poi risolvi in avanti quel nome host e conferma che restituisca lo stesso IP. Storebot-Google rispetta robots.txt (vedi l'ultima sezione), e Google pubblica gli intervalli IP dei crawler nella documentazione ufficiale sugli IP dei crawler, controlla il file per la categoria di crawler pertinente per confermare un IP Storebot verificato, invece di presumere che un singolo elenco li copra tutti.

Se lo UA dichiara Storebot ma la conferma reverse-DNS in avanti fallisce, stai guardando uno spoofer che finge di essere Google, e quel traffico puoi trattarlo diversamente. Quelli verificati devi lasciarli passare.

Perché bloccare Storebot è l'errore costoso

La mossa allettante, una regola firewall, un Disallow in robots.txt, un 403 sulla rotta del carrello per quello UA. Si ritorce contro, e lo fa attraverso un sistema che non controlli: Google Merchant Center.

• Blocca lo UA e i tuoi prodotti vengono disapprovati. La documentazione di Google è esplicita: permettere al crawler di raggiungere le tue pagine è "fortemente consigliato". Se Storebot non può verificare la tua procedura d'acquisto, i tuoi articoli rischiano disapprovazioni per pagina di destinazione e mancata corrispondenza del prezzo, e spariscono dagli annunci Shopping e dalle schede gratuite.
• Non prendere di mira nemmeno il POST del carrello. Consentire la lettura delle pagine prodotto ma bloccare l'invio dell'aggiunta al carrello rompe esattamente ciò che Storebot esiste per verificare, la coerenza del prezzo nel carrello, che è a sua volta un motivo di disapprovazione.
• Non bloccare mai gli intervalli IP al firewall. Gli intervalli 66.249.* e 66.102.* sono condivisi con il Googlebot normale. Bloccarli significa anche deindicizzare il tuo negozio dalla ricerca organica, una perdita molto più grande di qualche riga di carrello in più.

Il quadro corretto è questo: la visita di Storebot è un audit gratuito che conferma l'accuratezza delle tue inserzioni, e le inserzioni accurate vengono mostrate più spesso. Vuoi che esegua la scansione. Il problema da risolvere non è il crawler. Sono i residui che si lascia dietro.

Il costo reale: i carrelli dei bot falsano le tue analisi

I carrelli fantasma non sono solo disordine. Avvelenano silenziosamente i numeri su cui prendi decisioni:

• Il tuo tasso di abbandono è finzione. Se Storebot crea sette carrelli all'ora e quasi nessuno si converte, il tasso carrello-ordine nel back office appare molto peggiore della realtà. Abbiamo visto periodi in cui i carrelli dei bot superavano quelli reali di diversi a uno nell'arco di pochi giorni.
• Le tabelle ps_cart e ps_cart_product crescono senza fine, e su hosting con risorse database modeste questo peso si traduce in query lente su carrelli e amministrazione.
• Le automazioni di recupero sprecano lavoro. Poiché queste righe non hanno un cliente reale né una sessione utilizzabile, qualsiasi processo di recupero carrelli le salta (nel migliore dei casi) oppure consuma cicli tentando di agire su un contatto che non esiste.

Decidere quali carrelli sono bot e quali sono reali, prima di fidarti di qualsiasi dato di conversione, è la stessa disciplina alla base di ogni misurazione del negozio, sapere cosa contare e cosa ignorare. Approfondiamo questo approccio in analisi per negozi online: cosa monitorare e cosa ignorare, e la versione specifica per GA4 del filtro di questo rumore in le metriche GA4 che contano davvero.

Cosa fare invece: tieni il crawler, elimina i residui

1. Assicurati che Storebot trovi esattamente ciò che il tuo flusso dati ha promesso

La singola mossa più efficace è offrire al crawler una verifica pulita, così la visita passa senza attivare problemi. Flusso dati, dati strutturati, pagina prodotto, carrello e procedura d'acquisto devono concordare su prezzo (incluse imposte e valuta) e disponibilità. Su PrestaShop significa che il tuo modulo per il flusso dati legge prezzi e giacenze in tempo reale, e che le pagine prodotto contengono un markup schema.org/Product corretto con price, priceCurrency, availability e brand. Se invii le inserzioni tramite Merchant API, conferma che il tuo modulo per il flusso dati supporti v1, la vecchia Content API for Shopping verrà ritirata nel 2026, quindi un modulo per il flusso dati non aggiornato è una fonte pronta a esplodere di mancate corrispondenze.

2. Gestisci correttamente le pagine dei prodotti esauriti

Google si aspetta che una pagina prodotto esaurito mostri chiaramente lo stato di indisponibilità, impedisca l'acquisto e che la disponibilità corrisponda esattamente al flusso dati e ai dati strutturati. Un pulsante di acquisto visibilmente disabilitato (in grigio, con l'attributo HTML disabled) è un'implementazione accettabile, purché resti coerente con il flusso dati e con la disponibilità nello schema. Molti temi PrestaShop invece nascondono del tutto il pulsante di aggiunta al carrello quando la giacenza arriva a zero, controlla il product.tpl / template prodotto del tuo tema. Storebot lo testa direttamente: non deve poter aggiungere un articolo esaurito, e deve poter aggiungere un articolo disponibile.

3. Ripulisci i carrelli dei bot a intervalli regolari, ma proteggi l'eliminazione

La pulizia periodica è la soluzione pratica al gonfiamento del database, e i carrelli sono identificabili: id_customer = 0, id_guest = 0 (oppure una riga ospite con uno UA Storebot), id_carrier = 0, id_address_delivery = 0, creati da un IP Google verificato. La parte protetta conta quanto la corrispondenza: prima di eliminare, conferma che il carrello non abbia ordini associati, nessun cliente, nessun indirizzo e (come nella sezione sopra) sia stato creato da un IP Storebot confermato con risoluzione in avanti, mai solo in base alla forma.

Una trappola specifica di PrestaShop, se scrivi il tuo SQL di pulizia o cron: PrestaShop scrive i valori date_add usando l'orologio PHP, non quello di MySQL. Su un host in cui il fuso orario del database è diverso da quello di PHP, un filtro di età basato su NOW() / DATE_SUB(NOW(), ...) può giudicare ogni carrello come appena attivo e non eliminare nulla in silenzio (oppure eliminare le righe sbagliate). Calcola il cutoff dall'orologio dell'applicazione e cancella sempre le righe ps_cart_product corrispondenti insieme alle righe ps_cart, così non lasci righe articolo orfane.

4. Tieni i carrelli dei bot fuori da report e recuperi

Il tuo vero numero di abbandono è quello calcolato solo dai carrelli con un cliente reale o una sessione ospite identificata. Escludi i carrelli anonimi e verificati come bot dal funnel di conversione, e assicurati che qualsiasi automazione di recupero carrelli li filtri, così non agirà su righe che non sono mai state una persona. La stessa separazione ti permette finalmente di riportare un tasso carrello-ordine reale invece di uno gonfiato da Storebot, il tipo di numero pulito, utile al titolare, che appartiene alla reportistica avanzata del tuo negozio.

5. Riduci la scansione non commerciale con robots.txt (non toccare prodotti o carrello)

Puoi ridurre la scansione sprecata senza mettere a rischio la verifica indirizzando Storebot lontano dagli URL senza valore commerciale, mai dalle pagine prodotto o dalla rotta del carrello:

User-agent: Storebot-Google, poi Disallow: /*?order=, Disallow: /*?utm_, e infine Allow: / in modo che tutto il resto, pagine prodotto e rotta del carrello incluse, resti scansionabile.

Fare tutto questo senza sviluppatore: Spam Cart Blocker

Il flusso verifica-poi-elimina-in-sicurezza descritto sopra è corretto, ma farlo a mano, parsing dei log, conferma reverse-DNS in avanti, cron sicuro rispetto al fuso orario, eliminazioni protette che non toccano mai un ordine reale. È molto da mantenere. Abbiamo creato Spam Cart Blocker per i nostri negozi proprio perché le alternative disponibili sbagliavano in modo pericoloso: i pochi moduli in questo ambito o bloccano i carrelli dei bot (cosa che, come visto sopra, può far sospendere i tuoi prodotti in Merchant Center) oppure fanno eliminazioni grossolane basate sull'età senza sapere se un carrello fosse di un bot o di un acquirente reale senza cookie.

Quindi cosa fa per te? Classifica i carrelli controllando l'identità del crawler con reverse DNS confermato in avanti, così uno Storebot verificato viene riconosciuto e un impostore che falsifica lo UA no, poi etichetta ed elimina con TTL i carrelli bot autentici lasciando intatto qualsiasi carrello con ordine, cliente, indirizzo o sessione reale. Non blocca mai Google, quindi le tue inserzioni restano al sicuro. Ripara la creazione ospite interrotta sotto cache a pagina intera, così l'attribuzione dei carrelli reali ricomincia a funzionare. E mostra la verità nel back office: una suddivisione dei carrelli tra bot ed esseri umani e il tuo tasso di carrelli abbandonati reale, più intelligence sui carrelli per visitatore, tutto configurabile dall'amministrazione, senza override del core, quindi resistente agli aggiornamenti. In breve, trasforma l'indagine manuale di questo articolo in un'impostazione da selezionare una volta sola.

Domande frequenti

Perché la tabella dei carrelli di PrestaShop si riempie di carrelli vuoti, che non si convertono mai?

Nella maggior parte dei casi è Storebot-Google, un crawler dedicato di Google, separato dal Googlebot che indicizza le pagine, che verifica che le tue inserzioni di Google Shopping dicano la verità. Carica una pagina prodotto, aggiunge l'articolo al carrello per controllare che il prezzo corrisponda, si spinge verso la consegna per leggere spedizione e imposte, poi se ne va senza effettuare l'ordine. Ogni visita lascia un carrello a riga singola con id_customer = 0, id_guest = 0, id_carrier = 0 e una secure key vuota. È verifica, non abbandono.

Dovrei bloccare Storebot per fermare i carrelli fantasma?

No, è l'errore costoso. La documentazione di Google è esplicita: permettere al crawler di raggiungere le tue pagine è fortemente consigliato. Blocca lo user agent, il POST del carrello o (peggio ancora) gli intervalli IP, e i tuoi prodotti rischiano disapprovazioni in Merchant Center per pagina di destinazione e mancata corrispondenza del prezzo, sparendo dagli annunci Shopping e dalle schede gratuite. Gli intervalli 66.249.* e 66.102.* sono condivisi con il Googlebot normale, quindi un blocco firewall ti deindicizza anche dalla ricerca organica. Tieni il crawler; elimina i residui.

Come confermo che un carrello sia stato creato dal vero Storebot e non da un acquirente reale?

Verifica sul log di accesso, non sulla tabella dei carrelli. La forma con ospite vuoto da sola non è un indicatore affidabile di bot, perché un acquirente reale senza cookie che arriva con un gclid sotto cache a pagina intera produce un carrello orfano identico. Controlla user agent e IP sorgente nel log di accesso del tuo server web, poi esegui un controllo reverse DNS confermato in avanti: l'IP dovrebbe risolvere verso un nome host *.google.com / google-proxy-* che, risolto in avanti, torna allo stesso IP. Se fallisce, è uno spoofer che finge di essere Google.

Qual è la trappola specifica di PrestaShop quando si scrive SQL di pulizia per i carrelli dei bot?

Il fuso orario. PrestaShop scrive date_add usando l'orologio PHP, non quello di MySQL. Su un host in cui il fuso orario del database è diverso da quello di PHP, un filtro di età basato su DATE_SUB(NOW(), ...) può valutare male ogni carrello e non eliminare nulla in silenzio, oppure eliminare le righe sbagliate. Calcola il cutoff dall'orologio dell'applicazione, elimina sempre le righe ps_cart_product corrispondenti insieme alle righe ps_cart, e proteggi l'eliminazione in modo che non tocchi mai un carrello con ordine, cliente o indirizzo.

Posso ridurre la scansione di Storebot senza mettere a rischio la verifica?

Sì, indirizzalo solo lontano dagli URL non commerciali, mai dalle pagine prodotto o dalla rotta del carrello. Un blocco robots.txt sicuro prende di mira gli URL con parametri senza valore commerciale:

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

Ricorda che Disallow ferma la scansione di quegli URL, non l'indicizzazione di pagine collegate altrove. È uno strumento per il crawl budget, non un controllo di indicizzazione. Mantieni pagine prodotto e rotta del carrello completamente scansionabili, così la verifica continua a passare.

Farlo in sicurezza senza sviluppatore

Il flusso verifica-poi-elimina sopra, parsing dei log, reverse DNS confermato in avanti, cron sicuro rispetto al fuso orario, eliminazioni protette. È molto da mantenere a mano. Spam Cart Blocker classifica i carrelli controllando l'identità del crawler (così uno Storebot verificato viene riconosciuto e un impostore che falsifica lo UA no), elimina con TTL i carrelli bot autentici lasciando intatto qualsiasi carrello con ordine, cliente o sessione reale, non blocca mai Google e mostra nel back office il tuo vero tasso di carrelli abbandonati. Se il tuo negozio è già sommerso dai carrelli dei bot, il nostro Cleanup Revolution gestisce la pulizia programmata del database, e Google Analytics GA4 mantiene onesti i numeri di conversione una volta filtrato il rumore del crawler.

Guardando avanti: Storebot è l'inizio, non la fine

La scansione di Storebot sta aumentando, non diminuendo, perché Google si sta muovendo verso agenti di acquisto AI che agiscono per conto del cliente, verificando prezzi, controllando le giacenze e potenzialmente completando acquisti attraverso la tua procedura d'acquisto. Qualunque sia la tua opinione su questa direzione, l'implicazione pratica per un commerciante PrestaShop è la stessa sostenuta da questo articolo dall'inizio alla fine: i negozi in cui flusso dati, dati strutturati, pagine prodotto e carrello raccontano una storia coerente sono quelli di cui un crawler, guidato da una persona o da un agente, può fidarsi. Quelli con prezzi non corrispondenti, pulsanti per prodotti esauriti nascosti e una tabella ps_cart piena di spazzatura non esaminata vengono filtrati prima ancora che un acquirente li veda.

Quindi il punto non è "eliminare i carrelli strani". È: conferma cosa sono, accogli la verifica che mantiene attive le tue inserzioni, e ripulisci dopo il suo passaggio secondo le regole di PrestaShop, eliminazioni protette, cron corretto rispetto al fuso orario e analisi che contano le persone invece dei crawler. Se lo fai bene, Storebot smette di essere un mistero nel database e diventa ciò che doveva essere fin dall'inizio: un audit gratuito e continuo che conferma che il tuo negozio è pronto a vendere.