76.5% of Claimed AI Bot Hits Failed Verification: What Our Edge Logs Say About AEO Reporting

Of the 13,925 requests claiming an AI bot identity that fetched our robots.txt in 30 days, only 3,269 passed edge verification. That leaves 76.5% unverified. If an agency calls all 13,925 “AI bot traffic,” its headline number is mostly requests it cannot authenticate.

I have spent years telling clients not to pay for clicks that never had a chance to convert. This is a different measurement problem with a familiar shape: a large count looks like progress until you ask what it contains. Our edge logs cannot tell us that every failed request was a fake. They can tell us those requests did not clear the verification check. For a client report, that distinction is the point.

A User-Agent is a text field. Anyone can put GPTBot in a header. Cloudflare instead exposes verified-bot status at the edge using checks that include reverse DNS, ASN and public lists (Cloudflare’s verified-bot definition). Impersonation is real: HUMAN’s Satori team found that 1 in 18 requests using an AI-crawler User-Agent was fake in its analysis (HUMAN on fake AI crawlers). That finding does not give our site a spoof rate. It explains why a header alone is a poor reporting standard.

The agent matters, too. GPTBot, OAI-SearchBot and ChatGPT-User do different jobs and have separate CIDR files to check (OpenAI crawler guide). A single “AI traffic” total collapses training, search indexing and live retrieval before anyone has asked which activity a client wants to grow.

The source for this table is groas’s own 30-day edge-log summary. The supplied path list is truncated, so the hub rows show the shares we have, not invented request totals. Even with that limit, the reporting decision is clear: split claimed requests from verified requests before calling either one visibility. The AI Crawler Swipe File goes deeper on crawler identities and robots rules. The first fix here is simpler. Stop counting a self-declared name as proof.

Finding 1: Hub-page volume falls apart under verification

The /blog index verified at 5.7%; category hubs sat around 7%. Compare that with 19.3% for the homepage and 23.5% for robots.txt. A hub is an attractive page for broad link discovery: it presents a lot of URLs in predictable HTML. That helps explain why claimed crawler volume can pile up there. The logs show the low verified share; they do not identify the purpose of every request that failed verification.

Put raw hits on a client dashboard and the hub gets a tall bar anyway. In this window, three category pages each drew more than 3,000 claimed bot hits, yet none recorded a live-answer fetch. A dashboard built around the first number would make them look like winners. The second number says they were not helping with the activity this report is supposed to measure.

I recognise the temptation. I ran PPC accounts when impressions were the comfortable number because conversions looked thin. The chart looked healthy right up to the moment someone asked why the phone was not ringing. Keep hub requests in their own row, show their verified share, and do not let raw volume anchor an AEO report.

Finding 2: A fetch has to be classified before it means anything

The difference between those hubs and two specific posts is easier to see side by side. These figures also come from our 30-day edge-log summary:

The table does not say the posts earned 182 and 143 citations. A live-answer fetch is not a citation. It is a more relevant activity than a generic crawl if the question is whether an answer system fetched a page for live use, but confirming that the page appeared in an answer requires separate observation. One analysis of crawled versus quoted pages makes the same distinction: retrieval and quotation are not interchangeable outcomes.

This is also why a marketing analytics dashboard cannot settle the crawler question. Crawler requests generally do not run the JavaScript that GA4 relies on, while referral reports show people who clicked through, not the bot fetch that preceded an answer (why logs beat GA4 for bot activity). Access or CDN logs give you the requests. Verification tells you which claimed identities passed the check. Agent and request classification then tell you whether you are looking at training, indexing or live-answer activity.

I would report those measures in this order:

1. Verified bot fetches, by path and agent.
2. Live-answer fetches, separated from other verified crawls.
3. Observed cited answers, tracked separately rather than inferred from fetches.

Each line answers a different question. If a vendor offers one number called AI traffic, ask which of the three it represents. If the answer is “all of them,” you are buying the tall bar again.

Finding 3: The answer-focused posts drew the live fetches

The two posts with 182 and 143 live-answer fetches were dated, addressed narrow questions in their titles and URLs, and used structure that could be extracted without untangling an archive page. The hubs offered lists of links. In this window, the live-answer activity concentrated on the specific posts instead.

That pattern is worth acting on, but not overselling. Our logs show where the fetches went; they do not prove which page feature caused each fetch. A separate AirOps study of 217,508 retrieved pages from 7,500 commercial prompts found that only 15% of pages ChatGPT retrieved earned a citation. It also reported associations between answer-friendly structure and higher citation rates:

