Last updated: November 4, 2026
Say you generated an llms.txt file, uploaded it somewhere in your WordPress install, typed yourstore.com/llms.txt into the browser, and got your theme's 404 page. You check the file manager: the file is there. Three things can be wrong, and none of them is the file. Working out where to place the llm.txt file for the website is simple in principle, at the site root, and fiddly in practice on WordPress, where rewrite rules, caching layers and a CDN each get a chance to serve something other than your file. This guide gives the rule from the proposal, the four ways to add the file to WordPress, the test that proves it is served, and the fixes for each trap.
Key takeaways
- Place the file at the site root: https://yourstore.com/llms.txt. The proposal also allows any path, covering the pages under it, but root is what every tool and audit expects.
- On WordPress, the root is the folder that holds wp-config.php, usually public_html or htdocs on your host.
- Four ways to add it: upload a physical file, let an SEO plugin serve it, serve it from an analytics plugin, or add a rewrite rule. A physical file is simplest.
- Test it in a private window. You should see plain Markdown text, not a page and not a redirect.
- No AI provider has confirmed reading the file, so budget ten minutes for all of this and no more.
Where should the llms.txt file go?
At the root of the domain, so it is reachable at https://yourstore.com/llms.txt, next to where robots.txt lives. The proposal at llmstxt.org says the file "can be placed at the site root, or at any path within it, covering the pages under that path", but root is the location every generator, audit and tutorial assumes. Use root unless you have a reason not to.
The spelling is llms.txt with an s. "llm.txt" is a common misspelling of the same thing. Name the file llms.txt, lowercase, no spaces. Chrome's Lighthouse audit, per its documentation summary, checks for the file in the root directory, which is one more reason to put it there.
Where is the root on a WordPress site?
The folder that contains wp-config.php, wp-admin and wp-content. On most hosts it is called public_html, htdocs, www or the domain name. If WordPress is installed in a subfolder but the site runs at the domain root, the root is still the domain's top folder, not the WordPress folder. Robots.txt and sitemap files live in the same place.
| Where you put the file | URL it answers at | Correct? |
|---|---|---|
| public_html/llms.txt (next to wp-config.php) | https://yourstore.com/llms.txt | Yes |
| public_html/wp-content/llms.txt | https://yourstore.com/wp-content/llms.txt | No, wrong path |
| public_html/wp-content/uploads/2026/11/llms.txt (Media Library) | A long uploads URL | No, wrong path |
| public_html/shop/llms.txt when the store is at yourstore.com/shop/ | https://yourstore.com/shop/llms.txt | Allowed by the proposal, covers pages under /shop/, but root is what tools expect |
| A WordPress page with the slug llms-txt | https://yourstore.com/llms-txt/ | No, wrong name and returns HTML |
Multisite and subdomain setups follow the same rule per domain. A store at shop.example.com needs its own file at shop.example.com/llms.txt, because the root of a subdomain is a different root. A multisite network with subdirectory sites can use the proposal's any-path allowance, one file per site under its path, though most networks simply put one file at the network root and accept that it covers everything.
The Media Library trap catches many people. Uploading llms.txt through Media creates a file under wp-content/uploads with a dated path. It is a real file, it just lives in the wrong place. Use the hosting file manager or SFTP instead.
Four ways to add llms.txt to WordPress
Upload a physical file to the root with your host's file manager or SFTP, let an SEO plugin that offers the feature serve it, let an analytics plugin with AI visibility features write it, or add a rewrite rule that serves generated content at the path. The physical file is the simplest and the least likely to break. The plugin routes keep the file current automatically.
- Physical file. Open the hosting control panel's file manager, go to the folder with wp-config.php, create a new file named llms.txt, paste the content, save. Or upload over SFTP. Done in two minutes. Downside: you update it by hand.
- SEO plugin. Some SEO plugins generate and serve the file from their settings. Check the plugin's own documentation for where the setting is and whether it writes a physical file or serves the content on request. Downside: you now depend on the plugin's idea of what to include, which is often the whole sitemap.
- Analytics plugin with AI visibility. StorePinger writes an llms.txt file for the store from its AI visibility screen, alongside tracking visits from AI tools. Downside: none specific, but it is one more reason to keep only one tool writing the file.
- Rewrite rule. A developer can add a rewrite so that /llms.txt is answered by code that builds the file from the catalog on each request. Downside: it is custom code to maintain, and caching plugins may need an exclusion.
A worked example, not a customer result. An owner on a managed host with no SFTP access and a page builder that has no code box picks route one through the host's web file manager: new file, paste, save, two minutes. Six months later the catalog has changed and the file has not. The owner switches to route three so the file is written from inside WordPress and regenerated with the catalog, and deletes the physical file so the two cannot disagree. That sequence, manual first and generated later, is common and fine.
Whichever route you choose, choose one. Two plugins both trying to serve /llms.txt, or a plugin and a physical file, produce whichever one the server finds first, and that is rarely the one you updated.
How do you check that the file is actually served?
Open https://yourstore.com/llms.txt in a private browser window. You should see your Markdown as plain text starting with the H1 line. If you see a styled 404 page, the home page, a redirect or a login screen, the file is not being served from that path. Then check the response headers for a 200 status and a text content type.
- Private window, so your own logged-in session and any admin caching rules do not affect the result.
- Type the URL by hand. Do not click a link from the admin, which may carry a cache-busting parameter.
- Read what comes back. Plain text with your store name on the first line is a pass.
- Optional: in the browser's developer tools, Network tab, reload and check the status is 200 and the content type is text/plain or text/markdown.
- Check from a second network, such as a phone on mobile data, because a CDN can serve different copies to different regions.
Write the result down with the date. The next time you regenerate the file, repeat the five steps. It is a one-minute habit, and it is the only way to know the file is live rather than assume it, which is the mistake most of the 404 reports on forums come down to.
What should the file look like when it is served correctly?
Plain Markdown, starting with a single H1 line that is your store name, then a blockquote summary, then headings and link lists. No HTML tags, no theme styling, no cookie banner. If the browser renders it as a web page, something between the file and the browser has rewritten it. If you see raw text starting with a hash and your store name, it is right.
# Northwind Kitchen
> Northwind Kitchen sells cast iron and carbon steel cookware for home cooks, shipped from Oregon to the US and Canada.
## Skillets
- [10-inch cast iron skillet](https://example.com/product/10-inch-skillet/): pre-seasoned, oven safe to 500F, $48.
## Shipping and policies
- [Shipping](https://example.com/shipping/): free over $75 in the US, 2 to 5 business days.
The example is shortened. A real file lists the categories, the products worth quoting and the policy pages, and puts the blog under an Optional heading. The best practices guide gives the full structure, and the free generator produces it from your store URL. What matters on this page is that the thing in your browser looks like the block above and nothing else.
Does the file need any special configuration on the server?
No. A .txt file at the root is served by every web server as text by default, which is why the physical-file route is the simplest. Problems only arise when something in front of the file, a rewrite rule, a security plugin, a cache, or a CDN, intercepts the request. If the private-window test passes, there is nothing more to configure.
What you do not need: a plugin to "register" the file, a special MIME setting in WordPress, or any change to wp-config.php. Guides that suggest those are usually solving a rewrite problem the long way round.
Two optional refinements. A content type of text/markdown is closer to what the file is than text/plain, and some hosts let you set it per extension, but no reader is documented as caring. And a short cache time on the path, an hour rather than a day, means a regenerated file shows up quickly without a purge. Both are nice to have. Neither is worth a support ticket.
Why does WordPress show a 404 for a file that exists?
Three usual causes: the file is in the wrong folder, a rewrite rule is catching the request before the web server checks for the file, or a security plugin is blocking direct access to .txt files. Check the folder first, because it is the cause nine times out of ten. Then look at rewrites and security rules.
- Wrong folder. See the table above. The file must sit next to wp-config.php.
- Rewrite order. WordPress's standard rules tell the server to serve real files first and only pass other requests to WordPress. A custom rule added above them, often by a plugin or a past developer, can send every request to WordPress, which has no page called llms.txt and returns 404. A developer can check the .htaccess or server config for rules that run before the WordPress block.
- Security plugin. Some firewall plugins block direct requests to text files as a hardening rule. Look for a setting about blocking access to .txt files, or add llms.txt to the allow list.
- Nginx hosts. There is no .htaccess. The host's Nginx configuration decides, and most managed hosts serve real files first by default. If not, support can add a location rule for /llms.txt.
Why do I see an old version after updating the file?
Caching. A page cache plugin, a server-level cache or a CDN can hold the previous copy of /llms.txt for hours or days. After any change, purge the cache for that URL or for the whole site, then test in a private window. If the CDN has a long cache time for text files, set a shorter rule for this path or purge it each time you regenerate.
A worked example, not a customer result. A store owner regenerates llms.txt after retiring ten products, uploads it, opens the URL and still sees the old products. The hosting cache was purged, but the CDN was not. A purge at the CDN fixes it in a minute. The owner then adds a rule to purge that path whenever the file is regenerated, so the problem does not recur. This is the same discipline you apply to robots.txt and the sitemap, and the same purge usually covers all three.
Should I add llms.txt to my website at all?
If a generator or plugin can make it in a minute, yes, as a cheap hedge. As of November 2026 no AI provider has confirmed reading the file, Google has stated no ranking effect, and a ten-site study found AI crawlers rarely request it. So place it correctly, test it once, and move on. The evidence is set out in the llm.txt for SEO guide.
What does move the needle for AI visibility is letting the documented crawlers in and making product pages easy to read. OpenAI documents OAI-SearchBot for ChatGPT's search features and says sites that opt out of it are not shown in ChatGPT search answers. That robots.txt decision matters far more than where a summary file sits. The llm.txt for SEO guide has the sources, and the best practices guide covers what to put in the file.
Where should robots.txt be located, and does llms.txt replace it?
Robots.txt also lives at the domain root and does a different job: it tells crawlers which paths they may fetch. llms.txt does not replace it, cannot block anything, and is not read by crawlers as a rule set. Keep both at the root. Make sure robots.txt does not accidentally block llms.txt, and that it allows the AI search crawlers you want.
A quick way to review both files together is to open robots.txt, the sitemap and llms.txt in three tabs and read them as a set: what crawlers may fetch, what pages exist, and what the store is about. If any of the three contradicts another, fix it the same day.
A line such as Disallow: /*.txt in robots.txt, added by a past hardening guide, blocks llms.txt and sometimes the sitemap. Check for it. And if your store wants to appear in ChatGPT search answers, OpenAI's documentation is the reference for the user agents to allow, which the ChatGPT traffic guide walks through.
Common mistakes
- Uploading through the Media Library. Wrong folder, wrong URL.
- Creating a page called llms.txt. It returns HTML at a slug, not a text file at the root.
- Two tools serving the file. Pick one.
- Testing while logged in. Caching and security rules differ for admins. The same rule applies to checking live visitors or any front-end feature: test as a visitor.
- Forgetting the CDN. The old file lives on for the cache lifetime.
- Blocking .txt in robots.txt. It blocks llms.txt and often the sitemap too.
- Spending an hour on it. Ten minutes is the budget until a provider confirms reading the file. The AI visibility feature in StorePinger writes the file and, more usefully, counts the AI visits that arrive whether or not anyone reads it.
Conclusion
Place the llms.txt file at the domain root, in the folder that holds wp-config.php, so it answers at https://yourstore.com/llms.txt. The proposal allows other paths, but root is what every tool checks. On WordPress, add it as a physical file or let one plugin serve it, never both, then open the URL in a private window and confirm plain text. If you get a 404, it is the folder, a rewrite rule or a security plugin. If you see an old version, it is a cache. Ten minutes covers all of it, which is the right investment for a file that no AI provider has yet confirmed reading. Spend the rest of the hour on the product pages the assistants do read, and track whether they send buyers with the sales by source report, which names AI tools as a source inside WordPress. The what is llms.txt guide covers the background if you are starting from scratch.