llms.txt is a proposal for a markdown file at a site's root that gives a language model a curated, human-chosen map of what matters on the site. SiteRank AI drafts one from your actual content, validates it against the published format, shows you the exact bytes before anything is served, and lets you take it back down in one click. What it will not do is tell you that publishing one will get you cited.
What the format actually specifies
Verified against llmstxt.org on 9 September 2026. The format is deliberately small.
The file lives at /llms.txt, or at any subpath — a file covers the URLs beneath its own path, and where more than one applies, an agent should use the most specific.
Its structure is sequential:
- An H1 naming the project or site. This is the only required element.
- A blockquote summarising the site, with the context needed to understand the rest. Optional, strongly recommended.
- General content — paragraphs and lists, but no headings — giving further detail.
- Zero or more H2 sections, each containing a markdown list of links in the form
[name](url), optionally followed by:and a note about the file.
One section name is special by convention: ## Optional marks secondary information — links an agent can skip when a shorter context is needed. That is the only prioritisation mechanism the format has, and it is worth using properly.
The proposal separately recommends serving a clean markdown version of pages agents might need, at the same URL with .md appended or the extension replaced.
Adoption is real and documented on the specification site: thousands of sites publish one, several major AI companies use it for their own developer documentation, and Chrome's Lighthouse audits for its presence as part of its agentic browsing checks. llms-full.txt is widely discussed in the field but is not part of the specification text — treat it as a community convention, not a standard.
Drafting from your own corpus
The generator does not write prose about your site. It assembles a candidate file from what the content scan already found: your site title and tagline for the H1 and summary, and your pillar candidates, key pages and highest-connectivity documents as the link sections, each with the page's own description as the note.
That is a starting point, not an output. The whole value of this file is that a human chose what belongs in it — an automatically generated list of your fifty most recent posts is a sitemap with worse syntax. The draft is fully editable in the admin, and edits are preserved: regenerating never silently overwrites a file you have hand-written.
Validation
The validator runs against the draft before you publish and reports issues with a severity and an evidence tier attached.
It checks the structural rules the format states: exactly one H1, present and singular; a summary blockquote where one is expected; sections that contain links rather than sitting empty; and links that parse as usable markdown hyperlinks with absolute URLs. It flags a file with sections but no links, because an llms.txt pointing at nothing gives a reader nothing to follow. It enforces a 100KB ceiling, on the grounds that a file too large to fit in a context window is not doing the job the format exists for.
It also cross-checks every listed URL against the corpus the last scan observed, which catches the two failure modes that matter most: a link to a page that returns something other than a 200, and a link to a page your own site marks noindex. Recommending a page to an agent that you have told search engines to ignore is a contradiction worth catching before it ships.
One deliberate limitation: this check makes no HTTP requests of its own. It reports what the last scan saw. A URL the scan never visited is reported as unknown, not as broken — absence from the corpus is not evidence of a 404, and this product does not report what it did not observe.
Preview, publish, unpublish, history
Four states, four explicit actions.
Preview renders the exact bytes that would be served, not an approximation of them. If a byte is going to be public, you see it first.
Publish makes the file live at /llms.txt. It is served virtually through WordPress rather than written to disk, so there is no file to leave behind, no permissions problem on a read-only deployment, and nothing for a future deploy to clobber. If a physical llms.txt already exists on disk, that file wins and the plugin tells you rather than quietly losing to it.
Unpublish removes the live file immediately. Your draft is untouched, so taking it down is not a decision to start over.
History is the append-only activity log: each draft save, each publish and each unpublish is recorded with its timestamp and the WordPress user who did it. The published version and the working draft are held separately, so the admin can always tell you that you have unpublished changes — and can tell you what they are.
Nothing here happens on a schedule or on activation. A file that appears at your site root because a plugin decided it should is exactly the behaviour this product exists to avoid.
What you cannot claim about it
This section is not a disclaimer. It is the reason the feature is built the way it is.
Publishing an llms.txt is EMERGING PRACTICE. The format itself is a published, stable specification — that part is settled — but the effect of publishing one is not.
No AI provider has documented that it reads /llms.txt, prefers sites that publish one, or uses it as a retrieval or ranking input. Presence of the file is not evidence of ingestion, ingestion would not be evidence of retrieval, and retrieval would not be evidence of citation. The chain from crawled to retrieved to cited to recommended is unbroken by this file.
So SiteRank AI does not score a missing llms.txt as a deficiency, does not phrase adding one as a fix, and does not present it as a requirement. It sits in the interface as an optional, clearly labelled emerging practice, visually separated from standards compliance.
The honest case for publishing one is narrower and still worth making: it costs almost nothing, it is a genuinely useful curated index for any agent or human that finds it, and writing it forces you to decide which pages on your site actually represent it. That last effect is the one you can count on.
Official sources & further reading
- The /llms.txt file — Jeremy Howard / Answer.AI
Related reading
Frequently asked questions
Is there any downside to publishing one?
The real cost is maintenance rather than risk. A curated file goes stale the moment the pages it names are renamed, retired or replaced, and a list pointing at URLs that no longer resolve is worse than no list at all — which is why the validator cross-checks every link against the corpus the last scan observed. The other cost is psychological: publishing the file feels like finished work, and it is not the same as having pages worth pointing at. If you are not willing to revisit it when your site changes, do not publish it.
Do I need an llms-full.txt as well?
Not to comply with anything — it is not part of the specification text, so treat it as a community convention rather than a standard. No provider has documented that it reads either file, so a second, larger one adds a second thing to keep accurate without any evidence that it buys you more. If the curated file is genuinely useful to a reader, start and stop there.
Does this replace my sitemap?
No, they are different artefacts doing different jobs. A sitemap is a machine-generated enumeration for crawl discovery; an llms.txt is a short, human-chosen index of what represents your site, and the format specifies nothing but that structure — no access directives, no crawl instructions, no permissions of any kind. Publishing one changes nothing about what any crawler is allowed to fetch. If the file ends up listing your fifty most recent posts, you have written a sitemap with worse syntax.
How would I know whether anything is actually reading it?
You would not, and neither would we. A request for /llms.txt in your access log tells you the bytes were fetched, which is not the same as the content being ingested, retrieved or used for anything — and no provider documents its handling of the file either way. SiteRank AI reports what it observes, so it does not show an ingestion figure, an adoption score or an estimate of effect. Where the honest answer is that this is not known, the interface says that rather than filling the gap with a number.
How often should I regenerate the draft?
When the pages it points at change — a new pillar, a retired section, a URL that moved. Regenerating assembles a fresh candidate from the current scan and never silently overwrites text you have hand-written, so you can re-run it without losing your editing. Nothing regenerates or republishes on a schedule; every change is an action you take, previewed byte for byte before it is served.