How to write an llms.txt file, with examples

What an llms.txt is, what the proposal requires and whether your site needs one are covered in what is llms.txt, and does your site need one. This guide assumes you have decided to publish one. Four decisions shape the file more than any rule of the format:

1. 1Who reads it, and to do what. A coding agent wants the API reference; an assistant answering a buyer wants pricing, policies and what you sell. Write for the task, not for a generic reader.
2. 2Which pages. The file is a reading list, not an index: the proposal contrasts it with a sitemap, which lists every page, and calls it a curated overview^[1]. Choose the pages that answer the questions people bring.
3. 3Whether to link Markdown copies. The proposal asks that pages worth reading offer a clean Markdown version at the same address with .md added, or with .md in place of the extension^[2]. Link those where they exist; link the HTML page where they do not.
4. 4One file or several. A file can sit at any path and covers the pages under it, and where several apply, the most specific one is used^[1]. Large sites with separate products or documentation sets often do better with one file per path and a short root file that points to them.

Every example below follows the proposal’s order: the H1, the blockquote, optional notes without headings, then H2 sections of links, each written as a Markdown link with a note after a colon^[1]. The sites are invented, and so are their facts.

A software company’s file is read by assistants answering buyers’ questions as often as by agents working with its product. It leads with the facts a buyer asks for and keeps the documentation to its entry points.

# Example Books > Example Books is accounting software for agencies of 2 to 50 people,> sold by monthly subscription in the US, Canada and the UK. Prices are in US dollars and exclude tax. Each linked page has aMarkdown copy at the same address with .md added. ## Product- [Pricing](https://books.example/pricing.md): plans, limits, annual discount- [Features](https://books.example/features.md): invoicing, time tracking, bank feeds- [Integrations](https://books.example/integrations.md): banks and tools, by country ## Policies- [Security](https://books.example/security.md): hosting, encryption, access- [Refunds](https://books.example/refunds.md): trial, cancellation, refunds ## Documentation- [Getting started](https://books.example/docs/start.md): first invoice in ten steps- [API reference](https://books.example/docs/llms.txt): the API, in its own file

• The blockquote answers three questions in two lines: what it is, for whom, where. Those are the facts an answer about the company gets wrong most easily.
• The note under it states the conventions a reader needs, such as currency and tax, once, so every linked page does not have to.
• The last link points to another llms.txt. The API reference is large enough to need its own file, under its own path.

Documentation is where agents use these files most^[1]. A large documentation set works best as a root file that routes, and one file per section that lists. Because a file covers the pages under its path^[1], the section files can be generated by the documentation tool for each folder.

# Example Books API > REST API for Example Books. Version 3 is current; version 2> stops accepting requests on 1 March 2027. Authenticate with an API key in the Authorization header. Allamounts are integers in the smallest unit of the currency. ## Start here- [Authentication](https://books.example/docs/auth.md): keys, scopes, rotation- [Errors](https://books.example/docs/errors.md): codes and retries ## Resources- [Invoices](https://books.example/docs/invoices.md): create, send, void- [Clients](https://books.example/docs/clients.md): create and merge- [Webhooks](https://books.example/docs/webhooks.md): events and signatures ## Optional- [Changelog](https://books.example/docs/changelog.md): every release since v1- [Migration from v2](https://books.example/docs/v2-to-v3.md): field by field

• The summary carries the one fact an agent must not miss: which version is current. Version mistakes are the commonest error in generated code.
• The note states the two conventions every request depends on, so that no agent has to infer them from examples.
• The section named Optional holds links a reader can skip. Since the revision of August 2026 the name has no special meaning to tools; it remains a convention for secondary links^[2].

A shop cannot list its catalogue in a file meant to be read at once, and should not try. Its file points to the pages that answer what buyers ask before they buy: the range, sizes, delivery, returns.

# Example Ceramics > Hand-made stoneware mugs, plates and bowls, made in Portugal> and shipped to the EU, the UK and Norway. Every piece is dishwasher safe. Prices include VAT for EU orders. ## Range- [Mugs](https://ceramics.example/mugs.md): sizes, glazes, care- [Tableware](https://ceramics.example/tableware.md): plates, bowls, sets- [Made to order](https://ceramics.example/custom.md): minimums, lead times ## Buying- [Delivery](https://ceramics.example/delivery.md): times and costs by country- [Returns](https://ceramics.example/returns.md): 30 days, how to return- [Breakage](https://ceramics.example/breakage.md): what happens if a piece arrives broken

• Category pages stand in for products. They change less often than single products and answer the question a buyer asks first: what do you make?
• The note states the fact that would otherwise be repeated on every product: dishwasher safe.
• The buying section answers the three questions that decide an order abroad: how long, how much, and what if it goes wrong.

A local business is described in answers by where it works, when it is open, what it charges and how to book. Its file states those facts in the summary and the notes, and links the pages that hold the detail.

# Example Plumbing > Licensed plumbers for homes and small businesses in Leeds and> within 15 miles of the city centre. Open Monday to Saturday, 7am to 7pm. Emergency call-outs 24 hours.We do not install gas boilers. ## Services- [Leaks and burst pipes](https://plumbing.example/leaks.md): response times- [Bathrooms](https://plumbing.example/bathrooms.md): fitting, typical timelines- [Prices](https://plumbing.example/prices.md): call-out fee, hourly rates ## Booking- [Areas served](https://plumbing.example/areas.md): postcodes covered- [Book a visit](https://plumbing.example/book.md): how booking works

• The area is stated as a place and a distance, the way a person would ask about it.
• The notes say what the business does not do. An answer that recommends a plumber for a job it refuses is an answer you would rather not get.
• Hours and the area also belong on the site and in your business listings, word for word. The file only points to them.

Published files show what the format looks like in use, including where practice departs from the proposal. These five were read on the day this guide was written; each may have changed since.

Three lessons run across them. The sites that publish the largest files split them by path or by size rather than making one file ever longer. The ones written for agents state rules, such as which version to install, and do not only list pages. And none of them uses the file for marketing: the summaries describe, they do not sell.

One detail needs a decision on your own site. A tracking parameter on a link, such as the one Vercel adds, lets you count visits that came from the file, but it makes the address differ from the page’s canonical URL. Use one only on links to Markdown copies or other files that are not indexed, and keep the plain address everywhere else.

The serving checks, such as plain text with a 200 answer and robots.txt rules that let the right crawlers fetch it, are listed in the guide to what llms.txt is. These are the mistakes in the words of the file:

1. 1List the ten questions customers, prospects or developers ask most, from support tickets, sales calls and your search queries.
2. 2For each question, find the one page that answers it best. Where no page does, note it: that is work for the site, not for the file.
3. 3Write the H1 and a blockquote of one or two sentences: what the site is, for whom and where.
4. 4Add notes for the conventions every page shares, such as currency, units or the current version.
5. 5Group the links into two to five sections named for what a reader wants: product, policies, documentation, buying.
6. 6Give each link a note after a colon, in the words the page itself uses.
7. 7Parse the file. The proposal’s own site links a Python library for the format^[3]; any Markdown parser will show whether the headings and lists are where they should be.
8. 8Publish, then run the serving checks of guide 11, and put the file on the same review calendar as the pages it lists.

Keep the expectation honest. Google says Google Search does not use llms.txt, and that keeping one for other systems neither helps nor harms a site there^[8]. The file is for agents and assistants that read it; the pages it points to do the work.