How to Create an llms.txt File (With Example)

To create an llms.txt file, list the 15-30 pages that best explain your product, write a one-paragraph factual summary, format everything as Markdown (an H1, a blockquote, then H2 sections of links with short notes), and publish it at `yourdomain.com/llms.txt` as plain text. The format comes from the llmstxt.org proposal. Most teams can ship a good first version in an afternoon.

Before you start: read What is llms.txt? for what it does and doesn't do. It doesn't control crawling; that's robots.txt.

On this page

• What should you expect from it?
• Step 1: Which pages should you include?
• Step 2: How do you write the summary?
• Step 3: How do you format the link sections?
• Product
• Guides
• Step 4: What goes in the Optional section?
• Optional
• A complete example
• Product
• Guides
• Optional
• Worked example: Ledgerline's first file
• Step 5: How do you publish it?
• How do you handle multiple sites and languages?
• Pre-launch checklist
• Step 6: How do you test it?
• Should you write it by hand or generate it?
• How do you keep it accurate?
• Should you also create llms-full.txt?
• How do you know if it's being used?
• Common mistakes
• Common questions
• Sources

Checked against llmstxt.org and platform documentation on 30 October 2026. "Our view" marks MentionX opinion. Acme Payroll and Ledgerline are fictional.

What should you expect from it?

From MentionX data. We checked all 9,750 citation URLs in completed MentionX runs from 22 August to 29 October 2026 (UTC), across 2,154 runs, 18 anonymised projects and six engines. None pointed to an llms.txt or llms-full.txt file, and one pointed to a .md page. Among non-Gemini citations we could classify (n = 5,917), blog, guide and resource paths made up 19.6%, homepages 10.0%, review sites 2.7%, docs and help pages 2.6% and pricing pages 1.9%.

Limits. Most Gemini citations are Google redirect links that hide the destination. Being cited isn't the same as being read: a tool could use llms.txt to find a page and then cite the page. Our prompts are buyer questions, not coding questions.

Our view: build the file to help tools reach your best HTML pages faster, and judge it by whether those pages are accurate and easy to find. Don't judge it by citations of the file itself.

Step 1: Which pages should you include?

Curation is the point. Ask: "If an assistant could read only 20 pages before answering a question about us, which would give the most accurate answer?"

Typical picks:

Leave out: legal boilerplate (unless asked about often), tag pages, thin landing pages, anything gated.

Step 2: How do you write the summary?

The proposal requires an H1 with the site or project name, and recommends a blockquote with a short summary (llmstxt.org). Write the blockquote as a plain fact sheet, not a tagline:

• What the product is (category in plain words).
• Who it's for.
• The two or three facts most often misstated about you.

Weak: > The future of brand intelligence.

Strong: > Acme Payroll is payroll and HR software for companies with 5-200 employees in Germany and Austria. It runs monthly payroll, files tax and social-security reports, and integrates with DATEV. Plans are priced per employee per month.

You can add a short free-text paragraph after the blockquote with extra context, such as naming conventions or what not to confuse you with.

Step 3: How do you format the link sections?

Each H2 holds a Markdown list. Each item is [Name](URL) and optionally : note (llmstxt.org). Make the notes useful: what question that page answers.

