How to Test llms.txt Usage on Your Website

Before you invest more in the file, measure llms.txt usage on your own site. Ask a narrow question you can answer from server logs: does anything actually request the file? That is far easier to establish than whether it changes AI visibility, and the two questions should never be confused.

This guide shows how to set up the test, what to log, how to read a zero and how to report the result at the right strength. If you have not published the file yet, start with how to create an llms.txt file, then come back once it is live.

What the file is, and what claims surround it

llms.txt is a proposed convention: a Markdown file at a site's root that lists the pages an author considers most useful for language models, usually with short notes. It is simple to create. That simplicity invites strong claims that outrun the evidence, and they fall into three types:

• Adoption claims: "Major providers read it." Check each provider's own documentation, because absence of a statement is not adoption.
• Outcome claims: "Sites with the file get cited more." These are usually correlations across sites that also differ in size and documentation quality.
• Mechanism claims: "It tells the model what your site is about." Whether any retrieval system consults the file first is not publicly specified.

Meanwhile, Google's AI optimization guide says you don't need AI text files to appear in Google Search. So this test measures the one thing you can observe, requests for the file, and keeps it strictly separate from the outcome you might hope for.

Define the llms.txt usage test before you publish

Write the test down before the observation window starts. Record the publication date, the file contents, the response status and your logging coverage. Then decide which request types you will count and how you will separate verified agents, unknown clients and your own checks.

Next, run the file through the free llms.txt checker. It confirms that the file returns status 200 as plain text and follows the format. Otherwise you may count requests for a file that no reader can parse.

Make the log evidence complete

Access evidence is only as good as the logging layer. A zero can mean "nobody asked" or "we could not see", so confirm the points below and write them down before the window opens.

Check every logging layer

If a CDN serves the file from its edge cache, the request may never reach your origin server. In that case, origin logs alone will undercount access, sometimes to zero. So find out which layer serves /llms.txt and pull logs from that layer.

Also check bot-management rules. A firewall that challenges unknown clients can turn a fetch attempt into a block page, and a challenged request is not a fetch. Make sure the logs record the full user agent and client address, because you need both to verify an agent later.

Label your own traffic and keep a baseline

Your monitors, link checkers and colleagues will request the file too. Label these requests or exclude them by address, but keep them in the raw log. Then set a retention period at least as long as the test, because a four-week test needs four weeks of logs.

Finally, look at requests for the path from before the file existed. They will be 404s, yet their user agents show which clients were already probing for it. That baseline costs nothing and is useful on its own.

Collect a clean observation record

Each observation supports a specific, limited conclusion. The table maps what you might see to what it actually shows, so you can write findings at the right strength.

Worked example: access without outcome

Suppose a hypothetical four-week test records three relevant file requests and no detectable change in a fixed AI prompt panel. The result supports limited observed access during that period. However, it does not prove that the file is useless everywhere, nor that the requests improved visibility.

Likewise, zero recorded requests means something only within the completeness of your logs and the chosen window. State those boundaries next to the number. For context, an Ahrefs analysis of 137,000 sites reported that 97% of llms.txt files never got read, so a zero is a common result rather than a sign of a broken setup.

Avoid bundled changes

If you publish llms.txt while rewriting pages, changing internal links and launching a PR campaign, later visibility changes cannot be attributed to the file alone. Keep a dated change log for the whole test window.

For a stronger outcome investigation, choose a comparison suited to your site. Even then, external answer systems vary a lot and reveal little about how they work, so treat any outcome finding as provisional.

Report llms.txt usage at three levels

The finished test produces three separate statements. Keeping them separate is the entire discipline:

1. Access: how many requests for the file, from which verified agents, over which dates, with logging coverage stated. Example: "Three verified requests from two documented agents in 28 days; edge logs complete."
2. Sequence: whether listed pages were fetched by the same agents after the file request. Example: "No listed page was fetched within 72 hours of a file request."
3. Outcome: the prompt panel's results across the period, with variation and the change log. Example: "Two page rewrites also shipped in week three, so no attribution is possible."

A sequence is suggestive, not a mechanism. Similarly, an outcome without a clean change log supports no attribution at all.

Decide the appropriate maintenance level

The decision at the end is about maintenance, not rankings. Compare observed use with the cost of keeping the file accurate.

If the file is generated automatically from your sitemap and page descriptions, its cost is near zero, so keeping it is reasonable whatever the outcome. In contrast, a hand-maintained second description of the site competes directly with keeping the real pages accurate. In that case, let the access finding decide whether the effort continues.

Track the test in a worksheet

Copy the columns below into a spreadsheet and keep one row per request you review. The filled row is illustrative, not a customer result, so replace it with your own verified records.

Summarize the logs with AI

A model can summarize the log once you supply the records. Use the prompt below only after you paste them in:

Summarize these llms.txt request logs. Separate verified agents, unknown clients and internal checks. State logging coverage and observation window. Do not infer citation impact from requests or assume a later page fetch came from this file.

Then check every count against the raw log yourself. The log, not the summary, is your source of truth.

Conclusion

Measuring llms.txt usage is a logging exercise, not a ranking experiment. Define the test first, check every logging layer, label your own traffic and report access, sequence and outcome as three separate findings.

Then make a proportionate decision. Keep a generated file because it is cheap, and question a hand-maintained one if nothing requests it. Start by checking that your file is readable, then open your logs for the next four weeks.