llms.txt checker

What your site
tells an agent.

An llms.txt is a markdown file that hands a language model a curated map of your site. This reads one against the five structures the specification at llmstxt.org names, and shows the sentence each rule comes from.

This tool works differently from the generator. The generator never uploads your image — it runs in your browser. The checker cannot: it fetches the public address you type, from our server, and reads your origin’s llms.txt, the llms-full.txt some platforms publish beside it, and the HTML of the address you typed — read for one thing only: the link relation that says where your file is. Four addresses at most. Only the address you enter is sent. The addresses you check are then kept in this browser, so it can tell you what changed since last time; they go nowhere, and you can clear them.

How to give us the file

A site address is enough. We look for llms.txt at that origin, and follow the link relation on the page if it names a different one.

Questions

Is llms.txt an official standard?

No, and this page will not call it one. The document at llmstxt.org describes itself as a proposal that is “open for community input”, hosted as an “informal overview”. What is published today is v2. No standards body has ratified it, so a file that follows it is following a widely adopted convention rather than a requirement.

Does my llms.txt have to be at the site root?

No. The specification says the file may be “at the root path /llms.txt of a website or at any subpath (e.g. /docs/llms.txt)”, and that a file covers the addresses under its own path. This checker reads the conventional address at your origin, and if your page declares a different one with a rel="describedby" link it reads that instead.

Why is llms-full.txt not one of the rules?

Because it is not in the specification. The whole document was read on 2026-09-22 and the name does not appear in it once. Some documentation platforms publish one by convention, so this page says whether your site serves one — beside the findings, never as one of them. Scoring a site against a rule nobody published is the thing this tool exists not to do.

What happens if my file is very large?

It is read up to 512 KB and no further, and past that point nothing about its contents is claimed: every structural finding says “not measured” instead of passing, and no score is shown at all. A checker that reported “no errors” about a file it read half of would be describing its own limit rather than your file.

My site returns a page at /llms.txt. Why does the report say there is no file?

Because what is served there is a web page. A catch-all application answers every address with its HTML shell, including this one, and an agent asking for your llms.txt is handed that shell. The report names the content type it measured, so the finding is about what your server actually returns rather than about a 404 that never happened.

Does the text I paste get sent anywhere?

No. Pasted text is parsed and checked in this tab by the same code the server would run, and no request carries it anywhere. Giving an address is the other half of the tool and does reach our server, which fetches that address, your origin’s llms.txt and llms-full.txt, and reads the page for its link relations — four addresses at most.

The specification

The five rules this checks, and where each one comes from

Every rule above is one sentence from one document, quoted rather than summarised. It is a proposal open for community input rather than a ratified standard, so a file that follows it is following a widely adopted convention — and nothing here is scored against anything the document does not say.

Read from the v2 document on 2026-09-22. llmstxt.org

  1. 1 · An H1 that names the project

    “An H1 with the name of the project or site. This is the only required section”

    The only part the document requires. Everything else is “zero or more” or optional, which is why this is the one rule weighted as an error here.

  2. 2 · A blockquote summary

    “A blockquote with a short summary of the project, containing key information necessary for understanding the rest of the file”

    The line a reader uses to understand the rest of the file. Without it an agent has your section names and no idea what the project is.

  3. 3 · Detail blocks, without headings

    “Zero or more markdown sections (e.g. paragraphs, lists, etc) of any type except headings, containing more detailed information about the project and how to interpret the provided files”

    Paragraphs and lists are allowed between the summary and the first H2; headings are not. A heading there is read as opening a section, so the text under it changes meaning.

  4. 4 · H2 sections holding file lists

    “Zero or more markdown sections delimited by H2 headers, containing “file lists” of URLs where further detail is available”

    Zero is allowed, so a file with no sections breaks nothing — it just points nowhere. What fails here is a section that holds no list at all: a heading with nothing under it.

  5. 5 · Each item a markdown link

    “Each “file list” is a markdown list, containing a required markdown hyperlink `[name](url)`, then optionally a `:` and notes about the file.”

    A markdown link, then optionally a colon and notes. A parser finds nothing on a line written any other way, however clear it looks to a person.

How to write one that follows the specification

Five steps, in the document’s own order. The template beside them is the mock example the specification itself prints, copied rather than composed here.

  1. Open with an H1

    One `#` line naming the project or site. This is the only section the document requires, and a file without one does not follow the specification at all.

  2. Summarise it in a blockquote

    A `>` line directly under the H1, carrying what somebody needs to understand the rest of the file. Keep it to a sentence — it is read before anything else.

  3. Add detail, but no headings

    Paragraphs or lists explaining how to interpret what follows. Any markdown except a heading: a heading here opens a section instead.

  4. Group links under H2 headings

    Each `##` section holds a markdown list of links to the pages worth reading. Point them at markdown versions where you have them — that is what the file is for.

  5. Put the skippable ones under “Optional”

    Spelled exactly that way. The document gives that heading a meaning by convention: links an agent may skip when it needs a shorter context.

The specification’s own example

# Title

> Optional description goes here

Optional details go here

## Section name

- [Link title](https://link_url): Optional link details

## Optional

- [Link title](https://link_url)

Save it as llms.txt and serve it at your site root, or under the path it describes. Then check the address above — a file nobody can fetch is a file no agent reads.

Three things the document says that this does not score — and one it does not say

  • Where the file lives. The specification allows the root path or any subpath, and says a file covers the addresses beneath it. A file at /docs/llms.txt is not misplaced, whatever a checker that only looks at the root tells you.
  • The “Optional” section. Named as a convention rather than a rule, so having one is shown and not having one costs nothing.
  • The link relation. Version 2 recommends rel="describedby" so a client can find your file without guessing, in the page’s HTML or in an HTTP Link header — a recommendation, which is why it is weighted as worth knowing rather than as a fault.
  • And one thing the document does not say at all: llms-full.txt appears nowhere in it. It is a convention some platforms follow, reported here beside the findings and never as one.