Most companies know a great deal about who visits their homepage. They see visits, the sources of those visits, how many converted, and how the numbers move hour by hour. The same companies know far less about who reads their documentation. At best they have page views. Often they have nothing at all.
The homepage tells you how many people arrived. The documentation tells you what those people needed once they decided to look closer. The homepage gets attention because it sits at the top of the funnel. The documentation gets less because it sits further down. But a person reading your API reference is doing one of two things. They are deciding whether to buy your product, or they are trying to use what they already bought. There is no other reason to read an API reference. These readers are closer to a decision than your homepage visitors are. They are the group to watch, and most companies cannot see them.
The new readers of your docs
Your documentation now has readers that did not exist a few years ago. AI agents read your docs to answer questions for the people who sent them. An agent does not open a browser and click through your site. It reads the surfaces meant for it. It reads llms.txt, the Markdown version of a page, an MCP server, or WebMCP. A person loads a page and the tracker fires. An agent fetches text and the tracker does not. Each of those agent reads happens without a JavaScript tracker running. Web analytics never record them, because the tracker that records a person in a browser never loads.
You may already have agents reading your docs without knowing it. The reads look like nothing in your dashboard. A request for a Markdown file, or a call to an MCP server, produces no page view. The reader was there. Your tools were not built to count it.
- A person opens a page
A browser loads the page and runs its analytics tracker.
- A page view is recorded
Web analytics counts that browser visit.
- An agent retrieves documentation
It fetches llms.txt, a Markdown page, or the MCP server.
- The browser tracker does not run
That retrieval is missing from browser-based page-view analytics.
Questions you can now hear
Web analytics has always hidden the question that brought a reader. A search engine brings a person to a page, but it does not tell you what they typed. You see the landing page and not the intent. Before, you guessed at what readers wanted from the pages they landed on. That guess is why page views alone never told you what readers needed.
The new readers state their questions. An agent asks a question to get an answer. A person using the docs assistant types a question and waits for the response. The question is the record, and it is in your hands. You no longer have to infer the intent from a URL.
That record changes what you can learn. Some questions had a good page behind them. Others had no page at all. Some searches returned no result. Some assistant answers came without a citation, which means the assistant had no source to point to. The questions without a page, the searches without a result, and the answers without a citation are gaps. A gap is a question someone needed answered, with no answer present in the docs.
| What the reader did | What the docs had | What it becomes |
|---|---|---|
| Asked a question with no page behind it | Nothing | A drafted page |
| Searched and got no result | Nothing | A drafted page |
| Got an assistant answer with no citation | No source to cite | A drafted page |
Taken together, the gaps are the strongest product signal in your documentation. They are what readers looked for and did not find. Ordered by how often they were needed, they become a list of what to write next.
What happens to a question with no answer
A dashboard full of gaps changes nothing on its own. A chart that shows a missing answer does not write the page that would have answered it. The gap has to come back to you as work.
The useful form of a gap is a drafted page. The question that had no answer becomes a page that answers it, written and waiting for your review. The search that returned nothing becomes a page that would have matched. The assistant answer without a citation becomes a page that gives it one.
This is the loop. The docs produce the signal. The signal turns into drafted pages. You decide which ones ship. The gap closes only when the page publishes, and only after a person has approved it.
Where the approach has limits
Not every question needs a page. A reader may ask about a feature you do not plan to build, or about something outside your product. A gap can point to work you should not do. The list of gaps needs a judgment on top of it, which is why a person approves what ships.
A drafted page can also be wrong. The agents write from the product context you give them, and that context can be thin or out of date. A page that answers the wrong question, or answers the right one badly, is worse than the missing page it replaced. Review exists to catch that. The gap tells you a question was asked. The draft gives you a candidate answer. Neither one publishes on its own.
What SaturnDocs does
SaturnDocs is a documentation platform built for the AI agents that now read your docs, and for the people who still do. We serve the docs, so we record reads by people and by agents, counted separately, along with the questions asked and the questions that had no answer. Each gap comes back as a drafted page. The agents write those pages from the gaps the docs surfaced, and they update the docs after every product release. You supply the product context the agents need to write. You approve each change before it publishes. Send us a note and we will read your docs and send back the gaps we find and the pages we would draft to close them.