To generate an llms.txt file, write one site-name H1, add an optional summary and details, group selected canonical links under H2 headings, then validate and review the final Markdown before publishing it.

llms.txt is an emerging proposal for a curated Markdown overview and a short list of high-value references. The llms.txt Generator creates deterministic plain text locally: enter the content, generate it, copy or download a file named llms.txt, and use the separate validation mode for an edited draft. It neither crawls the domain nor sends content to an external service, and it makes no promise about crawler adoption, rankings, or citations.

how do i generate llms txt when using llms txt file example
How Do I Generate llms.txt? File Example and Checks

The required structure at a glance

The format proposed at llmstxt.org has a predictable order. The generator owns that order instead of accepting arbitrary Markdown fragments that could create duplicate top headings or misplaced sections.

Order Element Requirement Purpose
1 H1 Yes: exactly one Names the site or project.
2 Blockquote summary Optional Briefly explains what the site or project provides.
3 Free-form details Optional Adds context without introducing another heading.
4 H2 sections Optional: zero or more Groups related resources under clear section names.
5 Link list items Link required; note optional Points to a resource and may explain its contents.

The H2 named Optional has a defined convention: its links identify secondary material that can be skipped when a shorter context is needed. The tool does not make that editorial decision for you, so place a resource under Optional only when it is genuinely secondary.

Only HTTP and HTTPS URLs are accepted. Credential-bearing URLs and executable or embedded-data schemes are rejected. Labels, notes, headings, and summaries are normalized so control characters or accidental Markdown delimiters cannot break the generated structure. Duplicate normalized URLs are reported rather than silently multiplying entries.

A complete llms.txt file example

The following example uses illustrative placeholder URLs. Replace them with reviewed pages from your own site before publishing the file.

Example llms.txt

# Example Project

> A concise map of the project documentation and reference material.

This project explains how to install the client, authenticate requests, and use the public API.

## Guides

- [Authentication guide](https://example.com/docs/authentication): Request setup and token handling.

- [Error handling](https://example.com/docs/errors): Common responses and troubleshooting steps.

## Reference

- [API reference](https://example.com/reference/api): Endpoints, parameters, and response formats.

## Optional

- [Release notes](https://example.com/changelog): Historical changes that may be skipped for shorter context.

The summary follows the H1, the free-form details precede the H2 sections, and every list item contains a Markdown link. Optional identifies material that may be omitted when a shorter context is needed. The generator neither verifies that these illustrative URLs resolve nor checks whether each note accurately describes its page; those checks remain with the author.

If the site reliably serves a Markdown version of a page, link that version; do not invent an .md path that may fail. Keep Optional for genuinely secondary material, not for core documentation or product explanations.

Build the draft without scanning the site

In the generator, enter the site or project name, then add the optional summary and details. Create clear H2 section headings and populate them with only the canonical, high-value resources you have selected. Notes should state what a linked resource contains, while your section placement determines whether that resource is treated as optional.

The generator never scans a domain or sitemap. A client-side form cannot prove which dynamic pages are canonical, current, accessible, or safe to recommend, so you remain responsible for checking each public URL and excluding private or staging destinations.

For implementation background, the DeveloperHub llms.txt implementation documentation and the Answer.AI llms-txt reference repository provide useful references. Neither is evidence that every crawler or assistant will request the file.

Generate, validate, and publish the file

  1. Collect a short, reviewed URL set. Choose canonical documentation, product explanations, policies, and stable reference pages. Check that each URL is public and currently serves the intended content. Include a Markdown version only when it already works reliably.
  2. Enter the required site or project name. This becomes the single H1 at the top of the draft. Use the name readers will recognize rather than adding a separate introductory heading.
  3. Add the optional summary and details. A blockquote summary should identify the site's purpose, while non-heading details can explain scope or audience. Keep the language factual and concise.
  4. Build clear H2 sections. Group related links under descriptive headings and add a short colon-delimited note when the destination needs clarification. Put genuinely secondary material under the H2 named Optional.
  5. Generate and perform an editorial pass. The tool produces deterministic Markdown for copying or downloading as llms.txt. Review the Optional section and every note before accepting the output.
  6. Validate the final edited draft. If you changed the generated text, paste the complete file into validation mode. The validator reports line-oriented issues and warnings for the required H1, heading order, link-list syntax, duplicate targets, and bounded size. It does not rewrite the file, follow the URLs, or judge their accuracy.
  7. Publish at the intended path. Use /llms.txt or an appropriate subpath and serve it with a plain-text or Markdown-compatible content type. A clean validation result means the draft matches the tool's documented interpretation of the current proposal; it does not certify broader vendor support.
  8. Review it periodically. Recheck the title, summary, notes, canonical URLs, and Optional classification. Verify the linked pages and remove resources that are outdated or inaccessible. Recheck the proposal and syntax before building automation that depends on exact formatting.

Why generation and validation are separate

Generation constructs a constrained draft from local form input, while validation checks pasted text against the tool's current documented interpretation. Using one does not silently perform the other.

Mode What it checks or creates Boundary
Generation Creates one H1, an optional blockquote summary, optional details, ordered H2 sections, and Markdown link lists. Does not crawl, fetch listed pages, or determine whether their content is accurate.
Validation Checks the required H1, heading order, link-list syntax, duplicate targets, and bounded size. Does not rewrite the draft, follow links, certify content accuracy, or certify crawler adoption.

Review each validation issue and warning against your intended content. The result is a structural check of the draft, not a live website audit or a prediction of how an AI system will use the file.

Keep the file concise and reviewable

Curation matters more than length. A file containing every page can repeat the information overload of a large sitemap and consume context without helping a reader or model. Prefer a concise map of the resources that best explain the site.

  • Confirm that the H1 and summary match the site.
  • Include only canonical, public, high-value links.
  • Make every note factual and useful.
  • Reserve Optional for resources that are genuinely secondary.
  • Exclude private, staging, redirected, or outdated destinations.

After downloading, review the file as content rather than as a mechanical SEO artifact. Successful serialization does not determine which pages deserve inclusion; that editorial judgment remains yours.

Set expectations for crawler use

Publishing at /llms.txt makes a file available; it does not force any crawler or assistant to request it. The proposal is not a robots directive, security control, sitemap replacement, or guaranteed discovery protocol. It cannot grant access to blocked pages, override authentication, remove content from model training, or prove that an AI answer will cite the site.

Keep each web mechanism in its own role: robots.txt states crawl preferences for participating crawlers, sitemap.xml inventories indexable URLs for search discovery, structured data describes entities and page content, and llms.txt offers a curated Markdown overview for inference-time use. Measure whether your own tools and workflows actually use the file; publication alone is not evidence of ranking or citation improvement.

Related reading: robots.txt Generator for Large Text: Limits and Workflow.