~/TechPurAI
~/tools/llms-txt-generator
AI Search & LLM Visibility

llms.txt Generator & Validator

llms.txt
# Example Project

> A short, one-sentence description of what this project or site is.

Optional additional context an AI system might need before reading further.

## Docs

- [Getting Started](https://example.com/docs/getting-started): Setup and first steps.

llms.txt is a proposed convention — a plain-text, markdown-formatted file at a site's root — meant to give AI systems a concise, curated map of a site's most important content, in a format that's directly readable without needing to parse HTML or infer structure from navigation menus. This tool builds a spec-compliant file from your site's actual sections and links, and validates an existing one's structure.

Where llms.txt came from, and what it's actually trying to fix

The convention was proposed by Jeremy Howard (co-founder of Answer.AI and fast.ai) in 2024, motivated by a specific, practical observation: AI systems that answer questions using live web content — retrieval-augmented chat systems, AI search engines, coding assistants that browse documentation — generally have to work with an entire site's raw HTML, inferring what's actually important from navigation structure, headings, and page hierarchy the same way a search engine crawler does. That's a lossy, imprecise process, and it's particularly wasteful for AI systems working within a limited context window, where fetching and parsing an entire page's HTML — navigation chrome, footer links, cookie banners, and all — to extract a handful of genuinely relevant facts is expensive and often unreliable. llms.txt proposes a direct fix: a short, deliberately curated, plain-markdown index sitting at a predictable, well-known location (/llms.txt), giving any AI system that chooses to look for it a fast, low-noise map of what actually matters on the site.

The file's actual structure, and why each part exists

The convention specifies a fairly minimal shape. A single # heading names the site or project. A blockquote (>) immediately after gives a one-to-two-sentence summary — the single most important thing an AI system reading only that far should understand. An optional paragraph of additional context can follow, for anything a reader needs to know before diving into the linked sections. Then one or more ## sections organize links into logical groups, each link written as a standard markdown link followed by a colon and a short description: - [Getting Started](https://example.com/docs/start): Setup and first steps. An optional final ## Optional section is reserved specifically for lower-priority links — a convention that lets an AI system with a very tight context budget skip that section entirely and still get the most important content from everything above it. Every part of this structure exists to serve the same goal: letting a system with limited time or context budget get maximum value from reading as little of the file as possible, front-loading the highest-value information first.

Curated, not exhaustive — the most important design principle

The temptation, especially for a larger site, is to treat llms.txt as "the sitemap, but markdown" and simply list every page. This defeats the entire purpose. A sitemap.xml is deliberately exhaustive — every indexable URL, with no editorial judgment, because its job is ensuring nothing gets missed during crawling. llms.txt is deliberately the opposite: a short, hand-curated selection of the pages and sections that actually matter most, written with enough editorial judgment to be genuinely useful to something reading it under time or context pressure. A 500-page site with an llms.txt listing all 500 pages has produced something functionally identical to a sitemap and has thrown away the one property that made llms.txt worth creating in the first place — its selectivity.

Being honest about how much this actually helps right now

It would be misleading to present llms.txt as a proven, guaranteed lever for AI visibility — no major AI company has published a clear, verifiable commitment to prioritizing or even consistently checking for it, and adoption across the AI ecosystem remains uneven and largely unconfirmed at the level of any specific system's actual behavior. The honest, grounded case for maintaining one is about asymmetric cost and risk rather than a guaranteed payoff: the file costs very little to create and keep updated, causes no downside whatsoever if a given AI system happens to ignore it, and stands a real, non-zero chance of being genuinely useful as more systems adopt the convention over time — which is exactly the calculation that led this site to publish and maintain its own llms.txt as a working example, not because its effect has been definitively measured, but because the downside risk of maintaining one is close to zero.

Keeping it accurate as a site changes

An llms.txt file that quietly falls out of sync with what's actually on the site — describing a section that's been restructured, linking to a page that's moved or been removed — is arguably worse than not having one at all, since it actively misleads whatever reads it rather than simply providing nothing. Treating llms.txt as a living file that gets updated alongside major content or navigation changes, rather than a one-time artifact created once and forgotten, is what keeps it trustworthy for the systems it's meant to help.

How this differs from robots.txt and sitemap.xml, side by side

robots.txt controls crawling permission — what a crawler is and isn't allowed to fetch — and says nothing about content or priority. sitemap.xml is an exhaustive, uncurated list of every indexable URL, meant to ensure complete crawl coverage. llms.txt is neither a permission mechanism nor an exhaustive index — it's a curated, editorially-selected content map, written in a format optimized for a language model or AI retrieval system to read directly and efficiently. The three files serve genuinely different, complementary purposes, and a site that maintains all three is covering crawling permission, complete discoverability, and AI-optimized content prioritization as three distinct, non-overlapping concerns.

Write descriptions for the reader, not for keyword stuffing

Each link's description exists to help an AI system (or a person) quickly judge whether that link is relevant to what they're looking for — a clear, honest one-line summary of what's actually there. Padding descriptions with keywords rather than genuine, useful context defeats the file's actual purpose and produces a worse map, not a better-optimized one.

Frequently asked questions

Is llms.txt an official, enforced web standard, like robots.txt?

No — it's a proposed convention, put forward by Jeremy Howard and the team at Answer.AI in 2024, that a growing number of sites (including this one) have voluntarily adopted, but it isn't governed by a standards body and no major AI company has publicly committed to reading or prioritizing it the way search engines universally respect robots.txt. It's best understood as an emerging best practice worth adopting for the sites where it's cheap to maintain and potentially useful, not as a guaranteed lever with a documented, predictable effect.

What actual problem is llms.txt trying to solve?

AI systems that answer questions using web content generally work by retrieving and reading pages at query time, or by having been trained on crawled content — both approaches benefit from a concise, curated map of what a site actually contains and where the most important content lives, rather than having to crawl and interpret an entire site's raw HTML and inferred navigation structure from scratch. llms.txt is meant to be exactly that: a short, plain-text, deliberately AI-readable index of a site's key pages, written in simple markdown rather than requiring HTML parsing at all.

Why does llms.txt use markdown instead of JSON or XML, the way sitemaps and structured data do?

Because markdown is unusually easy for both humans and language models to read directly, without any parsing step — a person can open llms.txt in a plain text editor and immediately understand it, and a language model can process it as ordinary text without needing a dedicated parser the way XML or strict JSON effectively requires. That dual readability, by a person and by a model, without any format-specific tooling, is the whole design rationale behind choosing markdown over a more rigid structured format.

Should llms.txt just be a copy of my sitemap.xml?

No — and treating them as duplicates misses the actual point of llms.txt. A sitemap.xml is exhaustive by design: every indexable URL a site has, with no editorial judgment about relative importance. llms.txt is meant to be curated and selective — a short, deliberately edited list of a site's most important sections and pages, with a one-line description of each, giving an AI system a fast, high-value map instead of an undifferentiated list of every URL that happens to exist. A large site's llms.txt listing every single page would defeat the purpose entirely.

Does having an llms.txt file guarantee an AI system will actually read or use it?

No guarantee exists, since adoption is voluntary and inconsistent across different AI systems and companies, and this is worth being clear-eyed about. The honest case for maintaining one right now is asymmetric risk: it costs very little to create and keep updated, it causes no downside if a given AI system ignores it entirely, and it stands a real chance of being genuinely useful as more systems adopt the convention over time — a reasonable bet with low cost and only upside, not a guaranteed traffic lever.