How to Create an llms.txt File, With Examples

An llms.txt file is a short markdown map of your site, published at a fixed location so an agent can read it instead of working your content out from your HTML. Writing one takes about half an hour. Deciding whether it earns that half hour, and curating it so an agent gets something out of it, is the part worth doing carefully.

This is the how-to. If you want the definition and the element order, the llms.txt generator sets both out and builds a valid file from your domain in about a minute. What follows is the set of decisions the generator cannot make for you: whether to publish one at all, which pages belong in it, how to make it discoverable, and how to confirm that what you shipped is what is being served.

The proposal was revised to v2 in August 2026 and this guide is written against that version. The spec is short and worth reading once.

Key Takeaways

• llms.txt is a proposal, not a ratified standard, so no assistant or search engine is obliged to read one.
• Google's own guidance says you do not need new machine readable files or AI text files to appear in its AI features, and that page does not mention llms.txt at all.
• No assistant vendor has published a commitment to read a third-party llms.txt when it answers. Publishing one for your own docs, which OpenAI, Anthropic and Google all do, is a different thing.
• The documented use is agents navigating documentation, which makes this a far stronger bet for a docs site than for a marketing site.
• The notes after each link are the part that does the work. A file of bare URLs gives an agent nothing your sitemap did not already give it.

Decide Whether You Need One

Start here, because for a lot of sites the honest answer is that this is half an hour better spent elsewhere, and most writing on llms.txt will not tell you that.

What can be checked. The AI labs publish an llms.txt for their own developer documentation: OpenAI, Anthropic and Google all serve one. Documentation platforms now generate the file automatically, and the spec author's account of v2 says coding agents use these files reliably. Chrome ships an llms.txt audit in Lighthouse under its agentic browsing checks, though read what that audit does before reading anything into it: it flags a server error on the file, and marks itself Not Applicable when the file simply returns a 404, because Google calls providing one "optional at the moment" and the file itself "an emerging convention". A missing llms.txt is not scored against you.

What cannot. No assistant vendor publishes a commitment to read a third-party llms.txt when it composes an answer. Perplexity's crawler documentation describes what PerplexityBot and Perplexity-User do and says nothing about consuming llms.txt from the sites they visit; Anthropic has published no such statement either. Claims that a named assistant reads your file are repeated far past anything a vendor has actually said, so treat every one of them as unconfirmed. The circulating adoption rates and citation-uplift percentages have the same problem: they come from third-party samples rather than from any platform, so we do not repeat them.

Google Search is a clear no. Its guidance on AI features says: "You don't need to create new machine readable files, AI text files, or markup to appear in these features." The page never names llms.txt, which is itself the answer. Publishing one will not change how Google Search or its AI features treat you, in either direction.

So the decision comes down to what kind of site you have:

• You publish developer documentation or an API reference. Publish one. This is the case the format was designed for and the one with observable use.
• You have a large site with deep or awkward navigation. Worth doing. A curated file is a cheap way to make your best pages reachable in one hop.
• You are a small marketing site with a clean structure and a working sitemap. Optional, and low priority. Nothing is struggling to find your twenty pages.

None of this is a reason not to publish. The file is small, it carries no risk, and it costs half an hour. It is a reason not to expect it to move your citations on its own, and not to put it ahead of work that will.

Choose What Goes In It

This is the only real judgment call in the exercise, and it decides whether the file is worth anything.

The file is meant to stay small enough to sit in an agent's context in full, with the detail behind the links. That constraint is the entire design. A file that mirrors your sitemap recreates the problem it exists to solve.

• Pick the pages you want quoted, not the pages you want traffic to. Documentation, pricing, comparison pages, your core explainers. Ten to thirty links is a normal size.
• Write a real note after every link. The format allows [name](url): notes, and the note is what an agent reads to decide whether the page is worth fetching. "Pricing page" is not a note. "Per-seat and usage pricing, plan limits, and what counts as an active user" is.
• Group by what someone would be looking for, not by your navigation menu. ## Docs, ## Product, ## Comparisons, ## Policies.
• Point at the markdown version where you have one. The proposal expects the links to lead to content an agent can read cleanly, and a markdown page beats the same page wrapped in navigation and scripts.
• Leave out anything that changes weekly unless the file is generated. A dead link is worse than a missing one here, because this is the one file an agent reads end to end.

