llms.txt: what it is, examples, and how to write yours

You want agents and models to find the right pages first. You also want fewer wrong quotes from your docs or pricing. llms.txt gives them a short map you control.

It is low effort for a small site. One Markdown file with a title, a short summary and a few link lists. You can draft it in under an hour, then keep it fresh when you ship.

Adoption is voluntary. As of 2026 no major AI vendor has committed to reading it. You lose little by adding it, and you control the story models see when they do read it.

llms.txt is a proposal published in September 2024 by Jeremy Howard of Answer.AI at llmstxt.org. It is a Markdown file served at /llms.txt. It gives language models and agents a curated map of a site.

• It contains an H1 with your site or project name. This is the only required element.
• Then a blockquote with a one paragraph summary.
• You may add plain paragraphs for short extra context.
• Then H2 sections. Each section holds a list of links in the form [title](url): one line description.
• A section titled Optional marks links an agent can skip when its context is short.
• /llms-full.txt is optional. It carries the full text of the pages as Markdown.

Keep to the simple structure. Plain Markdown. No HTML. Avoid long prose in llms.txt itself. Put full page text in llms-full.txt when you need it.

# YourProduct

> YourProduct helps small teams capture feedback and turn it into clear product updates. Built for SaaS with a two week release cycle.

Short context line if needed.

## Start here

[Home](/): Overview of what it does and who it is for.
[Pricing](/pricing): Plans and limits in plain language.
[Changelog](/changelog): What shipped recently.

## Docs

[Getting started](/guides/getting-started): Install and set up in five minutes.
[CLI reference](/docs/cli): Commands with examples.
[Webhooks](/docs/webhooks): Events you can listen to.

## Use cases

[For product managers](/use-cases/product-managers): Triage, prioritise, and close the loop.
[For support teams](/use-cases/support): Turn tickets into tidy issues.

## Company

[About](/about): Team and background.
[Security](/security): Data handling and compliance.

## Optional

[Blog](/blog): Opinions and longer reads.
[Careers](/careers): Open roles.

Each link has a one line description. Keep it literal, not hype. Use absolute paths if your site is single domain. Use full URLs if you need cross domain links.

Here is a fuller worked example for a small SaaS. Replace the domain and adjust sections to match your site. This covers the core pages a model should try first.

# AcmeBoard

> AcmeBoard is a lightweight issue tracker for SaaS teams. Create tasks from support tickets, prioritise with impact, and ship in two week cycles.

AcmeBoard runs in the browser and on macOS. Data is stored in the EU. Email support replies become tasks.

## Start here

