FictionalWPSEO is in decent shape by this point: clear product information, structured public documentation, a documented PHP API, predictable hooks and filters, and AGENTS.md for coding agents working inside the project. Now for one of the most talked about ideas in AI-readable websites: llms.txt.
Should a premium WordPress plugin website have one? Probably yes, but not for the reason a lot of people think. llms.txt is a useful emerging convention for presenting important site content in a clean, structured way. It’s not a magic file that makes ChatGPT, Claude or anything else recommend your plugin. That distinction matters.
What is llms.txt
It’s a proposed convention for publishing a markdown file, usually at https://example.com/llms.txt. The spec describes a simple structure: a project or site title, an optional short summary, and grouped links to important resources. A normal site has a homepage, pricing, features, blog posts, documentation, comparison pages, support pages, API docs, changelog, terms, marketing campaigns. An AI system trying to understand the site doesn’t need all of that. llms.txt lets us say: these are the pages that actually matter for understanding this product. A curated map.
It isn’t robots.txt for AI
You’ll see it described as “robots.txt for AI.” Useful shorthand, but a bit misleading technically. robots.txt is about crawler access rules. llms.txt is about context and content discovery, it doesn’t control whether a crawler can access your site, and it doesn’t replace robots.txt, an XML sitemap, canonical tags, normal internal linking, or structured HTML. OpenAI’s current publisher guidance says public sites can appear in ChatGPT search and specifically recommends not blocking OAI-SearchBot if you want content discoverable and surfaced in summaries or snippets. That’s a crawler access issue. llms.txt is a different layer entirely.
What FictionalWPSEO’s file might look like
At https://fictionalwpseo.com/llms.txt:
# FictionalWPSEO
> FictionalWPSEO is a premium WordPress SEO plugin for site owners,
> agencies and developers. It provides SEO metadata, XML sitemaps,
> Schema.org markup, redirects, WooCommerce SEO and developer APIs.
## Product
- [Product Overview](<https://fictionalwpseo.com/product-information/>)
- [Features](<https://fictionalwpseo.com/features/>)
- [Pricing](<https://fictionalwpseo.com/pricing/>)
## Getting Started
- [Installation](<https://fictionalwpseo.com/docs/getting-started/installation/>)
- [Quick Start](<https://fictionalwpseo.com/docs/getting-started/quick-start/>)
## Developer Documentation
- [PHP API](<https://fictionalwpseo.com/docs/developers/php-api/>)
- [Hooks and Filters](<https://fictionalwpseo.com/docs/developers/hooks/>)
- [REST API](<https://fictionalwpseo.com/docs/developers/rest-api/>)
## SEO Features
- [SEO Metadata](<https://fictionalwpseo.com/docs/seo-metadata/>)
- [Schema](<https://fictionalwpseo.com/docs/schema/>)
- [XML Sitemaps](<https://fictionalwpseo.com/docs/sitemaps/>)
- [Redirects](<https://fictionalwpseo.com/docs/redirects/>)
- [WooCommerce SEO](<https://fictionalwpseo.com/docs/woocommerce/>)
## Examples
- [Custom Post Type SEO](<https://fictionalwpseo.com/docs/examples/custom-post-type-seo/>)
- [WooCommerce Product Schema](<https://fictionalwpseo.com/docs/examples/woocommerce-product-schema/>)
- [Generate SEO Titles from ACF Fields](<https://fictionalwpseo.com/docs/examples/acf-seo-title/>)
## Reference
- [Compatibility](<https://fictionalwpseo.com/docs/requirements/>)
- [Changelog](<https://fictionalwpseo.com/changelog/>)
- [Known Limitations](<https://fictionalwpseo.com/docs/limitations/>)That’s really all it needs to be.
What we left out matters
We didn’t dump every URL on the site. If the site has 800 pages, blog archives, author archives, marketing campaigns, old announcements, checkout pages, a privacy policy, affiliate pages, a file with all 800 links isn’t useful. We already have an XML sitemap for broad URL discovery. The value of llms.txt is that we curate: what is this product, what does it do, who’s it for, requirements, limits, pricing, how developers integrate, which APIs exist, examples, current version.
Think of it as a table of contents
Your documentation is the book. llms.txt is the table of contents, not a replacement for the book. If our file says [Developer Documentation](...) and that page is vague marketing text with no real API detail, we haven’t achieved much, the file is only as useful as the content it points to. This is why we built the documentation first in this series, before generating llms.txt we’d just have created a machine-readable map to mediocre content. The format isn’t the strategy. The information is the strategy. The format just helps systems access it.
Should WordPress generate it automatically
There are already WordPress plugins that generate and manage llms.txt, including some that support curation, WooCommerce, custom post types and llms-full.txt. For a normal content site, automatic generation can work well. For a product documentation site, I’d be more careful, I don’t want every post and page dumped in, I want the best entry points. Either maintain it manually or generate it from a curated list:
$llms_pages = [
'product-information',
'pricing',
'docs',
'developers/php-api',
'developers/hooks',
'developers/rest-api',
'woocommerce',
'schema',
'changelog',
];Generate the file from those canonical pages. Reduces maintenance without turning it into another sitemap.
What about llms-full.txt
The general idea: llms.txt is a short map, llms-full.txt is a much larger consolidated document. For FictionalWPSEO, a full file might contain selected documentation in one large markdown file, product overview, requirements, PHP API, hooks, REST API, Schema documentation, WooCommerce documentation, examples, limitations. Would I create it? Probably, if it can be generated reliably. I’d treat it as optional though.
Be careful with huge full files
If documentation grows to several hundred pages, combining everything into one file can become huge, slow to generate, expensive to process, hard to keep updated, and full of irrelevant context. Curation matters again. Maybe llms.txt plus a smaller set of topic-specific markdown resources, /docs/ai/php-api.md, /docs/ai/schema.md, /docs/ai/woocommerce.md. Implementation can evolve. The principle is: make high-value information easy to retrieve without forcing a system to process the whole site.
Don’t put private documentation in it
FictionalWPSEO is paid, and some documentation might exist only for licensed customers, private support procedures, account information, customer-specific integrations, internal release notes, restricted downloads. None of that belongs in a public llms.txt. A clean file points to resources an anonymous visitor can actually access. Some WordPress llms.txt tools already exclude non-public content for exactly this reason.
Don’t put secrets in llms-full.txt either
Automatic generation changes the risk. If your site has private pages, draft documentation, customer-only knowledge base articles, restricted custom post types or products, a generator needs to respect visibility, or you accidentally create a public text endpoint exposing information that was never meant to be public. Treat generated AI-facing files exactly like any other public endpoint. Review what they expose.
Does every plugin need one
I wouldn’t say every plugin needs it. A tiny plugin with one landing page and a README doesn’t get much value from it. A serious premium plugin with large documentation, multiple integrations, developer APIs, use cases, comparison pages, pricing, a changelog, and tutorials has a much stronger case. Implementation cost is low, so for FictionalWPSEO I’d add it. But I’d rank priorities as: good product, clear public product information, excellent documentation, stable developer APIs, a crawlable website, external authority and mentions, and only then llms.txt. Not the other way around, hoping the file does the work of the product.
Does ChatGPT actually use it
Worth being careful with the claim here. The existence of the convention doesn’t mean every major AI system uses it for discovery or ranking, and I wouldn’t write marketing copy claiming otherwise unless a provider directly says so. As of now, OpenAI’s public guidance for getting content into ChatGPT search focuses on public accessibility and crawler controls like allowing OAI-SearchBot, not on llms.txt. My honest position: it’s a sensible, low-cost emerging convention for presenting important resources to systems that choose to consume it. That’s reason enough to use it. No need to invent a stronger claim.
Does it help rankings
There’s a dangerous assumption floating around: add llms.txt, AI reads the site, AI ranks the product higher. No reason to assume that sequence. Even if a system reads FictionalWPSEO’s file perfectly, it learns FictionalWPSEO exists and supports these features, useful, but if the question is “what’s the best WordPress SEO plugin,” the system still has to weigh product quality, reputation, reviews, independent references, market adoption, documentation, security history, pricing, and fit. Our own llms.txt can’t prove any of that. It’s a first-party source, and every company thinks its own product is wonderful. We’ll get into authority properly later in the series.
Should marketing claims go in it
If the homepage says “the fastest WordPress SEO plugin,” should that go in llms.txt? I wouldn’t. Prefer factual statements:
> FictionalWPSEO is a premium WordPress SEO plugin supporting
> metadata, Schema.org markup, XML sitemaps, redirects,
> WooCommerce SEO, PHP APIs and REST API access.That’s a description. If we have real benchmarks, link to them instead of asserting the claim directly. Let evidence support claims.
Should pricing be in it
For a commercial plugin, yes, though probably not the whole pricing table since prices change. I’d include the canonical pricing page: [Pricing](<https://fictionalwpseo.com/pricing/>). That gives automated systems a reliable current source rather than encouraging them to repeat stale numbers from old reviews.
Should comparisons be in it
Potentially, but comparison pages need to be genuinely factual, which we’ll get into later. A first-party comparison is useful structured information, but it shouldn’t be treated as independent evidence.
WordPress can generate this easily
From a development standpoint this is simple. A rewrite rule, a query var, and a template redirect that outputs the markdown as plain text. Not complicated code. The real work is deciding which pages deserve inclusion, which page is canonical, whether the information is accurate and current, whether private resources are excluded, whether documentation URLs stay stable, and whether the linked pages actually answer useful questions. Content architecture, not a rewrite rule.
What FictionalWPSEO has now
At this stage the site might expose a curated llms.txt pointing to product information, pricing, requirements, documentation, the PHP API, hooks, REST API, Schema, WooCommerce, examples, the changelog, and limitations. Sensible addition. But another file on the site may matter more for whether these pages are even reachable in the first place: robots.txt. If we accidentally block the crawler, a beautifully curated llms.txt doesn’t help much. So next we move away from documentation and into the technical discoverability of the site itself.
Next: robots.txt for the AI Era