An H2 section headed Optional marks links an agent can skip when it needs a shorter context. Treat it as a hint and nothing more: v2 removed the context-expansion tooling that used to act on that heading, and the mechanical meaning went with it. Use it for the changelog and the press page, not as somewhere to put the links you could not justify.

Know The Format

The spec is strict about order and loose about almost everything else. A valid file holds these parts, top to bottom:

1. An H1 with the name of the site or project. This is the only required part. A file that is just # Acme Analytics is valid, though it tells an agent nothing.
2. A blockquote with a short summary. One or two sentences on what the site is, written for something that has never heard of you.
3. Any other markdown, except headings. Paragraphs or lists with context an agent should have before it follows a link: who the product is for, which pages are authoritative, what is deliberately left out.
4. H2 sections holding lists of links. Each item is - [name](url), optionally followed by a colon and a note: - [name](url): notes.

A few rules trip people up. The file is named llms.txt, plural and lowercase: llm.txt and LLMS.txt are different paths, and an agent looking for the convention will not try them. It is plain markdown in a .txt file, so save it as UTF-8 text rather than exporting it from a word processor. And nothing goes between the H1 and the H2 sections that uses a heading of its own; an H3 in the middle breaks the structure a parser expects.

Write The File

Here is a complete file for a fictional analytics product, short enough to read in one go and in the order the spec fixes:

# Acme Analytics

> Product analytics for teams that ship weekly. Self-serve from $49 a month, free up to 100k events.

The docs below are the authoritative source for API behaviour and pricing. Marketing pages are left out on purpose.

## Docs