[Home](https://yourproduct.com/): What it is and the main value.
[Pricing](https://yourproduct.com/pricing): Plans, limits, and billing cycle.
[Changelog](https://yourproduct.com/changelog): Latest fixes and features.

## Product docs

[Guides: getting started](https://yourproduct.com/guides/getting-started): Sign up, connect email, create first board.
[API reference](https://yourproduct.com/docs/api): Endpoints with auth, rate limits, and examples.
[Webhooks](https://yourproduct.com/docs/webhooks): Events and payloads.
[Import](https://yourproduct.com/docs/import): Bring data from Trello or Jira.

## Security and legal

[Security](https://yourproduct.com/security): Data handling, backups, SSO.
[Terms](https://yourproduct.com/terms): Service terms.
[Privacy](https://yourproduct.com/privacy): What data we process.

## Use cases

[For product managers](https://yourproduct.com/use-cases/product-managers): Plan and report.
[For support teams](https://yourproduct.com/use-cases/support): Turn tickets into tasks.

## Optional

[Blog](https://yourproduct.com/blog): Long form product writing.
[Case studies](https://yourproduct.com/case-studies): Customer stories.
[Careers](https://yourproduct.com/careers): Roles at AcmeBoard.

A good file reads like a table of contents. Clear titles, short descriptions, and sections that match your site IA. Put marketing fluff in your blog, not here.

You can draft a solid first version fast. Use your nav and docs index as your source. Keep the scope tight on v1, then expand later if you need to.

1. 1

   Create the file

   Open a plain text editor. Save a new file as llms.txt. Add it at the root of your site later, for example yourproduct.com/llms.txt.

2. 2

   Add the H1

   Write a single line with # YourProduct. This is required. Use your site or project name, not a slogan.

3. 3

   Add a one paragraph summary

   Add a blockquote line starting with >. Write one paragraph. State what the product is, who it helps, and the main proof point in one or two clauses.

4. 4

   Optional context lines

   Add one or two plain lines if needed. For runtime, platform, region, or data basics. Keep each line under a sentence.

5. 5

   Choose 4 to 8 core sections

   Common picks: Start here, Product docs, Use cases, Security and legal, Company, Optional. Use H2 headings with ##.

6. 6

   List 3 to 6 links per core section

   Format is [Title](URL): one line description. Use your most canonical URLs. Do not list every page. Link the source of truth, like /docs/api not a blog about it.

7. 7

   Add an Optional section

   List pages that help with colour but are not needed when context is short. Blog, case studies, press, event recaps.

8. 8

   Review for accuracy

   Open each link and check the title and description match the first screen and H1. Fix vague wording. Keep verbs plain: set up, import, secure, bill.

9. 9

   Publish

   Upload the file to the site root so it is served at /llms.txt with Content-Type text/plain or text/markdown. Ensure it is public and cacheable.

10. 10

    Optional: write llms-full.txt

    Only if you have time and steady docs. Add the full text of the linked pages as Markdown. Store it at /llms-full.txt.

A tidy v1 could link only Home, Pricing, Getting started, API reference, Security, and Privacy. That is enough signal for most agent tasks. Expand later with more docs and use cases.

Serve llms.txt at the root of your primary domain. For example, https://yourproduct.com/llms.txt. If you have a docs subdomain, keep its links absolute in the file. You still host one file at the main root.

• robots.txt controls what crawlers may fetch. Do not attempt to block with llms.txt.
• Your XML sitemap lists URLs for discovery and indexation. It is not a content guide.
• llms.txt complements both. It points models to the most useful pages and sections.
• Do not list staging or admin URLs. Only public, canonical pages belong here.
• If you must exclude a path from crawlers, set that in robots.txt, not in llms.txt.

# robots.txt snippet for clarity
User-agent: *
Allow: /
# Block private paths here if needed, not in llms.txt
Disallow: /admin

# You do not need to reference llms.txt in robots.txt or sitemaps
# But you can link to it from your footer for humans and agents.

You do not need a special validator. You need three checks: does it load, is the format clean Markdown, and are the links valid. Add one check to find it from your homepage.

1. 1

   Direct fetch

   Open https://yourproduct.com/llms.txt in an incognito window. You should see plain text Markdown. No redirects. 200 response.

2. 2

   Content type

   Check headers. text/plain or text/markdown is fine. Avoid text/html.

3. 3

   Link sanity

   Copy each URL into a new tab. Fix any 404s or redirects. Prefer the clean, canonical path.

4. 4

   Footer link

   Optional: add a small link to /llms.txt in your footer next to /robots.txt and /sitemap.xml. Humans and agents will find it faster.

5. 5

   Full text file

   If you created /llms-full.txt, fetch it once. Check the Markdown renders and the content matches the live pages.

You can also run a crawler on your domain and confirm the file is discoverable. It should not be blocked by robots.txt. Treat it like any other public asset in your checks.

llms-full.txt is optional. Use it when your key docs are long and you want to give models the full text in one fetch. It should mirror the links you list in llms.txt, but with full Markdown content below each heading.

# YourProduct full text

> Full text companion to /llms.txt. See that file for the curated map.

## Getting started

[Getting started](https://yourproduct.com/guides/getting-started)

# Getting started

Install the CLI by running...

## API reference

[API reference](https://yourproduct.com/docs/api)

# API reference

Authentication

Use a bearer token...

• Keep only canonical, public content.
• Match headings to the sections in llms.txt for easy cross reference.
• Do not paste secrets or draft docs.
• Regenerate when you ship large doc changes.

Treat llms.txt like your nav in code. Update it when you add or remove core pages. Review once per release cycle. It should reflect what a model should read first, as of today, not last year.

• Set an owner. Make it part of the release checklist.
• When you ship a major feature, add the doc and remove old ones.
• Keep descriptions aligned with the page H1 and first paragraph.
• Scan links for redirects quarterly. Clean them to the final URL.
• If you add llms-full.txt, rebuild it as part of your docs deploy.

You will not see direct traffic from it. Any effect will show in fewer wrong quotes in support, better answers from agents you test, and faster agent runs on your own stack. If a vendor announces support, you are ready without a scramble.

• Using slogans instead of literal descriptions.
• Listing every blog post. Keep it curated.
• Forgetting the Optional section, which helps context constrained agents.
• Putting licensing or opt out text in llms.txt. Use robots.txt for access rules.
• Letting it drift from your current IA. Treat it as living config.