What the checker reads
Enter a domain and the checker asks for /llms.txt at its root, as a tool following the llms.txt proposal would. To test a file in a subfolder, such as /docs/llms.txt, paste its full address ending in .txt. Our server makes the request from its own address, follows up to three redirects, and reads at most 1 MB.
The file must come back with a success status and a text type. A missing file, a server error, an HTML page or a binary type stops the check there, because no reader would get usable text either. When the file is read, the report shows the address it was finally read from, its size, its sections and the number of links.
Errors, warnings and tips
Errors break the format. The file must start with an H1 naming the site, the only required part, and contain only one. A link that is not a web address, or a file that is really an HTML page, also counts as an error. Fix these first: a reader may not recognize the file at all.
Warnings make the file harder to read. The summary blockquote after the H1 is missing, a section heading is deeper than H2, a line of text sits inside a link section, a list uses "*" instead of "-", a link is relative, a section has no links, or the file is large. Tips are small improvements, such as a colon between a link and its note, or an address listed twice.
Each issue carries the line number in the file, and the report shows the file as it was read, numbered, so you can find the line without opening your editor.
The problems this checker finds most
The first is a file that does not exist but looks like it does. A host that sends the site template for any path returns HTML with a 200 status, and a quick look in a browser can miss it because the page renders. The checker reads the content type and the first bytes, so it reports the template for what it is.
The second is a file written like a blog post. Several headings, paragraphs between the links, nested lists: people read it fine, but a parser that expects one link per line skips or rejects what does not match. Keep the prose in the summary and the details, before the first H2, and keep link sections to one item per line.
The third is a set of links that point to pages that moved. The checker opens the first ten distinct links on your own domain and its subdomains and reports any that fail, with the reason. A link ending in .md that returns an HTML page is flagged as a tip, since the proposal suggests a clean Markdown version at that address.
llms-full.txt and other files
The checker also asks whether llms-full.txt exists next to the file and reports what it found. That name is a convention used by some documentation platforms for the full text of the docs in one file; it is not part of the proposal, so a missing llms-full.txt is not an issue. Paste the address of an llms-full.txt to check that file alone: since it has no defined format and often weighs several megabytes, the report covers only its status, type, size and declared encoding, never its structure.
If you need to write or rewrite the file, the llms.txt generator builds it from a form and applies the same rules as you type. For crawl rules, which llms.txt cannot express, use the robots.txt generator.
What the check does not do
It does not run scripts, log in or send your cookies, and it only reads public addresses: private networks and local hosts are refused, including after a redirect. It does not judge whether your summary is accurate or whether an assistant will use it. Nothing is stored apart from an anonymous daily count used for the limits of the tool.
Run the check again after each change, since results are never cached. For the pages behind your links, the Open Graph checker shows the preview a shared link gets, and the SERP simulator shows how a title and description read in search.
