llms.txt Generator Example: AI Visibility File for SaaS
This example shows the aiwebpageseo llms.txt Generator for a SaaS marketing site. The tool extracted the site name, description, 6 key topics from headings, 8 key pages from navigation and generated a complete, validated llms.txt scoring 94/100 against the llmstxt.org specification.
/help to https://saas.example.com/help to achieve 100/100.A generator producing a well-formed llms.txt in seconds is useful, and the file is worth deploying. It is also worth being straight about what it is, because the marketing around this format has run some distance ahead of the evidence.
llms.txt is a community proposal. It is not an IETF standard. No assistant operator publishes a specification for it, none has stated that it reads one, and adoption is partial and unverified. There is no demonstrated relationship between publishing the file and being cited by anything. Claims to the contrary — including cohort statistics showing that sites with llms.txt get cited more — do not control for the obvious confounder, which is that a team disciplined enough to maintain one is a team that maintains its content generally. The file did not cause the outcome; the same habit produced both.
So the honest pitch is modest and still worth taking: it costs a few minutes, it does no harm, and if operators do converge on reading it, you already have one. Deploy it on that basis and it will never disappoint you.
A generator extracts headings and links and produces a structurally valid file. Structural validity is not the same as usefulness, and this is where a generated file needs a human before it ships.
The question the file exists to answer is deceptively demanding: if somebody could read six pages of this site and no more, which six, and why each one? Most teams have never sat down and answered that. A generator cannot answer it either — it can only guess from structure, and structure reflects your navigation, which reflects your org chart more often than it reflects what is genuinely worth reading.
Documentation, guides, explanations
The pages that explain how something works survive being lifted out of a layout and read cold. That is exactly what a retrieval system does with them, and it is why they are worth nominating.
Hero copy, feature grids, landing pages
Marketing prose depends on the design around it, the image beside it and a reader who already wants to believe you. Extracted as plain text it says almost nothing, which makes it the least useful thing you can nominate.
Eight good links beat two hundred
An exhaustive file is a sitemap with prose attached. Curation was the only thing this format added over a sitemap; exhaustiveness throws it away.
The most consequential misunderstanding about this file is that it functions as a permissions system. It does not, and a site that believes otherwise has controlled nothing while believing it has.
An AI-permissions statement inside llms.txt has no enforcement mechanism behind it and no established legal standing. Writing "this content may not be used for training" into a Markdown file prevents no training. If that is the outcome you want, it lives in robots.txt, where you name the agents — GPTBot for OpenAI training, Google-Extended for Gemini training — and even robots.txt is a convention honoured by the operators who choose to honour it, not an access control. Genuine enforcement is a WAF rule or an authentication wall, and it applies to everything, including the crawlers you wanted.
Two further corrections follow, since this is where they cause the most damage. Blocking GPTBot does not remove you from ChatGPT's cited answers, because those are served by different agents — OAI-SearchBot and ChatGPT-User. And disallowing Google-Extended has no effect on Google Search or on AI Overviews, which are served through ordinary Googlebot access. Training and retrieval are separate decisions with separate costs, and a site that conflates them usually pays one it did not intend to.
Whatever you decide, verify it in your access logs. A permissive robots.txt behind a WAF rule matching the string "bot" produces a flawless configuration and no crawler traffic at all.
This file has an unusual failure mode. When it rots, nothing breaks. The site keeps working, no monitor fires, no customer complains — and so a year later it is quietly recommending pages that were moved in March and citing a product figure that has been wrong since spring. A stale llms.txt is a machine-readable file on your own domain telling clients something false about your business.
Give it an owner and a trigger. Regenerate it whenever documentation ships. Add its links to whatever already checks the site for broken URLs, so that a 404 in llms.txt is caught by the same job that catches a 404 anywhere else. If you cannot commit to that, publish a shorter file with fewer links, because a small true file beats a large stale one every time.
And keep the effort proportionate. The four things that actually determine whether a machine can use your site are: whether the retrieval agents can reach you at all, whether your substance is in the served HTML rather than assembled client-side, whether your structured data accurately describes the page, and whether anybody has written an answer worth quoting. The first three are preconditions you finish. The fourth is the work, and it never ends. llms.txt is a signpost pointing at that work — a useful one, and a cheap one, and not a substitute for it.
What is llms.txt?
llms.txt is a plain-text Markdown file placed at the root of your domain — for example https://example.com/llms.txt — listing what the site is for and which pages are worth reading, with a short description of each. It is a community proposal rather than a standard: no assistant operator publishes a specification for it, adoption is partial, and there is no evidence that having one raises citation probability. It is often compared to robots.txt, but the comparison misleads. robots.txt governs access. llms.txt controls nothing — it is a recommendation about what is worth reading.
Does every site need llms.txt?
No site needs one, and no site is harmed by having one. The honest case is that it costs a few minutes, does no damage, and forces a genuinely useful editorial decision: if somebody could read only six pages of your site, which six, and why? Claims that it makes ChatGPT or Perplexity more likely to treat you as an authoritative source are unsupported — nobody outside those companies knows what governs retrieval, and no operator has said it reads this file. Publish it as cheap hygiene, not as a lever, and put your effort into the pages it points at.
What should llms.txt contain?
Keep it short and curated: the site name, a clear statement of what the site is for, and a list of your genuinely most useful pages with one honest sentence about each — what it contains and who would want it. Point at the pages that explain things rather than the pages that sell things, because explanatory prose survives being lifted out of a layout and marketing copy does not. Resist the urge to be exhaustive: a file listing two hundred URLs is a sitemap with prose attached, and it has discarded the only thing that made it useful, which was the curation.
Does llms.txt stop my content being used for AI training?
No. It has no enforcement mechanism whatsoever, and a permissions statement written inside it is a sentence, not a control. Training access is governed by robots.txt directives naming the relevant agents — GPTBot for OpenAI training, Google-Extended for Gemini training — and, if you need actual enforcement rather than a convention, by a WAF rule. Note also that training and retrieval are separate decisions: blocking GPTBot removes you from a training corpus and does not remove you from ChatGPT's cited answers, which are served by OAI-SearchBot and ChatGPT-User.
Where exactly does the file go, and does the format matter?
At the root of the domain, served over HTTPS with a content type of text/plain or text/markdown, reachable at /llms.txt without a redirect. Keep it Markdown, keep the links absolute, and keep the structure obvious — a heading, a summary, then linked sections. The format matters less than the maintenance: a beautifully structured file whose links 404 six months from now is worse than a plain one that is true, because it is a machine-readable file on your own domain telling clients something false about your site.
Should I also publish llms-full.txt?
Only if you actually want to serve expanded content in a single fetch. The idea is that a client reading llms-full.txt gets the substance of each linked document without having to retrieve each page, which is a genuine convenience for a system with a constrained context. There is no evidence that publishing it improves citation rates, and figures suggesting otherwise are correlations that fail to control for the obvious confounder: teams disciplined enough to publish one are teams that maintain their content. If your documentation is large, the file also gets large, and a large file that drifts out of date is a bigger liability than no file at all.
What actually makes a site usable by an AI assistant, if not this file?
Four things, and none of them is llms.txt. First, access: confirm in your access logs — not your robots.txt — that the retrieval agents are reaching you and getting a 200, because a silent WAF block produces a permissive config and zero traffic. Second, served HTML: most retrieval systems parse rather than render, so anything assembled client-side after load effectively does not exist for them. Third, accurate structured data, which disambiguates what your text means without conferring any preference. Fourth, and by far the largest: pages that answer questions in self-contained prose that still makes sense when lifted out of the page. That is the whole game, and llms.txt is a signpost pointing at it.
Related Demo Reports
Run llms.txt Generator on Your Own Site
Get your real audit report with specific issues, fixes and actionable improvements — free to start.