One Sentence Beats Every File
One Sentence Beats Every File
When we published Nobody Reads llms.txt (Yet), the fairest objection was one we had registered ourselves: our test site was small and well-linked, so the discovery files never had a real chance to matter. An agent that can reach every answer by clicking links has no reason to read an index.
So we built the site where the files were the only way.
A site with locked rooms
Study 2's fixture is a 300-page version of our fictional retailer: twelve paginated product categories, documentation that chains page to page, a deliberately thin header. And twelve orphan pages: product recalls, safety bulletins, rebate terms. They exist. They are listed in sitemap.xml and in every llms.txt variant we served, including a curated index and Cloudflare's hierarchical flavor. They are linked from nowhere. The only ways in are a discovery file or a lucky guess.
Then we asked five models 32 questions per site configuration, 960 runs in all, with a proper structured answer channel and a rule: if the site does not state the answer, say so.
Zero for two hundred
Every model scored zero out of ten on orphan questions in every configuration that relied on discovery files. Sitemap, curated llms.txt, giant llms.txt, hierarchical llms.txt: all identical to serving nothing at all, on a site engineered so the files were the only path.
The reason is not that models read the files and used them badly. They never read them. Out of 128 chances per model to consult a discovery file that was actually there, the frontier model took zero. So did the cheapest. The most curious model managed eleven. Meanwhile the models hammered out as many as a hundred guessed URLs per configuration, trying paths like /support/recalls and /faq, and almost never the two standardized paths the industry has spent a year telling websites to serve.
And here is the finding that should worry anyone with unlinked content that matters: in 148 of 150 orphan questions, the models did not just fail. They confidently declared the information not on the site. Recalls and safety bulletins, authoritatively denied, after an honest search that was looking in the wrong places.
we added one sentence
The final configuration served the identical site, files and all, and changed something on the agent's side instead: the fetch tool's description gained the sentence "The site may also provide machine-readable indexes at paths like /llms.txt or /sitemap.xml."
Orphan success went from zero out of ten to ten out of ten on the frontier model and the open-weight flagship, nine on the budget model, eight on the mid tier. Path guessing collapsed; one model went from 43 guessed URLs to zero. Input costs fell for the models that used the index best. One sentence, on the right side of the conversation, was worth more than every file on the site.
What this means
The llms.txt conversation has the beneficiary wrong. The file format is fine. The readers are missing. Discovery files are a protocol with only one side deployed: websites are publishing them, and nothing on the consuming side is looking.
If you own a website: llms.txt will not help AI agents find your content today, even if your site is the worst case it was designed for. The measured lever is linking your content, because link-following is the only navigation agents actually do. And if you have important pages reachable only through a sitemap, know that agents will not just miss them; they will tell users the information does not exist.
If you build agents: the cheapest capability upgrade we have measured in two benchmark series is telling your fetch tool that these files exist. It cost us one sentence and it converted total failure into total success on the hardest retrieval class we could construct.
Both studies, the fixture, the graders, and every number are in the open harness, with the full anatomy on the research dashboard.
