LLMs.txt Curator: a free WordPress plugin for curating your llms.txt

Don’t just generate your llms.txt. Curate what it says about you.

Automatic generation is easy. The harder question is whether you agree with the output.

Curator lets you see exactly what machines receive, understand where it came from, decide what represents you, and verify that visitors are actually getting the version you published.

Automatic discovery. Human judgement. Verifiable output.

By machines we mean the AI agents, assistants and other automated systems that request llms.txt from your server. Curator’s job is to control and check what those requests get back.

You are represented immediately. Curator publishes what it finds as soon as it is activated, clearly marked as discovered automatically rather than reviewed. You then promote what you have checked, improve what needs it, and exclude what you do not want. There is no queue of two hundred pages to approve before the file exists.

The difference in one line

A generator asks: what should I put in /llms.txt?

Curator asks: what is being represented, why is it there, do you agree with it, and is that actually what visitors receive?

Those last two questions are the whole of version 2.0. Everything else follows from them.

Version 2.2 adds a third: is the page a machine receives the page a visitor sees? For every page in your llms.txt, Curator can now show you, and check.

Download LLMs.txt Curator from WordPress.org

Who this is for

Curator is for site owners, SEOs and developers who want control over how their site is represented to machines, rather than another file generated invisibly in the background.

If you want WordPress to produce an llms.txt automatically and never look at it again, you probably do not need Curator, and there are simpler plugins that do exactly that. If you want to understand, edit and verify what is being published, that is what this was built for.

What version 2.0 gives you

Grouped by the working sequence the plugin is built around: Discover, Understand, Decide, Organise, Publish, Verify.

Discover

Discovery in batches. Curator finds your public content in batches that can be paused and resumed, and it never reports a site as fully checked when it was interrupted.

A resource for everything. Every page, custom URL and standalone fact is a resource with a recorded origin and its own editorial state. That is what lets Curator answer what it is publishing, where it came from, and why.

Page-builder templates. Elementor template-library entries and similar items visitors cannot open are no longer published when found. Ones carried over from an earlier setup stay published, marked as kept from your earlier setup, until you decide.

Understand

Why? Open any resource and see the decisions behind it, separated into what Curator observed about the page and what you decided, ending with the exact line it contributes to the file.

Representation coverage, and Everything accounted for. Curator states whether every resource it found has an explained outcome. It never claims completeness before discovery has finished.

Show the whole file. Read everything machines will receive before you publish, in readable form or as exact Markdown.

Decide

Review. Everything Curator knows about, with search, filters and bulk actions, and an editorial state on each resource: kept by you, published automatically, or excluded by you.

Suggested descriptions, honestly labelled. Curator fills an empty description from what the page already publishes and names the source it used. A suggestion stays marked as a suggestion until you accept or edit it. Curator does not write text for you.

Primary resources. Mark up to ten resources as especially important for understanding your site.

Facts, custom URLs and site details. Publish a short factual statement that does not deserve its own page, or a URL Curator did not find on its own. Describe the organisation behind the site once and Curator publishes it above the first section. Where WordPress or your SEO plugin says something different, Curator shows you both and publishes your choice.

Organise

Your llms.txt. Arrange sections and resources with the result shown beside you, in readable form or as the Markdown that gets published.

Every move is also a button. Drag if you like, or use move up, move down, move to position and move to section. Dragging is convenient; it is not the only way to do anything.

Publish

Unpublished changes. When your curation differs from the published file, Curator says so and shows what changed, including the previous and current wording.

Self-checks first. If Curator finds something it cannot account for, such as a missing resource table after a partial database restore, it refuses to generate, leaves the published file untouched, and shows a diagnostic code rather than publishing an empty file.

Atomic writes. Temporary file, then rename, so no half-written file is ever served.

When to publish. Instant, roughly thirty seconds after a change, or Daily, Weekly, or only when you click Publish.

Verify

