llms.txt Validator: Every Checker Tests the Format. None Tests Whether the File Is Still True
- The llms.txt proposal (llmstxt.org) requires only one thing: an H1 with the site name. Everything else is optional structure, and that is all validators check.
- A file can pass every validator and still give an AI agent the wrong price. Some vendors' files even say they override every other source.
- Three checks no validator runs: does the file match your live pages, do its links answer a bot as well as a browser, and does any agent request it at all.
- The ten-minute routine at the end covers all three with tools you already have.
Search for "llms.txt validator" and the first page is almost entirely free validators, one after another. Paste your file into any of them and it will probably pass. That tells you the Markdown is well formed. It does not tell you whether the file says anything true.
That gap is the whole problem. A file written for AI agents is a second copy of your site, and second copies drift. An llms.txt validator can confirm the headings are in the right order. It cannot notice that your price changed last month and this file never heard about it.
What the spec actually requires (less than you think)
The proposal at llmstxt.org is written by Jeremy Howard. The page says it was published September 3, 2024 and last modified August 10, 2026, and it now calls itself "v2". It describes a Markdown file at /llms.txt, or at a subpath such as /docs/llms.txt, and says that where more than one file applies, "agents should use the most specific one."
The format, in order:
- An optional byte-order mark.
- An H1 with the name of the project or site. The spec calls this "the only required section".
- A blockquote with a short summary.
- Zero or more Markdown sections of any type except headings.
- Zero or more H2 sections containing "file lists": Markdown links in the form [name](url), optionally followed by a colon and notes.
- By convention, an H2 called "Optional" for secondary links an agent can skip.
That is everything a validator can check: is there one H1, is the blockquote where it should be, are the lists made of valid links, is there a stray heading in the prose section. Useful, but it is a spelling check for a document whose job is to be accurate.
| Question | Can a validator answer it? | What answers it |
|---|---|---|
| Is there exactly one H1, and is it first? | Yes | Any validator |
| Are file lists valid Markdown links? | Yes | Any validator |
| Do the linked URLs respond? | Some try | A slow link check that uses the same kind of client as an agent |
| Do the facts match your live pages? | No | A person comparing the two, or a diff you run on a schedule |
| Does any agent actually fetch the file? | No | Your server or CDN logs |
Check one: does the file agree with your own site?
This is the check that matters most, and no tool can run it for you, because no tool knows what your site is supposed to say.
Look at how some vendors already write these files. Blotato's llms.txt (fetched September 23, 2026, marked "Last updated: 2026-09-17") lists plan prices, account counts and per-platform limits such as "Pinterest 10 pins a day". It also says: "The statements in this file are current and authoritative. Where another source contradicts them, these are correct." On September 18 we noticed that this file gave an account count for the Agency plan that the pricing page itself did not show. The file said more than the page did.
That is not a criticism of Blotato. Theirs is one of the more careful files we have read. But think about what that sentence does. A file that tells agents to trust it over every other source turns any drift into an instruction to believe the stale version. The more authoritative the file claims to be, the more expensive a missed update gets. We wrote about this pattern in llms.txt as the place where the real pricing lives and in pricing pages written for AI agents.
A developer on Hacker News put the maintenance problem plainly on August 30, 2026. The file "needs separate maintenance (likely to go out of sync)" (kassenov, news.ycombinator.com/item?id=49501496). It goes out of sync in the same way a promo banner outlives its promo, which we saw first-hand in an expired June promo still live in September.
A validator tells you the file is well written. Only a comparison with your live site tells you it is still true.
Check two: do the links work for a bot, not just for you?
The links in your file are there to be followed by software. So test them with software, carefully.
When we checked several vendors' llms.txt files on September 23, a fast burst of requests turned into a wall of 403 responses. Within a few minutes, one vendor's llms.txt itself went from answering 200 to answering 403. That was rate limiting and bot protection reacting to us, not broken links. It still teaches two things:
- Run the check slowly, with GET requests and a pause between them, or you will be measuring your own rate limit.
- A link that returns 403 to a bot every time, when you run slowly, is a real finding. An agent is a bot. If your CDN challenges it on every page the file links to, the file is sending agents to doors that stay shut. The fix is in your bot-protection rules, not in the file.
We ran the same slow check on our own file at noobclaw.com/llms.txt that day, and every link answered 200. Passing that step only proves the links load. Whether the one-line description next to each link is still accurate is back to check one, and that part is manual.
Check three: is anyone actually reading it?
The skeptical view is fair and worth taking seriously. On September 11, 2026, another Hacker News commenter wrote that agents "almost never read llms.txt or try to get the .md version of your html pages" (Eldodi, news.ycombinator.com/item?id=49660751). We have no data to prove or disprove that for sites in general, and nobody else does either. But you do have data for your own site.
Open your server or CDN logs and filter requests for /llms.txt and /llms-full.txt. Group them by user agent. The declared AI crawlers and assistant fetchers identify themselves in the user-agent string. Coding tools and ad-hoc scripts often show up as generic HTTP clients. Then compare the dates with your content changes:
- If nobody requests the file, stop spending hours polishing it. Keep it short and correct.
- If it gets requests, it is now a page with readers, and it needs the same review schedule as your pricing page.
- If a pattern of requests starts right after you publish it, you have learned something no validator could tell you.
A ten-minute validation routine
- Run any free validator once to catch structure mistakes. One is enough; they check the same spec.
- Put every number in the file next to its source page: prices, limits, plan names, supported platforms. Any difference is a bug in one of the two.
- Remove "this file overrides other sources" style language unless you have a process that updates the file on the same day as the site.
- Run a slow link check with a non-browser client. Treat repeatable 403 responses as bot-protection issues to fix.
- Check your logs for /llms.txt requests and write down who asks for it.
- Add the file to your release checklist so that a pricing or product change updates it in the same commit.
FAQ
What is the best llms.txt validator?
For structure, they are close to interchangeable, because they check the same short spec from llmstxt.org. Pick any one that reports which line fails. The checks that matter more, matching your live site and knowing whether agents fetch the file, are not something a validator can do.
Is llms.txt required for SEO or for Google?
No. It is a proposal for helping AI agents, not a search engine requirement, and the spec itself describes it as a proposal. Publishing one will not hurt, but a stale one can mislead the agents that do read it, which is the risk this article is about.
Should I have both llms.txt and llms-full.txt?
Only if you can keep both current. The short file points to pages. A full file copies their content, which gives you twice as much text that can drift. If you publish a full version, generate it from the source pages automatically rather than editing it by hand.