The llms.txt Study Found Most Files Unread: A Practical Reality Check for GEO Budgets

The appeal of llms.txt is easy to understand. A publisher can add a small file, describe important resources and feel that the website has taken a concrete step toward AI discovery. The harder question is whether relevant systems request the file and whether that activity produces any useful outcome.

An Ahrefs analysis published June 15 examined 137,210 sites receiving traffic through its Web Analytics sample during May 2026. About 28% had a valid llms.txt file, and 97% of those files received no requests during the observed month. The study checked for a successful response and Markdown content rather than treating every apparent URL as a valid file. Its population reflects participating sites, and the measurement concerns requests during a defined window. It does not establish that no AI product ever uses the format or test a causal effect on rankings.

For businesses allocating GEO budgets, the finding is a useful reality check. An implementation is an activity. A request is evidence of access. A citation, qualified visit or useful interaction is a different outcome. Treating those steps as interchangeable makes it easy to spend money without learning much.

A file can exist without being part of a discovery path

Publishing a resource does not ensure that another system knows about it, chooses to retrieve it or uses its contents. That is true of a new article, an API endpoint and a machine-oriented summary file. The existence of the file is therefore the beginning of an evaluation, not its conclusion.

The distinction matters because implementation reports often stop at a screenshot or a successful status code. Those checks can establish that the deployment worked. They cannot establish adoption by an external service. A technically correct artifact can remain unused.

For a small experimental file, that may be acceptable. A low-cost experiment can be worthwhile even when the outcome is uncertain. The concern arises when the same implementation is sold as a major visibility intervention without evidence of the mechanism or the result.

A useful report should say what was installed, why it might help, what activity was observed and what remains unknown. That language is less dramatic than a guaranteed optimization claim, but it gives the business a basis for deciding whether to continue investing.

Requests are not all equivalent

Even when a file receives traffic, the identity and purpose of the request matter. A developer testing a configuration, a monitoring service checking availability and a production retrieval system serving a user can all request the same URL. A raw count does not distinguish them automatically.

User-agent strings are also assertions, not complete proof of identity. Where a decision depends on the operator, use the verification methods appropriate to that service and retain the limits of the evidence. Do not turn a familiar name in a log into an unsupported claim that a particular AI answer used the file.

The request may be a preliminary check rather than a substantive use. A system can retrieve a file and ignore its contents. Conversely, a system may discover useful pages through ordinary links without requesting that file at all. Those possibilities make a simple before-and-after count difficult to interpret as a visibility effect.

This is why the evaluation should connect several observations instead of treating one as decisive. Access logs, page referrals, observed citations and user outcomes can each contribute evidence, but none should be stretched beyond what it actually records.

Put the work on an evidence ladder

A practical way to assess a proposed implementation is to describe the strongest evidence currently available. At the first level, the file exists and is valid. At the next, relevant requests are observed. A stronger level connects the resource to a documented workflow. Stronger still is evidence of a useful outcome that can reasonably be attributed to the change.

The ladder is not a universal scoring system. It is a way to prevent a deployment fact from being reported as a business result. A project can be worthwhile at an early level when the cost is small and the learning objective is clear.

This framing also makes vendor conversations more productive. Instead of arguing about whether the format is good or bad in principle, ask which level of evidence supports the proposed price and priority.

Opportunity cost is the real budget question

The cost of adding a small file may be modest. The opportunity cost can be larger if the task displaces work on missing content, broken links, inaccessible pages or inaccurate information. A business should compare the expected value of the available tasks, not evaluate each in isolation.

Imagine a hypothetical directory with outdated agency profiles, unclear comparison criteria and several important category pages that are difficult to reach. A polished machine-readable summary does not repair those weaknesses. It may simply describe an unreliable collection more neatly.

The same directory could reasonably add an experimental file after fixing the underlying resources. The sequence matters. A summary is most useful when the destination pages are accurate, coherent and worth retrieving. Otherwise, the technical artifact can create the appearance of progress without improving the resource itself.

Budget discussions should therefore include a concrete alternative. What would the same time achieve if spent updating ten important claims, improving a comparison table or repairing navigation? That comparison helps prevent a fashionable task from receiving priority merely because it is easy to demonstrate.

Maintenance can exceed the initial implementation

A file listing important resources becomes another place where information can go stale. URLs move, page titles change and product descriptions evolve. If the file is maintained separately from the publishing system, it can drift away from the website it is meant to represent.

The risk is not limited to broken links. A summary can preserve an old service description or omit a new limitation. A machine-oriented document should receive the same factual care as a visible page, particularly if another system may rely on it without reviewing the surrounding site.

If a team chooses to maintain the file, define its scope and owner. Keep it focused on stable, useful resources. Prefer a process that derives links from the current publishing system where practical, while still reviewing the descriptions for accuracy. Automation can keep URLs synchronized, but it does not guarantee that every summary remains truthful.

