llms.txt returns 404 on WordPress.com — and it didn’t matter

I wanted a page on this site written for machines. Not a hidden page and not a trick — just an index an AI could ingest cleanly and cite. The first thing I reached for was llms.txt. It 404s here. So does every variant of it.

The short version, for anyone who arrived from a search about llms.txt: it is a proposed standard with no confirmed adoption by any major AI provider, it cannot be served from a WordPress.com root, and the page you already publish matters more than the file you cannot.

Is a page written for AI actually a thing?

Three separate things get bundled under that question, and only one of them has controlled evidence behind it.

• llms.txt — a proposed root-level markdown index. As of August 2026 there is still no official centralized resource for it and no major provider has documented that it reads one. Google has said it is not required and compared it to the keywords meta tag.
• Markdown twin endpoints — serving page.md next to page. This one is real and shipping: PostHog and Mintlify both do it. Neither publishes numbers on how often those endpoints are actually fetched.
• Content shape — writing the page itself so a passage survives being lifted out of it. Aggarwal et al. (KDD ’24) tested nine strategies and found citations, concrete statistics and quotations from credible sources transfer to generative-engine visibility. Keyword stuffing does not. The often-repeated “+40%” is a ceiling on one metric, not an average.

Only the third one is a lever. The first two are plumbing, and one of them I could not install.

Why did llms.txt 404?

I probed four paths from a logged-out fetch: /llms.txt, /llms-full.txt, /history.md, and /history/index.md. All four returned 404 and served the site’s HTML error page. This is not a plugin gap. It is the same root-file constraint on this host that already blocked IndexNow and BingSiteAuth.xml — I cannot put an arbitrary file at the domain root.

What is the machine-readable twin you already have?

While confirming the 404s I fetched /wp-json/wp/v2/pages/385 and got a 200 with application/json, no auth required. Every page and every post on this site already has one of those. It is structured, it is versioned, it carries the raw content, and it has been public the whole time.

That is a better artifact than llms.txt would have been, and it cost nothing, because WordPress built it years before anyone proposed a standard for it.

How do you keep the schema honest?

Last month I found that this site’s About page declared FAQPage structured data with three questions while showing zero questions to a human reader. That is a guidelines violation, not a missed opportunity, and it happened because the markup and the schema were written by hand at different times.

The fix is not vigilance. It is structure: generate the visible HTML and the JSON-LD from one array in the same pass. Then a mismatch is not unlikely, it is impossible to express.

I rebuilt this site’s history index that way — 33 devlog entries pulled from the REST API, driving both the visible list and an ItemList in structured data. The gate is content equality in both directions: every headline in the schema must appear as visible link text, and every visible entry must appear in the schema. Not matching counts. Two lists of 33 can both be 33 and still disagree about what is in them.

What did the dates get wrong?

Six of those 33 posts land on a different calendar day in GMT than they do in local time. If I had rendered the visible dates from date_gmt, six entries would have silently shown the wrong day.

So the display dates come from the site’s local timestamp and the structured data carries a full datetime with a -05:00 offset. Worth knowing: a date-only string like 2026-08-05 is a perfectly valid schema.org Date, passes any ISO check you write, and still gets reported as an invalid datetime for the types that want a full one.

Should robots.txt name the AI crawlers?

Mine does not. It is 162 bytes, it declares two sitemaps, it disallows /wp-admin/, and it mentions no AI agent at all. I left it that way on purpose.

Providers now run separate crawlers for training and for answering. Blocking GPTBot, ClaudeBot or Google-Extended removes you from training data. Blocking OAI-SearchBot or PerplexityBot removes you from answers. Those are different decisions and people conflate them constantly. If the goal is to be readable by an assistant, the file to leave alone is this one.

What nearly shipped as a bug?

During the audit I flagged that the index listed 18 project pages while 19 existed. I was wrong. Two of the 19 are unlaunched and deliberately unlinked, so the visible count was correct and my denominator was not. I caught it before it reached a write, but only because I checked the two names instead of trusting the subtraction.

A count you produce is a claim, not evidence. That applies to the ones that confirm your suspicion just as hard as the ones that do not.

Where this landed

I set out to build a page for AI to read and ended up not building a page at all. The file I wanted was unavailable, the endpoint I needed already existed, and the only change worth making was to the page a human was already reading.