LLMs.txt: what it is and whether your site needs it

What is an llms.txt file?

LLMs.txt is a proposed Markdown convention for pointing language-model tools to selected pages on a website. It is a compact editorial map, not a replacement for your site or its existing technical signals.

• Location: commonly proposed at the site root as /llms.txt.
• Format: readable Markdown with a short introduction and links.
• Purpose: make a curated set of relevant resources easier to discover and interpret.

A useful file reduces navigation work for a reader by naming the pages that explain the project, product, documentation, and key policies. It does not contain a full copy of your site. Keep the source pages authoritative; use the file to point to them.

For a Web3 project, a practical selection might include protocol documentation, a product overview, security or audit information, token details, and support guidance—only where those pages exist and are maintained. Do not add a page simply because it contains a desired keyword. A clear, current source is more useful than a long directory of thin or overlapping URLs.

The proposal and its current examples are available at llmstxt.org. Treat that as a format reference, then decide whether the convention fits your own publishing workflow.

Do you need llms.txt for your website?

Most sites can treat llms.txt as an optional documentation task. Add it when a short, maintained index would help people or tools find your best source pages; postpone it when the underlying pages are incomplete or inconsistent.

Evidence should be separated from expectation. You can verify that a file is published, readable, and points to live pages. You can also monitor whether your organization appears in relevant AI answers. Those observations do not, by themselves, prove that the file caused a citation or visibility change.

For an evidence-led plan, record the pages selected, the publication date in your own change log, and the prompts or answer checks you already use. Compare observations over time without attributing every change to one file. If you need a broader assessment of AI-search readiness, see our technical AEO guide and AI visibility audit.

How to write an llms.txt file

Write llms.txt as a short, accurate index of pages that explain your site well. Start with the user’s information needs, then select links that directly answer them.

1. Choose the audience. List what a researcher, user, developer, or partner needs to understand.
2. Select source pages. Prefer stable, specific pages over broad pages that repeat the same claims.
3. Group links by purpose. Use a few descriptive headings, such as product, documentation, and security.
4. Describe each link plainly. State what the reader will find; do not promise what the page does not support.
5. Remove stale or duplicate entries. Every link should have a reason to be present.

A small illustrative structure could look like this:

Example file contents:

Project name

A short, factual description of the project.

Product

• Product overview: Features and supported use cases.

Documentation

• Developer docs: Integration and technical reference.

Replace the example domain and labels with your real pages. Use canonical URLs where available, preserve the site's actual naming, and avoid adding confidential material. The file should help readers reach public sources, not introduce new claims that cannot be checked against those sources.

Keep the draft concise enough to review manually. If the selection is difficult, that is a useful signal: the site may need clearer source pages before it needs an index.

How to implement llms.txt without creating maintenance debt

Implement llms.txt as a normal, reviewable website change: draft it, test it, publish it at the intended path, and assign someone to keep its links current.

• Confirm who owns the file and who approves factual claims.
• Check that each destination is public, relevant, and available at its listed URL.
• Verify that the published file can be opened as plain text or Markdown.
• Review it after changes to documentation, product pages, or site structure.
• Keep a copy of the approved version in the site's content or code workflow.

The implementation method depends on how your site is managed. A developer may add a static file to the web root; a content team may use a publishing workflow that exposes the same path. In either case, verify the final public URL rather than relying only on a local preview. If a redirect or hosting rule changes the path, confirm the destination still serves the intended content.

Keep llms.txt distinct from structured data. If your pages need schema markup, plan that work around the content and supported properties on those pages. Our guide to schema markup for AI search covers that separate task. For broader search foundations, see crypto SEO; the file should complement clear pages, not stand in for them.

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

LLMs.txt is a human-readable index of selected pages; schema.org markup is structured data embedded in or associated with a page. They have different formats and jobs, so one does not automatically substitute for the other.

Choose the work based on the problem you can verify. If people struggle to locate core documentation, curate navigation and consider an llms.txt file. If a page has suitable structured facts that need explicit machine-readable representation, evaluate schema markup against the page itself and the applicable vocabulary.

Do not add schema merely to imitate an llms.txt file, or add an llms.txt file as a substitute for page-level structured data. In both cases, consistency matters: the file and markup must agree with the public source content. Review the rendered page, the structured data, and the linked destination together. That gives your team a concrete quality check instead of treating either format as a shortcut to visibility.

What can llms.txt prove, and what remains unknown?

A sound llms.txt review can confirm what you published and whether its links and descriptions match your pages. It cannot establish, from publication alone, how a particular AI product will discover, process, or cite that material.

Use a compact review record:

• File check: the intended public path returns the approved content.
• Link check: every destination opens and supports its description.
• Content check: no entry conflicts with current product or policy pages.
• Observation check: AI-answer monitoring is recorded separately from file validation.

For evidence, keep a before-and-after log of the file and site changes, plus the questions used in any visibility review. If an answer changes, note other relevant site updates rather than assigning causation to llms.txt by default. This creates a useful audit trail for future decisions without presenting correlation as proof.

LLMs.txt has no documented control over a platform’s selection, indexing, or citation decisions, and publishing it does not ensure that any platform will use it. Our review step checks the public file against its destination pages and returns an annotated draft with a change list; the project team retains control of publication and source content.

Prices

Starting prices in USD. Custom bundles and volume discounts on request. Payment in USDT, USDC, BTC, ETH, SOL, TON or your project token.

How it works

1. Set the decisionName the information gap the file should address. If the source pages are unclear or missing, improve those first.
2. Select source pagesChoose current, public pages that answer real reader questions. Remove duplicates and pages with unsupported claims.
3. Draft and checkWrite a short introduction and grouped links. Check every description against the actual destination.
4. Publish at the intended pathUse the site's established content or code workflow, then open the public URL and inspect the served file.
5. Assign maintenanceSet an owner to revisit the links when key documentation or product pages change. Log file checks separately from AI visibility observations.