Check what visitors receive. After publishing, Curator requests your public file and tells you plainly whether visitors are getting the new version, or whether a cache or an older file is serving something else. It never records a publication that visitors are not receiving.

Optional Markdown pages. Each page in your llms.txt can also be available as Markdown at its address plus index.md, for example /about/index.md. Off by default. Excluded and non-public pages return not found.

What version 2.2 adds

Version 2.2 is called Representation and Agent Readiness. Version 2.1 was built and tested but never published on WordPress.org, so everyone updates from 2.0 straight to 2.2 and gets both. The thinking behind it is written up in Present Is Not Useful; this is what it does.

Represent

Markdown that matches the page. With Markdown pages on, Curator takes a snapshot of each page in your llms.txt as a logged-out visitor sees it, in the background, and builds the Markdown from that. Content added by page builders and block templates, which never reached the stored post, is now included. Menus, headers, footers, comments, share buttons and “more posts” lists are left out.

A better converter. Tables come out as tables, code keeps its indentation, numbered lists keep their numbers and nested lists stay nested. The same converter writes llms-full.txt and every .md address, so they always agree.

Never out of date. A snapshot is retired the moment its page, its approved comments or a synced pattern it uses changes, and the stored content is served until a new one is taken. When a post is unpublished, made private or given a password, every snapshot that links to it is retired too.

Inspect

See what machines receive, per page. Open Markdown on any page in Your llms.txt to see its Markdown version laid out for reading, exactly as served, and how it was made: whether it came from a snapshot or the stored content, which part of the page was used, what was removed and what was kept. Take a snapshot now refreshes it on the spot.

Checks for every page. A Pages group in Checks reports pages built from stored content because a snapshot failed, and why; pages with very little text; unrendered shortcodes; leftover markup; repeated text; uneven tables; and menus that leaked into the content. Check what visitors receive now also tests a sample of .md addresses for the right content type, the noindex and canonical headers, and revalidation.

Expose, read-only

Access for tools and agents. Through WordPress’s own Abilities API, signed-in tools can list what your llms.txt publishes, get a page’s Markdown exactly as its .md address serves it, and ask what changed since they last looked. With WordPress’s MCP Adapter installed, AI clients such as Claude can use the same four abilities. Everything answers from the record of what you published, never from your working curation, and anything you have not published gets one identical “not available” answer, so nothing hidden can be enumerated. No ability can change your curation, settings or what you publish. An Agents group in Checks shows whether it is working.

From 2.1, included

• Notes for machines: your own answer to “what would a machine get wrong about your site?”, published as written.
• Checks: Structure, Content, Delivery and Ownership, now joined by Pages and Agents. Observed facts, not a score.
• Ownership: anything else that answers, or could answer, /llms.txt.
• Bring in an existing llms.txt: staged for review, approved in one step, undoable.

A fix for non-Latin sites

The same release corrects a bug that had damaged Persian, Arabic, Hebrew, Hindi and some accented Latin text in every version since at least 2.0: a whitespace pattern that, in byte mode, matched a byte inside letters such as the Persian m and n. It was reported by Saeid Afshari of kabook.ir, is credited to him in the public changelog, and is now covered by a test of every character from U+0080 to U+FFFF. If the stored file on an affected site is invalid, updating publishes once to repair it.

Upgrading from 1.x carries your curation across exactly. Sections, pages, descriptions, title overrides and exclusions are migrated, and the file regenerates with the same content in the same order until you deliberately change something. Two lines move: Curator’s own comment lines now sit below the heading rather than above it, so the file begins with the H1 the llms.txt proposal asks for.

Version 2.0 requires WordPress 6.2 or later, because resources are stored in their own database table rather than a single option, which is what keeps large sites fast.

What llms.txt is, and what it isn’t

Curator makes no ranking claim for llms.txt.

Google Search ignores the file. It will not help your Google rankings and it will not harm them, and Google confirmed in June 2026 that it is fine to maintain it for other systems that do read it.

