What it measures

This check grades your llms.txt against the specification at llmstxt.org. It is not a presence check. We fetch the file, parse it, and score how well an AI agent could actually use it: whether it has the required heading, whether it summarises your site, whether the links use the parseable list format the spec defines, and whether those links lead to content that is cheap for a model to read.

What llms.txt is, and what it is not

llms.txt is a curated index of your site, written for language models. An agent that needs to answer a question about your product reads it, picks the relevant links, and fetches those.

It is not an access-control file. It has no blocking directives and never has, in either version of the spec. Controlling which crawlers reach your content is the job of robots.txt. The two answer different questions: robots.txt says what a crawler may fetch, llms.txt says what is worth fetching.

The structure the spec defines

The spec fixes the order, and that is what makes the file parseable:

1. An H1 with your site or project name. This is the only required section.
2. A blockquote holding a short summary, carrying the context an agent needs to read the rest.
3. Optional prose. Any markdown except headings.
4. Optional H2 sections containing file lists.

Each file list is a markdown list. Each entry is a link, optionally followed by a colon and a short description:

# Acme Widgets

> Acme sells industrial widgets and publishes a full API reference.

## Docs

- [Quick start](https://acme.com/docs/start.md): Install and make your first call
- [API reference](https://acme.com/docs/api.md): Every endpoint, with examples

## Optional

- [Changelog](https://acme.com/changelog.md): Release history back to 2019

That "Optional" heading is a convention for secondary links. In v1 it told context-expansion tools what to drop. v2 removed that machinery, so it now reads as a hint and nothing more.

Point your links at markdown

Version 2 of the spec, published in August 2026, made this the central expectation: links in your llms.txt should lead to content a model can read cheaply, not to HTML pages wrapped in navigation and scripts.

Serve a markdown version of each page at the same URL, either by appending .md (page.html.md) or by replacing the extension (page.md). v1 allowed only the first form; v2 allows both. For URLs with no filename, use index.md or index.html.md.

Let agents find the file

v2 added link relations so an agent does not have to guess. rel="alternate" type="text/markdown" points at a page's markdown version, and rel="describedby" points at the llms.txt covering that page. Either can be an HTML <link> element or an HTTP Link: response header:

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

The header form also covers non-HTML files and can be set at your CDN without touching a single page. It matters because llms.txt does not have to sit at your root: a file at /docs/llms.txt covers everything under /docs/, and where several apply, agents use the most specific one.

What the grades mean

Grade	What it means	Score
No file	Nothing at /llms.txt, and nothing declared through rel="describedby"	0 of 4
Does not follow the spec	No H1, or no file lists at all, so agents cannot parse it	1 of 4
Follows the spec	The structure is correct and parseable	3 of 4
Follows the spec, links to markdown	Every link described, and most point at markdown versions	4 of 4

We check coverage separately: whether your homepage, landing pages and product pages appear in the file, and whether any listed page has stopped resolving. Links to other sites never count against you. The spec names them as a reason llms.txt beats sitemap.xml, which cannot reference anything off-domain.

A note on llms-full.txt

Some sites publish llms-full.txt next to llms.txt, holding full page text rather than links. It is a community convention and has never appeared in the spec. We report it when we find it and treat it as a bonus, never a requirement.