Who publishes llms.txt, and what they put in it

llms.txt is a plain text file at the root of a site that tells a language model what the site is and where its useful pages are. It is a convention, not a standard. Nobody is required to serve one and no search engine has said it changes anything.

Adoption across the web is somewhere around one percent. In this category it is about half, and among the providers those agents run on it is closer to three quarters.

Who publishes one

Forty-two of the 90 messaging agents with a public site serve a real one. Nineteen of the 26 infrastructure providers do.

Both halves have moved since this was first measured on 6 September, when the count was 17 agents of 31 and 7 providers of 13. The ratio held as the directory doubled, which is the more interesting result than either number: adoption in this category is not a handful of early movers, it is roughly half of everybody, and it stayed roughly half as the sample grew.

Linq is the one to watch here. It carries the messages for all 29 agents in this directory that disclose a provider, and on 6 September it published nothing at that path while its competitors Sendblue, Photon, LoopMessage, Blooio and Tuco all did. It now serves one, at 3.5 KB and 21 links. Telnyx has since done the same. Twilio still has not, and respond.io remains the largest file in the set at 184 KB and 758 links.

Verify before you count

A status code is not evidence. Plenty of hosts answer 200 with the application shell for any path you ask for, and if you count those you are measuring hosting configurations rather than publishing decisions.

We fetched every file and inspected it. A file counts here only if the server sends it as text rather than HTML, the body does not begin with markup, it is not empty, and it opens with the # Title line the convention calls for.

That check changed the answer. Tomo returns an HTML shell at /llms.txt, and a naive sweep counts it as adoption. The honest number is 17, not 18. If you run this measurement yourself, expect the same trap.

Three genres, not one

The convention says almost nothing about content, so the files have diverged into recognisably different documents.

The docs index. The most common shape. A one line summary, then a list of documentation pages with a sentence about each. Poke's is the tidiest example in the set at about a kilobyte: seven links covering integrations, MCP servers, the API and release notes, and nothing else.

The sales sheet. Catch restates its entire marketing site for a machine: 62 KB, 211 links, use cases broken out by job title, and the price stated in the second paragraph as a flat 99 dollars per user per month. Pally's runs to 103 links, Arlo's to 68 with a 433 KB companion file. The largest in the set now belongs to an infrastructure vendor rather than an agent: Daytona's is 205 KB and 2,137 links. These are not written for developers. They are written for the assistant a buyer is asking which executive assistant to use.

The guardrail. Boardy's is the outlier and the most interesting. After the summary and a short list of canonical pages, it closes with an instruction to the reader: use these pages as the authoritative source, and do not infer access to private profiles, conversations, calendar data, introductions or account state from this file.

That is a company using the format defensively, to constrain what a model asserts about it rather than to advertise. For a product whose entire surface is other people's professional relationships, this is a rational thing to want, and it is the only file in the set that attempts it.

Forty-three of the 45 files include the > summary line under the heading. Lindy and OpenClaw are the two that do not. Eleven agents also ship the expanded llms-full.txt, ranging from 10 KB to folk's 843 KB, and nine of the providers do.

Does it do anything

There is no public evidence that any assistant ranks a site higher for serving one, and we are not going to claim otherwise.

What can be said is narrower and still useful. A model that reaches your site through one of these files gets your own summary of yourself, in your words, with your links, instead of whatever it reconstructs from rendered marketing pages. Half this category has decided that is worth controlling. Whether it moves anything is unproven, and the cost is an afternoon.

The stronger argument is the one Boardy is making. If assistants are going to describe your product to people whether or not you help them, a file that states what you are and marks the boundary of what should not be inferred is cheap insurance.

If you are writing one

Keep the shape the convention specifies, because it is the only part anything can rely on: an # H1 with your product name, a > blockquote summary directly under it, then ## sections of markdown links with a short description after each colon.

Say what the product is in the first sentence, including the things a model cannot infer from your homepage: what it costs, where it works, what it will not do. Catch stating its price in the summary is the single most useful line in any of these files, because it is the question a buyer's assistant will actually be asked.

Link canonical pages, not campaigns. If you serve markdown versions of your pages, link those instead of the HTML.

And write it for a reader that will quote you. Everything in the file is a claim you are handing to a machine that may repeat it without the surrounding page.