- [Quickstart](https://acme.example/docs/quickstart.md): Install the SDK and send a first event, in about five minutes
- [Event API reference](https://acme.example/docs/api/events.md): Endpoints, payload shape, rate limits and error codes for event ingestion
- [Data retention](https://acme.example/docs/retention.md): How long raw events are kept on each plan, and how deletion requests are handled

## Product

- [Pricing](https://acme.example/pricing.md): Per-seat and event-volume pricing, plan limits, and what counts as a billable event

## Optional

- [Changelog](https://acme.example/changelog.md): Release notes, updated weekly

Two things there are worth copying. Every note says something the URL and the link text do not, and every link points at a .md version of the page rather than the HTML.

If you would rather not hand-write it, the llms.txt generator builds one from your sitemap and lets you edit the shortlist before you publish. Editing what it gives you is the half that matters.

Publish It Where Agents Can Find It

Put it at the root, so it resolves at yourdomain.com/llms.txt, and serve it as a static file. If your host makes you choose a content type, text/plain; charset=utf-8 is the safe answer and text/markdown is also fine.

How you get it there depends on the platform:

• WordPress. Yoast SEO generates the file for you, under Yoast SEO, Settings, Site features, AI tools (not available on multisite). Rank Math has an llms.txt module you switch on from its dashboard, and its file stays empty until you pick the post types and pages it should list. Without a plugin, upload a hand-written file to the web root over SFTP. Run one of these, not two: a plugin and a manual file competing for the same path leaves you guessing which one is served.
• Webflow. Upload the file under Site settings, SEO, LLMs.txt. Webflow wants UTF-8 and under 100 KB, and the file is served only on your published custom domain, not on the staging domain, so check it after you publish.
• Shopify. Yoast SEO for Shopify generates one from your products, collections and policies, and several apps do the same. Some stores have reportedly started serving a default file without the merchant adding one, so fetch yourstore.com/llms.txt before you install anything.
• Next.js and other frameworks. Put a static file in public/llms.txt and it is served at the root. If the file should follow your content, generate it from a route handler instead, which is how ours is built.
• Anything else. Any host that serves a static file at a fixed path will do. Failing that, a CDN or reverse proxy rule pointing /llms.txt at a file you host elsewhere works.

Use a subpath if you only control one. Since v2 a file covers the pages under its path, so /docs/llms.txt covers everything in /docs/, and where more than one file applies an agent should use the most specific.

Then make it discoverable, which is the step almost every published file still skips. v2 recommends two standard link relations: rel="describedby" points at the llms.txt covering a page, and rel="alternate" type="text/markdown" points at that page's markdown version. In your HTML template:

<link rel="describedby" href="/llms.txt">
<link rel="alternate" type="text/markdown" href="/docs/page.md">

Or as an HTTP response header, which also works for files that are not HTML and can be set in your CDN without touching a single page:

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

Serve markdown versions of the pages you link to. This is the other half of the proposal and the reason the link relations exist. Put a clean markdown copy at the same URL as the page, either with .md appended (page.html.md) or with the extension replaced (page.md); v2 accepts both, where v1 allowed only the first. URLs without a filename use index.html.md or index.md.

Verify It Is Actually Working

Do not trust the upload. Four checks, none of which takes a minute:

1. Fetch it and look at the status and the content type. curl -sI https://yourdomain.com/llms.txt should return a 200 and a text content type. A 200 that is really your HTML 404 page is the commonest failure, and it looks completely fine in a browser.
2. Check robots.txt is not blocking the path. A disallow rule makes the file unreachable to any crawler that respects robots.txt, which defeats the point of publishing it.
3. Follow every link in it. A file full of redirects and 404s is worse than no file at all.
4. Run Lighthouse. The llms.txt audit under agentic browsing will flag a server error on the file. Remember that it reports Not Applicable rather than a failure when the file is absent, so a pass there is a narrow result and not an endorsement.

Keep It Current

The file is a claim about what is worth reading on your site, so it goes stale the way any curated list does. Two rules keep it honest: review it whenever your information architecture changes, and pull a link the moment the page behind it is retired or redirected. If you ship documentation continuously, generate the file from the same source as the docs instead of maintaining it by hand.

FAQ

What about llms-full.txt? It is not in the spec. Neither v1 nor v2 defines it. It is a convention some documentation platforms emit alongside llms.txt, holding the full text of the linked pages in a single file. It is harmless if your tooling produces it for you, but nothing requires it and it is not part of the proposal.

Can I have more than one? Yes, since v2. One per path, and an agent should use the most specific file that applies. A root file plus a /docs/llms.txt is a normal setup for a site with substantial documentation.

Does publishing one mean more of my content gets scraped? It grants access to nothing. llms.txt is description, not permission, and every page it lists was already reachable. If you need AI crawlers kept out of a section, that stays a robots.txt and server-level job.

Is it llm.txt or llms.txt? llms.txt, plural, at /llms.txt. llm.txt is a common typo and not part of the proposal, so a file published under that name is one nothing looks for.

Does it replace robots.txt or my sitemap? No. robots.txt says what a crawler may fetch, the sitemap lists every page you want indexed, and llms.txt is a curated reading list for an agent. They answer different questions and you keep all three.

Should I reference it in robots.txt? There is no robots.txt directive for llms.txt, so a line pointing at it is read by nothing. The discovery mechanism v2 defines is the describedby link relation covered above.

How long can the file be? The spec sets no limit. The practical one is that the whole file should fit in an agent's context alongside the question it is answering, which in practice means a few kilobytes and tens of links, not hundreds. Webflow caps uploads at 100 KB, which is far more than a curated file needs.

Do I need a tool to create one? No. It is a text file you can write by hand in half an hour. A generator saves you the typing and the formatting, and the curation is still yours either way.

Do I need to update it every time I publish a page? No, and you should not want to. The file is a shortlist. If a new page belongs on the shortlist, add it. Most will not.

Is it worth doing when nothing confirms it is read? For a documentation site, yes: the use there is observable and the cost is small. For a marketing site, treat it as hygiene you get to once the work that actually earns citations is done.

Where To Go Next

Build the file with the llms.txt generator, publish it at your root, and add the describedby link relation while you are already in the template.

Then put the rest of the time into the work that decides whether you get cited at all. Confirm the crawlers doing the citing can reach you with the free AI SEO audit, read the AI crawlers reference if any of them turn out to be blocked, and use the complete AI SEO guide for everything after that.