What AI agents did on a Shopify store in 30 days

Ask a store owner how much traffic AI sends them and they will open Google Analytics. For the fashion brand in this post, GA4 recorded 121 sessions from ChatGPT in 30 days, well under 1% of the site's traffic. By that measure AI is a rounding error.

The server logs for the same 30 days show something else. ChatGPT and Claude opened the store's pages 1,264 times for people who asked them questions. They kept requesting products the store no longer sells, guessed at Shopify addresses the storefront doesn't serve, and shared the logs with about 10,600 requests from bots pretending to be AI crawlers. None of that reaches analytics, and some of it pointed to fixes the store could make in a day.

What we measured

The brand sells clothing through a headless Shopify storefront: a custom front end that runs on Cloudflare, with checkout on Shopify. We have left the brand and its products unnamed.

A Cloudflare Worker on the storefront forwards copies of requests from bots, AI assistants and visitors arriving from AI answers to Canonry. Canonry classifies each request and checks each bot's IP address against the ranges its operator publishes. Visits and purchases come from the store's GA4 property. The window is the 30 days from October 3 to November 1, 2026, and every number below comes from those two sources.

Three kinds of request matter here, and they are easy to blur:

• A crawl is a bot such as Googlebot, ClaudeBot or OAI-SearchBot fetching pages in bulk, for a search index or model training.
• A read is an assistant fetching a page while it answers a person, under a user agent such as ChatGPT-User or Claude-User. The request comes from the provider's servers.
• A visit is a person clicking a link in an AI answer and landing on the site in their own browser.

Classifying AI crawlers and user fetches covers how the first two are told apart.

Reads outnumber visits

ChatGPT fetched the store's pages 1,100 times and sent 121 visits, about nine reads for every visit. Claude fetched pages 164 times and sent no visit that GA4 recorded. Perplexity sent none either. Gemini sent one.

A read is invisible to the store's analytics because the assistant fetches the page from its own servers. The page's JavaScript never runs, so the GA4 tag never fires. The person gets an answer that may draw on the page, and may never visit.

The homepage was the page assistants read most, at 357 of the verified reads. Other pages they read often included a popular product page, the About page, a collection page, and the shipping, contact and returns pages. Several of those answer questions about the business rather than about a product.

Most of the visits that did happen came from phones. Between October 22 and November 1, 69 visitors arrived from AI answers, 68 of them from ChatGPT, and 42 of the 69 used Safari on an iPhone. Of their 70 visits, 27 started on the homepage and 24 on a product page. The median visit viewed two pages, and 32 visits viewed only one. Seven came through product links in ChatGPT's shopping results.

Over a longer 90-day window, ChatGPT sent 370 sessions that produced 4 purchases, a 1.1% conversion rate. The whole site converted at 2.4%. Four purchases is too few to call a trend, but it fits the funnel above: at this store, ChatGPT reads far more than it sells.

Assistants keep asking for products that are gone

In 30 days, ChatGPT requested 28 product pages for items the store no longer sells, 81 times in total. One discontinued jacket accounted for 17 of those requests. Search crawlers did the same at a larger scale: verified bots from Google, Amazon, Bing and others requested 273 product URLs that redirected, 2,166 times.

The storefront handled a missing product by redirecting to /404, and the /404 page answered with HTTP 200, the status of a working page. Search engines call this a soft 404. To a crawler or an assistant, a product that no longer exists looked like a live page whose content happens to say "not found".

The logs can't show what an assistant did with that page. They do show ChatGPT coming back to the same dead jacket URL 17 times in a month, which suggests the URL is still in whatever ChatGPT draws on when people ask about the brand. That last part is our inference, not something the logs prove.

In a headless storefront, the front end, not Shopify, decides what a missing product returns. So we sent the store's developers a change in three parts:

1. A missing product, collection or page answers 404 at its own URL, and /404 itself answers 404.
2. A retired color redirects to the same style: another color of the same product, or the collection page for that style.
3. The redirect applies only when Shopify has no product for that address. A color that comes back next season is served normally.

A discontinued style with no close match gets the plain 404. Redirecting it to a generic category would send shoppers somewhere they didn't ask to go, and Google may treat that kind of redirect as a soft 404 anyway.

Claude asks for standard Shopify addresses

Claude kept asking for addresses that standard Shopify stores serve and this one doesn't. Verified Claude-User requests went to /products.json, to /products/<handle>.json and .js (Shopify's product data URLs), and to /pages/contact, /pages/shipping, /pages/size-guide, /policies/privacy-policy and /policies/terms-of-service. In 30 days, 18 of those requests failed.

On a standard Shopify Online Store, the policy pages and the product data URLs exist by default, and a /pages/contact page is common. The headless storefront uses its own routes, such as /contact and /shipping-and-delivery, so each guess hit a redirect or a 404. Our reading is that Claude recognizes a Shopify store, since the checkout runs on Shopify, and tries the standard paths.

