How (and Whether) to Write an llms.txt File

llms.txt won't get you cited in ChatGPT or ranked in AI Overviews - the evidence doesn't support that claim (see our companion piece, Do You Need an llms.txt File?). But that doesn't make it worthless. For a specific type of site, it's a genuinely useful, cheap file to have. Here's who should bother, and exactly how to build one properly.

Who should actually do this

If you run developer documentation, a public API, or a SaaS product with technical docs, llms.txt is worth 30 minutes of your time. The real audience isn't AI search - it's developers who use AI coding assistants (Cursor, Claude Code, GitHub Copilot) to build against your product. Those tools don't discover llms.txt automatically, but a developer can manually point their coding agent at your /llms.txt URL, and when they do, it saves the assistant from wading through your site's navigation, cookie banner and marketing copy to find the documentation it actually needs.

If you run a blog, an e-commerce store or a local business site, you can skip this. There's no evidence it does anything for you, and your time is better spent on crawl access, renderable content and structured answers.

The two files

/llms.txt is a short index - a map of your site's key resources, in root-level, plain Markdown.

/llms-full.txt is the expanded version: your entire documentation set stitched into one continuous Markdown file, for tools that want to ingest everything in one pass rather than following links.

Not every site needs the second file. Add it once your documentation is substantial enough that following individual links becomes inefficient.

Structure of /llms.txt

The format is deliberately simple: an H1 for your site or project name, a blockquote for a one-line summary, H2s for sections, and plain Markdown bullet links for navigation.

# Website Title or Project Name

> A concise, one-sentence description of what this website or software project does. Keep this under 150 characters to save AI tokens.

## Main Overview
A brief paragraph providing critical context about the organization, project, or primary documentation. This helps the LLM understand the core purpose before it reads further.

## Core Resources
* Getting Started Guide (/docs/getting-started): Quick introduction to installation and initial setup.
* API Reference (/docs/api): Complete documentation for our public REST endpoints.
* Configuration Options (/docs/config): Detailed breakdown of env variables and settings.

## Secondary Resources
* Troubleshooting FAQ (/docs/faq): Solutions to common errors and deployment bugs.
* Changelog (/docs/changelog): Latest version updates and breaking changes.

## Full Content
* Full Documentation Bundle (/llms-full.txt): A single text file containing all documentation for easier ingestion.

Place this at your site root (https://example.com/llms.txt) so it's found the same way robots.txt and sitemap.xml are.

Structure of /llms-full.txt

Consolidate your documentation into one file, using H1s to mark where each original page begins. Each page section can include tagged code fences (for example, a bash block for install commands and a typescript block for API examples).

# Website Title - Complete Content

> This file consolidates all documentation into a single file for complete context window ingestion.

---

# Page 1: Getting Started

## Installation
Run the following command to install the package:
(npm install example-package)

## Quick Start
Initialize the library in your code...

---

# Page 2: API Reference

## Authentication
All requests must include the Bearer token header...

Rules that matter

Use relative URLs. Links inside both files should be relative (/docs/api, not https://example.com/docs/api), so the file resolves correctly regardless of environment or domain mapping.

Declare the language on every code fence. Always tag code blocks (```typescript, ```bash) so a coding assistant parses syntax correctly rather than guessing.

Cut the structural fluff. No headers, footers, cookie banners, or sidebar navigation. These files exist to save tokens - padding them with boilerplate defeats the point.

Keep the summary line under ~150 characters. It's the first thing consumed and the cheapest to get wrong by making it too long.

Automating it, so it doesn't go stale

A hand-written llms.txt drifts out of date the moment your documentation changes, and a stale index is arguably worse than none - it actively misdirects. Wire generation into your build rather than maintaining it by hand:

• VitePress: the vitepress-plugin-llms (or vitepress-plugin-llmstxt) packages generate llms.txt and llms-full.txt automatically from your existing docs source at build time.
• Next.js: next-plugin-llms generates llms-standard output from your Next.js documentation routes.
• Mintlify-hosted docs: Mintlify generates and serves llms.txt automatically for sites built on it, no separate build step required.

If your framework isn't covered by an existing plugin, a simple build script that walks your docs directory and emits both files following the structure above is a half-day job at most - treat it the same as your sitemap generation: automated, run on every deploy, never hand-maintained.

Quick checklist

• Confirm this is worth doing for your site type (dev docs / API / SaaS, yes; blog / e-commerce / local business, skip)
• /llms.txt at site root, H1 + blockquote summary + H2 sections + relative links
• /llms-full.txt if your docs are substantial enough to warrant it
• Code fences tagged with language
• No structural fluff
• Generation wired into your build pipeline, not maintained by hand
• Set a reminder to spot-check it after any major documentation restructure

Validate what you publish with our free llms.txt checker - it flags missing structure, broken formatting and HTML masquerading as a text file.

References

• Answer.AI, /llms.txt - a proposal to provide information to help LLMs use websites
• GitHub, vitepress-plugin-llms
• GitHub, next-plugin-llms
• Mintlify, How to generate llms.txt
• dev.to, Using llms.txt with Cursor and Claude Code: a concrete playbook