## Product
- [How Acme Payroll works](https://acme.example/how-it-works): monthly payroll run, approvals, filings
- [Pricing](https://acme.example/pricing): per-employee price, plan limits, as of Oct 2026
- [Integrations](https://acme.example/integrations): DATEV, Personio, Xero

## Guides
- [Running your first payroll](https://acme.example/guides/first-payroll): step by step, 20 minutes
- [Minijob rules explained](https://acme.example/guides/minijob): thresholds and filing

Step 4: What goes in the Optional section?

An H2 titled exactly "Optional" marks links that can be skipped when context is limited (llmstxt.org). Put secondary material there:

## Optional
- [Changelog](https://acme.example/changelog)
- [Customer stories](https://acme.example/customers)

A complete example

# Acme Payroll

> Acme Payroll is payroll and HR software for companies with 5-200 employees in Germany and Austria. It runs monthly payroll, files tax and social-security reports, and integrates with DATEV. Plans are priced per employee per month.

Acme Payroll is not affiliated with Acme Corp (manufacturing).

## Product
- [How it works](https://acme.example/how-it-works): payroll run, approvals, filings
- [Pricing](https://acme.example/pricing): per-employee pricing and plan limits
- [Security](https://acme.example/security): hosting region, certifications

## Guides
- [First payroll](https://acme.example/guides/first-payroll): setup checklist
- [Acme vs DATEV Lohn](https://acme.example/compare/datev): honest comparison

## Optional
- [Changelog](https://acme.example/changelog)

Acme Payroll is a fictional example.

Worked example: Ledgerline's first file

Ledgerline is a fictional accounts-payable tool for mid-sized companies in the UK and Germany. Its content lead builds the first file in four steps.

1. Pull the question list. Sales and support export their most common questions from the last quarter. The top five are about pricing, NetSuite and Xero integrations, approval workflows, VAT handling and security.
2. Map one page to each question. Two questions have no good page: VAT handling is spread across three blog posts, and the security answer is a PDF behind a form. The team writes a VAT page and publishes an ungated security summary before finishing the file.
3. Write the summary. "Ledgerline is accounts-payable software for companies with 50-1,000 employees in the UK and Germany. It captures invoices, routes approvals and syncs with NetSuite, Xero and SAP Business One. Plans are priced per invoice volume."
4. Pick 22 links across Product, Integrations, Guides and Compare, with five in Optional.

The fix in step 2 matters more than the file. In MentionX data, docs, help and pricing pages together made up under 5% of classified citations, so the pages that answer specific buyer questions need to be clear and public before any file points at them.

Step 5: How do you publish it?

The file must load at the root as plain text.

Optional extra from the proposal: offer Markdown versions of key pages by appending .md to their URLs (llmstxt.org).

How do you handle multiple sites and languages?

Many companies have a marketing site, a docs subdomain and a help centre, sometimes in several languages. The proposal describes one file per site, at its root, so each host gets its own file.

• Marketing site (`www`): product, pricing, integrations, comparisons and best guides. Add one link in the Optional section to the docs site's own llms.txt.
• Docs (`docs.`): getting started, core concepts, API reference and SDKs. This is where generated files and llms-full.txt make most sense.
• Help centre (`help.`): the 20 or so articles behind most support tickets, grouped by task.
• Languages: if pages are translated, add H2 sections per language, such as "Deutsch", or publish a file under each language's root path and link to it from the main file. Keep summaries in the language of the pages they describe.

Use the same product name and one-sentence description in every file. A model that reads two of them should come away with one consistent picture.

Pre-launch checklist

• The file loads at /llms.txt with a 200 status and a text content type
• The H1 matches your product name exactly
• The summary states category, audience, regions and pricing model
• Every link resolves, and none sits behind a login
• Every note says what the page answers
• The Optional section holds secondary links
• robots.txt allows the agents you want to read the linked pages
• An owner and a review date are recorded

Step 6: How do you test it?

1. curl -I https://yourdomain.com/llms.txt should return 200 and a text content type.
2. Open it in a browser; check the Markdown renders sensibly as plain text.
3. Run a link checker over every URL in the file.
4. Paste the file into ChatGPT or Claude and ask: "Based only on this, what does the company do and what does it cost?" If the answer is wrong, fix the summary.
5. After a few weeks, search server logs for /llms.txt requests and record the user agents.

Should you write it by hand or generate it?

Both work. The right choice depends on how often your key pages change.

A hybrid is common: generate the link list automatically, and keep the H1, summary and section order in a small hand-edited template that the build fills in.

How do you keep it accurate?

• Generate, don't hand-edit, if your CMS allows it.
• Tie updates to pricing and positioning changes. Add "update llms.txt" to the launch checklist.
• Review quarterly. Remove dead links and pages that no longer matter.

Should you also create llms-full.txt?

Some sites publish a second file, often called llms-full.txt, that contains the full text of their docs in one Markdown file. It's a common convention among documentation tools rather than part of the core proposal. It can help coding assistants that want everything at once, but it gets large quickly and goes stale fast. Start with a curated llms.txt; add a full version only if your docs platform generates it automatically.

How do you know if it's being used?

There's no dashboard for llms.txt. You have three sources of evidence:

Record a baseline for the month before you publish. Then compare the month after, and note any other changes you made, such as new pages or crawler rules, so you don't credit the file for their effect.

Our view: if three months of logs show no requests, keep the file (it costs almost nothing) but stop spending time on it.

Common mistakes

• Serving the file as HTML (a 404 page styled to look right).
• Including hundreds of links with no notes.
• Promotional summaries that a model will repeat as unsupported claims.
• Expecting it to change Google AI Overviews; Google says AI text files aren't needed (Google Search Central).
• Adding crawl rules to it. Crawl rules belong in robots.txt.

Common questions

Do I need Markdown versions of every page? No. They're optional in the proposal. Start with the pages listed in the file, or link to the HTML pages if you can't produce clean Markdown.

Can I list pages from other domains? You can, for example your docs subdomain or a status page. Keep third-party links rare; the file should describe your own content.

Will it show up in Google results? It can, as a plain text file. If you don't want that, send an X-Robots-Tag: noindex header for it (Google). Don't block it in robots.txt, or compliant tools can't read it.

Should the summary mention competitors? Only to prevent confusion, such as a similarly named company. Comparisons belong on comparison pages.

Sources

• llmstxt.org, the llms.txt proposal
• Google Search Central, AI features and your website
• Mintlify, llms.txt; Yoast, llms.txt feature; WordPress.org, Website LLMs.txt plugin; Firecrawl, create-llmstxt-py
• Google Search Central, Block indexing with noindex