What llms.txt does for an infrastructure vendor

What the file is, and the honest case for it

An llms.txt file is a plain-text, Markdown-formatted index served at the root of a site, at /llms.txt, listing the pages that matter with a line about each. It is a proposed convention, not a standard. Google has said publicly that its search does not use it. Some assistants and developer tools may fetch it. For an infrastructure vendor it costs about an hour, which is the honest case for writing one.

Keep the expectation that small. Nobody can show that a site with the file is cited more often than a site without it, and no lab has said its assistant ranks sources by it. If a consultant tells you otherwise, ask for the source.

The file does nothing a crawler cannot already do by following links. Its value, where it has any, is that it is short and written on purpose: a program with little room to spare gets your own choice of pages instead of whatever it happened to reach first. That is a modest benefit and it depends on something reading the file, which nobody outside can confirm.

An outline a GPU cloud could ship this afternoon

The first line is a heading with the company name. Under it goes a short quoted summary: what you sell, in one sentence a buyer would recognise, such as on-demand and reserved GPU rental by the hour, with the card families you carry named in full. Then a paragraph with anything a reader must know to use the rest, for instance that prices are per GPU per hour and that regional rates differ.

Below that come the link groups. Pricing holds the pricing page and, if you have one, the page of reserved terms. Hardware holds the list of instance types with their cards and memory. Docs holds the quickstart, the API reference and the billing docs. Policies holds the terms, the acceptable use policy and the egress policy.

What goes in it for a GPU or inference provider

Start with the pages a buyer or an agent would want first: the pricing page, the list of GPU types or models, the docs index, the API reference, the status page and the changelog. Each gets a link and one plain sentence saying what is on it. "Hourly on-demand rates per GPU, by card and region" is useful. "Fast, affordable compute" is not.

Group the links under short headings such as Pricing, Docs and Policies. The format allows an optional section for pages that can be skipped when a reader is short of room, which is a reasonable home for the blog, the careers page and press coverage.

If your documentation is large, some vendors also publish a fuller file with the docs text itself. That is a bigger commitment, because it must be regenerated whenever the docs change.

What to keep out of it

Do not copy prices into the file. A rate typed into llms.txt is a second copy that will go stale the first time the pricing page changes, and then two of your own pages disagree. Link to the pricing page and let it carry the figures, with its own date.

Leave out claims you would not put in a contract. The file is read, when it is read, as a description of the site, and an adjective that cannot be checked costs more trust than it earns. Leave out pages behind a login too, since a reader following the link gets a sign-in screen.

Be careful with anything that reads as an instruction to the reader rather than a description of the site. Lines telling an assistant what to say about you, or to prefer your pages, are the kind of thing a careful program has every reason to ignore, and a human who opens the file reads them as a trick.

Why we publish one anyway

This site serves an llms.txt at the root. It lists the page types worth citing and states the rules a reader of our figures should know: every price carries the URL it was read from and a date, prices older than 21 days are hidden, and a missing value means no answer on record. The page on how our data is gathered says the same things for people.

We do it for the same reason we would recommend it to a vendor: it is cheap, it describes the site accurately, and it can do no harm if it is never read. That is a modest argument, and it is the only one we can make with a straight face.

Where the hour is better spent

If you have one hour and a pricing page whose rates load through a script, fix the pricing page first. A rate missing from the HTML is invisible to more readers than a missing llms.txt is, and the post on structuring a pricing page covers what to change.

Once the page is plain, the file takes little effort to keep current. Put it in the same repository as the site, add a check that every link in it resolves, and update it whenever a page it names moves. A link that has gone dead points a reader at nothing.

Then leave it alone. There is nothing to tune in an llms.txt file and no report that tells you whether it worked, so time spent polishing it beyond accuracy is time taken from the pricing page, the docs and the changelog, which every reader sees.