Coding agents make bounce rate a bad documentation metric
A developer asks a coding agent how to configure an SDK. The agent fetches one Markdown page, finds the answer, edits a file, and never opens the documentation in a browser. Standard analytics call that a weak visit: one request, no navigation, no time on page, no conversion event. Yet the documentation may have worked exactly as intended.
We can now see part of this traffic. Hugging Face publishes an agent-usage dataset built from the agent/<name> token that supported coding harnesses send through huggingface_hub and the hf CLI. Its dataset card says the data represents tens of millions of requests. The scope is limited to one platform. It is not a census of coding-agent adoption. The data does confirm that agents consume documentation and APIs, and that some identify themselves when they do.
Documentation teams need another analytics model alongside the human one. Otherwise, an efficient machine retrieval gets recorded as a failed browsing session.
One request may be the entire journey
A 2026 study of HTTP signatures in developer documentation portals tested nine coding agents and six AI assistant services against a live documentation endpoint. The observed tools often reduced a human-style, multi-page journey to one or two requests. In that setting, the paper says, session depth, time on page, click paths, and bounce rate are unreliable measures of documentation use.
This was an exploratory study using one endpoint and a limited set of trials, not a universal profile of agent traffic. Its measurement problem is more useful than any individual fingerprint. A person leaves traces while moving through a website. An agent can take an answer into the editor and complete the useful action beyond the documentation owner's view.
Automated requests also need more than one label. Training crawlers, search crawlers, user-invoked assistants, and coding agents do different jobs. Cloudflare's AI Crawl Control analytics distinguishes requests by crawler, operator, status, path, content format, and referral source. That taxonomy is more informative than a single bot=true flag.
Identification does not prove identity
Hugging Face's dataset demonstrates both the value and the limit of attribution. In July 2026, Claude Code accounted for 44.4% of agent-attributed Hub requests and Codex for 20.8%. Nearly a quarter landed in the unknown row. The dataset also warns readers that its token is self-declared, its coverage is limited to Python-library traffic, and its figures are shares rather than absolute request counts. A smaller share does not establish that usage fell.
An analytics pipeline should preserve those limits:
- Retain the raw user agent alongside any verified platform classification.
- Label the request as a known crawler, a self-declared harness, or an ordinary browser.
- Where the evidence permits it, separate user-initiated retrieval from background crawling.
- Do not treat a self-declared product name as authentication.
- Keep unknown traffic visible instead of assigning it to the nearest familiar product.
Stable labels help with trends, regression checks, and content planning. They do not belong in authorization or other security decisions because user-agent strings may be absent, changed, or spoofed.
Test the answer path, not the visit length
Begin with retrieval health. Record successful responses, latency, bytes served, content type, redirects, rate limits, and error codes for agent-attributed requests. Split the results by path and documentation version. A sudden run of 404s against an old API path is useful evidence even when those requests never form a session.
Discovery needs a separate view. Log access to llms.txt, Markdown alternatives, sitemaps, API schemas, and repository instruction files, then note which linked resource the client requests. Jeremy Howard's updated llms.txt v2 proposal describes a small Markdown index linking to detailed machine-readable pages. It also proposes HTML link relations or HTTP Link headers to advertise those alternatives.
The proposal is not a client guarantee. None of the tools in the HTTP-signature study requested llms.txt. Publishing one is useful only if you test whether your readers can discover and follow it.
Keep a short set of versioned questions that test whether the documentation supplies a correct answer. For example:
- Which authentication method applies to the current SDK?
- What replaces a deprecated endpoint?
- Which parameters are required for a streaming response?
- What command runs the supported test suite?
Run the questions through the clients or models your readers use. Grade citation accuracy, version selection, command validity, and whether the documented entry point leads to the answer. Treat this like an integration test for documentation. A site serving several model providers through an endpoint such as api.ish.chat can use the same questions to reveal retrieval differences without presenting a single run as a model ranking.
Put feedback where the work happens
Page ratings, site search, support tickets, and edits give human readers ways to report documentation trouble. An agent may skip all four. Add a feedback route to the machine-readable material: an issue template, a documentation-feedback URL in a tool result, or an error response carrying a stable code and a link to the current page.
The trace can stay useful without storing sensitive prompts or source code. Record the requested documentation version, resolved page, response status, selected format, and whether the client followed a replacement link. Our guide to instrumenting AI agents covers the wider trace design. Repository maintainers can use AGENTS.md to place test commands and local rules beside the code, where a coding agent can read them without a portal visit.
Run a two-week audit
Choose the ten documentation pages most closely connected to successful setup or API calls. For each page:
- Serve clean Markdown or another concise machine-readable representation.
- Include an explicit version, last-updated date, canonical URL, and prerequisite links.
- Check the response using a browser, a known crawler, and at least two coding-agent clients.
- Log status, format, latency, bytes, and the next resource requested.
- Ask five real setup questions, then verify the answer and resulting command against the current product.
- Repair broken discovery and stale version paths before polishing the prose.
Keep the human and agent dashboards next to each other. People still need accessible pages, examples, navigation, and text they can scan. Agents need concise sources, stable versions, discoverable alternatives, and errors that point toward repair. The site can serve both groups, but success looks different for each.
A zero-second, single-page session once looked like an obvious bounce. For an agent, it can be the shortest path from a question to working code. The response, version, retrieval path, and correctness now say more than the clickstream alone.
