An llms.txt file is a short, plain-text Markdown document placed at your site's root that gives language models a predictable summary of who you are and where the canonical pages live. The format proposed at llmstxt.org is built around a single required H1 containing the project or site name, followed by an optional blockquote summary, optional free-form details, and zero or more H2 sections that group Markdown links to your most useful resources. Because the document is meant to be readable by both language models and ordinary parsers, the order of those parts is fixed: the H1 line comes first, the blockquote summary follows when present, any free-form details appear before the H2 link sections, and an H2 named Optional marks secondary material that a consumer may skip for shorter reasoning. To generate an llms.txt file, you can use a local browser tool that serializes those sections deterministically from your inputs and then validates the draft against the documented order without sending data anywhere or crawling your domain.
What the llms.txt Proposal Actually Requires
The llms.txt proposal, documented at llmstxt.org and maintained in the AnswerDotAI llms-txt reference repository, treats the file as a small Markdown index rather than a configuration directive. Its structural rules are deliberately strict because a parser needs to know exactly where the title ends, where the summary starts, where free-form details stop, and where each link section begins. The llms.txt Generator encodes those rules so you do not have to memorize them and so a hand-edited file cannot accidentally produce duplicate top headings or misplaced sections.
The full required order is summarized below.
| Position | Element | Required? | Purpose |
|---|---|---|---|
| 1 | H1 line containing the project or site name | Yes | Single document title; exactly one allowed |
| 2 | Blockquote summary (lines starting with >) | No | Short paragraph describing the project |
| 3 | Free-form Markdown details (no headings) | No | Extended context before any link lists |
| 4+ | H2 sections, each followed by Markdown list items | No | Grouped links to canonical resources |
| Last | H2 named "Optional" with secondary links | No | Resources that may be skipped for shorter context |
Each list item under an H2 must be a Markdown link whose required core is the URL. An optional colon and note can follow the link to explain what the resource contains. The proposal does not allow executable schemes, embedded-data URIs, or credential-bearing URLs, so a generator that honors the format rejects those inputs before serializing and reports duplicate normalized URLs instead of silently multiplying entries.
Why a Two-Mode Generator Beats Hand-Written Markdown
Most people who try to write llms.txt by hand run into the same three problems: duplicate top titles, misordered sections, and Markdown that breaks when notes contain colons or stray control characters. A hand-edited file can look correct in a preview but fail the moment a stricter parser reads it. A two-mode local tool separates the writing job into two clearly bounded steps so each step has a single, reviewable outcome.
In generation mode, the tool takes a small set of explicit inputs (site name, optional summary, optional details, and grouped links) and serializes a deterministic Markdown document. Labels, notes, headings, and summaries are normalized so accidental Markdown delimiters cannot break the generated structure. In validation mode, the same tool accepts a pasted draft and reports concrete line-oriented issues such as a missing H1, an H2 placed above the details block, list items without the required link core, duplicate normalized targets, or files that exceed a bounded size.
That separation matters because llms.txt is an emerging proposal rather than an enforced standard. The DeveloperHub llms.txt implementation documentation tracks real-world adoption, and the proposal itself can evolve. A local generator that owns its interpretation of the current format gives you a known starting point, while the validator gives you a way to confirm your edited draft matches that interpretation before the file leaves your machine.
Generate llms.txt Step by Step
To generate an llms.txt file that matches the documented order, work through the following steps in the llms.txt Generator. Everything happens locally in your browser; nothing is uploaded, and nothing is crawled.
- Enter the project or site name. This becomes the single H1 line and must appear exactly once at the top of the file.
- Add an optional blockquote summary. One or two lines beginning with > are enough to describe what the site is and who it serves.
- Add optional non-heading details. Plain paragraphs or short Markdown (no H2 or H3 headings) can sit between the summary and the link sections to provide extra context.
- Create H2 sections and add only canonical high-value links. Each section heading is an H2, and the items below it are Markdown links. Add a colon and note after a URL only when the note is genuinely useful.
- Generate the deterministic Markdown. The tool serializes the document in the fixed order, normalizes control characters, and reports duplicate normalized URLs instead of silently multiplying entries.
- Review the Optional section and every note. Confirm that links placed under an H2 named Optional are genuinely secondary and can be skipped when a consumer wants a shorter context.
- Copy or download llms.txt. The downloaded file is named llms.txt and contains plain text; copy it into your editor if you need to make small editorial adjustments.
If your workflow starts from an existing draft rather than a blank form, you can skip straight to the validation path described in the next section.
Validate the Draft Before You Publish
Validation is a separate pass from generation. Paste the final edited Markdown into the validator and read each report rather than treating warnings as cosmetic. The validator inspects the document line by line and surfaces concrete problems, but it does not rewrite the file, follow any listed URL, or claim that the linked resource is accurate.
| Check | What the validator looks at | Why it matters |
|---|---|---|
| Required H1 | Exactly one top-level heading with the site name | Multiple or missing H1 lines break the parser contract |
| Heading order | Summary before details, details before any H2 section | Reordering breaks predictable parsing for language models |
| Link syntax | Every list item under an H2 starts with a Markdown link | Plain-text list items violate the link-list requirement |
| Duplicate URLs | No two list items point at the same normalized target | Silent duplication wastes a consumer's context |
| URL safety | No credentials, executable schemes, or embedded-data URIs | Unsafe URLs can leak secrets or trigger handlers |
| Bounded size | Total byte length within reasonable limits | Mirrors the proposal's intent of a curated overview |
A successful validation run means the draft matches this tool's documented interpretation of the current proposal. It does not certify broader vendor support, and it does not promise that any crawler or assistant will actually request or cite the file.
What the Generator Will Not Do
Several things the tool deliberately does not do are central to using it safely. It does not crawl your domain, fetch your sitemap, or scan your pages, because a purely client-side form cannot prove which dynamic pages are canonical, current, accessible, or safe to recommend. It does not invent .md URLs that your site does not actually serve, and it does not rewrite an existing draft behind your back. If you need Markdown versions of pages that do not yet exist, author or convert them first.
The tool also makes no outcome promises. llms.txt is not a robots directive, a security control, a sitemap replacement, or a guaranteed discovery protocol. Publishing the file does not force a crawler or assistant to request it, cannot grant access to blocked pages, cannot override authentication, cannot remove content from model training, and cannot prove that an AI answer will cite the site. Treat the file as a curated inference-time resource map and measure whether your own tools and workflows actually use it rather than treating publication alone as evidence of search or citation improvement.
For a walkthrough that emphasizes the no-crawl aspect specifically, see the guide on Generate llms.txt From a Website Without Crawling It.
How llms.txt Fits Alongside robots.txt and sitemap.xml
llms.txt is one of several mechanism-level files a site may publish, and each mechanism keeps its own purpose. Treating the four formats as competing options hides the fact that they answer different questions: who is allowed to crawl, what URLs exist, what a page is about, and which references a model should prefer when forming an answer.
| File | Format | Audience | Purpose |
|---|---|---|---|
| robots.txt | Plain-text directives | Participating crawlers | Express crawl preferences for specific user-agents |
| sitemap.xml | XML URL set | Search engines | Inventory indexable URLs for search discovery |
| Structured data (JSON-LD / Microdata) | Embedded markup | Search and AI systems | Describe entities and page content for parsing |
| llms.txt | Curated Markdown index | Language models and humans | Offer a short overview and high-value references for inference-time use |
Robots.txt expresses preferences, sitemap.xml inventories URLs, structured data describes what a page is about, and llms.txt curates a small set of high-value references. A long file that lists every page of a large site can repeat the overload of a large sitemap and waste a consumer's context, so curation matters more than length. Prefer canonical documentation, product explanations, policies, and stable reference pages, and link to Markdown versions when the site reliably serves them. For an order-focused walkthrough, see the guide on Generate llms.txt for a Website in the Right Order.
Publish, Verify, and Re-Check Periodically
Once the draft passes validation, publish the file at /llms.txt (or the appropriate subpath) with a plain-text or Markdown-compatible content type. Then treat the file as content rather than a mechanical SEO artifact. Confirm the title and summary match the site, that every link is canonical, that notes are factual, that resources under the Optional H2 are genuinely secondary, and that no private or staging URL appears in the final draft.
The proposal and ecosystem can evolve, so recheck referenced URLs on a regular cadence and revisit the proposal and the tool's methodology before you build automation that depends on exact syntax. Measure whether your internal tools and workflows actually consume the file rather than treating publication alone as evidence of search or citation improvement.