llms.txt Validator: How to Check Your File Is Actually Working

Writing an llms.txt file is the easy part. The failure mode that actually costs you is publishing one that looks correct — clean markdown, sensible sections — but silently doesn't work: served with the wrong content type, sitting behind a redirect, or full of links to pages that moved six months ago. None of that is visible by reading the file. It's only visible by validating it.

If you haven't written your file yet, start with how to write an llms.txt file first — this guide assumes you have a file and want to confirm it actually holds up.

The 8 checks a real validator runs

1. Exactly one H1. The spec expects a single top-level heading with your site or project name. Multiple H1s, or none, break the parsing assumption most tools make about where the file starts.

2. A blockquote directly under the H1. This is your one-line summary — the thing most likely to get read even if a model only samples the first few lines of the file. Missing it doesn't break parsing, but it wastes the highest-value line in the whole document.

3. Content type served correctly. The file needs to be served as text/plain or text/markdown, not wrapped in your site's HTML template with a text/html content type. A surprising number of llms.txt files fail this check because they were generated as a page in a CMS instead of a static file at the domain root. 4. No redirect between the URL and the file. yoursite.com/llms.txt needs to resolve directly with a 200 status. If it 301s to www.yoursite.com/llms.txt or to an HTTPS variant, some fetchers will follow it fine and others won't — don't rely on the redirect working everywhere. 5. Valid markdown link syntax throughout. - [name](url): description is the required pattern for every entry. A missing bracket, an unescaped character, or a bare URL instead of a markdown link will parse incorrectly or not at all.

6. Every linked URL actually resolves. This is the check most manual reviews skip, and the one that decays fastest — pages get renamed, features get merged, old URLs 404. A validator should fetch every link in the file and flag anything that doesn't return 200.

7. Descriptions that add information. Not a hard parsing rule, but a quality one: if every description just restates the link title, the file isn't doing the one job llms.txt exists for — giving a model context it can't get from the link text alone.

8. An Optional section, used correctly. Lower-priority links belong in the final ## Optional H2, not scattered through the main sections. This is what lets a context-constrained model safely skip content without missing anything important.

Common errors, ranked by how often we see them

Wrong content type — HTML wrapper instead of plain text/markdown.

Dead links — pages renamed or removed after the file was written.

File in the wrong location — anywhere other than the domain root.

No blockquote summary — H1 with no context line underneath it.

Everything crammed into one section — no prioritization, defeating the point of the format.

Each of these passes a casual glance and fails the first time something actually tries to use the file.

Validate it in under a minute

Run your live URL through our llms.txt validator — it checks all eight items above automatically: structure, content type, redirects, link syntax, and whether every linked page actually resolves. You'll get a pass/fail on each check plus the exact line or link that's causing a failure, rather than having to diff your file against the spec by hand.

If you don't have a file yet, the llms.txt generator builds a spec-compliant one from your sitemap, pre-checked against most of this list before you ever publish it. And if you want the broader context on why this file matters alongside robots.txt and your sitemap, see llms.txt vs robots.txt vs sitemap.xml.