Bot traffic in a single day: how Arbling caught 3,200+ aggressive requests, and why e-commerce brands need to tell them apart

On 3 October 2026 (UTC), Arbling's own sensor counted the bot traffic on arbling.com and its blog: 3,209 automated requests. For comparison, it counted 1,613 browser-like page requests that same day, and that figure includes Arbling's own test runs, so it is not a count of human visitors. Add the two together and you get 4,822 requests. Of those, 3,209 were not a person in a browser. That is two of every three.

Every figure in this article comes from Arbling's own sensor on arbling.com. We are not quoting a study, and we are not describing a customer's store. This is one site and one day.

What the bot traffic was made of

The 3,209 automated requests fall into two groups.

557 came from named crawlers and AI agents, 36 different ones that day. The other 2,652 came from programmatic clients that are not a browser and match no known crawler: 2,321 of them on the main site and 331 on the blog.

The unnamed group is the larger one, and it is the least informative. These are scripts, scanners, monitors and unknown bots. A small part of it is Arbling's own checks. We do not call it an attack, because we cannot show that it was one. We show the volume and leave the judgement to you.

The named group is where the useful signal is, because a name tells you what the visitor is for.

The 557 named requests, by what they do

Source: Arbling's own sensor on arbling.com, 3 October 2026 (UTC). Names are declared user agents, not verified by address.

One note on Meta. Meta-ExternalAgent is counted with the training crawlers: Meta's own documentation says it crawls the web for uses such as training foundation AI models. The fetcher that acts on a person's request is a different one, Meta-ExternalFetcher. For every other bot the split follows our catalogue's label.

Why the split matters for an e-commerce brand

A single "bot traffic" number hides what each visitor wants from you. (For the shopping side of it, see how to track AI recommendations for a Shopify store.)

Search-index crawlers decide whether you can be found. If they cannot read your pages, you do not appear in the index, whether that index feeds a classic search engine or an AI answer engine. Blocking them by accident costs you discovery.

Training crawlers collect text for models. They do not send a shopper. Whether to let them in is a policy decision about your content, and it is yours to make. It should be made on purpose, not by default.

Assistants fetching a page for a person can be a shopper at work. When ChatGPT-User or Perplexity-User requests a product page, someone asked an AI a question a moment ago and the assistant is reading your page to answer it. If agentic commerce reaches your store, reads like these are where a server log would start to show it. Of the four classes, it is the only one with a person waiting at the other end.

Unnamed scripts are noise to separate out. Not every one is hostile, but none of them is a person in a browser. If they sit in the same bucket as the rest, they inflate any request-based traffic count and bury the signal above.

Blend all four together and you cannot answer a basic question: are AI assistants reading my product pages right now, and are any of those reads turning into visits?

What a brand can do about it

1. Measure each class separately. Search-index, training, live assistant and unnamed traffic need their own lines in your reporting. A total tells you very little.
2. Keep the paths AI assistants use readable. Product pages, collection pages and the files that describe your catalogue should load without a login, a script wall or a block aimed at crawlers in general. If a live assistant cannot read the page, it cannot use that page in its answer.
3. Decide per class what to allow. You may welcome search-index crawlers, permit live assistants, and set a different rule for training crawlers. That is a normal position. A blanket "block all bots" or "allow all bots" rule usually means nobody made the decision at all.
4. Treat the unnamed group as its own problem. Rate limits and monitoring belong there, and not on the crawlers you want.

How it was measured

The sensor reads each request's declared user agent on the server and matches it to a catalogue of 186 known crawlers and agents. A user agent is a declaration, not proof. Any client can claim any name, so every name in this article means "declared as", not "verified by address". Requests that match nothing in the catalogue and are not browser-like land in the unnamed group.

Five days of the same sensor

The sensor was switched on for our own site on 30 September 2026. Named-crawler requests per day since then:

That is 964 named-crawler requests in all. On 3 October, 7 visits arrived from an AI assistant's answer (ChatGPT). Seven is small next to 557. It is also the only line in this article where an AI answer sent a visit to the site, and you only see it once the traffic is sorted. We explain the difference between that and AI-traffic analytics in AI traffic analytics vs AI attribution.

What Arbling does

Arbling tells a store which AI agents and crawlers visit it, and which visits come from AI answers. The classes above are the starting point: found, collected, fetched live, or noise. If you would like to see that split for your own site, start at arbling.com, or read what an AI visibility audit for an online store covers first.