Google Storebot is shopping in your PrestaShop store: what merchants need to know in 2026

Open your Customers → Shopping carts grid in the PrestaShop back office and you may find something that looks alarming: hundreds of carts with no customer name, no address, no carrier, just a product, a timestamp, and nothing else. Day after day, at a steady drip, never converting. Your first instinct is that something is broken or that you are being attacked. Neither is true. In most cases, the culprit is a Google crawler called Storebot, and it is doing exactly what Google designed it to do: literally shopping in your store to verify that your Google Shopping listings tell the truth.

This post is about that specific phenomenon on PrestaShop. What Storebot is, how to confirm it is what is filling your ps_cart table (and not a bot you actually should block), why blocking it is a costly mistake, and what to do instead. We investigated this first-hand across several live PrestaShop shops in 2026, so the back-office paths, the database shapes, and the verification steps below are the real ones, not hand-waving.

Last updated: June 2026.

What Storebot-Google actually is

Storebot is a dedicated Google crawler, separate from the Googlebot that indexes pages for organic search. Its job is e-commerce verification: it loads a product page, reads the price and availability, then tests whether a real customer could actually buy the item by adding it to the cart and moving toward checkout. It renders JavaScript like a real browser, which matters on PrestaShop because the default theme adds to cart over AJAX.

You can recognise it by its user agent, which contains the literal token 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

