How to check your llms.txt file

What does an llms.txt validator actually check?

An llms.txt validator checks four things: that the file returns HTTP 200 over HTTPS at the domain root, that the body is plain markdown rather than JSON or an HTML wrapper, that every linked URL resolves instead of returning a 404 or a redirect chain, and that the layout follows the llmstxt.org convention — a level-1 title, a blockquote summary, and one or more sections of markdown links.

A validator cannot tell you whether ChatGPT, Perplexity, or any other assistant has actually fetched the file, and it cannot confirm that AI crawlers can reach the pages it links to — that is a separate robots.txt and CDN check, not a file-format check. Treat validator output as a structure report, not a visibility score.

Most validators report each check as a simple pass or fail rather than a single blended score — HTTP status, content type, link reachability, and structural layout are graded separately. That separation is useful in practice: a file that fails only the freshness check needs a one-line date fix, while one that fails the HTTP status check needs a hosting or CDN change before anything else is worth touching.

What are the most common llms.txt validation errors?

The errors that show up most often are structural, not content-related: the file served with a text/html content type instead of text/plain or text/markdown; a missing blockquote summary line directly under the H1; links that point to pages behind a login wall or that 404 after a site redesign; and an Updated line that was never refreshed after a pricing or route change, so it silently misrepresents how current the file is.

A less obvious mistake is publishing a JSON export or a full sitemap dump instead of a short, curated markdown file — llms.txt is meant to be a table of contents an assistant can scan in seconds, and a bloated file defeats that purpose even when every individual link works.

A related issue is treating the Updated line as decorative. A date that claims the file changed last week, when the actual content has not moved in months, does more harm than an honest older date — it tells anyone checking freshness that the file is actively maintained when it is not, and a diff against your deploy history will expose the mismatch.

Can you validate llms.txt manually, without a tool?

Yes. Request the URL with a command like curl -I to confirm a 200 status and the content type, then fetch the body and check for a level-1 heading, a blockquote summary, and at least one linked section. Open every linked URL by hand and confirm it loads without a login prompt.

Manual checks are enough for a single small site you update rarely. An automated validator earns its keep once you maintain several domains, re-check after every deploy, or want a repeatable report to hand to a developer instead of describing the fix verbally.

One false alarm worth knowing about: some CDNs and static site generators serve a cached copy of /llms.txt for a few minutes after a deploy. If a manual check right after publishing still shows the old content, that is usually a caching delay rather than a failed fix — wait for the cache to clear and re-check before assuming the deploy did not take.

How often should you re-validate llms.txt?

Re-validate whenever something changes that the file references: a pricing update, a renamed or removed route, a CMS plugin update, or a new CDN or WAF rule. Any of these can silently break a link or reintroduce a block on the bots you listed the file for in the first place.

If you cannot tie validation to a specific event, a quarterly check is a reasonable minimum for small sites — the same cadence worth using for a full robots.txt and crawl-access review, since a stale llms.txt and a stale robots.txt tend to drift out of date together.