Those figures come from the AirOps study, not our edge logs, and they are not promises that adding a table produces the same lift on a client site. They do give a sensible reason to prefer a page that answers a question plainly over another archive that merely points elsewhere. Write the useful sentence. Put the comparison in a table when a table helps. Let the page stand on its own.

Our agent-level view reinforces the need to keep categories separate. ChatGPT-User appeared in focused fetches on the two posts; Claude-User appeared repeatedly on robots.txt, where permission checks add requests without adding answer content. Neither observation makes a robots.txt hit a visibility win. Nor does a GPTBot training fetch prove a page appeared in a live answer. Build pages that answer specific questions; measure whether verified live-answer agents fetch them.

What I would change across 10 or more client domains

First, I would retire the report line labelled “AI bot traffic.” On our robots.txt requests, 76.5% of claimed identities did not verify. On the homepage, 80.7% did not verify. Those are our figures, not industry-wide rates, but they are enough to make an unqualified raw-hit total indefensible for our domain. Give clients the three-line sequence instead: verified fetches, live-answer fetches and observed citations. When a category page shows more than 3,000 claimed hits and zero live-answer fetches, the conversation can move from volume to what the page actually does.

Second, I would collect and classify requests as close to the edge as the setup allows. Raw access logs can contain the necessary requests, but collecting them across 10 hosts, normalising paths and checking identities every week is a job in itself. Edge verification performs the identity check when the request arrives. The practical gain is a repeatable per-path report, not a more impressive chart. A client without a developer should not need a custom log pipeline to learn that a header claim failed verification.

Third, I would stop adding archives just to chase an AI crawler count. The evidence from this window is narrow: three high-volume category pages recorded no live-answer fetches, while two specific posts recorded 182 and 143. That supports prioritising useful, narrow answer pages over another hub built for the sake of a bigger crawl bar. It does not guarantee that every dated post will be fetched or cited. Put the content work where the verified live activity is, then check the result.

How I would judge AEO software against these numbers

Before putting a platform across a 10-client book, I would ask four questions:

1. Does it accept a User-Agent claim, or verify the bot identity with checks such as reverse DNS and ASN?
2. Does it separate training, indexing and live-answer fetches rather than rolling them into one traffic total?
3. What does pricing look like across 10 domains, and who handles implementation when a client has no developer?
4. Does it only track the numbers, or does it also do the work of improving the pages those numbers identify?

Price matters because a reporting method that multiplies noise across domains is not rescued by a tidy dashboard. In a Scrunch and Peec pricing comparison, Scrunch entry is listed at $250 per month annually, or $300 monthly, with four engines and three seats. Peec Starter is listed at around €89 per month with 50 prompts; the comparison describes unlimited seats and six engines on standard plans. Those plans count and package different things, so the sticker prices do not answer the verification question. The same comparison of AEO tracking cadence describes daily refreshes for new Scrunch prompts during the first 14 days, then every 72 hours, and daily Peec tracking on standard plans. Its advice to judge directional trends over 30 to 60 days is more useful than treating one prompt check as a verdict.

The weakness of a tracker-only approach is the gap between noticing a page problem and fixing it. Agency AEO Tools: The Questions to Ask Before You Buy Another Dashboard covers that buying decision in more detail. Here, my minimum is less glamorous: show me verified requests by path, distinguish live-answer fetches, and keep citation observations separate. Then tell me who improves the page.

groas is built for agencies that need both reporting and execution, with SEO and AI search from $199 a month per client domain under their own brand. That flat per-domain starting point is a better fit for standardising a client book than choosing a tracker because its first dashboard looks inexpensive, then budgeting the page work separately. A tracker can tell you that a hub drew more than 3,000 claimed hits and no live-answer fetches. It cannot turn that finding into a useful answer page by itself. Pay for the measurement and the work, not the chart alone.

What this 30-day window cannot prove

This is one site, one 30-day window and a truncated path list. It does not establish that every site has a 76.5% unverified rate, that category pages cannot earn citations, or that the same agents will behave the same way across your clients. Failed verification is not proof that every request was malicious. A live-answer fetch is not proof of a quoted answer. And the difference between our posts and hubs does not isolate a magic content format.

What the window does show is enough to make a reporting decision. On this domain, claimed bot requests greatly exceeded verified requests at prominent paths. The category pages with the biggest claimed counts recorded no live-answer fetches, while two specific posts recorded 182 and 143. A raw-hit report would obscure both facts.

So I would put verified fetches first, live-answer fetches second and observed citations third. Raw requests can stay in an appendix. Judge an AEO platform by whether it can make those distinctions per domain and help act on what they reveal. Anything less is counting strangers knocking on robots.txt and calling the noise visibility.