On a typical visit it loads the product page, fires the add-to-cart request (a POST handled by PrestaShop's CartController. The controller_class is cart, regardless of whether your localised URL says /cart, /panier or /warenkorb), checks that the cart total matches the product-page price, probes toward the address and delivery steps to read shipping and tax, and then leaves without ordering. That last step is why you end up with a pile of one-line abandoned carts. It is verification, not abandonment in any meaningful sense.

Why these carts look the way they do on PrestaShop

The phantom-cart shape is specific and recognisable. When we examined them on production shops, every Storebot cart had the same fingerprint in ps_cart:

• id_customer = 0, no logged-in customer
• id_guest = 0, no guest session row attached
• id_carrier = 0 and id_address_delivery = 0, never reached delivery selection
• secure_key = '', empty

There is a PrestaShop-specific reason these carts get created at all. CartController::updateCart has long checked $this->context->cookie->exists() before letting an add-to-cart change the cart, a guard meant to limit exactly this kind of ghost cart (newer branches lean more on a Connection::isBot() check). On the shops we looked at, the bot still got through because a full-page-cache layer (the dynamic AJAX add-to-cart it uses) hands the bot a cookie that has no id_guest in it. The guest row itself normally only gets created by a stats hook on the page header; under full-page caching that hook frequently does not fire, so the front controller builds a cart with id_guest = 0 and an empty secure key.

So what does that mean for you? Two things. First, the empty-guest shape is a side effect of caching, not proof of a bot, which leads directly to the next section. Second, because no guest session is attached, PrestaShop's own cart-recovery and visitor attribution silently break for these rows: there is nothing to email, nothing to tie back to a session, and yet they still sit in your tables inflating every count.

First, confirm it really is Storebot, don't guess

This is the step most "just delete the carts" advice skips, and it is the one that protects you from deleting real customers. The empty-guest cart shape is not a reliable bot marker on its own. On a PrestaShop store running full-page cache with an empty ps_connections table, a genuine cookieless shopper, for example, paid-ad traffic arriving with a gclid and no prior cookie, produces an identical orphan cart. If you purge by shape alone, you can delete real abandoned carts and corrupt your own recovery funnel.

Verify against the access log, not the cart table. Two checks, in order:

• User agent + IP source. Find the requests that created the carts in your real web-server access log (on nginx that is typically /var/log/nginx/access.log; note that Apache domlogs often exclude proxied traffic, so check the right file). Genuine Storebot requests come from Google's ranges, we confirmed hits from 64.233.172.x, 66.102.8.x, 66.249.92.x, 72.14.199.x and 192.178.11.x.
• Forward-confirmed reverse DNS. Do not trust the IP or the UA string alone. Both can be spoofed. Run a reverse DNS lookup on the IP (genuine Google hits resolve to *.google.com / google-proxy-* / rate-limited-proxy-*.google.com), then forward-resolve that hostname back and confirm it returns the same IP. Storebot-Google obeys robots.txt (see the last section), and Google publishes crawler IP ranges in its official crawler IP documentation, check the file for the relevant crawler category to confirm a verified Storebot IP, rather than assuming any single list covers it.

If the UA claims Storebot but the reverse-DNS forward-confirm fails, you are looking at a spoofer pretending to be Google, and that traffic you can treat differently. The verified ones you must keep.

Why blocking Storebot is the expensive mistake

The tempting move, a firewall rule, a robots.txt Disallow, a 403 on the cart route for that UA. Backfires, and it backfires through a system you do not control: Google Merchant Center.

• Block the UA and your products get disapproved. Google's documentation is explicit that letting the crawler reach your pages is "highly encouraged." If Storebot can't verify your checkout, your items risk landing-page and price-mismatch disapprovals, and they drop out of Shopping ads and free listings.
• Don't single out the cart POST either. Allowing product-page reads but blocking the add-to-cart submission breaks the exact thing Storebot exists to verify, cart-price consistency, which is itself a disapproval trigger.
• Never block the IP ranges at the firewall. The 66.249.* and 66.102.* ranges are shared with the regular Googlebot. Block them and you also de-index your store from organic search, a far bigger loss than some extra cart rows.

The honest framing: Storebot's visit is a free audit confirming your listings are accurate, and accurate listings get shown more often. You want it crawling. The problem to solve is not the crawler. It is the debris it leaves behind.

The real cost: bot carts are lying to your analytics

The phantom carts are not just clutter. They quietly poison the numbers you make decisions on:

• Your abandonment rate is fiction. If Storebot creates seven carts an hour and almost none convert, your cart-to-order rate in the back office reads far worse than reality. We saw periods where bot carts outnumbered genuine carts several to one over a handful of days.
• The ps_cart and ps_cart_product tables grow without end, and on hosts with modest database resources that drag shows up in slow cart and admin queries.
• Recovery automations waste effort. Because these rows have no real customer and no usable session, any cart-recovery process either skips them (best case) or burns cycles trying to act on a contact that does not exist.

Deciding which carts are bots and which are real, before you trust any conversion figure, is the same discipline that underpins all store measurement, knowing what to count and what to ignore. We cover that mindset in analytics for online stores: what to track and what to ignore, and the GA4-specific version of filtering this noise in the GA4 metrics that actually matter.

What to do instead: keep the crawler, clear the debris

1. Make sure Storebot finds exactly what your feed promised

The single most effective move is to give the crawler a clean verification, so its visit passes and triggers nothing. Feed, structured data, product page, cart and checkout must all agree on price (including tax and currency) and availability. On PrestaShop, that means your feed module reads live prices and stock, and your product pages carry correct schema.org/Product markup with price, priceCurrency, availability and brand. If you push listings through the Merchant API, confirm your feed module supports v1. The old Content API for Shopping is being retired in 2026, so a stale feed module is a ticking source of mismatches.

2. Get out-of-stock product pages right

Google's expectation is that an out-of-stock product page clearly shows its unavailable status, prevents purchase, and that the availability matches your feed and structured data exactly. A visibly disabled buy button (grayed out, with the HTML disabled attribute) is one acceptable implementation, as long as it stays consistent with your feed and schema availability. Many PrestaShop themes instead hide the add-to-cart button entirely when stock hits zero, check your theme's product.tpl / product template. Storebot tests this directly: it should not be able to add an out-of-stock item, and it must be able to add an in-stock one.

3. Clean up bot carts on a schedule, but guard the delete

Periodic cleanup is the practical fix for the database bloat, and the carts are identifiable: id_customer = 0, id_guest = 0 (or a guest row carrying a Storebot UA), id_carrier = 0, id_address_delivery = 0, created from a verified Google IP. The guarded part matters as much as the match: before deleting, confirm the cart has no associated order, no customer, no addresses, and (per the section above) was created by a forward-confirmed Storebot IP, never by shape alone.

One sharp PrestaShop-specific trap if you write your own cleanup SQL or cron: PrestaShop writes its date_add values using the PHP clock, not MySQL's. On a host where the database timezone differs from PHP's, an age filter built on NOW() / DATE_SUB(NOW(), ...) can misjudge every cart as freshly active and silently purge nothing (or the wrong rows). Compute your cutoff from the application clock, and always delete the matching ps_cart_product rows alongside the ps_cart rows so you don't orphan line items.

4. Keep bot carts out of your reporting and recovery

Your true abandonment number is the one computed only from carts with a real customer or an identified guest session. Exclude the anonymous, verified-bot carts from your conversion funnel, and make sure any cart-recovery automation filters them out so it isn't acting on rows that were never a person. The same separation lets you finally report a real cart-to-order rate instead of a Storebot-inflated one, the kind of clean, owner-facing number that belongs in your store's advanced reporting.

5. Trim non-commercial crawl with robots.txt (don't touch product or cart)

You can reduce wasted crawl without endangering verification by steering Storebot away from URLs that have no commercial value, never the product pages or the cart route itself:

User-agent: Storebot-Google, then Disallow: /*?order=, Disallow: /*?utm_, and finally Allow: / so everything else, product pages and the cart route included, stays crawlable.

Doing all of this without a developer: Spam Cart Blocker

The verify-then-purge-safely workflow above is correct, but doing it by hand, log parsing, reverse-DNS forward-confirmation, timezone-safe cron, guarded deletes that never touch a real order. Is a lot to maintain. We built Spam Cart Blocker for our own shops precisely because the available alternatives got it dangerously wrong: the few modules in this space either block bot carts (which, as covered above, can get your products suspended from Merchant Center) or do blunt age-based deletes with no idea whether a cart was a bot or a real cookieless shopper.

So what does it do for you? It classifies carts by checking the crawler's identity with forward-confirmed reverse DNS, so a verified Storebot is recognised and a UA-spoofing impostor is not, then tags and TTL-purges the genuine bot carts while leaving anything with an order, customer, address or real session untouched. It never blocks Google, so your listings stay safe. It repairs the broken guest-creation under full-page cache so your real cart attribution starts working again. And it surfaces the truth in the back office: a bot-versus-human breakdown of your carts and your real abandoned-cart rate, plus per-visitor cart intelligence, all configured from the admin, no core overrides, so it survives upgrades. In short, it turns the manual investigation in this article into a setting you tick once.

Frequently asked questions

Why is my PrestaShop cart table filling with empty, never-converting carts?

In most cases it's Storebot-Google, a dedicated Google crawler, separate from the page-indexing Googlebot, verifying that your Google Shopping listings tell the truth. It loads a product page, adds the item to the cart to check the price matches, probes toward delivery to read shipping and tax, then leaves without ordering. Each visit leaves a one-line cart with id_customer = 0, id_guest = 0, id_carrier = 0 and an empty secure key. It's verification, not abandonment.

Should I block Storebot to stop the phantom carts?

No, that's the expensive mistake. Google's documentation is explicit that letting the crawler reach your pages is highly encouraged. Block the user agent, the cart POST, or (worst of all) the IP ranges and your products risk landing-page and price-mismatch disapprovals in Merchant Center, dropping out of Shopping ads and free listings. The 66.249.* and 66.102.* ranges are shared with the regular Googlebot, so a firewall block also de-indexes you from organic search. Keep the crawler; clean up the debris.

How do I confirm a cart was created by the real Storebot and not a real shopper?

Verify against the access log, not the cart table. The empty-guest shape alone is not a reliable bot marker, because a genuine cookieless shopper arriving with a gclid under full-page cache produces an identical orphan cart. Check the user agent and source IP in your web-server access log, then run a forward-confirmed reverse DNS check: the IP should resolve to a *.google.com / google-proxy-* hostname that forward-resolves back to the same IP. If that fails, it's a spoofer pretending to be Google.

What's the PrestaShop-specific trap when writing cleanup SQL for bot carts?

Timezone. PrestaShop writes date_add using the PHP clock, not MySQL's. On a host where the database timezone differs from PHP's, an age filter built on DATE_SUB(NOW(), ...) can misjudge every cart and silently purge nothing or the wrong rows. Compute your cutoff from the application clock, always delete the matching ps_cart_product rows alongside the ps_cart rows, and guard the delete so it never touches a cart with an order, customer or address.

Can I trim Storebot's crawl without endangering verification?

Yes, steer it away from non-commercial URLs only, never the product pages or the cart route. A safe robots.txt block targets parameter URLs with no commercial value:

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

Remember that Disallow stops crawling of those URLs, not indexing of pages linked elsewhere, it's a crawl-budget tool, not an index control. Keep product pages and the cart route fully crawlable so verification keeps passing.

Doing it safely without a developer

The verify-then-purge workflow above, log parsing, forward-confirmed reverse DNS, timezone-safe cron, guarded deletes, is a lot to maintain by hand. Spam Cart Blocker classifies carts by checking the crawler's identity (so a verified Storebot is recognised and a UA-spoofing impostor is not), TTL-purges genuine bot carts while leaving anything with an order, customer or real session untouched, never blocks Google, and surfaces your real abandoned-cart rate in the back office. If your store is already buried under bot carts, our Cleanup Revolution handles the scheduled database trimming, and Google Analytics GA4 keeps the conversion numbers honest once the crawler noise is filtered out.

Looking ahead: Storebot is the start, not the end

Storebot's crawling is increasing, not fading, because Google is building toward AI shopping agents that act on a customer's behalf, verifying prices, checking stock and potentially completing purchases through your checkout. Whatever you make of that direction, the practical implication for a PrestaShop merchant is the same one this article has argued throughout: the stores whose feed, structured data, product pages and cart all tell one consistent story are the ones a crawler. Human-driven or agent-driven, can trust. The ones with price mismatches, hidden out-of-stock buttons and a ps_cart table full of unexamined junk get filtered out before a buyer ever sees them.

So the takeaway is not "delete the weird carts." It is: confirm what they are, welcome the verification that keeps your listings live, and clean up after it on PrestaShop's terms, guarded deletes, timezone-correct cron, and analytics that count people instead of crawlers. Get that right and Storebot stops being a mystery in your database and becomes what it was always meant to be: a free, continuous audit confirming your store is ready to sell.