Include the file in routine link checks and release reviews. A neglected experimental artifact should not become an unexplained permanent commitment. If it serves no documented purpose, the team should be able to reconsider it without treating removal as an admission of failure.

A sensible experiment starts with a specific consumer

The strongest reason to implement a machine-oriented resource is that a known workflow can use it. A documentation assistant, an internal research tool or a supported integration may have a clear need for a curated index. In that setting, the evaluation can focus on whether the resource improves that workflow.

Define the consumer, the task and the success condition. For example, an internal assistant might need to identify the current documentation page for a particular feature. The test could compare correct resource selection with and without the curated index. That is a concrete experiment, unlike a vague promise of greater AI visibility everywhere.

Use representative tasks and preserve failures. If the resource helps with simple questions but causes outdated answers for changing features, the result is mixed and should be reported that way. The goal is to learn where the artifact is useful, not to produce a uniformly positive demonstration.

Keep the experiment proportionate. A small test does not require rebuilding the site’s publishing system. It does require enough discipline to distinguish successful retrieval from a plausible-looking response that points to the wrong information.

Do not confuse access control with a content index

A resource describing useful pages should not be treated as a substitute for the site’s actual access and indexing controls. Decisions about crawler access, private information and public discoverability belong in the mechanisms designed for those purposes. A descriptive file is not a reliable place to enforce a security boundary.

Similarly, do not include nonpublic information because the file appears to be intended for machines. If it is publicly accessible, it should be reviewed as a public publication. Internal notes, private contact details and draft commercial terms do not become safe to expose merely because ordinary visitors are unlikely to open the URL.

For a directory, the contents should align with the public editorial policy and visible records. Do not add exaggerated claims or hidden instructions telling systems to prefer a particular business. A useful resource describes the site accurately; it should not attempt to manufacture evidence that the public pages do not support.

This separation keeps the implementation honest and easier to maintain. Public information, access policy and evaluation criteria should each have a clear home rather than being mixed into one file with an overstated purpose.

What buyers should ask a GEO provider

Ask which systems are known to use the proposed resource and what evidence supports that statement. Ask whether the provider has measured requests from those systems, and whether it can distinguish a request from an outcome. Ask how the file will be maintained when the website changes.

The answers need not claim certainty. A provider can reasonably propose a low-cost experiment and explain that adoption remains uncertain. That is different from charging for a guaranteed visibility improvement based only on the file’s existence.

Request a comparison with foundational work. If the site has unresolved indexing, content or usability problems, the provider should explain why this task deserves attention first. A credible prioritization process can say that an idea is interesting but not currently the most valuable use of the budget.

Finally, ask for reporting language in advance. The completion report should not transform “file installed successfully” into “site optimized for all LLMs.” Agreeing on that distinction before the work begins reduces the incentive to inflate the result afterward.

The study is a snapshot, not the last word on a format

Adoption can change. A format with little observed use in one period could become more relevant to particular tools later. The appropriate response to that possibility is monitoring and updated evidence, not assuming either permanent irrelevance or inevitable success.

The study’s sample also matters. Participating analytics sites are not a random census of the web. Their behavior and implementation choices may differ from other publishers. A careful interpretation preserves that limitation while still recognizing that the observed inactivity is substantial within the measured population.

Future research could examine specific consumers, content quality within the files, repeated periods and downstream use. Those questions would provide more detail than a simple existence check. Until such evidence is available, businesses should avoid claiming more than their own observations can support.

The durable lesson is about evaluation. Every new optimization artifact should face the same questions: who uses it, for what task, with what evidence, and at what cost? Those questions remain useful even if the answer for a particular format changes.

Publish useful resources first

For most teams, the immediate priority is a website whose pages are accurate, accessible and worth citing. A machine-oriented index may support a particular workflow around those pages. It cannot supply missing expertise, repair unsupported claims or create a reason for a reader to trust the site.

That makes the llms.txt debate less mysterious. Treat the file as a potential tool with a defined use, not as proof that a site has completed AI optimization. Test it where a credible consumer exists, maintain it if it helps, and report the outcome at the level the evidence supports.

Make the experiment easy to retire

A trial implementation should have a review date and an explicit decision about maintenance. If no relevant use is observed, the team can keep a low-cost artifact, revise the test or remove it according to its broader publishing policy. None of those choices should require defending an earlier marketing claim.

That flexibility is easier when the original proposal was honest about uncertainty. Calling an experiment an experiment preserves the ability to learn. Calling it an essential ranking requirement before evidence exists creates pressure to maintain it indefinitely, even when more useful work is waiting.

Source and analysis note: The sample, period and request findings are attributed to Ahrefs. The evidence ladder, budget examples and evaluation process are original SEOS.co analysis. No ranking experiment or independent crawl-log study was conducted for this article.