Documentation is the part of a site an agent has the most reason to fetch. A person asking an assistant how to do something with your product is asking a question the docs answer, and an agent trying to call your product is looking for the API you describe there. That makes a docs site the highest-value surface on the rubric per page, and also the one most often built by a generator whose defaults nobody has examined against a plain fetch. This post covers what three checks want from a docs site, what four common generators give you by default as far as their documentation describes it, and a short checklist that applies to all of them.
The three checks that decide it
A7, server-rendered content parity, is five points. The scanner compares the visible text in the raw HTML of the homepage against the text of the rendered DOM and awards full marks at a ratio of 0.8 or above, three points between 0.5 and 0.8, and nothing below 0.5. For a docs site the homepage is usually the docs landing page, and the number says whether an agent doing a plain fetch, which is how an agent without a browser reads, receives the content or a shell.
A4, llms.txt present, is four points: three for a file at the root with at least three links that each carry a description, one more for an llms-full.txt beside it, and one point in total for a file whose links are undescribed. How to write an llms.txt that earns its place covers the format; for a docs site it is close to a table of contents with a sentence per entry.
C4, machine endpoints and agent manifests, is five points: three for any one of an agents.json, an OpenAPI spec, an MCP manifest or an API documentation link, five for two or more. The engine fetches /agents.json and then runs three pattern matches over the homepage HTML only: one for a file name such as openapi.json, openapi.yaml or swagger.json, one for an MCP reference, and one for a link whose href contains /docs or /api-docs or points at a developer. or developers. host. A docs site that links its own spec by file name from its landing page earns a signal it already deserved.
Which host is being scanned
The scanner scores one host. If the documentation lives at docs.example.com and the scan is of example.com, the docs count only as far as the marketing homepage links to them, which satisfies the API documentation match in C4 and nothing else. The llms.txt that a docs platform generates at docs.example.com/llms.txt does not exist as far as a scan of example.com is concerned, because A4 fetches /llms.txt at the root of the scanned host.
Scan the docs host separately if you want its own score, and put an llms.txt at the root of the marketing host regardless, pointing into the docs. The two files can share content; what matters is that each host answers for itself.
The four, by default
Two families. Docusaurus is a generator you build and host yourself, so you own the root files, the headers and the hosting layer. Mintlify, GitBook and ReadMe are hosted platforms: the platform decides what appears at the root, what the search does and what sits in front of the origin. That decides how much of the checklist below is a file you write and how much is a setting you find or a request you make.
Everything in this section is limited to what each vendor's documentation describes as of this writing. Defaults change; check the documentation linked for each before relying on a sentence here.
Docusaurus
Docusaurus generates a static HTML document for every route at build time and hydrates it in the browser afterwards, so the page text is in the raw HTML by default and parity is a matter of not undoing it with client-only components. The classic preset includes a sitemap plugin. There is no llms.txt by default as of this writing; the file goes in the static assets directory and is served from the root, or comes from a community plugin. API reference pages generated from an OpenAPI document are a plugin rather than a core feature, and the check rewards a link to the spec file itself, not only to pages rendered from it. The search its documentation recommends is a hosted widget driven by JavaScript, which is fine for people and invisible to a plain fetch, so the search endpoint on the checklist below is something to add. The Docusaurus documentation is the reference for all of this.
Mintlify
Mintlify hosts the site and generates the pages from your content and, for API sections, from an OpenAPI document you supply, so the spec is a first-class input. Its documentation describes generated llms.txt and llms-full.txt files for hosted sites as of this writing, which is the A4 shape exactly. Confirm it with a plain fetch of your own docs host rather than taking the description on trust, and do the same for parity. The hosting layer is Mintlify's, so A5 measures their edge rather than yours. The Mintlify documentation is the reference.
GitBook
GitBook hosts published spaces, and its documentation describes OpenAPI-based API blocks and, as of this writing, machine-readable variants of published content including an llms.txt for published sites. Treat the specifics as things to verify on your own site rather than as a default you have already got, since what a hosted platform generates for one plan or one site configuration may differ from another. The GitBook documentation is the reference.
ReadMe
ReadMe is built around an API reference generated from an OpenAPI document, with guides alongside it, and hosts the result. Whether an llms.txt is generated for your project, and what the rendered HTML contains before scripts run, are the two things to check against its current documentation and with curl, because both are the kind of feature a hosted platform adds and changes between the time a post is written and the time it is read. The ReadMe site is the starting point for its documentation.
A checklist for a docs site
Whatever generates the pages, five things decide most of the score.
- Parity. Fetch the landing page with curl and read it. If the prose is there, A7 is fine. If the body is a mount point and a bundle, it is not, whatever the generator's marketing says. Measuring server-rendered parity has the method.
- One h1 per page. Most generators render the page title as the h1. A markdown file that also opens with a
#heading produces two, and B3 wants exactly one on every crawled page. - A real search endpoint. A search form that uses GET with a query parameter, so an agent can construct a results URL, earns C6. A widget that runs entirely in the browser does not, however good it is for people.
- An llms.txt at the root of the scanned host. Three or more described links; an llms-full.txt beside it if the docs are small enough to ship as one document.
- A link to the API spec by file name. On the landing page of the docs host, and on the marketing homepage if that is the host being scanned. Publishing an OpenAPI spec for a site that has no API covers what to put in one when there is no API to describe.
Our own documentation page is the example we hold ourselves to: a server-rendered page that links the OpenAPI 3.1 document by file name, links the MCP endpoint, and is itself linked from the site navigation, so the homepage carries the API documentation match. The llms.txt is generated from the same route registry as the sitemap, so the docs page is listed there with the same one-line summary.
Check your own site
Run the free scan against the docs host and against the marketing host separately, and compare the A4 and C4 evidence for each. The definitions are on the methodology page under discovery and access and actionability.