50,075 AI Bot Hits. Only 2,703 Were On-Demand Fetches

Only 2,703 of the 50,075 AI bot hits in our 30-day edge logs came from verified on-demand agents. If I put the larger number in a visibility report, I would be counting mostly requests I could not even attribute to an AI provider.

The first filter cut those 50,075 user-agent matches to 8,573 verified requests (17.1%). The second isolated requests from ChatGPT-User and Claude-User, the agents that fetch pages in response to user activity: 2,703 (5.4% of the raw total). That last number matters more than the headline count. It still does not tell us whether a particular page appeared in an answer, earned a citation, or sent a buyer to groas.

These figures come from our 30-day log analysis, not from a universal benchmark. They show why a dashboard full of bot hits is a poor substitute for measuring which pages on-demand agents actually request.

Three counts, three different claims

A user-agent string is a requester’s claim about its identity. It is not proof. We checked claimed AI bot requests against provider network information, including published IP ranges and verification records, then separated on-demand agents from other verified crawlers. The counts describe requests, not people, prompts, citations, or revenue.

The middle row includes more than live retrieval. Verified crawlers can fetch pages for other operational purposes. The bottom row is narrower, but an on-demand fetch is not a confirmed citation. Server logs show that an agent requested a resource; they do not show the answer a person saw.

That leaves 41,502 requests that matched an AI bot string but did not pass our verification filter. Some may have been scrapers or probes. The logs do not justify assigning a motive to every one of them. The risk is straightforward enough without that story: as practitioner log audits and crawler-spoofing accounts illustrate, a requester can claim to be ChatGPT-User or ClaudeBot in a header. Counting that header as verified visibility gives the requester control of your report.

The blog archive looked busy. Its articles told another story

The /blog root path collected 4,356 AI user-agent matches during the same window. If you stop there, the archive looks popular with answer engines. Only 263 requests (6.0%) passed our provider checks, and we recorded zero on-demand fetches to that path.

That does not mean the articles under /blog were invisible. The archive is a listing page, not the articles themselves. Nor can I identify all 4,093 unverified requests as content harvesters from the count alone. What I can say is that archive traffic made a weak visibility metric: it mixed a large unverified total with no observed on-demand requests to the archive URL.

Our earlier breakdown of category pages showed the same reporting trap. Listing hubs drew thousands of claimed bot requests but no recorded answer-time retrievals. A category page can help people navigate. Its bot-hit count does not tell you whether an assistant retrieved the underlying article to address a specific question.

Report the article paths separately from their directory pages. Otherwise, a noisy archive can make a quiet content catalog look successful.

Three technical posts drew 518 on-demand fetches

When we grouped the 2,703 verified on-demand fetches by path, three articles accounted for 518, or 19.2% of that total. They were practical, dated pieces rather than broad positioning copy.

These are fetch counts from our logs, not counts of answers that quoted the posts. We cannot recover the user’s exact question or the assistant’s final wording from a request alone. What the paths do show is where on-demand agents went when they requested material from our domain.

As we noted when looking at what those pages had in common, each supplied details that are useful to check against a current source: dated changes, specific settings, and direct answers. They put the operational point near the top instead of making a reader wade through a ceremonial introduction to discover it.

I would not turn three posts into a rule that every generic explainer fails or every table wins. The logs do not run that experiment. They do give me a clear editorial bet: when a page covers a changing technical detail, make the detail easy to find and verify. If a team calls that answer engine optimization, fine. I call it writing down the answer.

Most on-demand requests did not land on an article

Two paths took 2,107 of the 2,703 on-demand fetches, nearly 78% of the total: /robots.txt and the homepage. That changes how I read the three-post result. The articles won a meaningful share of recorded on-demand activity, but much of the denominator was infrastructure or navigation, not article retrieval.

Anthropic’s crawler documentation explains why crawl permissions matter. Our logs show frequent Claude-User requests for /robots.txt; they do not prove that every request preceded an article fetch or that a slow response cost us a citation. Still, if that file is broken or your CDN blocks the agent, fixing access is more useful than celebrating a rise in claimed bot traffic.