What can be substantiated is narrower and more useful:

• It gives agents already on your site a short, deliberate route through your content.
• Some surfaces do read it, such as Perplexity and coding agents.
• It forms part of Chrome’s Agentic Browsing audit.

So the honest question is not “does this rank me” but “which systems are actually reading my file”. Curator answers that from your own server logs rather than from a claim, recognising 12 known crawlers: GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended, Meta-ExternalAgent, Bytespider, CCBot, Cohere, DeepSeek and Amazonbot. IP addresses are anonymised before storage and nothing leaves your server.

Safe by default

• Both files are generated in an anonymous context. Curator renders them as a logged-out visitor rather than as the administrator who triggered the run, so content that only appears when signed in is not rendered into them.
• Restricted content is excluded. Drafts, private pages, password-protected pages and noindex pages are left out. Restriction by membership plugin is handled directly for Paid Memberships Pro, MemberPress, Restrict Content Pro and WooCommerce Memberships, and the llmscu_is_restricted filter covers any other plugin.
• Every exclusion is explained. A page left out is listed with the reason, so nothing disappears silently.
• An llms.txt this plugin did not create is never overwritten. If one is found, Curator says so and offers to replace it, writing and checking the new file before moving the original to a protected backup, and restoring the original if the swap fails.
• Nothing is sent anywhere. No telemetry, no external API calls, no cookies. The only requests Curator makes are to your own site, to check what visitors receive.

To be precise about the first two, because it is a claim about access control rather than a feature: anonymous rendering is the default, the common membership plugins are handled by name, and the filter is there for anything else. That combination is strong, and it is why the 1.5.3 release was a security release. It is not a claim that every access-control plugin ever written is understood without configuration. If you run something unusual, the filter is the supported way to tell Curator about it.

Having a description isn’t the same as having a useful description

Version 1 measured description coverage. It could tell you that 45 of your 48 pages had a description, and that felt like the right thing to measure.

Then I ran 2.0 across a real catalogue site and watched it report excellent coverage on a file that was, on inspection, close to useless. Dozens of product descriptions opened with the same line of shop furniture, a call to action repeated across the whole catalogue, because that was the first text the page actually published. Every one of those descriptions was present. Almost none of them was useful.

That is the limit of coverage as a measure, and it cuts against how version 1 sold itself:

• Version 1 asked: does this resource have a description?
• Version 2.0 asks: what representation am I actually publishing, and where did it come from?
• The next question is: is that representation any good?

2.0 did not answer the third one. It made the representation visible, which is the necessary first step, because you cannot judge what you cannot see.

2.2 is the first release that starts to answer it, at the page level. The Markdown view shows what a machine receives for each page and how it was made, and the Pages checks name the things that make a page present but not useful: a snapshot that failed, almost no text, an unrendered shortcode, repeated text, a menu that leaked in. Curator still does not score anything and still does not write anything. It shows you, and you decide. The reasoning is set out in Present Is Not Useful.

Everything else the plugin does

• Five SEO plugin integrations: Rank Math, Yoast SEO, All in One SEO, SEOPress, The SEO Framework.
• llms-full.txt: the companion file with full Markdown content for each curated page, with a size ceiling and a report of anything left beyond it.
• Description coverage reported as counts rather than a score, in the workspace and at the foot of the generated file. The list of pages still needing a description is never published in the file.
• Per-page title override: a different title for a page in your llms.txt without touching your on-site SEO.
• Format check: an on-demand check with plain-English results. Errors block publication; warnings are shown but do not.
• WooCommerce: SKU, price, stock, categories and dimensions, respecting product visibility.
• Multisite: network-activate across all sites, each managing its own independent llms.txt, with a network screen to publish any site or all of them.
• Import and export as JSON, validated and previewed before anything is written.
• WP-CLI: wp llms-txt regenerate, wp llms-txt status, wp llms-txt crawler-log.
• REST API: POST /wp-json/llms-txt/v1/regenerate, GET /wp-json/llms-txt/v1/status, plus the llms-txt/v2 resource endpoints the workspace itself uses.
• ETag and 304 handling for CDN revalidation.
• Subdirectory and Bedrock support, finding the site root correctly on non-standard installs.
• Developer filters including llmscu_capability, llmscu_post_limit, llmscu_full_max_bytes, llmscu_is_restricted and llmscu_backup_dir, plus an llmscu_regenerated action.

