Llms.txt and Google AI features: what the documentation actually requires

Google explicitly says llms.txt neither helps nor harms visibility or rankings in Search. The file remains an optional documentation resource for systems that read it. The workflow below separates that possible use from AI feature eligibility and access controls. Position checked on October 5, 2026.

What does Google's AI features documentation actually say?

The official AI optimization guide names llms.txt and says Google Search ignores it. This explicit position replaces the older reasoning based on an absence of mention. The June 15, 2026 changelog dates that clarification.

The practical question is which system the file serves. A documentation convention does not become a Google requirement because another tool can read it. Record its intended consumer before assigning maintenance work.

Where does llms.txt come from, and what is it for?

The llms.txt proposal, updated to version 2 on August 10, 2026, describes a Markdown file at the root or under a path, providing context and links for agents. It is a separate proposal, not a Google Search requirement.

For your own decision, identify the consumer, the documents it should find and the person maintaining those references. A file with no known consumer should not be described as a proven acquisition channel.

Is llms.txt useless then?

Separate Google's explicit position from the intended third-party use. For a system that reads the file, our proposed check asks whether the listed documents are current and whether the expected information can be found. For a system that ignores it, avoid claiming an undocumented benefit.

Treat the file as a documentation task with a named consumer, rather than a visibility switch. An outdated reference may confuse that consumer; it does not establish a Google ranking effect.

What actually governs inclusion in AI features?

Our proposed diagnostic starts with the page: final URL, accessibility, indexation, displayed information and internal links. Record the observed issue before choosing a repair. A file listing an address does not remove noindex or resolve a server error.

The Search generative AI control documentation states worldwide rollout on August 31, 2026. It manages inclusion, exclusion and inheritance for the relevant features; model training is a separate decision.

Check the effective property configuration before blaming a missing file. Do not change it automatically: another team may have chosen exclusion deliberately. Our working ledger records the property, observed setting, responsible owner and open question.

Example: a hypothetical publisher

Consider a hypothetical UK-based publisher with 4,000 articles. It adds an llms.txt listing 200 "best" pages. Nothing else changes. The review still needs to inspect the pages and effective inclusion settings. The scenario does not demonstrate a traffic or citation benefit from the file. If some were blocked by a misconfigured robots.txt rule, the file does not unblock them, as this is a hypothetical illustration. The fix is the robots.txt rule, not the file. These figures are illustrative only.

How should teams decide?

What about AI crawler controls?

Our proposed review keeps three questions separate: which requests may access the site, whether the site is included in Google's relevant AI features, and which documentation a third-party agent consumes. Record the mechanism involved in each decision.

Avoid offering llms.txt as a repair for all three. If a rule is blocking access unintentionally, investigate that rule. If exclusion is deliberate, ask the responsible owner about the intended policy before proposing a change.

What remains uncertain?

The behavior of a particular non-Google service needs verification in that service's current documentation. Do not generalize Google's position to every agent, or an agent's documented use to Google Search.

Our suggested review records system, version where available, date, expected behavior and observed result. This makes a narrow documentation experiment reviewable without calling it proof of an acquisition effect.

How can you verify claims about llms.txt?

Ask three questions: which system is involved, what does its official documentation say, and what useful behavior can your team observe? For Google Search, use the explicit position in the guide cited above. For another system, look for its own evidence.

Keep claim and observation separate in the review. A successful document fetch proves access to that document, rather than a future recommendation, search ranking or sale.

For related context, see our Search profile badge article and regional testing guide.

A decision record without a ranking promise

Consider a fictional team maintaining twenty documentation pages. It receives a proposal to add llms.txt to “earn Google citations.” Our suggested review starts by unpacking that promise: which engine, which outcome and which evidence are involved? For the Google claim, the guide’s explicit position resolves the central question without an invented experiment.

The team then examines a separate documentation use. It records the proposed third-party system, documentation describing how that system consumes the file, and the question it should answer. If those details are missing, the status remains “consumer unconfirmed.” An assumed benefit does not enter the results column.

When a use is confirmed, the proposed checks concern observable elements: document address, current information, working link and response to a defined question. The owner preserves the raw result. A successful document read establishes that read, rather than a product recommendation, higher ranking or increased traffic.

The record also names an owner, a next review date and a stopping condition. In our scenario, removing an unused resource would be a maintenance decision. Repairing an obsolete link would be a documentation correction. Neither needs to be described as a ranking intervention to justify the work.

Connect the note with your SEO reporting workflow so the team can understand the decision later. Keep expected behavior, observed behavior and unresolved questions in distinct columns. This prevents an apparently successful technical check from becoming an unsupported acquisition claim when the report is shortened for a manager.

Follow-up questions

Does adding llms.txt improve rankings in Google Search?

Google explicitly says Search ignores the file and that it neither helps nor harms visibility or rankings. Claims of a Google uplift caused by llms.txt contradict that current position.

Should I remove llms.txt if I already published one?

Identify its actual consumer first. Retaining or removing an optional documentation file should follow its usefulness and maintenance needs, without presenting either choice as a Google ranking repair.

Does the Search Console AI control replace llms.txt?

They serve different purposes. The control manages inclusion in the relevant Google features, while llms.txt can provide documentation to a third-party consumer. Inspect those decisions separately and keep the effective settings visible in the review.