What llms.txt can—and cannot—establish

A navigation artifact, not a verdict

The llms.txt proposal describes a concise machine-friendly guide to a website and links to useful resources. Its value should be tested against a concrete task, such as finding the methodology or the current interface contract. Publishing the file is not evidence that an agent read it or that any search system improved the site’s placement.

Source: llms.txt: a proposal, not a search requirement

Keep the guide honest

We recommend listing only resources the operator maintains and capabilities the service actually implements. An informational website should not advertise purchasing, identity verification, or autonomous actions it cannot perform. A short accurate guide is preferable to a long speculative list of future features.

Test representation parity

Choose three statements that appear in both the human site and the machine guide: who operates the service, what it does, and where its current methodology lives. Compare the statements and destinations. A stale guide that points to retired routes creates a second source of confusion rather than solving the first one.

Make maintenance explicit

Give the guide an owner, a version or change record, and link validation in the release process. Exclude credentials, customer identifiers, account-recovery URLs, private pilot identities, and confidential operational details. Public machine files should be written with the expectation that anyone can retrieve them.

Measure what is measurable

A first-party request for the file is a retrieval observation. A completed bounded task using a linked resource is stronger evidence of utility, provided the test conditions are recorded. Neither establishes a universal ranking effect. Google’s AI search guidance says special AI text files are not required; the observatory treats llms.txt as an optional, task-specific representation.

Source: llms.txt: a proposal, not a search requirement · Google: AI features and your website