Why I rebuilt Curator for 2.0

Version 1 proved that generating the file is not the hard part. A script can assemble an llms.txt in thirty seconds. Once people actually started curating one, harder questions appeared, and none of them were about generation:

• What is actually in my file right now?
• Why is this page in there, and who decided that?
• Where did this description come from, and is it text I would have written?
• Has the arrangement I set up been preserved, or has something quietly reordered it?
• What will a machine actually receive, character for character?
• I clicked publish. Did it work?
• WordPress says the file is published. Is a cache serving something else?

That last pair matters more than it sounds. The most uncomfortable moment in building version 1 was a site where the admin screen said the file was live and current, and the public URL was serving a copy from months earlier. Nothing was broken in the code. The plugin had written the file, recorded that it had written the file, and told the truth as it understood it. It simply had no way of checking.

Version 2.0 was built around those questions rather than around a feature list.

Design principles

Two of these were written down early and never bent:

Displayed representation must equal published representation. If the workspace shows you a line, that is the line in the file. If it cannot be, Curator says so rather than showing you an optimistic version.

A failed publication must never advance the recorded published state. If the file cannot be written or replaced, nothing is marked as published. The plugin does not get to record a success it did not achieve.

Two more that fell out of building it:

Every exclusion is explained, so nothing disappears silently.

Detect, explain, then let the user decide. Curator does not overwrite an llms.txt it did not create, and it does not quietly win arguments with other plugins over who owns the file.

A public development record

LLMs.txt Curator is published on WordPress.org, which keeps its own independent record of every release. The chronology below can be verified there rather than taken on trust.

Version 2.0 was developed during August and September 2026, following migration, scale, security, publication-integrity and real-site testing. The work moved the plugin beyond automatic file generation and towards explicit editorial control over a site’s machine-readable representation.

Version 2.2 followed in late September and early October 2026. Its release record lists 2,075 converter checks, 262 checks of the agent layer, four rounds of independent review of the representation work and a further review of the agent layer before release, with every finding fixed and covered by a regression test. The numbers are published so they can be questioned, not because a count proves quality.

Independent references:

• Plugin page and full changelog on WordPress.org
• Release tags in the WordPress.org Subversion repository: tags/2.0.0 and tags/2.2.0
• Two fixes in 2.0.0 came from public reports on WordPress.org and are credited in the changelog: the missing H1 at the top of the file, and untranslatable strings in the admin JavaScript raised by the Persian translation editor.
• The non-Latin text fix in 2.2.0 came from a public report by Saeid Afshari and is credited to him in the changelog.

Where llms.txt sits in AI-first SEO

llms.txt is one file at the discovery layer. It tells a machine that has already arrived at your site where to look. It does not make anyone arrive, and it does not decide whether you get cited.

At SEO Strategy we call the broader discipline LLM Optimisation: making sure your brand, your expertise and your content are correctly understood by AI systems at every layer. That includes entity SEO, schema markup, authorship signals, and Generative Engine Optimisation. Curator covers one specific job within it, which is controlling and verifying what your own site exposes.

For the wider picture, see our LLM Optimisation services, the complete llms.txt guide, the AI Discovery Stack and the CITATE framework.

Free, GPL v2, requires WordPress 6.2 or later and PHP 7.4 or later.

Download LLMs.txt Curator from WordPress.org