llms.txt: A source map you can inspect, not a visibility signal

What can a reader inspect in an llms.txt file?

The published file, its headings, and its links are directly inspectable. That makes llms.txt a curated directory of selected pages, not evidence that any outside service has used those pages.

The proposal describes a plain-text or Markdown file at a website’s root. It can group links under readable headings and add brief descriptions. A link points toward information; it does not transfer the page’s meaning or prove its claims. See the proposal at llmstxt.org and treat its format as a convention, not a universal requirement.

For a Web3 project, a useful source set might include product documentation, token information, security disclosures, governance details, and official contact pages. Include a page only when it is public, current, and clear without private context. Check these 3 properties for each candidate:

• Subject: the page explains one identifiable topic.
• Support: its content substantiates the description you plan to write.
• Status: it is the canonical, accessible version.

This distinction matters when people search for llms.txt SEO. A readable file can help a visitor navigate your selected sources. Its presence alone does not establish a search or citation effect.

When does llms.txt solve a real site problem?

A page inventory reveals whether llms.txt addresses a real discovery problem. If your key information is already easy to locate and consistent, the file may be useful housekeeping rather than the next priority.

Consider drafting one when public documentation spans many pages, product information has multiple versions, or important facts sit across separate sections. A maintained list can give editors one place to review which sources represent the site. It also makes URL ownership visible during site changes.

Use this 4-point readiness check before drafting:

• The important pages are public and do not require an account.
• Each page has a clear subject and a responsible editor.
• Related pages agree on core facts and official links.
• Someone can review the list after relevant site changes.

If a condition fails, address the source pages first. Missing explanations, conflicting product details, and inaccessible documents are not fixed by listing their URLs. For a wider technical overview, see technical AEO: schema, llms.txt, and crawlers. The decision is simple: curate sources that are ready to represent the site; repair sources that are not.

Which llms.txt claims can you actually verify?

A fetched file and a set of working links are evidence of publication quality. They do not show that an external platform fetched, interpreted, or cited the file.

Keep these observations in separate records. For the file itself, record its published URL, review date, and link-check outcome. For any separate visibility check, record the exact question, tool, observation date, and sources shown in the answer. Do not combine a successful file check with an unobserved claim about AI use.

A practical 4-field record can include:

• File URL: the public location you checked.
• Version: the reviewed content or saved copy.
• Link status: whether each listed destination opened publicly.
• Editorial owner: who reviews the file after changes.

If you are checking whether an organization appears in answers, repeat the same prompt and note what the tool displays. Those observations describe that test, not a guaranteed effect of llms.txt. For work on source clarity, see citable content for AI assistants. This gives you a separate basis for improving pages that readers can inspect and verify.

How should you arrange the llms.txt file?

A short source list with accurate labels is easier to review than a second copy of the website. Draft around the reader’s information needs, then remove links that do not add a clear source.

Start with the organization name and a concise description. Group pages under headings that identify their purpose. Add a short note when a title does not explain the destination. Prefer canonical pages over duplicate, temporary, or campaign URLs. Keep descriptions factual and aligned with the linked content.

For a crypto project, possible headings include product documentation, token details, security information, governance, and official channels. These are examples, not required categories. Do not imply that a review, approval, or disclosure exists unless the linked page supports that statement. Avoid vague labels such as “important”; name the subject instead.

Use this 3-pass editorial check:

• Scope: does each link belong in this directory?
• Accuracy: does its note match the page as published?
• Clarity: can a new reader understand the destination?

A line-by-line editorial review can catch mismatches before publication. For broader file and crawler considerations, see llms.txt and AI crawler setup.

What does implementation require on your domain?

The root URL, the reviewed content, and working destinations are the key implementation checks. The work is editorial and operational: choose sources, publish the file, then validate what visitors can open.

Follow this 5-step sequence:

1. Inventory public pages and select one canonical URL for each subject.
2. Confirm that every destination is accessible and matches its proposed description.
3. Draft a readable plain-text or Markdown file with consistent headings.
4. Publish it at the root of the domain it represents.
5. Open the live file without signing in, then follow every listed link.

For an organization with multiple domains, identify which site the file describes. Do not list private dashboards or internal documents as public sources. If a URL changes, update the file and check whether other site pages still point to its former location.

At GeoMarketing Experts, a line-by-line editorial review compares each proposed URL with its description before publication. Save the reviewed version and name an owner for later edits. For adjacent markup work, see schema markup for AI search.

How do llms.txt and schema.org differ in practice?

The file organizes selected links; schema.org provides vocabulary for structured information in page markup. The llms.txt vs schema.org choice depends on the task you need to address, not on one format replacing the other.

Use llms.txt when you have a defined set of public sources to curate and maintain. Consider structured data when page information fits a relevant schema type and the markup can stay aligned with what visitors see. Either option still relies on accurate source content. A file cannot repair an unclear product page, and markup cannot make an unsupported claim reliable.

For a broader comparison, review schema markup for AI search. Validate any markup against the visible page. Add only types that describe information the page actually contains. A team may use both formats, but each needs a defined purpose and an editor responsible for keeping it accurate.

Which changes should trigger an llms.txt review?

A changed URL or superseded source can make an otherwise accurate file misleading. Review the list when product documentation moves, a policy changes, or an older page stops representing current information.

Assign one owner to check the file when relevant pages change. That owner can confirm the destination, compare the description with the live page, and remove references that no longer belong. Keep a copy of the reviewed file so later edits can be compared against a known version.

You can verify the file’s location, contents, and linked pages. Those checks cannot establish from publication records whether an external platform fetched or cited the file. Treat any platform answer as a separate observation, not as proof that publication caused it.

Start with a short source inventory. Mark each page as current, unclear, or outdated, then select the canonical public URLs. Send GeoMarketing Experts your domain and that inventory. We can review the proposed sources, flag unclear descriptions or conflicting destinations, and return a file structure for your team to publish and maintain.

How it works

1. List public sourcesIdentify pages for product information, documentation, policies, and important claims. Mark one canonical URL for each subject.
2. Check the destinationsConfirm that each page is public, current, and understandable without private context.
3. Draft the directoryGroup the selected links under descriptive headings. Write notes that match each destination.
4. Review and publishCompare each description with its page, then publish the file at the intended domain’s root.
5. Validate and assign ownershipOpen the published file, follow its links, and name an editor for future updates.