How to › WordPress

How to add llms.txt to WordPress

This is the easy version, and it needs no plugin and no code: a real file in the web root is served by your web server before WordPress is involved at all. If your host will not let you write to the root, take the other route instead.

Can this platform serve the file at the exact path?

Yes — if you can put a file in the web root.

WordPress’s own server documentation is what makes this safe: the rewrite rules it writes only send a request to index.php when the target is not an existing file or directory. Sources: Apache configuration and nginx configuration.

before you start

What you need first

The file itself. Build one with the generator if you do not have one yet.
A way to put a file in the web root: SFTP, your host’s file manager, or a shell.
Knowing where the root is. It is the directory containing wp-config.php and index.php — unless WordPress is installed in a subdirectory, in which case see the warnings below.

the steps

Four steps, no plugin

Write the file. Markdown, opening with a level-one heading — # Your Business — and containing at least one Markdown link. Save it as llms.txt, in UTF-8, with no byte-order mark.
Upload it to the web root. The same directory as wp-config.php. Not wp-content, not the uploads folder, not the theme.
Do nothing in WordPress. There is no setting to change. WordPress’s default rewriting only routes a request to index.php when the requested path is not an existing file (!-f) or directory (!-d), which is documented in its own server configuration guidance. On nginx the equivalent is try_files $uri $uri/ /index.php?$args;, which the same documentation describes as meaning no PHP is touched for static content.
Publish and check the URL. Open https://yourdomain/llms.txt in a private window and confirm you get the raw text and not a themed page.

The rule that makes this work — WordPress’s own default `.htaccess`

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

what breaks it

The ways this goes wrong on WordPress

A subdirectory install. If WordPress lives in a folder, the file still has to sit in the domain’s document root, not in the WordPress folder. The path a robot asks for is the domain root, and nothing else counts.
A read-only web root. Some managed hosting will not let you write there at all. WordPress documents that the web server often runs as a different user from the owner of the files, which is where the permission wall comes from. If you hit it, use the dynamic route.
Creating a WordPress page with the slug llms.txt. It does not work and it is worth knowing why: WordPress’s own slug function is documented as limiting output to alphanumerics, underscores and dashes, and it replaces a period with a dash. You get /llms-txt, which is a different path and satisfies nothing. Source: sanitize_title_with_dashes.
A caching layer or CDN in front. Your first request may be served from a cache that predates the file. Purge, then re-check.

verify it

Prove the file is really there

A file that looks published in an admin screen and returns anything other than a plain 200 at the exact path has not been published. Three checks, in order:

Open https://yourdomain/llms.txt in a private window. You want the raw text, not a styled page, and not a redirect to another path.
Confirm the first line is a level-one Markdown heading — # Your Business. Google’s agent-readiness audit fails a file with no H1 heading anywhere in it, and the llms.txt specification puts the H1 first, so first is the safe place for it.
Confirm at least one Markdown link is present, in [label](https://…) form. A file with no links in that form is reported as a failure by the same audit.

Then run it through the validator, which checks the same conditions and tells you which recommendation each one comes from. The package passes the llms.txt and page-structure checks of Google’s agent-readiness audit; the WebMCP audits cover interactive tools a fact package deliberately does not install. That is the claim we make about this file, and the only one. It does not improve your search position.

the honest part

This file is the compliance surface, not the mechanism

Publishing it is worth doing and takes ten minutes. What it will not do on its own is get you found: in a controlled test, agents given no pointer to the file opened it 0 times in 18 visits (Note 15), and in a census of nine real sites, seven published one and not one of them placed it where it gets read (Note 09).

What moved the numbers was putting the answers in the homepage itself, where a one-page reader lands: 78% of fact checks recovered against 30% in the control, with agents stopping after 1.1 pages on average (Note 41). Do this file because Google’s page-quality tooling checks for it and the package passes the llms.txt and page-structure checks of Google’s agent-readiness audit; the WebMCP audits cover interactive tools a fact package deliberately does not install. Do the fact block because it works.

Sources: MARKETING_NOTES_AGENT_VISIBILITY.md, Notes 09, 15, 41.

If somebody has told you this file moves your search position, read does llms.txt help SEO first — the answer is documented, and it is not the one they gave you.

other platforms

The same job elsewhere

free audit

See what AI sees on your site

The file is ten minutes of work. Whether your homepage answers a buyer's question is a different question, and it is the one we measure.

One model fetches your homepage and answers buyer questions from it. You get the recovery score and the specific answers it could not find. That is the whole free tier: it shows you the problem, and the fix package is not included.

Request the free audit → See a real before-and-after What the package costs