seoder

llms.txt validator

Enter any URL on the site. seoder fetches llms.txt and llms-full.txt from that host and checks the file against the format, including the parts a text editor cannot show you.

Any URL on the host works. The file is always read from the root of that host, which is the only place a reader looks for it.

Result

The file report lands here, with the counts the format asks for.

Fetching the file. This takes a few seconds.

The check did not finish.

What a valid file looks like

llms.txt is markdown with a shape. One H1 at the top carrying the name of the site or project. A short summary under it, written as a blockquote, saying what the site is in a sentence or two. Then H2 sections, each holding a list of links, where every link has a title and a short note about what the reader will find there. The whole thing is meant to be read start to finish by something with a limited context window, which is why brevity is part of the specification rather than a style preference.

The validator reports each of those parts separately: whether the file opens with an H1, whether a summary follows it, how many sections there are, how many links they carry, and how many of those links are relative. It also reports the byte size and whether the response looked like HTML.

The three failures worth catching

Relative links are the quiet one. A path such as /docs/start resolves fine in a browser sitting on your domain and resolves to nothing at all for a reader that was handed the file contents without the URL it came from. Write every link absolute, with the scheme and host. The validator counts relative links precisely so this shows up as a number rather than as a vague feeling that something is off.

An HTML response is the loud one. Static file routing is easy to get wrong on a framework that owns every path, and the result is a 200 with a full page in the body. Any reader that parses markdown gets a wall of tags. The check reads the first bytes of the body rather than trusting the content type header, because the header is often the thing that is wrong.

Size is the slow one. There is no hard cap in the format, but a file with several hundred links stops being a summary, and a reader that truncates it drops whatever sat at the bottom. Keep the index short and put the bulk in llms-full.txt, which exists for exactly that split.

What it does not do for you

Publishing the file grants no access and blocks nothing. Crawl permission is decided in robots.txt and at your server, and an AI crawler that is disallowed there stays disallowed no matter what your llms.txt says. If your goal is to control access rather than to describe your content, start with the robots.txt tester instead.

The format, its history and the operators who have actually committed to reading it are covered in the llms.txt glossary entry. If your worry is how much of your site a crawler gets through in the first place, that is a different measurement, and crawl budget explains what sets it. For everything a single fetch can tell you at once, run the full report, and read how each verdict is decided before acting on any of it.

Common questions

Does anything read llms.txt today?

Some tools and assistants fetch it when a user points them at a site. No major search crawler has committed to reading it as a ranking or access input, so treat it as documentation for machines rather than as a control.

Is llms.txt a replacement for robots.txt?

No. robots.txt decides whether a crawler may fetch a URL and is enforced by the crawler. llms.txt describes what is worth reading and enforces nothing. A site that wants to block an AI crawler has to do it in robots.txt or at the server.

What is llms-full.txt for?

It carries the actual content rather than a map of it, usually the documentation flattened into one markdown file. The validator reports whether it exists and how large it is, because a multi-megabyte file gets truncated by most readers.

Why does the check say my file is served as HTML?

Because the response body starts with markup. A framework catch-all route or a 404 handler answered instead of a static file, so a reader that expected markdown gets a web page. Serve it as text/plain or text/markdown from the site root.