Choose and Test an llms.txt Generator

An llms.txt file gives a documentation site a compact, readable map. It can point a client toward the quickstart, authentication reference, and version policy without asking it to infer the site's structure from navigation markup.

The file is useful only if its links and descriptions match the published docs. A generator should make that relationship easy to inspect and keep current.

Understand the file's role

The llms.txt proposal describes a Markdown file that provides context and links for language models. It is a proposal for presenting information, so support depends on the client using it. Publishing the file does not guarantee crawling, search rankings, citations, or correct answers.

Keep that distinction in your evaluation. You can test whether a URL returns useful content and whether a particular client follows it. Those observations do not establish what every assistant will do.

An overview file and a full-content export serve different reading tasks. The overview helps a reader select pages. A full corpus makes the content available in one larger response. Inspect both if the platform publishes both, and check how a client handles response size limits.

Generate from the published source

The safest input is the same content that produces the public documentation. A separate manually maintained list will drift when routes move or guides are retired.

For example, a small project could publish this overview:

# Acme API

> Documentation for Acme API v2.

## Start here
- [Quickstart](https://docs.example.com/quickstart): Send a first request.
- [Authentication](https://docs.example.com/authentication): Create and rotate API keys.

## Reference
- [Events](https://docs.example.com/api/events): Create and retrieve events.
- [Versions](https://docs.example.com/versions): Supported versions and migration guides.

The example uses placeholder addresses. Replace them with live canonical URLs and test each one before publishing. If the site offers Markdown representations, verify that those addresses contain the complete article and useful code samples.

Choose links that help a client find the right page

Begin with the tasks customers ask about. A quickstart, authentication guide, and version policy usually provide more orientation than a list of every heading on the site.

Write descriptions that distinguish neighboring pages. “Create and rotate API keys” explains the authentication guide's scope. Repeating “API documentation” beside each link adds little information.

Keep version boundaries visible. A retired endpoint should not look like the current recommendation. Link a migration guide when readers need to move from an old version, and identify the supported version in the overview.

Private pages require a separate access policy. A public llms.txt file can reveal titles and URLs even when the linked body requires authentication. Review the generated list for internal names, private routes, and accidental source material before deploying it.

Test the generator as part of the build

Fetch the deployed file after a build. Check its status, content type, links, and actual body rather than relying on a local source file. A host rewrite can accidentally return the site's HTML shell for an unknown path.

Make a temporary preview change that renames or removes a page. Rebuild and confirm that the old link disappears from the generated output. Add a new page and confirm that its title and description appear correctly. This tests whether generation is connected to publication.

When the generator extracts text from rendered HTML, inspect code samples, tables, and callouts. Shared navigation and footer text should not overwhelm the page's instructions. When it reads source files directly, check how it handles components and conditional content.

Check the client you intend to support

Ask the client to retrieve a specific guide and inspect the visible result where possible. Compare the returned steps with the published page. If the client uses MCP, check the server's discovery and page-reading behavior separately from llms.txt.

Thally's agent-ready documentation guide explains the different access paths. On this website, llms.txt, llms-full.txt, and the public MCP catalog expose related published material. Availability through these paths does not promise that an assistant will choose or cite a page.

Keep the source instructions accurate. If the authentication guide still uses a retired header, making it easier to retrieve will expose the same mistake more widely. Review content changes alongside code releases and rerun the access checks when routes or generation logic change.

Use a small acceptance checklist

A generator is ready to adopt when its output is readable, its public links resolve, its version context is clear, and a content change reaches the deployed file through the normal build. Add a check for private material and test the client workflow you expect readers to use.

Save those checks with the site rather than treating the first generated file as a finished integration. The next renamed page is when the automation needs to prove itself.