The 947 ChatGPT-User homepage requests make the root page worth checking too. They do not reveal the prompts behind those requests. They do tell us the homepage was a frequent destination, so I want its primary content readable in the HTML an agent receives. A polished browser rendering is not much help if the initial response is an empty shell.

Before optimizing a page for retrieval, confirm that the agent can read it. That is less glamorous than a visibility score and considerably easier to test.

The limit: logs cannot settle Google visibility

This analysis covers what we could distinguish in our edge logs, chiefly verified requests from OpenAI and Anthropic agents. It does not produce a complete count of AI answers involving our site.

Google is the obvious blind spot. Its crawler overview and AI features documentation describe an indexing setup that does not give us a separate, identifiable live AI Overview fetch in these logs. Google-Extended is a robots.txt control, not a request user agent we can count. A regular Googlebot visit therefore cannot be labelled an AI Overview appearance just because we would like another row in the report.

The same restraint applies to the 2,703 on-demand fetches. We can identify the requesting agent and path, then investigate whether the page was accessible. We cannot turn that into a verified citation or a qualified visit. To examine what an assistant displays for relevant questions, we need prompt evaluations alongside the logs; to assess business value, we need to look beyond fetches altogether.

Use logs to measure access and retrieval, not to claim exposure they cannot show.

Run the three-number audit on your own site

Here is the test I would run before accepting a report that says AI visibility surged because bot hits went up. The question is narrow: How much of the claimed bot traffic can we verify, and which paths do on-demand agents request? Run it prospectively on one 30-day window. Keep the window, path handling, and verification rules consistent across all three counts so the filters, not a changing setup, explain the drop.

1. Metric A — raw matches. Pull edge or access logs from your CDN or server and count requests whose User-Agent contains the identifiers you intend to track, such as ChatGPT-User, GPTBot, Claude-User, ClaudeBot, and PerplexityBot. Keep the request path. This is your noisy starting count, not your result.
2. Metric B — verified requests. Check the source network against the relevant provider’s published information and, where appropriate, use forward-confirmed reverse DNS. Record what passes your checks and what does not. A failed check means unverified by this method, not automatically malicious. If crawler access itself is in doubt, our curl and CDN audit is a useful preliminary check.
3. Metric C — on-demand fetches. Within the verified set, count requests from ChatGPT-User and Claude-User. Group them by path, separating /robots.txt, the homepage, archives, and individual content pages. Do not label the resulting count “citations.”

Calculate Metric B / Metric A to see how much the raw headline survives verification. Then inspect Metric C’s path distribution rather than treating every fetch as a content win. On our site, those calculations produced 17.1% verified requests and 2,703 on-demand fetches, with /robots.txt and the homepage taking nearly 78% of the latter. Those are comparisons for our window, not thresholds that diagnose every site.

I expect many raw dashboards to shrink under this test. The mechanism is mundane: user-agent matching accepts a self-reported string, while provider checks ask whether the network identity supports it. I also expect the path breakdown to complicate the remaining headline, because an on-demand request for a permission file is not the same thing as a request for an article. If your verified share stays high and on-demand fetches reach a broad set of useful pages, keep that evidence. If the count collapses or clusters on infrastructure, change the report before you change the content strategy.

Put the verified number in the report

I would make three changes from these logs. First, stop presenting raw AI bot matches as AI visibility. Show the raw count, the verified count, and the on-demand count together, with the verification method stated plainly. A percentage increase in unverified strings is not evidence that more buyers saw your brand.

Second, check the paths agents request. Make sure crawl permissions work and that the homepage and important articles return readable content. Our /robots.txt and homepage counts make those checks hard to dismiss. They do not justify a made-up timeout rule or a promise that one server tweak will earn a citation.

Third, put editorial effort into pages that answer specific, changing questions clearly. Our three technical posts drew 518 on-demand fetches; that is a reason to examine their structure and produce more useful reference material, not a guarantee that copying their tables will reproduce the count. Measure future pages by their verified on-demand fetches per page, then check displayed answers and business outcomes separately.

At groas, I would rather explain a smaller number tied to a real mechanism than sell a spectacular one built from a header anyone can type. The decision these 50,075 matches support is not “publish more for bots.” It is verify the requester, inspect the requested page, and report only what the evidence can carry.