This generator vs. writing llms.txt by hand

Q: How do I keep llms.txt updated as my docs change, without redoing this by hand every time?

Wire cli.mjs's --dir (a local Markdown docs tree) or --sitemap (a local or live sitemap.xml) mode into your build or deploy script. It regenerates the file from your current pages on every run, so the file tracks what you actually publish instead of a snapshot from whenever you last remembered to edit it by hand.

Hand-writing an llms.txt means copying URLs into a text file and getting the Markdown shape right yourself — the exact link-bullet syntax, the ## Section grouping the spec expects — then remembering to update it every time a page is added or removed. This free tool builds and validates the same spec-compliant file from a pasted sitemap.xml, a short page list, or a local docs tree, and the CLI keeps it current automatically.

What actually goes wrong by hand

llms.txt looks like a plain text file, so it is tempting to just type one. Three specific things go wrong when you do, and none of them are judgment calls — they are mechanical slips that are easy to make once and never notice:

The link syntax. Each entry under a section has to be a real Markdown link bullet — - [Title](url): optional note — not a bare URL pasted on its own line. Drop a bracket or forget the leading - [ and the file still looks fine to read; it is just no longer the shape the spec describes.
The section grouping. The convention expects links grouped under ## Section headings, not one flat list. Nothing stops you from skipping the headings entirely, and a flat list is exactly what you get if you started by pasting a raw sitemap.xml in by hand, one <loc> per line.
Staying in sync. The file is a snapshot of whatever your docs looked like the day you wrote it. Add a page, rename one, or retire a section, and the hand-written file does not know — nothing forces you to reopen it, so it quietly drifts from what you actually publish.

This generator removes exactly those three failure points. It always emits the correct H1 title, optional blockquote summary, and Markdown link bullets grouped under ## Section headings, from a pasted page list, a pasted sitemap.xml, or — via the CLI — a local Markdown docs tree, and every build is checked against the same validator shown in the tool's third tab before you publish. For staying in sync, wire cli.mjs's --dir or --sitemap mode into your own build or deploy script and it regenerates from your current pages on every run, instead of from whatever you remembered to type in by hand.

What it does not do is pick which pages belong in the file — that judgment call is still yours, generator or not. See what llms.txt is, and whether you need one for the background, or this generator vs. a hosted docs platform's built-in llms.txt feature for the other comparison this venture publishes.

Writing it by hand	This generator
Type each `- [Title](url): note` bullet yourself and hope you didn't drop a bracket.	Paste a page list or sitemap; the Markdown link syntax is always correct.
Remember to group links under `## Section` headings, or skip it and get a flat list.	Sections come from the page-list tab's own `## Section` lines, or one grouped "Pages" section from a sitemap.
No way to check the result except reading it over yourself.	Every build runs back through the same validator you can also paste any llms.txt into directly.
Reopen and re-edit the file by hand whenever a page is added or removed.	Wire `cli.mjs --dir` or `--sitemap` into your deploy script and it regenerates automatically.
Deciding which pages belong in the file.	Still your call — this tool formats and validates, it does not curate.

This tool needs no account and no sign-in: it is a static page, building and validating run in your browser, and nothing you paste is uploaded anywhere.

Common questions

What actually goes wrong when you write llms.txt by hand?

Three things, all mechanical rather than judgment calls. The link bullets have to be exact Markdown — "- [Title](url): optional note" — and a missing bracket or a bare URL without the link syntax is easy to type past yourself. The pages need grouping under "## Section" headings, not a flat list, which the spec expects but nothing stops you from skipping. And the file has to be kept in sync as pages are added or removed, which nobody remembers to do by hand once it is not new anymore.

Isn't llms.txt just a short text file — why would I need a generator for it?

The content decisions — which pages matter, what to say about each one — are genuinely yours, and this tool does not make them for you. What it removes is the formatting risk: it always emits the required H1 title, optional blockquote summary, and Markdown link bullets grouped under "## Section" headings, and it validates the result against the same rules before you publish, so a typo'd bracket or an ungrouped link list is caught rather than shipped.

How do I keep llms.txt updated as my docs change, without redoing this by hand every time?

Wire cli.mjs's --dir (a local Markdown docs tree) or --sitemap (a local or live sitemap.xml) mode into your build or deploy script. It regenerates the file from your current pages on every run, so the file tracks what you actually publish instead of a snapshot from whenever you last remembered to edit it by hand.

I already have an llms.txt I wrote by hand — do I need to redo it?

Not necessarily. Paste it into this tool's validate tab first — it checks the same structural rules a generated file already satisfies, for free, with nothing uploaded. If it comes back clean, keep it; if it flags a missing section heading or a malformed link, you now know exactly what to fix instead of guessing.

Open the llms.txt Generator, or read what llms.txt is, and whether you need one.