llms.txt on this site
Two files: /llms.txt, a short map grouped by section, and /llms-full.txt, every public page with its answer-first paragraph, canonical link, Markdown twin, status and verification date. Both are generated by tools/docs_build.py with the rest of the corpus. llms.txt is a community proposal, not a standard, and it is published as a supplement rather than a substitute.
What is published, and where#
| Path | Contains |
|---|---|
/llms.txt | The short discovery map: the product summary, then links grouped by section |
/docs/llms.txt | The same map, at the documentation root, for a client that starts there |
/llms-full.txt | Every public page: heading, canonical URL, Markdown URL, status label, verification date, and the page's answer-first paragraph |
The grouping in the short map follows the URL: a page under /docs/ is filed by its second path segment, so /docs/phone/latency/ lands under *phone*, while /research/, /developers/ and /changelog/ are sections in their own right. That is the same shape as the site's navigation, because it is derived from the same URLs rather than maintained beside them.
The long file is the more useful of the two for a retrieval client that wants to decide what to fetch. Each entry carries the answer-first paragraph — the same text the manifest calls summary — so a client can often answer a simple question without fetching anything, and can always tell which page is worth the second request.
An entry in the long file#
## Held drafts
https://connectbyjbrh.com/docs/email/held-drafts/ · Markdown: https://connectbyjbrh.com/docs/email/held-drafts/index.md · Status: Available · Verified: 2026-09-10
A held draft is a finished reply that Connect wrote and did not send, because
the autonomy rule for that channel says a person decides. …Three things in that line are worth a client's attention. The Markdown URL is the alternate representation, and it is the right body to parse. The status label is one of five words from the capability vocabulary, and it is what stops a summariser from turning a foundation capability into an available one. The verification date is per page, so staleness is visible at the level it actually varies.
What is deliberately kept out#
Nothing private is advertised. tools/docs_check.py reads the generated llms.txt back and fails the build if it names a private path, and it scans both files for anything that looks like a secret. A discovery file is a list of things you are inviting a machine to fetch; the check exists because that is exactly the sort of file into which an internal URL gets added by accident.
It is also not a mirror of the corpus. Page bodies are not inlined into either file — the short map carries links, the long file carries one paragraph each. A client that wants text fetches the Markdown alternate; a client that wants structure reads /docs-manifest.json.
Reading it as a client#
It is plain text with Markdown-style headings, served as text/plain. There is no schema to validate against and no versioning, which is a property of the proposal rather than a decision made here — treat it as a human-and-machine-readable index, and parse defensively.
The MCP server exposes the same file as a resource, llms.txt, titled *Documentation map*, so a connected model can read it without an HTTP client of its own. That resource returns the identical bytes: one generator, several doors.
If you are choosing one entry point, choose by what you are building. A crawler wants the sitemap. A retrieval index wants the manifest and the Markdown alternates. A model with a small context and a specific question wants /llms-full.txt and then one fetch.
Questions#
Does publishing llms.txt affect search ranking?
There is no evidence that it does, and this corpus does not claim it. Google has said no Search system reads the file. It is published because it is a cheap index for a retrieval client, which is a different job from ranking.
Why is the same map served at two paths?
Because clients guess differently. One looks at the site root, another starts from the documentation root it was given. Serving both costs one extra generated file and removes a class of 404 that would otherwise look like the map does not exist.
Is the long file safe to fetch on every request?
It is a static text file with one paragraph per page, but it grows with the corpus. Fetch it on a schedule and cache it against the generated value in the manifest rather than pulling it per query.