An llms.txt is a shortlist. It tells a machine which pages exist and which are worth fetching, and the previous post covers how to write one. An llms-full.txt is the other half of the bargain: the substance of those pages, as one markdown document, so an agent that needs the content rather than the map can read it in a single fetch. It is the fourth point of check A4, and it is the file most sites publish either not at all or as a dump of navigation that a reader would regret opening. This post is about what it is for, what belongs in it, how large is too large, and how to generate it so that it cannot go stale.
What the file is for
An agent answering a question about your product has two ways to get at the substance. It can fetch a page, strip the navigation, the footer, the script payload and the markup, and keep what is left. Then do that again for every page the question touches. Or it can fetch one plain-text file that already contains the substance, in a format a model reads without preprocessing, and stop.
The second is cheaper in every currency an agent spends: requests, time, and above all tokens. Every byte of HTML chrome an agent has to read past is context it cannot use for the answer. Markdown carries the structure that matters, headings, lists and links, and none of the structure that does not.
That is the whole purpose of the file, and it decides what belongs in it. The llms.txt proposal at llmstxt.org defines the index file; the companion full-text file has settled into a convention under the name llms-full.txt, and that is the name check A4 probes for.
How A4 scores it
A4 is worth four points. A missing llms.txt scores zero; one that exists but has fewer than three described links scores one; three or more described links score three; an llms-full.txt that returns 200 adds the fourth. The order matters. The full-text point is only reachable once the index file has earned its three, so an llms-full.txt beside a bare list of URLs scores one, not two. The index is the thing an agent reads first, and a full-text file nobody is directed to is a file nobody reads.
The evidence block on your report records present, describedLinks and llmsFullTxt, the last being whether /llms-full.txt at the root answered 200. As of rubric v1.0.1 that is all the check reads. It does not parse the body, so a 200 with an empty file, or a catch-all route serving your application shell as HTML at that path, earns the point. Treat the status as the floor rather than the goal: the agent that fetches the file does read the body, and a shell or an empty file costs it a request and teaches it not to try again. If the check tightens in a later version, the change will be logged at /methodology#changelog and earlier scores will stand.
What belongs in it
Substance, not navigation. The test for every section is whether a reader who wanted the content of a page would be satisfied by what the file says about it, without fetching the page. A list of links with descriptions is the job of llms.txt; repeating it here helps nobody.
Ours is the site in this order: the rubric, every check with its id, name, points, effort rating and the published detail, then the grading bands; the services, each with its timeline, price, deliverables and the body of its page; pricing; how reports, the leaderboard, comparisons and badges work, and the listing rules; every published article in full, each with its category, date and canonical URL; the crawler policy, including how to block us; and contact details. Abbreviated, and not verbatim:
# AgentFriendlyRank — full reference
> Agent readiness audits and fixes, scored against a published rubric.
## The rubric (v1.0.1)
### Pillar A — Discovery & access (25 points)
_Can agents find and reach the content at all?_
- **A4 llms.txt present** (4 pts, fix effort: Low). An llms.txt at the root with three or more described links scores three points; an llms-full.txt adds one. An empty or boilerplate file scores one.
## Services
### Agent readiness audit
...
## Articles
### How to write an llms.txt that earns its place
Discovery · Published 11 September 2026 · https://agentfriendlyrank.com/blog/write-llms-txt-earns-its-place
The articles are the markdown source, not the rendered HTML stripped back. Each carries its date, so the file is honest about freshness as well as content. The crawler policy is there because an agent reading a file about a scanning service will reasonably want to know what the scanner does, and it is the same text as /bot.
Leave out what you would leave out of the sitemap: confirmation pages, anything behind a login, anything carrying a credential in its URL. Leave out the marketing frame too. A tagline that opens every page of the site adds nothing on its second appearance in a file that is read top to bottom.
How large is too large
A file that is too large to read in one go has stopped being one fetch and become one fetch the agent must chunk, which is the problem it was meant to remove. There is no fixed number, because the limit is the context window of whichever model is reading, and those are published by the vendors and change. Measure your own file rather than guess:
curl -s https://www.example.com/llms-full.txt | wc -c
Then compare against the documented limits of the models you care about, remembering that the file has to share the window with the question, the instructions and the answer. If it does not fit comfortably, trim in this order. First, anything that is navigation dressed as content. Second, the archive: on our file the articles are the only section that grows, and they are the first thing we would move out if the file outgrew a single read, into a second file linked from llms.txt with its own description. Third, long-tail pages a reader can fetch individually if the index file describes them well. The rubric, the services and the pricing stay, because they are what the site is.
Do not trim by truncation. A file that stops mid-sentence at some byte limit is worse than a shorter file that ends on purpose, because the reader cannot tell what was cut.
Generate it from the registry
A hand-written llms-full.txt is a second copy of every page, and a second copy drifts. Prices change on the pricing page and not in the file; a check is reworded in the rubric and the file describes the old one. The remedy is the same as for the sitemap: do not write the file, generate it from whatever already knows the content.
Ours is a route handler, not a file. It renders the rubric from the same structure the methodology page renders from, the services from the same list the service pages use, and the articles from the same loader that feeds the blog, the sitemap and llms.txt. It is regenerated hourly, so a scheduled post joins it on its day without a deploy, and it is served as text/plain; charset=utf-8 with a one-hour cache header. It cannot describe a rubric we no longer use, because there is no second copy of the rubric to describe.
If your site is a static build, the equivalent is a build step that concatenates the same markdown sources the pages are rendered from, run on every build. If your site is a CMS, it is a template that loops over the same collections as the pages. Either way, the property to keep is that adding or changing a page changes the file without anyone remembering to.
When not to publish one
If the substance of your site is behind a login, do not publish a file that either leaks it or contains nothing. If your site is a handful of pages whose content is already in the index file's descriptions, a full-text file adds little, and the point is cheap enough to take anyway. If what you would publish is a concatenation of navigation, do the index file properly instead and come back to this when there is something to put in it.
For most companies with a documentation section, a pricing page and a body of written material, the file is worth an afternoon, and the afternoon is mostly spent deciding what to leave out.
Check your own site
The free scan fetches your llms.txt and llms-full.txt and reports how many links carry a description and whether the full-text file answered. Check A4 is defined under discovery and access, and ours is at /llms-full.txt if you want to see the shape at full length.