How to Generate an LLMs.txt File: A Step-by-Step, Evidence-Led Workflow

You do not need an AI writing subscription to create the file. An editor can write a small one manually; a changing documentation site can generate it from approved navigation. The work is choosing accurate destinations and keeping them current. A generator cannot make an inaccessible page readable or guarantee a citation.

1. Choose the pages and the scope

Start with the questions someone should be able to answer from your site: What does the product do? How is it installed? What are its limits? Which policy applies? Select a page that actually answers each question. A homepage alone rarely supplies that detail.

Use current, canonical URLs: the preferred versions you want people to visit. Leave out internal environments, account pages, tracking variants, expired campaigns and private material. Do not publish confidential links just because you expect only an automated reader to open the file.

The llms.txt v2 proposal permits a file at the origin root or within a path. An origin-wide guide can live at /llms.txt; a documentation guide can live at /docs/llms.txt. Under the proposal, the most specific applicable file describes that part of the site.

Keep a small source record before generating anything. This is an example selection, not a scan of a real company:

2. Write a file you can copy and check

In the proposal, the H1 site or project name is the only required section. A brief summary and grouped, described links make the file more useful. The section named Optional is for secondary material that a reader can skip when less context is needed.

Copy this short example into a plain-text editor. Replace the name, summary and example.com links with approved content, then save the file as UTF-8 Markdown named llms.txt.

# Example Co

> Product documentation.

## Pages

• • Product
  • Setup

The hash, angle bracket and Markdown link brackets are literal file text. This table shows what each part needs before you publish it.

The proposal recommends clean Markdown destinations where available. Do not invent a Markdown version by adding .md to a URL. Open and check that destination first. If your site does not provide one, use its real public page while deciding whether a maintained Markdown version would help your users. If you publish both formats, compare their material facts after updates.

For discovery, the proposal recommends rel="describedby" for the applicable index and rel="alternate" with type="text/markdown" for a page's Markdown version. Your developer can add these through link elements or response headers. Advertising a URL cannot show that any particular agent followed it.

3. Choose a generation method your team can maintain

A hand-written file is reasonable for a small, stable site. For frequent releases, generate from the same approved content records that drive your navigation. Keep descriptions factual: say what a page answers, rather than adding claims it does not contain.

• Small static site: Generation method: Maintain a plain file in the site's public assets. Who checks it? Content owner checks links after relevant changes.
• Application with changing docs: Generation method: Build the index from a reviewed manifest or navigation. Who checks it? Developer checks output; editor checks descriptions.
• Hosted documentation: Generation method: Check the platform's existing generated file before adding another. Who checks it? Documentation owner checks scope, versions and access.
• CMS-driven website: Generation method: Export selected approved public entries. Who checks it? CMS owner excludes private, duplicate and retired entries.

For example, Mintlify documents automatic generation, along with a custom-file override and different behavior for authenticated sites. Check your own output and access rules before relying on defaults.

The similarly named llms-full.txt is a companion containing expanded page content in platforms such as Mintlify. It is different from the short navigation index. Do not concatenate a whole site by default: first decide whether the consuming workflow needs that much text and whether you can keep it synchronized.

If an LLM helps write the index, provide the approved URL list and page descriptions. Ask it to format that material and flag missing descriptions. Check that it has neither invented paths nor rewritten limitations into promises. You remain responsible for the output.

4. Publish the file, then test what the URL returns

Your publishing method depends on the site. A static build can copy the file from its public assets. A server can return a text response. A documentation platform may already manage the endpoint. Ask the site owner to use the existing deployment process.

After that deployment, open the exact production URL while signed out. For a public index, expect readable raw Markdown and a successful response, not a login screen, a branded error page or the site's homepage. A browser view alone does not show the response status; check the network response or ask the developer to provide it.

Here is a real endpoint check. Xtrusio's public llms.txt returned HTTP 200 as text/markdown on September 30, 2026. The capture shows the raw site heading, summary and grouped links. It verifies file delivery on that date, not use by an AI assistant.

If you use a terminal, replace the placeholder domain before running this read-only command. On Windows, curl.exe selects the executable rather than a shell alias. On macOS or Linux, use curl.

curl.exe -i https://example.com/llms.txt

This read-only command displays response headers and the body. Replace example.com with your domain. If the URL redirects, check the final destination and its content.

A response can succeed while the file is wrong

Suppose the site returns HTTP 200 for every unknown route and serves the homepage. A check that tests only the status accepts /llms.txt even though there is no usable index. The body check catches that mistake.

Use this table for the file and its listed destinations. These failure cases show why status alone is insufficient.

• 200 with raw Markdown and the expected site name: What it means: File delivery passes this check. Next action: Check every listed destination.
• 200 with homepage HTML: What it means: The route served a fallback, not the index. Next action: Correct the file route and retest.
• 404 for a guessed .md link: What it means: No accessible Markdown page at that URL. Next action: Use a verified destination or publish the missing representation.
• A sign-in page or access denial: What it means: Anonymous readers cannot obtain this resource. Next action: Exclude it from a public guide or confirm the intended authenticated workflow.
• A live page with an outdated description: What it means: Delivery works, but the index misleads. Next action: Update the description against the current page.
• A redirected or duplicate URL: What it means: The manifest needs a canonical destination check. Next action: Replace it with the verified current URL.

Check each destination's final URL, status, readable body, access and factual match. A list with 19 working links out of 20 has a 95% delivery rate. That does not make the remaining broken link acceptable. Fix or remove it, then rerun the check. A successful link check also does not show that all descriptions are accurate.

Keep the expected file and the returned response together, with the date and person responsible. That gives you something concrete to compare when a later deployment changes routing or content.

5. Separate file delivery from AI visibility

There are three different questions after deployment: Can the file be fetched? Did a relevant client request it? Did an answer cite or accurately describe your pages? Evidence for one does not answer the others.

Verified server request records can support a claim that a client requested a path. Whether an answer then cited your page is a separate check. An answer can cite a page it found through another route. Do not attribute that citation to llms.txt simply because it happened after publication.

Google Search ignores llms.txt. Its AI optimization guide, updated July 10, 2026, says the file neither helps nor hurts rankings or AI features. Other services may still read it.

To check whether answers change, save the buyer question, engine, date, full answer and cited URLs. Xtrusio can keep these records together. The saved answer below includes source URLs; it says nothing about whether an agent fetched llms.txt.

Use the saved answer to identify which page and explanation the buyer encountered. On a later check, use the same questions and settings, and note failures or other page changes. A changed answer alone cannot tell you why it changed. The CMO metrics guide explains why comparable denominators matter.

6. Give maintenance an owner

Recheck the index when a listed product, documentation version, policy or URL changes. Generate from approved records where practical, check the diff, and test the resulting public response. A file that was correct at launch can become misleading without ever returning an error.

The job is done when the file is readable, its selected destinations work, its descriptions are current and someone owns updates. Judge later visibility separately. If you need help connecting a technical change to verifiable answer evidence, ask Xtrusio about a free evaluation using your own buyer questions. Publishing llms.txt is not a promise of a recommendation.