llms.txt in practice: making your site readable to AI agents (and what it can't do)

An increasing share of your future customers will first encounter your product through a language model — an answer engine summarising options, or a buyer's agent doing the first pass of a vendor evaluation. Those systems do not browse the way people do. They fetch, they parse, they run out of context window, and they leave. llms.txt exists to make that visit count.

This is a practical guide: what the file is, exactly what to put in it, and — just as important — what it cannot do for you.

What llms.txt is

llms.txt is a proposed web standard, published by Jeremy Howard in September 2024, for a markdown file at your site's root (/llms.txt) that gives language models a concise, curated map of the site: what it is, and which pages matter, with links. The analogy that stuck: robots.txt tells crawlers what they may read; llms.txt tells models what is worth reading.

The format is deliberately minimal:

# YourProduct

> One-paragraph summary of what the product does and who it is for.

## Docs

- [Pricing](https://example.com/pricing.md): plans, limits, and overage terms
- [Security](https://example.com/security.md): certifications, data location, subprocessors

## Optional

- [Blog](https://example.com/blog.md): product announcements

Only the H1 is required. Everything else — the blockquote summary, the H2-sectioned link lists — is convention. Two companion practices are worth adopting at the same time: serving clean markdown versions of key pages at the same URL with .md appended, and publishing an llms-full.txt that concatenates full page text into one file for models that want everything in a single request.

What to put in it (for a B2B product)

Think of the file as your pitch to a reader with no patience and perfect recall. Order sections by what a buyer's first-pass evaluation needs:

1. What you are, in one blockquote. This paragraph will be quoted. Write it like the answer you want repeated.
2. Pricing. The page an evaluating agent looks for first — and the one most vendors hide. If your pricing page says "contact us", your llms.txt cannot fix that.
3. Security and compliance. Certifications, data residency, subprocessor list. The raw material of every security questionnaire.
4. Integrations and docs. Agents check claimed integrations against documentation. Link the docs, not the marketing page.

Keep it curated. The file is a map, not a sitemap — fifty links defeats the purpose, which is triage under a limited context window.

The honest limits

Adoption is voluntary on both sides: you can publish the file, and any given AI system may or may not read it. So treat llms.txt as low-cost groundwork rather than a growth strategy — the cheapest way to make your site legible to answer engines in one request, with your own framing of what matters.

The deeper limit is structural: a file can be read, but it cannot answer. An agent evaluating you against a buyer's requirements has questions your site does not literally address — "does the flat-rate plan cover audit logs?", "is data stored in Japan?", "can it export to this format?". A static file ends the conversation exactly where it gets valuable. And silence in an agent-written comparison does not read as neutral; it reads as unknown, next to a competitor whose answer was checkable.

That is the gap between being readable and being answerable. llms.txt is the passive end of a spectrum. The active end is an interactive, permissioned endpoint — what we call a door — where a visiting agent can ask its actual questions and get answers with citations, drawn only from material the vendor approved. We publish both llms.txt and llms-full.txt for this site, and we consider them table stakes; the door is the part that did not exist before.

AgentDoor launches at the end of August 2026. If you want your product to be answerable — not just crawlable — when buyers' agents arrive, join the waitlist.