llms.txt Setup: Copyable Example, Format, and Validation

llms.txt is a proposed Markdown file at /llms.txt that gives AI agents a curated map of a site's most useful pages. The current proposal describes it as a small, human- and machine-readable entry point that points to more detailed resources. It is not robots.txt, not a sitemap, and not a Google ranking lever. This post covers the format, a small example, and the checks that tell you whether maintaining one is worth the effort.

What Is llms.txt?

The short answer: llms.txt is an optional, plain-text Markdown file at a site's root or at a subpath such as /docs/llms.txt. The llms.txt glossary entry is the one-sentence definition; this post explains the implementation. The file states what the site or section is about, then groups links to canonical pages with short descriptions. An agent can use that map to choose which source to inspect instead of inferring the site's structure from navigation, duplicated pages, and boilerplate. The convention is an open proposal, not a mandatory web standard.

llms.txt vs. robots.txt vs. sitemap.xml

These files solve different problems. RFC 9309 documents the robots.txt protocol for crawler access. Google's sitemap documentation describes sitemaps as a way to tell search engines about pages, videos, and other files on a site. The llms.txt proposal is about giving an agent a concise explanation of which resources matter and why.

Use them together when they fit your site. A sitemap is not a substitute for a curated explanation, and llms.txt is not an access-control file. Publishing it cannot override a robots rule or a firewall that blocks the client trying to fetch your content.

What the Current llms.txt Proposal Requires

The current v2 proposal gives the file a simple structure, not a magic keyword list. A file can sit at the site root or under a path such as /docs/llms.txt; the more specific file covers the more specific path. The main sections appear in this order:

1. An optional byte-order mark, followed by an H1 naming the site or project. The H1 is the only required section.
2. An optional blockquote with a short summary and the context needed to understand the rest of the file.
3. Optional detail paragraphs or lists. This opening detail section does not use headings.
4. Zero or more H2 sections containing file lists. Each list item has a Markdown link and may add a colon followed by notes about the linked resource.
5. An H2 named Optional for secondary links that an agent can skip when it needs a shorter context.

The proposal also recommends clean Markdown versions of important pages and standard link relations such as rel="alternate" with type="text/markdown". Treat that as an optional enhancement. Start with accurate canonical pages, then add Markdown alternatives only if your publishing workflow can keep them synchronized.

A Small llms.txt Example

A small site does not need to list every URL. This representative shape gives an agent the business description, the pages that answer common service questions, and a clearly marked secondary section:

# Acme Plumbing

> Fictional plumbing business used only to illustrate this file format.

Replace the name, summary, URLs, and services with verified facts before publishing.

## Services

