Agent analytics from your server logs
Prompt tracking shows the answers. Your server logs show the other side: which AI bots visit, which pages they fetch and which ones they never reach. We read them for you and turn them into a short list of what to build more of, what to stop, and what to unblock.
What the logs tell us, and what we do with it
Three kinds of AI visit look the same in a log file. They mean very different things.
Three kinds of visit
A training crawler, a search indexer and a live fetch are three signals
A training crawler reading your site says little about next month. A search indexer decides whether a page can be cited at all. A live fetch means a person just asked an assistant something and it opened your page to answer. We keep the three apart, because only the last two tell you what is in use right now.
Three kinds of visit read separately
- Training
- Collects text to train future models
- Search
- Decides which pages can be cited at all
- Live fetch
- Someone asked, and the assistant opened your page
On our own site
What the logs showed us about llms.txt
We tested it on our own site first. Over 30 days, AI bots fetched our llms.txt twice, the same number of times they asked for a credentials file we never had. That is the kind of answer logs give you and prompt tracking cannot: whether the thing everyone recommends is read at all.
AI bot visits to radyant.io over 30 days, filtered for .txt files. robots.txt was fetched 3,850 times, llms.txt twice, as often as an aws_credentials.txt that does not exist. Coding agents
Where it is different: developers and their agents
There is one place where a file like that can matter. When we asked a coding agent to integrate another vendor's API, it went looking for the documentation and read that vendor's llms.txt to find it. That is one session, not a study. If you sell a technical product that developers wire up through a coding agent, it is worth checking, and your own logs will show whether those agents come.
One of our own Claude Code sessions. While researching a vendor's API, the agent fetched the vendor's llms.txt to find the documentation. The work
What we take from it, and put on your roadmap
How this fits into AI Search →What comes out is a short list: the content AI keeps coming back to and deserves more of, the topics it ignores, and the errors or blocks that keep a page from being cited at all.
What we take from it and put on your roadmap
- Which pages AI fetches most, and which it never reaches
- Which topics to build more of, and which to stop
- Errors and redirects served to AI crawlers
- robots.txt and CDN rules that shut out the wrong bots
Questions about agent analytics
Do you need access to our server logs?
Yes, or at least to the part of them that comes from AI bots. That can be the access logs from your server, your CDN or your hosting provider, or a small job that forwards only the lines from known AI user agents. For each request we need the time, the page, the status code and the user agent. Visitor IP addresses are not needed for this. If your CDN already keeps these logs, that is usually the quickest way in.
Should we block AI crawlers?
Usually not all of them, and not without looking first. The search indexers and live fetches decide whether you can be cited at all, so blocking them shuts you out of the answers. Whether to allow training crawlers is a separate call, and the logs show you how much of your traffic each one is.
Is this part of your AI Search work?
Yes. Agent analytics runs inside our AI Search work, next to visibility monitoring: one shows what the engines answer, the other what they read.
