llms.txt is a plain Markdown file that sits at the root of a domain and lists a site's most useful resources for language models in a predictable order, and you can create an llms.txt file in WordPress by drafting it locally with a structured generator, reviewing the links, and uploading the finished text to your site's document root. The format was proposed at llmstxt.org and described in the Answer.AI llms-txt reference repository: one required H1, an optional blockquote summary, optional free-form details, and zero or more H2 sections containing Markdown link lists. WordPress does not generate the file automatically, does not surface it in Settings, and does not require a plugin. You compose the text in a browser, validate it against the documented order, and publish the file yourself at /llms.txt. The rest of this guide walks through that workflow with attention to the limits that matter on a WordPress install.
What llms.txt Actually Is on a WordPress Site
The file proposal lives outside WordPress core and outside any SEO plugin's default surface. It is a single plain-text document that follows one structure: a single H1 with the site name, an optional blockquote that summarizes the project, optional details that sit between the summary and the first H2, and any number of H2 sections that group Markdown links to canonical resources. Each link line is required; an optional colon and note can describe what the resource contains. The Optional H2 section, when used, identifies secondary material that a language model can skip when a shorter context is needed. Order matters because the file is intended to be predictable for both models and parsers, so the generator enforces H1 first, then summary, then details, then ordered link sections. WordPress gives you none of this out of the box: there is no llms.txt field under Settings > Reading, no menu item, and no REST endpoint that emits the file. The file you publish is your responsibility, which is why a transparent local generator is a safer starting point than a tool that silently crawls your install.
Why Drafting Locally Beats Crawling WordPress
Automated tools that promise to scan your WordPress site and build llms.txt face real limits on a dynamic CMS. They cannot prove which post slugs are canonical versus archived, which pages are private versus public, which product URLs redirect, or which Markdown variants your server reliably serves. The result is often a draft that lists duplicate or stale URLs, repeats the overload of a large sitemap, or surfaces drafts you did not mean to recommend. The llms.txt Generator takes a different route: nothing is crawled, nothing is sent to an external service, and you enter every link by hand. That manual step is the point. You decide what counts as canonical, you write the summary, and you confirm which resources belong in the Optional section. The same input discipline applies whether you run a self-hosted WordPress install, a managed host with restricted file access, or a WooCommerce storefront where the sitemap alone exceeds a thousand entries.
Build the Draft in the Right Order
- Open the llms.txt Generator and enter the site or project name exactly as you want it to appear in the H1 line of the file.
- Add an optional blockquote summary that states what the site is and who it serves in one or two sentences, then add free-form details only when they add context that the summary cannot carry.
- Create H2 sections with clear names, then enter only the canonical URLs you have personally verified, paired with short labels and an optional note that describes the linked page.
- Reserve an H2 named Optional for genuinely secondary material such as changelogs, archives, or marketing pages that should be skipped when context is short.
- Click Generate and review the deterministic Markdown output line by line, paying attention to the order, the heading hierarchy, and the link text.
- Copy the result to the clipboard or download the file named llms.txt, then open it in a text editor for a final content review before upload.
Publish llms.txt on a WordPress Site
There is no WordPress admin button that publishes llms.txt, so the deployment choice depends on your file-access surface. The simplest path is a file manager or FTP and SFTP client: upload the validated llms.txt to the directory that maps to your site's document root, which is normally the same folder that contains wp-config.php and the wp-content directory. Confirm the URL by opening https://yourdomain.com/llms.txt in a private browser window and checking that the response is the raw text, not a 404 page rendered by WordPress. If your host serves WordPress through a reverse proxy or a managed panel that hides the root, use the panel's file manager or ask support to place the file. Several SEO plugins, including popular WordPress SEO suites, accept a static file upload through their file-editor module; the file still lives at /llms.txt and is not stored inside the database, so removing the plugin does not delete it.
A third option is to emit llms.txt dynamically from a WordPress filter, which is useful when you want one canonical map of pages without hand-editing the file after every publish. The most common implementation hooks the template_redirect or init action, sets the content type to text/plain, prints the same H1-first Markdown the generator produced, and exits before WordPress renders its 404 template. If you go this route, serve the static file you validated rather than rebuilding the Markdown on every request, and confirm the static route still wins when a caching plugin is active. Do not paste the llms.txt body into a WordPress page or post; search and AI tools will treat it as HTML and the Markdown link list will not parse. For a comparison of how this static file relates to the one WordPress generates on its own, see how to publish robots.txt in WordPress without a plugin, which uses the same document-root principle.
Validate the Final Draft
Validation is a separate mode in the llms.txt Generator and it is worth running before and after any hand edit. Paste the draft back into the validator and check that the tool reports a single H1, that the summary sits in a blockquote, that details appear before the first H2, that every link line uses the Markdown list syntax, and that no duplicate normalized URL appears twice in the file. The validator also flags oversized drafts, and it reports each issue against a concrete line so you can fix the source rather than guess. HTTP and HTTPS URLs are accepted; credential-bearing URLs and executable or embedded-data schemes are rejected, which protects the file from leaking tokens or triggering unsafe downloads. Labels, notes, headings and summaries are normalized so control characters cannot break the generated structure. Validation success means the draft matches the tool's documented interpretation of the current proposal. It does not certify that any specific vendor reads llms.txt, that the file will be requested, or that the linked pages are accurate. Treat the validator as a structural check, not a discovery test.
Periodically Verify After Publishing
Publishing llms.txt is the start of a maintenance loop, not the end of one. The proposal is emerging, the format itself is stable enough to monitor, but the URLs you listed will drift: pages get renamed, products get archived, policies get rewritten, and a draft you validated in January may reference a 404 by March. Re-open the file once a quarter, click each link, and remove or replace anything that does not return the intended content. Re-run the validator after every edit so the structural guarantees hold. Keep the file short. A curated map of canonical documentation, product explanations, policies and stable reference pages is more useful to a language model than a thousand-line index that repeats the overload of a large sitemap. Do not invent .md URLs that your WordPress install does not reliably serve; if you do not have a Markdown mirror of a page, link to the HTML version and let the consumer decide. Finally, measure whether your own tools and workflows use the file; publication alone is not evidence that an AI answer now cites your site.
How llms.txt Fits Next to robots.txt and sitemap.xml
| Mechanism | Primary purpose | Lives at | Format | WordPress default |
|---|---|---|---|---|
| llms.txt | Curated Markdown map of high-value resources for inference-time use | /llms.txt or an appropriate subpath | Markdown with one H1, optional blockquote, ordered H2 link sections | Not generated; published manually |
| robots.txt | Crawl preferences for participating crawlers | /robots.txt | Plain text with User-agent and Allow or Disallow rules | Generated by WordPress on a virtual host when no static file exists |
| sitemap.xml | Inventory of indexable URLs for search discovery | /sitemap.xml or /wp-sitemap.xml | XML with URL entries and lastmod values | Emitted by WordPress core at /wp-sitemap.xml |
| Structured data | Describes entities and on-page content for rich results | Embedded in page HTML | JSON-LD or Microdata | Not emitted by core; added by SEO plugins or theme code |
Each mechanism keeps its own purpose. robots.txt expresses what participating crawlers may fetch, sitemap.xml inventories what you want discovered, structured data describes what a page is about, and llms.txt offers a short, curated Markdown overview plus a focused list of references for inference-time use. The four complement each other rather than replace one another, which is why publishing llms.txt should sit alongside your existing SEO plumbing rather than replace it.