llms.txt On WordPress: We Measured Twelve Sites, And Ours Were The Worst.

Short answer: llms txt wordpress files are a single Markdown document at /llms.txt that gives an AI agent a short, curated map of your site. It is a proposal rather than a standard. It is trivial to add. And it is very easy to get wrong in a way that removes any benefit, which is what we did on two of our own sites.

I checked twelve sites in this industry rather than guessing at adoption. Here is what came back.

Who actually has an llms txt on their WordPress site

sitec.example’s is roughly forty times the size of the file on wordpress.org.*

Site	llms.txt	Size
wordpress.org	present	5.8KB, 36 links, a curated index
sitea.example	present	2.3KB, 12 links
yoast.com	present	7.7KB
kinsta.com	present	9.5KB
patchstack.com	present	15.2KB
elementor.com	present	15.5KB
siteb.example (ours)	present	119.8KB, far past “fits in context”
sitec.example (ours)	present	212.5KB, 679 lines, 662 links
woocommerce.com	absent	none
wpengine.com	absent	none
rankmath.com	absent	none
sited.example (ours)	absent	none

Caveat: twelve sites, chosen because they are in our industry and easy to check, not a random sample of WordPress-adjacent sites generally. I would not generalise an adoption percentage from this. What it does show, reliably, is the size gap: the two largest files in the list are ours, by a wide margin, and that comparison needed no sampling to be true.

I counted a 200 that returns HTML as absent, because several sites answer every path with their normal 404 page at status 200. If you check this yourself, look at the body rather than the status code.

error page, not a missing file. A status-only check would have recorded several of these as present.*

Our own good example has started down the same path

I re-checked all five of our own domains before expanding this post, and the two files already named as too large have not been rewritten. siteb.example sits at 120,105 bytes, 212,742 for sitec.example, both essentially unchanged from the original reading. “On the list to rewrite by hand” has not happened.

The more interesting finding is sitea.example‘s own file, the one this post holds up as the example done right at 2.3 KB and 12 links. It is now 8,077 bytes with 33 links:

curl -s https://sitea.example/llms.txt | grep -c "^- ["

33

Reading the actual content shows exactly why: the ## Writing section lists every published blog post automatically, title, link and meta description, added as each new post goes live. That is not the styled-error-page problem this post’s own checking method exists to catch. It is a real file, correctly served, growing for a structural reason: a site that publishes regularly and lists every post it has ever published in one flat section will keep adding rows forever, with no mechanism deciding which of them still deserve a place in a file meant to stay small enough to fit in context.

Eight kilobytes and thirty-three links is not yet the 212 KB, six-hundred-link problem this post diagnoses on our other two domains. It is the same mechanism, caught earlier, before it became unusable. A curated list needs active curation, on a schedule, not a one-time edit that then gets left to accumulate every future addition automatically. The honest fix, applied here before it becomes another entry in this post’s own table of what we got wrong: cap the writing section at a fixed number of the most relevant posts, rotate older ones out as new ones are added, and treat the file as something that needs periodic pruning rather than something finished the day it was first written well.

What the file is supposed to be

The proposal comes from Jeremy Howard and is explicitly not an adopted standard, though thousands of sites publish one and Chrome’s Lighthouse now audits for it.

Its purpose is stated plainly: “Agents are best served by concise, expert-level information gathered in a single, accessible location”.

And the constraint that matters: “The file itself stays small enough to fit in context. The detail lives behind the links, and is fetched only when needed”.

That last sentence is the whole design. It is a map, not the territory.

specification. It is a short document by design.*

Where we went wrong

thing the format exists to do.*

The proposal says	wordpress.org	sitec.example (ours)
concise, single accessible location	5.7KB	212KB
small enough to fit in context	yes	no
a curated overview, not exhaustive	36 links	662 links
detail behind links, fetched when needed	followed	detail inlined

Nobody did anything careless here. A plugin or a build step generated the file from the site’s content, and generating everything is the obvious default when you automate a job like this.

But the value of llms.txt is entirely in the curation. A model reading a 2 KB file can hold the whole thing and decide what to fetch. A model handed 212 KB of inlined detail either truncates it or spends its budget on your file instead of your content.

Both of ours are on the list to rewrite by hand. Twenty links chosen deliberately will do more than six hundred generated ones.