The fix is a short list of redirects in the storefront's configuration. Shopify's /pages/* addresses go to the storefront page with the same name, with explicit entries where the names differ. The /policies/* pages go to the storefront's privacy, terms, shipping and returns pages, and the product data URLs go to the product page. It costs nothing, and an assistant that guesses the Shopify path gets the right page instead of an error.

Thousands of AI bot requests were fake

Eleven bot names that claimed to be AI crawlers made about 10,600 requests in 30 days. They used names such as ClaudeBot, OAI-SearchBot, PerplexityBot, Grok, DeepSeek, Cohere and CCBot. None could be verified against a published IP range, and none of them requested a single product page. Most of their requests probed for secrets: /.env files, /proc/self/environ, directory traversal paths and deployment configs.

Each name made between roughly 650 and 1,890 requests with a similar mix of paths and failures. That looks like one scanner rotating through AI user agents, though the logs can't prove it is one operator.

Fake assistants were an even bigger share of their category. Another 1,604 requests used AI assistant names and failed Canonry's checks: they asked for scanner paths, used a user agent unlike the one the operator publishes, or came from an address that had just probed for secrets. On November 1, fake assistant requests outnumbered the rest 187 to 64.

One detail looked alarming at first. 967 of the secret-file probes got HTTP 200 back. All of them were under /api/. We read the storefront's code before guessing: unknown /api/ paths return the app's empty page shell, so the scanners received a blank page, not data. A log line alone would have suggested a leak.

A user agent string is a claim anyone can make. Count a bot as AI only when its IP matches the published range. Some crawlers can't be checked this way yet: Meta's made about 19,000 requests that Canonry could not verify either way.

Who actually crawls a store

These are all the verified crawlers with at least 100 requests in the 30 days, with the number of different product URLs each one fetched:

About three quarters of Googlebot's requests went to the storefront's Shopify data endpoint rather than to pages. Google runs the front end's JavaScript to render each page, and the page calls that endpoint for its product data. Crawlers that don't run JavaScript see only what the server sends in the HTML.

Applebot made about as many verified requests as Bingbot, OAI-SearchBot, GPTBot, ClaudeBot and PerplexityBot combined. Parallel, a web search API built for AI agents, went from 489 verified requests the month before to 7,086. Requests claiming to be Exa's crawler went from 4 to 371.

OpenAI's search crawler fetched 68 different product URLs, a fraction of what Google, Bing and Amazon fetched. Yet ChatGPT sent nearly all of the store's AI visits. Two things in the logs may explain part of that: ChatGPT-User fetched pages live 1,100 times, and seven visits came through ChatGPT's shopping results. How ChatGPT weighs those sources is not something the logs can show.

Counting AI clicks is easy to get wrong

Before we fixed it, Canonry's own dashboard said ChatGPT sent this store 2,123 arrivals in 30 days. GA4 said 121. Canonry's visitor journeys, which follow each visitor across requests, found 70 AI visits in 11 days, about 6 a day. One of these numbers was wrong by more than a factor of ten, and it was ours.

The cause is how utm tags travel. A ChatGPT link lands on a URL ending in ?utm_source=chatgpt.com. Every request the page makes after that, including scripts, API calls and the next page the shopper opens, carries that full URL in its Referer header. A counter that treats any request with ChatGPT's tag in the referer as an arrival counts the same visit again every minute it lasts. On this store, 86% of the counted arrivals were follow-on requests from visitors already on the site.

The rule existed for a reason. On a site served from a cache, the landing page never reaches the server logs, and the follow-on requests are the only evidence that a visitor came from ChatGPT at all. Any fix has to keep that case.

So we changed the counting to follow the same rule as the journeys. A request whose referer is outside the site is an arrival. A same-site request that still carries the engine's tag belongs to that visitor's arrival from the same engine, for 30 days. It counts as the arrival only when the visitor has no arrival from that engine in that window, which covers the cached-site case. Canonry also handles a visit's later request reaching it before the landing page does, so the visit is counted once.

Applied to this store's 30 days, the corrected count is about 290 arrivals from ChatGPT, roughly 10 a day. That is still more than GA4's 4 a day. Server logs see visitors that GA4 misses, for example people who block the tag or decline consent, so we expect the two to differ. Link previews from messaging apps also open tagged links, and we don't filter those yet. Even so, the two should not differ by more than seventeen times.

What we would check on any store

The evidence points to a short list, and most of it takes an afternoon:

1. Request a product you no longer sell and look at the status code, not the page. It should be 404, or a redirect to the same product in another color.
2. If your storefront is headless, request /pages/contact, /policies/refund-policy and /products/<handle>.json on your own domain, and redirect whichever ones fail.
3. Verify bots by IP before you count them. On this store, more than 10,000 requests in a month used AI crawler names while probing for secrets.
4. Count reads and visits separately, and count an arrival only once per visit. Reads show how often assistants use your pages; visits show how often people follow.

We also started recording ordinary page views from this store on November 2, so the next question is whether the people ChatGPT sends come back. That needs a few more weeks of data.

If you check only one thing, check what your store returns for a product you no longer sell.