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 more than half.

Who publishes one

Seventeen of the 31 messaging agents with a public site serve a real one. Seven of the 13 infrastructure providers do.

That the agents out-adopt their own suppliers is the part worth sitting with. These are companies whose product is an AI that reads and writes on your behalf, and they have concluded that being legible to other AI is worth an afternoon. Their vendors, who sell to developers, mostly have not.

The most conspicuous absence is Linq, which carries the messages for all eight agents in this directory that disclose a provider, and which publishes no llms.txt. Its competitors Sendblue, Photon, LoopMessage, Blooio and Tuco all do. So does respond.io, at 184 KB and 746 links. Twilio and Telnyx do not.

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: 60 KB, 199 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. 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.

Sixteen of the 17 include the > summary line under the heading. Notis is the one that does not. Six of them also ship the expanded llms-full.txt, ranging from Kachi's 10 KB to folk's 843 KB. Four of the providers do too.

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.