--- title: "How to Generate an llms.txt on WordPress, and Whether It Is Worth It" url: https://hostmy.blog/llms-txt-generator-wordpress/ date: 2026-09-13 modified: 2026-09-03 lang: en author: "Aditya Sharma" description: "Generate a valid llms.txt on WordPress, verify it with curl, and read the honest evidence on whether the file does anything at all." categories: - "RankReady" image: https://hostmy.blog/wp-content/uploads/2026/09/hmb-card-1860-1024x538.jpg word_count: 1513 --- # How to Generate an llms.txt on WordPress, and Whether It Is Worth It Three llms.txt files came across my desk last month. All three were served as `text/html`. One of them also had `X-Content-Type-Options: nosniff` set, which tells a strict client to trust the declared type and refuse to sniff for a better one. That file is unparseable by anything careful. It looked perfect in a browser. Generating the file is the easy half. Serving it correctly is where sites fail quietly, because nothing warns you. So the order here is generate, verify, then decide how much to care, which is roughly where this file sits among [the WordPress tasks worth doing for AI search](/ai-search-optimization-wordpress/). That last part is where most writing on this topic gets dishonest, and the evidence section below is blunt about it. ## Generate the file first, argue about it afterwards Your llms.txt lives at the root of the domain, at `https://yoursite.com/llms.txt`. It is plain Markdown. It carries an H1 with your site name, an optional blockquote summary, then H2 sections holding bulleted links with one short description each. That is the entire format. No XML, no schema, no validator whose opinion carries weight. You have three ways to produce one on WordPress. - Write it by hand and drop it in the web root. Fine for a ten page brochure site. Painful for anything that publishes weekly. - Paste your URLs into an online generator, save the output, upload it. Same problem as above, and the file is stale the day you publish again. - Generate it from the database on a schedule, so it tracks the site without you. Option three is the only one that survives contact with an active blog. A static file written in March describes a March site, and nothing about it announces that it has rotted. ## A correct llms.txt looks like this `# Host My Blog > WordPress hosting and AI SEO tooling, run by one person, documented in public. ## Guides - [Generate an llms.txt on WordPress](https://hostmy.blog/llms-txt-generator-wordpress/): generating, serving and verifying the file, plus the evidence on whether it helps. - [The five layer AI SEO audit](https://hostmy.blog/ai-seo-audit/): fetchability, then parseability, then structure, in dependency order. - [Markdown copies of your posts](https://hostmy.blog/markdown-version-of-blog-posts/): who actually reads them and how to serve them safely. ## About - [About Host My Blog](https://hostmy.blog/about/): who runs this, and what it costs.` Descriptions should say what the page contains. A line that sells the page is worse than a line that describes it, because the reader here is a program deciding whether to spend a fetch on you. Ordering matters more than people expect. Put the pages you genuinely want read at the top of the first section. A file listing 400 URLs in database order is a sitemap with extra characters. ## Verify with curl, because the browser lies Open the file in Chrome and it will look correct in almost every broken case. Browsers sniff content and quietly fix your mistakes. Strict clients do not. Start with the headers: `curl -sI https://yoursite.com/llms.txt | grep -i -E 'http/|content-type|x-content-type-options'` What you want back: `HTTP/2 200 content-type: text/plain; charset=utf-8` A `text/markdown; charset=utf-8` response is equally fine. A `text/html` response is the failure, and it is the common one, because the request is being routed through WordPress and PHP is setting the type on the way out. Then confirm the body is the file rather than a 404 page wearing a 200 status: `curl -s https://yoursite.com/llms.txt | head -20` Then check the size, since a truncated file fails silently: `curl -s -o /dev/null -w '%{http_code} %{size_download} bytes\n' https://yoursite.com/llms.txt` Anything under a few hundred bytes on a site with real content means the generator ran before your posts existed, or a cache is serving an empty first write. ## Four ways this file breaks after you generate it | Symptom | What curl shows | Cause | Fix | | ------- | --------------- | ----- | --- | | Wrong type | `content-type: text/html` | Response rendered through the theme | Send the header before any output | | Refused parse | `text/html` plus `nosniff` | The security header stops the client rescuing the bad type | Correct the type, keep nosniff | | Soft 404 | Status 200, HTML body | Rewrite rule missing, WordPress serves the 404 template | Register the route, flush rewrites | | Stale content | Clean headers, old URLs | Static file with no regeneration | Generate from the database on a schedule | The same llms.txt, served two ways The same llms.txt, served two ways Served correctly Served by a default WordPress route Content-Type text/plain text/html X-Content-Type-Options absent nosniff What the client does reads the file renders it as a page Net result usable ignored Generating the file is the easy half. A file served as text/html with nosniff is read as a web page and discarded. The `nosniff` case is the one worth staring at. That header is correct security practice and you should keep it. Combined with a wrong content type it turns a cosmetic problem into a hard failure, and it was live on a real site I looked at this year. ## The evidence says llms.txt does not drive citations Here is the part that gets skipped. SE Ranking studied roughly 300,000 domains and found no correlation between carrying an llms.txt file and AI visibility. Dropping the variable improved their model, which is the statistical way of saying it was contributing noise. Ahrefs looked at 137,000 domains, about 38,000 of which had the file in place. 97 percent of them saw zero traffic attributable to it. Google has said plainly that it does not use llms.txt. None of that is ambiguous, and none of it is a vendor claim. If your reason for generating the file is that it will get you cited, that reason does not survive the data, and [the fuller case that the file does nothing for citations](/llms-txt-does-not-work/) goes through the studies one at a time. ## Generate it anyway, and say exactly why The honest case takes three lines. The file is cheap. One setting, no ongoing effort once it regenerates itself, and zero front end cost because no human visitor ever requests it. The file is expected. Enough agent tooling probes `/llms.txt` on arrival that its absence is a small piece of friction for anyone pointing a tool at your domain, including you. Most of [the free readiness checkers we read](/ai-readiness-checkers/) look for it in their first few requests. The file is a forcing function. Writing one sentence descriptions for your thirty best pages tells you very fast which pages you cannot describe in one sentence. Those are the pages that needed rewriting anyway. What it is not is a ranking lever. Anyone selling it as one is either behind on the research or hoping you are. ## The reach is in the pages, not the index of them Machine readable copies of the posts themselves do more work than a list pointing at them. An agent that follows a link out of your llms.txt still lands on whatever you serve, and a typical WordPress page is mostly navigation, inline scripts and markup wrapped around a few hundred words. [The request chain between an answer and your server](/ai-crawlers-request-by-request/) shows where that weight is paid. One real page in my own testing dropped from 4.7 MB of HTML to 18 KB of Markdown. Roughly 260 times smaller, identical words. That is a different mechanism with a different audience, and it is covered in [who reads Markdown copies, and how to serve them safely](/markdown-version-of-blog-posts/). Do the llms.txt because it is cheap. Do the Markdown layer because it changes what a machine actually receives. ## The WordPress route that takes about five minutes Generating, serving with the right content type, and regenerating on publish are three separate problems, and hand rolling all three in `functions.php` is how you end up with the soft 404 in the table above. That whole path is what [RankReady](https://wordpress.org/plugins/rankready-ai-llm-seo/) handles. It is a WordPress AI SEO plugin, and it runs alongside Rank Math, Yoast, AIOSEO or SEOPress rather than replacing any of them, because your existing SEO plugin is still doing the job it was built for. Setup is about five minutes, most of it spent choosing which sections belong in the file. What that buys you is crawlability and a correctly served file. Whether any model then quotes your work is not something a plugin decides, and my answer will not change on that. The parts of this field that get sold dishonestly are set out in [what the term AI SEO actually covers](/what-ai-seo-means/). ## Run the check on your own domain now Three commands, less than a minute: `curl -sI https://yoursite.com/llms.txt | grep -i 'content-type' curl -s https://yoursite.com/llms.txt | head -5 curl -s -o /dev/null -w '%{http_code}\n' https://yoursite.com/llms.txt` If the type comes back as `text/html`, fix that before you touch the contents. If the body starts with your theme's doctype, you have a routing problem and the file does not exist as far as any careful client is concerned. Once that is clean, the next layer up is whether the crawlers were ever allowed to fetch it, which is its own trap and is covered in [the 29 named crawlers and the group trap](/block-ai-crawlers-robots-txt/). After that, run the full sweep in [an audit that starts at reachability and works up](/five-layer-ai-seo-audit/). When did you last look at the headers on a file you generated, rather than the file itself?