llms.txt Validator

Eight things, all drawn from the llmstxt.org specification. It looks for a single H1 giving the site name, a blockquote summarising what the site does, H2 sections grouping links by theme, and Markdown links with one-line descriptions after the colon. It then checks that links are absolute, that the file stays light, and that the server is returning plain text rather than an HTML page. The last check catches the most common failure by far. A server with no llms.txt often returns the site homepage instead of a 404, so the file looks present in a browser while containing nothing a model can use.

Because an llms.txt file is designed to be pulled out of your site and loaded into a context window. Once it is there, a link written as /docs/getting-started has no origin to resolve against. The model cannot follow it, and the entry becomes dead weight in a budget you are already paying for. This is the difference between llms.txt and a sitemap. A sitemap is read by a crawler that knows where it came from. An llms.txt is read by a model that may have received the text through three intermediaries. Absolute URLs are the only form that survives that journey.

Yes. Switch the tool to paste mode and drop the content in directly. Nothing is fetched and nothing is stored, the file is parsed and scored on the spot. This is the mode we recommend while you are writing. Publishing a file, discovering it is malformed, fixing it and redeploying is a slow loop for something that takes seconds to check. It also lets you validate files for sites you do not control, which is useful when you are auditing a client or looking at how a competitor structured theirs.

No, and the tool validates against a community specification rather than a ratified one. The format was proposed by Answer.AI in September 2024 and is documented at llmstxt.org, but it has not been adopted by the W3C or the IETF and no major AI vendor has committed to reading it. What has happened is adoption without ratification. Coding assistants and agent frameworks fetch it when building context, and a growing number of documentation sites publish one. The honest position is that the file costs minutes to produce and carries an option on an ecosystem that is clearly moving toward structured content at inference time.

Because llms.txt is the index and not the content. The specification splits the two deliberately: llms.txt carries the map, llms-full.txt carries the territory. A file that grows past a hundred kilobytes has usually stopped being a map. The cost is real. Anything loaded into a context window displaces something else, so a bloated index crowds out the content the model actually needs to answer. A tight file of twenty or thirty well-described links outperforms an exhaustive one every time, for the same reason a good table of contents beats a photocopy of the whole book.

It removes friction, which is worth something but is not worth everything. A well-formed file tells a model what your site covers and which pages matter, without making it infer that from crawled HTML. For agents and coding assistants that fetch it directly, the effect is immediate and measurable. For consumer assistants answering a general question, the effect is indirect at best. None of them has confirmed that they read it at query time. Treat the file as infrastructure you put in place cheaply rather than as a lever that moves citations on its own, and spend the saved effort on the content those citations actually depend on.