LLMs.txt: What It Is, How to Write It, and Whether You Need It

What does llms.txt do for AI search?

LLMs.txt is a proposed file that gives a compact, human-readable map of important website content. It can help a person or a tool locate selected sources without first navigating every page on the site. Its value is clarity: it makes your preferred references easier to discover and interpret.

The proposal is not a replacement for your pages. A file can point to technical documentation, product explanations, policies, or other sources, but those pages still need to contain the facts themselves. For a Web3 project, a useful selection might include the protocol overview, supported networks, token information, security documentation, and official announcements—provided those pages are current and genuinely useful.

For AI-search work, start with what you want a reader to understand about the brand, then identify the pages that substantiate it. In an AI Presence Scan, we review the public site and the questions people are likely to ask. An Answer Map connects those questions to the strongest existing sources and flags missing or conflicting information. That review is more valuable than publishing a file full of every URL on the domain.

The llms.txt proposal describes the convention and its intended use. Read it as a proposal to assess, not as evidence that every search engine or AI assistant consumes the file in the same way.

Is llms.txt needed for your website?

You need llms.txt only when a curated guide solves a real discovery or maintenance problem. It is most useful when a site has valuable material spread across documentation, product pages, policies, and resources, or when the site has a clear set of preferred sources that are otherwise difficult to find.

It is usually a low priority if the site is small, its navigation already makes key information obvious, or its important pages are incomplete. Fix the underlying content and internal navigation first. A file that points to thin, outdated, or contradictory pages only makes those weaknesses easier to encounter.

Use this decision check before drafting:

• Can you name the questions your audience needs answered?
• Do current pages answer those questions clearly and consistently?
• Can you select a small, maintained set of sources rather than listing the whole site?
• Is someone responsible for updating the file when those sources change?

If the answers are yes, a concise file is worth testing as a navigation aid. If not, improve the source pages and revisit the file later. For broader technical work, the technical AEO guide covers how llms.txt fits beside crawlers and structured data. The decision should follow the needs of your site, not the idea that adding a new file automatically improves AI visibility.

How should you write an llms.txt file?

Write llms.txt as an editorial map: explain what the site is, then link to a selective set of pages with descriptions that tell readers why each page matters. Keep the claims in the file consistent with the pages it points to. A concise, accurate list is more useful than a long catalogue with vague labels.

A practical outline can include:

• A heading naming the site or project.
• A short summary of its purpose and the audience it serves.
• A few clearly labelled groups of important resources.
• Descriptive Markdown links to the live pages, each with a brief explanation.
• Optional notes about which pages are canonical or most suitable for a particular topic.

For example, a protocol might group its overview, documentation, security material, and governance information separately. Do not include a page just because it contains a desirable phrase. Include it because the page is reliable, current, and helpful as a source. Avoid promotional claims that the linked content does not substantiate.

Under the Source Plan, we prioritize pages by topic and source quality, then draft descriptions in plain language. The project team should confirm technical terminology, product details, and ownership-sensitive facts before publication. If an important answer does not exist yet, record it as a content gap rather than pretending the file can fill it. This makes llms.txt a useful index of evidence instead of a second, potentially inconsistent version of the website.

How to implement llms.txt and verify the result

Implementation means publishing the file where visitors can reach it and checking that the delivered text matches the approved version. The conventional location is the site root as /llms.txt; the exact change process depends on how the site is hosted and managed.

Before release, confirm that every listed link opens the intended public page, descriptions match the destination, and no private or temporary material is exposed. Check the response in a browser or with your normal site verification tools. Then review the rendered content for encoding issues, broken Markdown, accidental redirects, and stale URLs. Keep a copy of the approved file with the project’s content records so later edits have a clear reference.

A sound rollout also has an owner. When a documentation section moves or a product page changes, that person should review whether the file still points to the best source. Add the check to the same editorial routine used for important navigation and documentation updates.

AIPromote can handle the editorial review, prepare the file, coordinate publication with your site owner, and return an Engine Report recording what was checked. This is a defined deliverable, not a claim that an AI service has adopted the file. For the wider relationship between structured data and AI search, see schema markup for AI search.

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

A published llms.txt file proves that your site offers a curated guide at a public location; it does not prove that an AI answer used the file. Keep evidence of what you can verify: the approved file, its public availability, the destination pages, and the review date. To assess AI presence, compare real buyer questions with the answers and sources visible in the tools your team cares about, then record what appeared and when.

Use a stable set of prompts that reflect actual decisions, such as what a protocol does, which networks it supports, and where its security information lives. Save the exact question, the visible answer, and any cited sources. This gives the team a repeatable observation rather than a vague impression. The AI search visibility hub and AI monitoring guide provide context for that broader measurement work.

LLMs.txt remains a proposal, and publication does not give a site control over whether a particular crawler or assistant reads it, how a service selects sources, or whether a page appears in an answer. Do not report the file itself as proof of rankings, citations, or a change in AI visibility; report the implementation checks separately from observed platform behavior.

LLMs.txt vs schema.org: how are they different?

LLMs.txt and schema.org markup have different jobs. LLMs.txt is a curated text file that points to selected pages; structured data adds machine-readable descriptions to a page using defined types and properties. One is a site-level guide, while the other is attached to content and describes entities or page details.

Neither makes the other redundant. A well-organized file can help someone locate your canonical material, while accurate structured data can describe what a page contains in a format supported by the site’s implementation. The right order is practical: make the page accurate, use structured data only where it fits the visible content, and then decide whether a curated file adds useful navigation.

For LLMs.txt vs schema.org, check these basics before adding either:

• Is the page’s visible information complete and internally consistent?
• Does any structured data describe content that a visitor can actually see?
• Does each llms.txt link point to a maintained, authoritative page?
• Is there a clear owner for future changes?

The schema markup guide explains the structured-data side in more detail. If you want help evaluating the whole setup, share your domain, target audience, key questions, and preferred source pages with AIPromote. We will review the evidence, identify what should be fixed first, and return a scoped recommendation for the file and its implementation.

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. Share the site and intended audienceSend your domain, the audience you serve, and the questions you want your important pages to answer. Include any product or documentation areas that must be represented accurately.
2. Review existing evidenceWe inspect the public pages and note where information is clear, duplicated, outdated, or missing. This keeps the file grounded in sources the project can stand behind.
3. Select the pages and draft the mapWe organize the strongest sources by topic and write concise descriptions for their links. Your team checks factual and technical details before the draft is approved.
4. Publish and verifyThe file is published at the site root with your site owner’s access. We check the public version, its links, and the consistency between descriptions and destinations.
5. Record the review and ownershipYou receive the checked deliverable and a clear note on who should revisit it when important pages change. Any wider AI-search measurement is treated as separate evidence.