This is a pattern I keep running into while writing these posts. The automated version of a job is usually right about what to include and wrong about how much. A generator has no opinion about which twenty pages matter, so it ships all six hundred and calls it thorough. Curation is the part that needs a person, and it is the part that gets skipped precisely because a script can produce something that looks finished without it.

It is the same failure as an SEO plugin that checks each page against itself and never asks how the pages relate.

What to put in it

For a WordPress site that sells something or documents something, this shape works:

# Site Name

> One paragraph saying what this is, who it is for, and what is true today.

Any context a reader needs before following a link. Pricing model, what is
free, what is not shipped yet.

## Documentation
- [Getting started](https://example.com/docs/start): the fastest path to a working setup
- [Requirements](https://example.com/docs/requirements): what the site needs to run

## Product
- [What it does](https://example.com/features): the capability list, current as of today

Three rules I would apply after doing this exercise:

Cap it. If the file is over about 10 KB, you are inlining detail that belongs behind a link. Generate a candidate list if you like, then cut it by hand.

Say what is not true yet. Ours states that the Super Agents are built and not released. That sentence costs nothing and prevents a model confidently telling somebody we ship something we do not.

Date it, or do not claim currency. A stale llms.txt is worse than none, because it presents itself as authoritative.

Point at pages, not at PDFs and downloads. The links are there so an agent can fetch detail cheaply. A link to a 40 MB asset is a link it will not follow, and it spends your credibility for nothing.

The four well-curated reference files did not grow at all

Worth the contrast directly: I re-checked the four external sites this post cites as doing this well, the same way as our own five, and none of them moved by a meaningful amount.

Site	Original reading	Re-checked
yoast.com	7.7 KB	7,682 bytes
kinsta.com	9.5 KB	9,497 bytes
patchstack.com	15.2 KB	15,182 bytes
elementor.com	15.5 KB	15,451 bytes

Flat, stable, no drift, across every one of the four. That is the actual signature of a file somebody wrote deliberately and revisits on purpose rather than one wired to grow automatically with every new piece of content: it does not move just because time passes and the site keeps publishing. Our own sitea.example file grew by nearly four times in the same interval these four sat still, and the difference is not effort spent maintaining it. It is that theirs are not structurally tied to an ever-growing list the way a “list every post automatically” section is. Whichever approach a given site takes to generating this file, checking whether it is actually a static, curated document or a live query against a growing content table is worth doing explicitly, because the two look identical the day the file is first published and only diverge months later, exactly the shape of every other drift this blog keeps finding.

Is it worth doing at all

Honestly: the evidence that llms.txt changes anything is thin. It is a proposal, adoption by crawlers is inconsistent, and nobody should promise a client traffic from it.

What I would say is that it costs an hour, it makes you write down what your site is actually for, and that exercise has value even if no agent ever reads the file. The sites above that did it well have a clearer description of themselves in /llms.txt than on their homepage.

Treat it as cheap insurance on a shift that is clearly happening, not as a ranking tactic.

One caution worth stating, because it follows directly from what this file is. An llms.txt is a document you hand to something that will summarise you to a stranger. Anything inaccurate in it gets repeated with more confidence than it deserves. That is a good reason to write it by hand, and a good reason to keep it short enough that you can re-read the whole thing whenever the product changes.

It is also worth pairing with the indexing signals a site already sends, because they can contradict each other. A site that publishes a friendly llms.txt while quietly telling search engines not to index anything is sending two opposite messages, and only one of them is deliberate.

Protuno’s free audit checks for the presence of llms.txt from the domain alone, alongside the sitemap and robots.txt, which is how I built the table above. Straight with you as on every post here: Iris, the SEO agent that would keep this current, is built and named but not live yet.

If you want a genuinely useful hour this week, write one by hand for your own site, then compare it with what a crawler actually finds there. The gap between the two is usually the more interesting document.

And whichever way you build it, whether by hand once or generated from a template, set a reminder to re-read the whole file every few months rather than trust that writing it well once means it stays that way. Ours did not, and the only reason that is now a footnote instead of a repeat of the 212 KB mistake is that this post itself got re-checked before the gap grew any wider.

The mechanical part, if you would rather not write it by hand

Covers the plugin-assisted route. Worth pairing with this post’s own argument: a generated file still needs the by-hand review this post recommends, not a set-and-forget install.