> ## Documentation Index
> Fetch the complete documentation index at: https://wtd2026.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQs

> Questions and answers from Write the Docs 2026. On data quality, methodology, AI readers, and what this means for documentation.

## On the data and methodology

<AccordionGroup>
  <Accordion title="How do you know `llms.txt` requests are really AI and not bots?">
    You're right that we can't be 100% certain, but these endpoints were purpose-built for AI consumption and have no meaningful human use case. Someone typing `/llms-full.txt` into a browser is essentially unheard of. Other than technical writers checking their own files, few human users even know these endpoints exist. It's the clearest signal we have, which is why we treat it as "certain" rather than "inconclusive." Traditional bots (link checkers, SEO crawlers) don't target AI-specific endpoints.
  </Accordion>

  <Accordion title="Isn't 35-47% a huge range? Can't you be more precise?">
    The range is the honest answer. The 9.3 million events between those percentages are genuinely ambiguous. High-volume clients wearing human user agents. We could pick a midpoint, but that would be false precision. The range tells you something true: 35% is the floor (only traffic we trust), 47% is the ceiling (everything suspicious is attributed to AI). The gap is the size of our uncertainty and will shrink as we refine how we detect AI traffic.
  </Accordion>

  <Accordion title="Is one day of data enough to draw conclusions about the Read and Write layers?">
    For behavioral patterns—conversation length, message style, verbosity by turn—yes. These reflect stable user behaviors that don't change dramatically day-to-day. For volume trends, seasonal patterns, or day-of-week effects, a single day may not be sufficient.
  </Accordion>

  <Accordion title="What about privacy—you're tracking IPs and user agents?">
    This data is aggregate analytics, the same category as web server logs. No personally identifiable information is stored. IP addresses are used for pattern detection (identifying bot clusters) and cloud provider attribution, not for tracking individuals. The analysis is at the level of user agent and IP pairs and event counts. There are no user profiles or identities involved.
  </Accordion>

  <Accordion title="How fast is AI traffic growing?">
    This data is a snapshot. What we can say is that 35-47% is where we are today, and the infrastructure (`llms.txt`, MCP tool integration) is still being broadly adopted. The ceiling is likely higher as more AI products add documentation retrieval.
  </Accordion>
</AccordionGroup>

## On the AI agents

<AccordionGroup>
  <Accordion title="Is Claude reading docs because users asked it to, or is Anthropic crawling?">
    Both, probably. "Claude" in the named agent breakdown is a group of distinct user agents:

    * **ClaudeBot** — Anthropic's crawler, used for training and indexing
    * **Claude-User** — Claude responding to a user query in real time, fetching docs to answer
    * **Claude Code** — the coding agent fetching documentation programmatically during development tasks

    They all show up with distinct user agent strings and we group them under "Claude." The 591K figure is the aggregate. Claude Code alone was 11,008 events in the same 24-hour window.
  </Accordion>

  <Accordion title="Should technical writers now write for Claude specifically?">
    Less "write for Claude" and more "write for machine consumption generally." Clear structure, good headings, concise section introductions, explicit context—these help agents and humans alike. The optimization isn't at odds with good documentation practice; it raises the stakes for structure.

    The most AI-specific thing you can add is `llms.txt`. It's the entry point agents use to orient in a doc site. Everything else is just good documentation hygiene.

    As evidence rises that agents need shorter file sizes than humans, writing for the two audiences may diverge.
  </Accordion>

  <Accordion title="What's MCP?">
    Model Context Protocol is an open standard that lets agents call tools and fetch structured data from external sources. A documentation site that implements MCP exposes a search or retrieval tool that agents (like Claude) can call on demand, rather than relying on a cached crawl. It's a more direct, more accurate integration between agents and live documentation. Mintlify implements MCP natively, which is what the MCP events in the traffic data represent.
  </Accordion>
</AccordionGroup>

## On the Read layer

<AccordionGroup>
  <Accordion title="How do you know the one-and-done users were satisfied vs frustrated?">
    We don't. 55% one-and-done could mean "got the answer immediately" or "gave up immediately." The data is silent on this. Designing to find out—a simple thumbs up/down, a follow-up prompt—is part of the process. If you can't distinguish success from abandonment, you can't improve. You shouldn't rely on only quantitative data to make decisions.
  </Accordion>

  <Accordion title="Why does verbosity spike at turn 7?">
    Users hit a wall. By turn 7 they've tried and failed several times, so they switch strategy—dumping all context at once hoping something sticks. This is a known pattern in human-computer interaction when the system doesn't behave as expected. Average response length at turns 6 and 7 reaches 70-150 words vs \~32 words at turn 2. It's an intervention opportunity: if you can detect turn 5-6 degradation, you can surface different help before the user gives up.
  </Accordion>
</AccordionGroup>

## On the Write layer

<AccordionGroup>
  <Accordion title="Why do writing agents take 10x more API calls per session than the reading assistant?">
    Writing agents are multi-step by design. They read existing docs, check a codebase, draft content, verify, revise. Each step is a separate API call. The reading assistant is effectively single-shot: one question, one answer. The 19.7 vs 3.3 ratio reflects architectural difference, not inefficiency.
  </Accordion>
</AccordionGroup>

## On the craft

<AccordionGroup>
  <Accordion title="Does this change what good documentation looks like?">
    Yes, in specific ways. Agents don't scroll, don't click "show more," don't infer context from page layout. They parse text.

    * Clear headings matter more, not less. They're navigation signals for machines and humans
    * Code examples should be self-contained. An agent may retrieve just the code block
    * Avoid burying key information in sidebars or tabs. Agents often don't see them
    * Write section introductions that stand alone. Agents often retrieve just one section
    * `llms.txt` is the entry point agents knock on. It's no longer optional

    None of this conflicts with writing for humans. It raises the stakes for structure.
  </Accordion>

  <Accordion title="Does this mean people are reading documentation less?">
    We can't answer that from this data. We're seeing shares, not absolute human trends over time. What we can say is that AI is adding a massive new category of reads on top of whatever humans are doing. Whether humans are reading more, less, or the same is a genuinely separate question this data doesn't address.
  </Accordion>
</AccordionGroup>