- [Drain cleaning](https://example.com/drain-cleaning): Service details and booking.
- [Water-heater repair](https://example.com/water-heater-repair): Repair options and preparation.

## Optional

- [About](https://example.com/about): Team and contact details.

Download the example file, rename it to llms.txt, and replace the fictional facts and example.com URLs. The example is a starting point, not a file to publish unchanged.

Replace the example URLs with pages you would trust as the source of truth. A useful description says what the reader will find on the destination; it does not repeat a slogan. For a SaaS site, sections might be Docs, Products, Guides, and API. For a local service, they might be Services, Service area, Pricing, and Contact.

Do You Need llms-full.txt?

No. The current proposal specifies llms.txt and recommends links to detailed Markdown pages; it does not require a universal llms-full.txt file. Some documentation tools, such as X's developer docs, describe a full-text companion, but that is a tooling convention rather than a required section in the proposal. Keep the short file useful on its own, and add a full-text companion only when a specific workflow consumes it and you can keep it synchronized. Answer Patch's Technical Access check looks for both files, but presence alone is not a ranking guarantee.

What llms.txt Does Not Do

llms.txt does not make a page crawlable, place it in a search index, or guarantee a citation. Google's current generative AI guidance says Google Search does not use LLMS.txt for Search or its generative AI features and that maintaining one neither helps nor hurts Google visibility. On other systems, access is still controlled separately: the OpenAI publisher FAQ points site owners to OAI-SearchBot access for ChatGPT search, while Perplexity's crawler documentation documents PerplexityBot and Perplexity-User as separate clients. llms.txt can be a useful map for agents that consume it, but it cannot override robots rules or decide what an answer engine cites.

How to Create llms.txt for Your Website

Start with the smallest file that accurately explains your site. For a small business, that may be the homepage, core service or product pages, FAQ, contact or location page, and a few policies. For documentation, it may be a getting-started guide, reference, tutorials, and troubleshooting.

1. Choose Canonical Pages

List the pages you would want a person or agent to consult first. Prefer one authoritative page per topic. Skip tag archives, duplicate landing pages, thin campaign URLs, and links that are no longer maintained. The goal is a guided path into the site, not a second sitemap.

2. Write the Summary First

Write one or two factual sentences that name the business or project, what it offers, and who it serves. Use the language a knowledgeable customer would understand. A tagline can be memorable, but it is usually too vague to explain which questions the linked pages answer.

3. Organize Links by User Task

Use H2 sections that match how people look for information: Services, Products, Docs, Guides, Pricing, or Support. Keep the most important sections first. Put low-priority material such as changelogs or legal documents under Optional when it helps an agent ignore them during a short context pass.

4. Add Descriptions That Explain the Destination

After each link, add a short note about the page's actual contents. Say which product, problem, audience, location, or policy it covers. Avoid stuffing the same keywords into every description; accuracy is more useful than repetition.

5. Publish and Test the File

Serve the file at https://yourdomain.com/llms.txt, or at the relevant subpath for a documentation section. Open the URL without a browser interface and confirm that it returns the intended plain text, the links resolve, and the file is not blocked by your own access controls. The Chrome Lighthouse audit treats the file as optional, but flags a server error when a site does provide one.

6. Ask Questions Using Only the File

The proposal recommends testing the file by giving it to an agent as a starting point and asking questions about the site. Try questions your customers actually ask: what do you sell, who is it for, where do you operate, and which page supports each answer? If the result is vague or points to the wrong page, improve the summary or descriptions before adding more links.

7. Update It When the Site Changes

Review the file after a URL migration, product launch, documentation restructure, or major service change. Remove links to deleted pages and update descriptions that no longer match their destinations. A short, accurate file is more useful than a large file that quietly drifts away from the site.

Publish the file and verify the response

For a static site, publish the file with your other public assets. In a Next.js project, put it in public/llms.txt; Next serves public files from the site root, as described in the public folder documentation. With a CMS, use its documented file-publishing feature and verify the actual URL. A page titled llms.txt that returns a full HTML document is not the same file.

curl -sS -D /tmp/llms-headers.txt https://example.com/llms.txt -o /tmp/llms-body.txt
cat /tmp/llms-headers.txt
cat /tmp/llms-body.txt

Replace example.com with your own domain. A successful publication returns HTTP 200 and the intended Markdown body. A text/plain or text/markdown response is appropriate. These are checks from your connection, not evidence that a particular AI service has fetched or used the file. Expected response shape:

HTTP/2 200
content-type: text/plain; charset=utf-8

# Your verified business name

An example from our own site

On September 13, 2026, we inspected Answer Patch’s published llms.txt. Its curated links include the methodology and sample report rather than every application URL. Those choices give an agent a route to product evidence. This is an observation about our file, not proof that a search service uses it. The owned-site audit case study explains what our public checks can and cannot establish.

Keep the HTTP result and a list of checked URLs in the audit worksheet. For broader crawler and source issues, use the business diagnosis guide.

How Answer Patch Checks llms.txt

The free homepage score is the starting point; it does not perform sitewide crawler, sitemap, llms.txt, live-fetch, or competitor checks. The one-time $19 Fix Report adds the six-pillar audit, including Technical Access checks for crawler rules, sitemap, llms.txt, and live fetch, then returns evidence-backed, prioritized copy-ready or developer-ready edits. It can tell you whether the file exists and is usable alongside the site's other access signals. The Answer Readiness pillar covers whether the page itself has direct, usable answers. It cannot promise rankings, traffic, or citations. See the AI Search Readiness audit and methodology for the boundary.