llms.txt checker: 7 checks to run on your file

The llms.txt spec at llmstxt.org requires one thing: an H1 naming the project or site. Everything else is optional: a short summary in a blockquote, then H2 sections that list pages as Markdown links, each with an optional note. A file covers the URLs under its path. Run the seven checks below by hand, or use the free check just below, which reads the file against the format and checks that its first 25 links load. A pass means the file is readable. It does not mean an assistant will use it or cite you.

Validity is mostly structural

The published specification allows an llms.txt file at the root path or beneath a more specific path. The specification at llmstxt.org says that a file covers the URLs under its path, and that agents should use the most specific applicable file.

The required core is small. The file needs an H1 naming the project or site. The specification calls this “the only required section”.

It also describes a blockquote with a short summary, optional prose, and H2 sections containing useful URL lists. Each file list should be a Markdown list, with a required Markdown link and optional notes.

The specification also describes an Optional section for secondary information that an agent can skip when it needs a shorter context. A valid file should work for a person and a parser. The person should understand what the site does, while the parser should find the project name, summary, sections, and links without guessing. For a complete file to copy and adapt, see llms.txt example and generator.

Here is the worked example from our own readiness check. When we ran these 121 audits, the check only confirmed that a file existed at /llms.txt, was not an HTML page and had more than 40 characters. Under that rule it passed on 66 sites, warned on 55, and failed on 0.

Read the warnings carefully. Under that rule, a warning meant the site had no usable llms.txt, not that a file had problems: 55 of 121 sites had none, and 66, about 55%, had one. The result describes this sample, not every file on the web.

The check now reads the file against the llmstxt.org format. No H1 is a fail. Links that do not load are a warning, and it checks the first 25 links. A missing summary is only a note, because the spec makes it optional. List items under an H2 that do not open with a link get a note too: the format expects a link there, but a plain list costs no points. A pass still does not say that the summary is sharp, that the links are valuable, or that an assistant will use the file.

Scope and clarity both matter

A file can fail in ordinary ways: no H1, bare URLs instead of Markdown links, or an unexplained list of pages. It can also be technically tidy and commercially empty, describing the company without saying who the product is for, what it costs, what it replaces, or where the evidence sits.

That leaves an assistant with a directory rather than a useful brief. A parser can spot a missing heading more easily than it can judge whether a description says anything worth knowing.

Use this checklist when you inspect the file:

• The file is available at the path you intend to cover.
• The first heading names the project or site clearly.
• The summary explains what the project does without relying on a slogan.
• The sections use Markdown headings and make their purpose clear.
• Each resource uses a Markdown link and a useful description.
• The linked pages contain the facts the file says they contain.
• The file is concise enough to serve as a starting point.

As noted above, a file covers URLs under its path, which is why placement, not just content, decides whether it counts as valid. Where more than one file applies, the most specific file should be used.

Put the file where its intended scope is clear, then test that scope rather than assuming the root file covers every part of the site. The 121-site readiness results are available in the free AI readiness check, alongside checks for page content, crawler access, structured data, and citations.

Other signals need attention

The same sample shows larger gaps elsewhere. A plain statement of what a site is, who it is for, what it costs, and what it is measured against passed on 20 of 121 sites, warned on 56, and failed on 43.

The check for comparison or alternatives pages passed on 54 of 121 sites, warned on 46, and failed on 21. Questions answered on the page passed on 56 sites and warned on 63.

The checks that fail or warn most in this sample are the plain statement of what the site is, comparison or alternatives pages, and questions answered on the page, which is why a passing llms.txt file should not be mistaken for a healthy site.

More basic access signals were stronger. A homepage answering a plain request passed on 119 of 121 sites, while the check for AI crawlers allowed in robots.txt passed on 116. Those figures do not make llms.txt irrelevant. They show why a neat file should not outrank a clear homepage or accessible content.

Of the fifteen checks we run, llms.txt shares the lowest weight, 3 points, because a missing or malformed file is cheaper to fix and less consequential than a missing product statement or absent comparison page.

The check for a site’s own pages getting cited passed on 5 of 121 sites, failed on 11, and warned on 5. That is a separate outcome from file validity, and it is the reason a structural pass should not be reported as citation evidence. Whether the engines use the file at all is a separate question, covered in Does llms.txt work? What the data shows.

The argument against our position is reasonable: a small, cheap file is a cheap improvement, so why not fix it first? Fix it if it is broken, then keep its weight in proportion. It can help an agent find pages, but it cannot replace crawl access, page content, or third-party evidence.

Use how CiteGraph measures to keep readiness signals separate from observed mentions and citations. The distinction prevents a tidy file from becoming a tidy story about demand.

The check is a starting point

Use an llms.txt validator when you need a fast structural review. Check the H1, summary, headings, lists, links, and scope, then read the file as a buyer would, with no knowledge of the company beyond what it provides.

The specification suggests asking an agent questions while giving it only llms.txt as a starting point. That is a useful test of whether the file points to the right facts, although it remains a test of one interaction rather than a forecast.

The data has a firm limit. We measure samples, we state the sample size, and we do not know what we have not measured. The 121 audited sites tell us how these checks appeared in that sample, not how every assistant will treat every llms.txt file.

What to do this week:

• Run an llms.txt checker, then fix missing structure and broken scope before adding more prose.
• Rewrite the summary and link notes so a stranger can identify the product, audience, important pages, and buying context.
• Check crawler access, the homepage, direct product facts, and comparison pages next.