Why Your Analytics Can’t See AI Agents

Open your analytics. Whatever you use — Google Analytics, Plausible, Fathom, Vercel Analytics — look at last month's traffic.

Now count the AI agents. ChatGPT reading your docs to answer a question about your product. Claude pulling three pages to decide whether to recommend your library. Perplexity crawling you for a comparison. GPTBot indexing you for the next model.

You can't count them, because none of them are in there. Not undercounted. Absent.

This is not a configuration problem, and there is no setting that fixes it. It's structural, and once you see the mechanism it's obvious.

The mechanism: your analytics is a browser script

Every mainstream web analytics tool works the same way. You paste a snippet into your site. A human's browser downloads your page, executes the snippet, and the snippet sends a pageview event home. The measurement depends entirely on something running JavaScript in a browser.

An AI agent does none of that. It makes an HTTP request, receives your HTML — or better, your Markdown — parses the text it wanted, and leaves. There is no browser. There is no JavaScript engine executing your tag. There is nothing to fire.

So no event is sent. No session is created. No row is written. From your analytics' point of view, the visit did not happen.

The request is real, though. It's sitting in your server logs right now, with a user-agent string that says GPTBot or ClaudeBot or PerplexityBot. Nobody is reading those logs for agents.

And then it's filtered twice

Here's the part that surprises people. Even in the edge cases where something does fire, Google Analytics throws it away on purpose. Bot and spider filtering is on by default, and has been for years. It was a sensible feature when bots were noise to be excluded from your human numbers.

It stopped being sensible when bots became buyers. The filter is doing exactly what it was designed to do, on a category of traffic that has quietly changed meaning.

So the blindness is doubled: the tag never fires, and if it did, the hit would be discarded as junk.

What you're actually missing

It would be one thing if this were a rounding error. It isn't, because the invisible traffic is the part that decides whether you get recommended.

• Which agents read you, and how often. The difference between "ChatGPT reads us daily" and "no assistant has ever fetched our site" is the difference between two completely different strategies. Today most teams can't tell you which one they're in.
• What they read. Agents don't browse the way people do. They go straight to documentation, llms.txt, Markdown mirrors, API references — the pages your human funnel treats as the back of the store.
• What they asked for and didn't get. An agent requesting /llms.txt and receiving a 404 is a fixable problem with a known fix. You will never learn about it from a tool that can't see the request.
• Whether any of it turns into customers. The read is upstream of the signup, and if you can't see the read you can't connect the two.

The second-order problem: your content strategy is calibrated on the wrong population

This is the part that costs more than the missing dashboard.

You decide what to write, what to update, and what to promote based on what your analytics says people read. That data is real — it's just a sample of one audience. The agent audience reads a different set of pages entirely, and it's invisible in the numbers you're optimizing against.

So the docs page an agent pulls every single day looks like a low-traffic page you should probably deprecate. The marketing page you keep polishing may be one an agent has never fetched. You're not making bad decisions — you're making reasonable decisions from a partial view, which is worse, because it feels like data.

And the invisible share is the growing share. Every month more of your funnel starts with an agent, which means every month a larger fraction of it is missing from the report you run the business on.

How to actually see it

The fix follows directly from the mechanism. If the problem is that measurement depends on a browser executing code, then measure somewhere a browser isn't involved: at the server, at the edge, or in the logs. Four practical options.

• Read an access log. The zero-commitment version. Your logs already have every agent request. Paste a chunk into a free scanner and you'll know in thirty seconds whether this is happening to you.
• A log drain from your host. On Vercel, this is a URL you paste into a settings page — no code, no deploy, and it works for every framework at once. See the Vercel guide.
• An edge worker in front of your origin. The option when you don't control the codebase — hosted documentation, a no-code builder, someone else's repo. See the Cloudflare guide.
• Framework middleware. One line, if you can edit the app. Next.js guide.

One thing worth knowing when you choose: middleware runs before the response exists, so it can't record status codes. Log drains and edge workers see the finished response, which is what lets them tell you an agent asked for a page and got a 404. If you want to find your gaps, pick one of those two. The full comparison is in the install guides.

What server-side measurement still can't tell you

It would be easy to end here, so it's worth being straight about the limits. Seeing agent traffic is a real improvement over seeing none of it. It is not omniscience.

• User-agent strings are self-reported. An agent says who it is and you believe it. Most declare themselves honestly because they want to be well-behaved citizens of your robots.txt, but nothing forces them to, and anything can claim to be anything. Treat named-agent counts as very good, not as forensic.
• A read is not a recommendation. Knowing ClaudeBot fetched your pricing page forty times tells you that you're in the consideration set. It does not tell you whether you won.
• The agent-to-human gap is a separate, harder problem. When an agent reads you and a human signs up days later in a fresh browser, connecting those two events needs different machinery than counting requests. We wrote about why that's structurally hard, and which parts of it are genuinely solvable, in An Agent Sent You a Customer. Your Analytics Called It "Direct."

Start by finding out if it's happening to you

The honest first move isn't to buy anything. It's to answer a question you currently can't: are AI agents reading my site at all, and which ones? For some sites the answer is "barely," and that's a genuinely useful thing to learn. For others it's a daily stream nobody has ever looked at.

Either answer is worth having, and both are sitting in your logs already. We publish our own agent readout at /for-agents — every agent that reads Pickrate, and what it read — because a company measuring this should be willing to show its own numbers.

Paste a log and see yours. No account, nothing stored. Then decide whether it's worth measuring properly.