llms.txt: what it is, how to write it, and whether you need it

What is llms.txt, and what does the file contain?

llms.txt is a proposed convention for publishing a curated guide to a website’s important content. It is usually described as a Markdown file at the site root, intended to make useful pages easier for language-model tools to find and interpret. The proposal and examples are available at llmstxt.org.

The idea is deliberately simple: offer a short orientation and a selected set of links, rather than copying an entire site into one document. A file might point to product documentation, a company overview, support material, or authoritative pages about a project. Each entry should help a reader understand why that page matters.

For a Web3 project, the strongest candidates are stable, public pages that explain the product, protocol, token or security practices in direct language. A link list is not a substitute for those pages. If the underlying information is unclear, outdated, or inaccessible, a directory file cannot repair it. Think of llms.txt as an editorial signpost: it describes where useful information lives, while the destination pages carry the evidence and detail.

What evidence shows whether llms.txt is useful?

The clearest evidence that a file is doing its basic job is inspectable: it is published at the intended address, contains accurate links, and gives readers a coherent route to important information. Those checks show that the file exists and is maintained; they do not show that an AI assistant has read or relied on it.

Separate three questions when evaluating llms.txt:

• Is it valid and accessible? Open the public URL and check that the response displays the intended text.
• Is it useful to a person? Ask whether an unfamiliar reader can identify the project’s key pages without guessing.
• Is there evidence of external use? Look for an attributable source or a documented observation, rather than assuming that a published file caused a change in an answer.

Keep a dated copy of each revision and record why links were added or removed. If you are monitoring AI visibility, log the prompt, platform, answer, and cited sources separately from file maintenance. That distinction makes it possible to discuss observations without assigning cause prematurely. For a broader site-level review, see technical AEO: schema, llms.txt, and crawlers and AI visibility monitoring.

How do you write an llms.txt file?

Write llms.txt for a reader who needs a reliable orientation, not as a keyword inventory. Start with the project name and a short, neutral description. Then group a small set of useful links under descriptive labels, with one-line explanations where they help a reader choose the right page.

A simple outline could look like this:

Project name

A concise description of the project and its purpose.

Overview

• About the project: https://example.com/about — product scope and intended users. - Documentation: https://example.com/docs — product and integration guidance.

Trust and policies

• Security information: https://example.com/security — published security details. - Terms: https://example.com/terms — current terms of use.

Use real, public URLs from your own site; the example addresses above are placeholders, not links to publish. Prefer pages that answer distinct questions and can be kept current. Avoid vague labels, repeated destinations, promotional superlatives, and claims that are not supported on the linked page. Before publishing, have the page owners verify both the wording and the destination. A concise file with accurate descriptions is more maintainable than a long inventory nobody has responsibility to update.

How to implement llms.txt without creating a maintenance problem

Implement llms.txt as a small content change with an assigned owner. First, agree on the audience and purpose: for example, helping people or tools locate a project’s canonical product and policy information. Next, select the destination pages and confirm that each is public, current, and the intended source of truth.

Before publication, use this checklist:

• Confirm the final filename and the root address where it will be served.
• Check every destination URL in a browser and remove redirects or dead links where a direct URL is available.
• Make descriptions match the actual content of each linked page.
• Review the file for confidential, unpublished, or superseded material.
• Assign a named owner and a practical review trigger, such as a documentation reorganization or product change.
• After publishing, open the public address and compare it with the approved version.

Keep the source file in the same editorial workflow as other site content, so updates do not depend on someone remembering an isolated technical task. For the related question of how structured data describes a page, see schema markup for AI search. If the site is being assessed as a whole, citable content for AI assistants is a useful companion topic.

LLMs.txt vs schema.org: what is the difference?

llms.txt and schema.org markup serve different editorial and technical roles. llms.txt is a curated text document that points to selected pages; schema.org provides a vocabulary for describing entities and page content in structured data. Neither should be treated as a substitute for clear, complete information on the page itself.

Use schema when a page has information that can be accurately represented in a relevant schema.org type. Use llms.txt when a concise map of selected pages would help orient readers. These choices can coexist, but adding both does not itself establish that a search engine or AI assistant will use either one. For help distinguishing technical signals from content work, review schema markup for AI search alongside this guide.

Is llms.txt needed for your website or Web3 project?

You probably do not need llms.txt as a prerequisite for publishing a useful website. Consider creating it when your site has several important public resources, those resources are hard to discover from one another, and someone can keep the file accurate. If a small site already has a clear navigation structure and a few authoritative pages, improving those pages may be a more useful first task.

For a Web3 project, ask whether a reader can quickly reach reliable information about the product, network, documentation, governance, security disclosures, and terms. Include a page only when it is public, current, and relevant to the intended orientation. Do not use the file to imply that a project has been audited, endorsed, or verified unless the linked evidence supports that statement.

A practical decision is to draft a short version, ask an informed person outside the writing process to find the key pages, and revise any labels that cause hesitation. If the test exposes weak or missing destination pages, address those first. If the file adds no meaningful navigation beyond the site menu, leave it out and revisit the decision when the site changes.

What llms.txt cannot establish, and what to do next

A published llms.txt file confirms only that your site offers a particular set of links and descriptions; it is not evidence that a platform has fetched, accepted, or used them. No one can promise that Google, an AI assistant, or another third party will read the file, cite a linked page, or change how it presents your project; those systems control their own access, selection, and presentation.

Keep the decision proportional to the value of the file. If you have stable pages worth surfacing, the work is modest: choose them, describe them accurately, publish the file, and maintain it alongside the source pages. If those pages are missing or inconsistent, fix the source material before curating a map. A practical review should leave you with an approved URL list, draft text, an owner for future updates, and a record of what was checked.

If you would like an independent review, send Premium Promotions your site URL, the pages you consider authoritative, and any concerns about sensitive or outdated information. We will check the proposed destinations and descriptions, flag gaps for your team, and return a publication-ready draft for your approval.

How it works

1. Set the purposeWrite down who the file should help and what information they should be able to find. Keep the goal specific enough to guide page selection.
2. Choose source pagesCollect public, current pages that represent the project’s authoritative information. Ask each page owner to confirm the content and URL.
3. Draft the mapAdd a brief introduction, descriptive headings, and accurate link descriptions. Remove duplicative or promotional entries.
4. Check and publishVerify every destination and the final root address. Compare the published file with the approved draft.
5. Maintain the recordAssign an owner and update the file when an important page changes, moves, or is no longer authoritative.