TL;DR: The agent's half of your funnel mostly ends up as bot noise, as Direct, or nowhere, because coding agents read your docs without running your analytics snippet. You can see it from the server side. Start with your logs: look for llms.txt and .md requests, and for the gap between what your logs and your analytics count.
Open your analytics and look for the coding agents in last week's docs traffic. You probably won't find them, and it's not because your setup is wrong.
There's no shortage of them. On OpenRouter alone, coding agents made about 60 million model requests in a single day this week. Those are model calls, not visits to anyone's docs. But in early sampling, Vercel found that coding agents search the web in roughly one prompt in five, so some of that work goes through docs like yours.
1. Your analytics was built to watch people, not agents
Both kinds of analytics work the same way underneath. A page loads in a browser. A JavaScript snippet runs, sets a cookie and sends an event: page viewed, button clicked, signed up. Everything in your funnel is built from those events. That works for people, because they use browsers.
Even GA4's newer "AI Assistant" channel depends on it. Since May, GA4 can label a visit as coming from an AI assistant such as ChatGPT, Gemini or Copilot, but only when a person clicks a link and the browser passes the referrer along. When the link opens in the assistant's in-app browser, the referrer is often stripped and the visit lands in Unassigned or Direct. We went through GA4's side of this in detail in Why AI agent traffic looks invisible or Direct in GA4.
Anything that reads your docs without running that snippet never enters your funnel.
2. Coding agents read a different version of your site, one your analytics doesn't see
A coding agent fetches your page over plain HTTP, the way curl does. It reads the HTML or, better, the markdown. It usually doesn't run your JavaScript, so the snippet doesn't fire and no session gets recorded.
Then it goes where people rarely go: llms.txt, the .md version of your quickstart, the API reference. After that it calls your API directly with a key the developer pasted in. None of those requests touch your front end.
On our own site, agents get a different page than people do. They get the same content as markdown, because that's what they read best, so in effect they're reading a different site. You can check it on our blog: request any post with an Accept: text/markdown header, or add .md to the URL, and you get the markdown version.
As agents do more of the reading, more of your docs traffic happens where your analytics can't see it.
3. Agent visits show up as bot noise, direct signups, or not at all
Whatever reaches your dashboards usually ends up in one of these places:
- Server-side tools often see the requests, then filter them out as bot noise along with the scrapers and crawlers, because that's what they look like. When this came up in an X thread this month, one person replying wrote that they'd "been treating agent visits like bot noise this whole time."
- The developer signs up later, after the agent did the work, and your analytics records it as a direct visit from nowhere.
- If the agent tried you, hit a problem and switched to an alternative, nothing in your analytics records it.
Your funnel starts at signup. The agent's starts at the quickstart, and sometimes it gives up before it ever reaches your funnel. Everything in between is missing: which docs it read, which dead link it got stuck on, how many tries it took, what it compared you against. Agents often get stuck on docs written for people: tabbed code examples, setup shown on another page, code in images, and auth explained after the endpoints.
The signups agents bring in get credited to Direct, so the docs work that earned them looks like it did nothing. The integrations they abandon are lost without anyone on your team seeing them.
4. You can't fix this with better tracking, only from the server side
Tracking lives in the browser, and the agent usually doesn't open one. More events, better UTM tags and a cleaner bot filter all work on traffic that runs your snippet. Google's server-side option, the Measurement Protocol, doesn't change that either. It lets you send events you already know about, such as an offline conversion, but it doesn't detect a visitor who never ran your JavaScript. Tools that track AI answers have the same gap. They measure AI reading you (crawls, citations and referrals), not what a coding agent did with your docs and API.
What you need is a view from the server side: every request, identified by which agent made it, joined into the path that agent took through your docs and API, so you can see which pages it read, where it stopped, and whether a signup followed.
Your current analytics can't be configured to do that. It takes a tool that reads the requests themselves.
5. Three checks show how much of the agent's funnel you're missing
You can run all three today:
- Look at your server or CDN logs for llms.txt and .md requests. People almost never request those directly, but agents do. Note which user agents asked and for which pages.
- Compare your docs traffic in analytics with your docs traffic in the logs. The gap is a rough upper limit on what you can't see, because the logs also include crawlers and other bots. Use the same pages and the same week for both.
- Look at the "direct" share of your signups over the last six months. If it's grown, ask what's sending them.
None of these will tell you which agent did what, but they'll show you whether there's a gap worth looking into.
