What does an llms.txt validator check?

It checks the structure defined by the llmstxt.org specification: the file starts with a single H1 title, an optional blockquote summary follows, any free prose contains no headings, every H2 section contains only link entries of the form - [name](url): notes, and every link is an absolute, valid http(s) URL. It also warns about conventions: a missing summary, duplicate URLs, an Optional section that is not last, non-standard bullets, and over-long titles, notes or lists.

Is the blockquote summary required in llms.txt?

No. The H1 title is the only section the specification requires. The blockquote summary is optional, but it is the sentence an agent reads to understand what the links are for, so this validator reports its absence as a warning rather than an error.

Can links in llms.txt be relative?

Treat them as an error. The specification's examples use absolute URLs, and an agent reads llms.txt out of context — it fetched one file and has no base to resolve /docs/ against. Write every link as a full https:// URL.

What is the Optional section in llms.txt?

A section headed ## Optional holds secondary links an agent may skip when it is short on context. In v1 of the specification it drove a context-expansion tool; since v2 (August 2026) it is only a convention, so the validator warns if it is present but not last.

Does a valid llms.txt improve Google rankings?

No. Google's documentation states that Search does not use llms.txt and that keeping one will neither help nor hurt your visibility. The file exists for coding agents and documentation tools that fetch it on demand. Validate it for them, not for rankings.

Is my llms.txt uploaded when I paste it here?

No. The validator is a small script that runs entirely in your browser; nothing you paste leaves the page, and there is no account or signup. You can load the page once and use it offline.

Can the validator fetch my site's llms.txt from a URL?

No, by design. Browsers block a page on one domain from reading a file on another (CORS), so a URL field would fail for most sites. Run curl https://yourdomain.com/llms.txt, or open the file in a tab, and paste the text.

llms.txt Validator: check and fix your file free

How to validate an llms.txt file

Three steps, all on this page. The validator checks the structure defined at llmstxt.org — it does not fetch your site, so paste the file rather than a URL.

Paste the file. Copy the contents of your llms.txt (or run curl https://yourdomain.com/llms.txt) and paste it into the box on the left. Validation runs immediately, on every keystroke.
Read the errors and warnings. Each finding carries a line number. Errors break the format an agent parses; warnings are conventions worth following but not violations of the spec.
Copy the fixed version. The right-hand box holds a normalized copy: bullets, note separators and spacing repaired, everything that needs a human decision left exactly as written and flagged. Copy it back to your site root as /llms.txt.

What the validator checks

The check follows the structure of the llmstxt.org specification section by section. An error means an agent parsing the file as Markdown would misread it; a warning means the file is valid but leaves value on the table.

Rule	Level	Why
First line is an H1 (`# Site name`), and there is only one	error	The H1 is the only required section. A second H1 or a late H1 breaks the outline.
No `###` or deeper headings	error	The spec allows a title (H1) and sections (H2) — nothing else.
Every line in a `##` section is a link entry: `- [name](https://…): notes`	error	Sections are file lists. Prose belongs above the first `##`.
Link URLs are absolute and valid `http(s)`	error	An agent reads the file out of context; a relative path resolves against nothing.
No empty sections, no links without a name	error	A heading with nothing under it, or `[](url)`, gives the reader nothing.
A `>` blockquote summary follows the H1	warning	Optional in the spec, but it is the sentence that makes the links interpretable.
Duplicate URLs (trailing slash ignored)	warning	The same page listed twice usually means a copy-paste slip.
`## Optional` is the last section	warning	Convention: secondary links an agent may skip go at the end.
Bullets are `-`, notes are separated by `:`	warning	Both are what the spec's examples use; the fixed version normalizes them.
Very long H1, notes or link lists	warning	An index, not a dump: keep the title a name, the notes one line, the list short.

Why the format matters

llms.txt is a Markdown file published at the root of a domain that gives large language models a short, curated index of a site: an H1 with the site's name, a blockquote summary, optional prose, and H2-grouped lists of links that each carry a one-line description. Its consumers parse it mechanically — a coding agent or documentation tool fetches /llms.txt, splits it into title, summary and sections, and follows the links it finds. A file that breaks the outline is not "slightly wrong": the parser either drops the section it could not read or treats the whole file as prose, and the agent scrapes your site instead.

The rules are few, so the common failures are mundane. A site name written as plain text instead of # Name. A ### sub-heading copied from the docs. A paragraph of marketing under a section heading where only links are allowed. Relative links such as /docs/ that resolve to nothing once the file is read out of context. Every one of these is a one-line fix — provided something tells you the line.

What the format does not do is rank you. Google has said that Search ignores llms.txt, and measured request logs show that most published files are never fetched at all. The evidence, and who actually reads the file, is on our llms.txt explainer. Validate the file because agents reading your documentation parse it, not because a checklist told you it helps SEO.

What the fixed version changes — and what it leaves to you

The right-hand box is a normalized copy, not a rewrite. It repairs what a machine can repair without guessing your intent:

Bullets — * and + become -.
Note separators — - [Name](url) - notes becomes - [Name](url): notes.
Spacing — trailing whitespace removed, runs of blank lines collapsed to one, one blank line between blocks.
A missing title — a placeholder # Site name is inserted so the outline is valid; replace it.

It deliberately does not touch anything that needs a decision: a relative URL stays relative and stays flagged, a prose line inside a section stays where it is, a duplicate link is reported rather than deleted. The order of your entries never changes. Read the list on the left, fix those by hand, and the file will pass.

Creating an llms.txt from scratch

If you have no file yet, press Insert a minimal template. It gives you the smallest conforming shape: a title, a one-sentence summary, one section of links and an ## Optional section. Replace the example lines with yours and validate again.

For a site with more than a handful of pages, do not hand-maintain the file — derive it from the page inventory that already builds your sitemap, so the two cannot disagree about what the site contains. The generator pattern, and a worked example, are in how to generate llms.txt from a sitemap; clize.ai/llms.txt is produced that way and passes this validator.

Two checks after you publish, because they are the ones that silently fail: curl -I https://yourdomain.com/llms.txt must return 200 with a text/plain or text/markdown content type, not a styled 404 served with a 200; and the file must be reachable without a redirect to an HTML page. If your site's pages need their own machine surface too — hreflang for language versions, FAQ markup that matches the visible text — the hreflang tag generator and the FAQ schema generator are built on the same rule: one source, no drift.

llms.txt validator

How to validate an llms.txt file

What the validator checks

Why the format matters

What the fixed version changes — and what it leaves to you

Creating an llms.txt from scratch

// FAQ