Draft an llms.txt file
Generate a concise file that points language-model tools toward the site's most important public pages.
llms.txt Generator + Validator
Free, no signup. Build a clean llms.txt that points LLMs at your key pages, or paste one you already have and check that it's well-formed.
| Check | Status when healthy |
|---|---|
| H1 | One site-name H1 |
| Summary | A short blockquote is recommended |
| Links | Grouped, absolute HTTPS URLs |
| Size | Keep the map concise (under ~20 KiB) |
Heads up:
llms.txt is a community proposal
(llmstxt.org), not an official standard.
No major AI crawler is documented to read it today. Treat it as low-effort, low-risk housekeeping —
not a ranking lever. If you want to influence what AI systems can access, that's
robots.txt and your on-page content, not this file.
More on how AI crawlers actually work → Want evidence instead of assumptions?
Upload your own access log to the Log File Analyzer. Its browser-local /llms.txt report distinguishes verified AI crawler requests, unverifiable crawler claims, spoofed claims, other traffic, and no observation in the supplied period. A request is retrieval evidence only—not proof of rankings, citations, or broad provider adoption.
The Optional section (a crawler may skip it) is emitted last automatically — just name a section “Optional”.
Output — llms.txt
Runs entirely in your browser — nothing you paste is uploaded or stored. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
We fetch only <domain>/llms.txt (nothing else) — browsers can't, because of CORS.
Runs entirely in your browser — nothing you paste is uploaded or stored. Fetch by URL sends only the domain to our server to retrieve /llms.txt (browsers can't — CORS); validation still runs locally. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Sample report
Fill in a site name, a summary, two sections, and an Optional link, and the generator emits this
llms.txt — one # title, a > summary blockquote,
## section headings with Markdown link rows, and the Optional section
moved to the end:
# Acme Docs
> Acme builds developer tools. This file maps our docs, guides, and API reference.
## Docs
- [Getting started](https://acme.example/docs/start): 5-minute quick start
- [API reference](https://acme.example/docs/api): every endpoint and field
## Guides
- [Authentication](https://acme.example/guides/auth): tokens, scopes, rotation
## Optional
- [Changelog](https://acme.example/changelog)
Example data — captured by running this page's own validator against the file above
0 errors 0 warnings 0 info
- 0 errors, 0 warnings — the file has a title, a summary placed right after it,
absolute
https://links grouped under sections, and no duplicates. See what each severity means ↓. - "Optional" landed last automatically because the generator always emits that named section after every other section, regardless of input order.
- A clean validator result says nothing about adoption — no major AI crawler has
published support for reading
llms.txt. Read llms.txt for why this is a proposal, not a directive.
How to use it
- Generate tab: enter your Site name (becomes the required
#title) and a one-line summary (the>blockquote). Optionally add a Site URL so off-site links get flagged. - Add sections (Docs, Guides, Blog) and a link row under each —
title, absolute
https://URL, and optional notes. Or hit Prefill from sitemap.xml to auto-bucket URLs by their first path segment. - Name any section “Optional” and it is emitted last automatically — that's the proposal's skippable section. Watch the live Output pane; it self-validates as you type.
- Copy, Download llms.txt, or Copy share link (state is packed into the URL fragment — nothing is sent anywhere).
- Validate tab: paste an existing file, or switch to
Fetch by URL, enter a domain, and we pull only its
/llms.txtfor you. Read the error/warning/info pills and the parsed-structure preview.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Rate this tool
Where this is heading: serving Markdown to LLMs
Looking ahead — not something to do today. llms.txt and per-page Markdown are proposals no major AI crawler is documented to consume yet.
llms.txt is a directory — one file pointing at your key pages. The more interesting
idea, once AI clients adopt it, is content negotiation: same URL, two representations.
Serve HTML to browsers and a clean Markdown rendering to LLM clients,
and decide which at the edge.
A Cloudflare Worker picks the representation from the request — either
Accept: text/markdown or a known AI user-agent — and emits
Vary: Accept (or Vary: User-Agent) so shared caches don't hand the wrong
variant to the wrong client.
It's exactly the move behind this site's hybrid /robots.txt —
same bytes, only the Content-Type label negotiated — just extended to actual content,
and to a real body difference rather than only a header.
This tool does two jobs: it generates a well-formed llms.txt from a
simple form (or a sitemap you upload), and it validates one you paste or fetch from
a live domain. Both run entirely in your browser. For context on why this file is optional
housekeeping rather than a ranking move, see
how AI crawlers actually work and
the llms.txt explainer.
What the results mean
The validator groups findings into three severities, shown as pills:
- The file breaks the proposal's shape —
no
#title, a malformed list item that isn't a[title](url)link, a relative (non-absolute) URL, or an empty file. - Well-formed but not ideal — no
>summary, anhttp://link, a duplicate URL, a second#H1, or links that appear before any##section. - Advisory only — a summary placed
somewhere other than right after the title, an off-site link, a deep
###heading that isn't part of the structure, or a file large enough (past 20 KiB) to have stopped being a concise map.
A green result means the file is well-formed against the proposal. The result summary is deliberately blunt that this validates form only and cannot guarantee any AI system consumes the file.
How it works
The generate/parse/validate engine (src/lib/tools/llms-txt.ts) is pure TypeScript with
no DOM and no network calls, so everything you do in the Generate and
paste flows happens locally in your browser — your draft never leaves the page.
The parser reads line by line: it recognises the # title, a >
blockquote summary, ## section headings, and Markdown link list items, while skipping
the insides of fenced ``` code blocks so they aren't misread as directives. It then
runs file-level checks — required title, recommended summary, duplicate URLs, absolute-URL and
HTTPS rules, and size — and rolls everything into the error/warning/info tally.
The one server touch is Fetch by URL: browsers can't fetch another site's
/llms.txt because of CORS, so a small SSRF-guarded, cached proxy
(/api/llms-fetch) pulls only that exact path — nothing else on the domain — and hands
the body back for validation.
Features
- Form-based generator with add/remove sections and link rows, live output, and self-validation as you type.
- Prefill from sitemap.xml — upload a sitemap and it buckets URLs by first path segment into ready-to-edit sections.
- Automatic handling of the Optional section (always emitted last).
- Copy, download, and a share link that packs your draft into the URL fragment (compressed, never sent to a server).
- Validator with paste or live Fetch /llms.txt by domain, an error/warning/info tally, per-line findings, and a parsed-structure preview.
- Runs client-side; the only server call is the CORS-bypassing llms.txt fetch.
Limitations
It validates the form of the file against the community proposal — it cannot tell
you whether any AI crawler reads it, because none is documented to. It checks link syntax
(absolute, HTTPS, well-formed Markdown) but does not crawl the links to confirm they resolve or
return the content you claim. The sitemap prefill is a starting point, not a curation step — an
llms.txt is only useful if you trim it to your genuinely important pages. And this is
not a lever for AI visibility: what AI systems can access is governed by your
robots.txt and your on-page content.
Frequently asked questions
Do AI crawlers actually read llms.txt?
Not in any documented way. llms.txtllms.txt is a proposed (not adopted) Markdown file at /llms.txt that gives AI systems a curated map of a site's most important pages. Proposed by Jeremy Howard in 2024, it's read mostly by coding agents like Claude Code — not search crawlers — and Google ignores it. is a community proposal from llmstxt.org, not an official standard, and no major AI crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. (OpenAI, Google, Anthropic, Perplexity) has published support for reading it. Treat it as low-effort, low-risk housekeeping — a tidy map of your best pages — not a ranking lever. What AI systems can actually reach is governed by your robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. and your on-page content.
What goes in an llms.txt file?
One required "# " H1 title (your site name), a recommended "> " blockquote one-line summary right after it, then "## " section headings (Docs, Guides, Blog) each containing Markdown link list items in the form "- [title](url): optional notes". A special "## Optional" section holds links a crawler may skip. Every link URL should be an absolute https:// address the LLM can fetch directly.
Where does the llms.txt file go on my site?
At the root of your domain, served at https://site.example/llms.txt — the same location convention as robots.txt. This validator can fetch that exact path for any domain (via a small server-side proxy, because browsers cannot fetch cross-origin) so you can check a live file without pasting it.
What does the validator check?
The form of the file against the proposal, not whether anything reads it. It flags a missing H1 title (error), missing summary (warning), malformed or relative link URLs, http:// links, duplicate URLs, links that appear before any section, deep "### " headings that are not part of the structure, off-site links, and files large enough to have stopped being a concise map. It cannot and does not guarantee any AI system consumes the file.
How big should llms.txt be?
Small. It is a directory of links, not a copy of your content. The validator raises an informational note once a file passes about 20 KiB, because at that size it has usually stopped being a concise map and started duplicating pages. If you want to serve full clean content to LLMs, that is per-page Markdown and content negotiation, not a bigger llms.txt.
Feature requests for Llms Txt
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Validate an existing file
Paste or fetch llms.txt and check its H1, summary, absolute links, duplicates, and off-site destinations.
Review a file before deployment
Catch formatting and URL problems locally before publishing the document at the site root.
Set honest stakeholder expectations
Explain that llms.txt is a community proposal, not an official standard that major AI crawlers are documented to follow.
Watch the full workflow
llms.txt Generator + Validator walkthrough
Read the transcript
llms.txt Generator + Validator
llms dot t-x-t is a community proposal, not a supported ranking directive. I’ll show you appropriate use cases, how to generate and validate a file, the required structure, the built-in template and sample result, main features, limitations, deployment steps, and stronger evidence to check next.
Step 1
The file is a proposed Markdown directory that points at important pages. No major A-I crawler is documented to consume it today, so treat it as low-cost housekeeping, not a ranking factor, access control, or adoption signal. Robots dot t-x-t and page content remain more consequential.
Step 2
It can provide a concise map for documentation, product help, research, guides, or other stable canonical resources. It should not duplicate full pages, replace navigation or sitemaps, include every U-R-L, or promise A-I citations. Curate pages that are public, useful, current, and directly fetchable.
Step 3
Enter a site name, optional site U-R-L, one-line summary, and optional details, or insert the canonical template. Add named sections and link rows manually or prefill from a sitemap. The generator updates and self-validates locally as you edit.
Step 4
A well-formed file has one hash title, a recommended blockquote summary immediately after it, double-hash section headings, and Markdown list links with absolute H-T-T-P-S U-R-Ls and optional notes. A section named Optional is emitted last so clients may skip it.
Step 5
The left pane shows the exact file bytes and the right pane previews the Markdown. Check the title, summary, section order, link labels, absolute destinations, and notes. Remove generic or duplicate pages. The share link stores compressed state in the U-R-L fragment rather than uploading the draft.
Step 6
Switch to Validate, paste a file, and run the local parser. You may instead fetch only slash l-l-m-s dot t-x-t from a public domain through the guarded proxy. The clean sample returns zero errors and warnings, which confirms structure only—not crawler use.
Step 7
Errors cover missing title, empty files, malformed links, and relative U-R-Ls. Warnings cover missing summary, insecure links, duplicates, extra top-level titles, or links outside sections. Information notes cover misplaced summaries, off-site links, deep headings, or a file larger than about twenty kibibytes.
Step 8
Review each line-level finding and the parsed title, summary, sections, and links. A green result only says the syntax matches the proposal. It does not check whether destinations return two hundred, contain the claimed information, allow crawling, or are consumed by any A-I system.
Step 9
Features include live generation, removable sections and links, sitemap prefill, automatic Optional ordering, copy, download, fragment-based sharing, paste validation, public-root fetching, issue counts, and a parsed preview. Build l-l-m-s-full is experimental and should not turn the directory into a content dump.
Step 10
The validator checks form, not adoption, link health, factual accuracy, crawl permission, ranking, citation, or A-I visibility. Sitemap grouping is only a starting point and must be curated. Fetching is limited to the conventional root path. A valid file can still be useless, stale, inaccessible, or ignored.
Step 11
Download the file, review it with content owners, and serve it at slash l-l-m-s dot t-x-t with a successful response and readable text. Check every listed U-R-L, redirects, canonicals, robots rules, authentication, and maintenance ownership. Revalidate after edits and remove obsolete destinations.
Step 12
Document the publication date, scope, owner, validator result, and link checks. Then use access logs to distinguish verified A-I crawler requests, unverifiable claims, spoofed identities, ordinary traffic, and no observation. Retrieval is still not proof of training, citation, rankings, or provider-wide support.
Keep it concise—and keep expectations honest.
Publish the reviewed file at the root, confirm its response and links, and update it when your key pages change. Keep robots controls and on-page content as the real access foundations, and use server logs to look for verified retrieval instead of assuming adoption or visibility impact.
Common issues & how to fix them
- Error File contains multiple H1 titles Fix: Keep exactly one H1 for the site name and convert additional top-level headings to H2 sections.
- Error Link URL is relative Fix: Replace the relative link with a fully qualified HTTPS URL that a crawler can fetch directly.
- Error Link URL is invalid Fix: Correct the malformed link target to a valid absolute HTTPS URL.
- Warning Link URL uses HTTP Fix: Change the HTTP link to its working HTTPS equivalent.
- Information Link points to another host Fix: Remove the off-host link or place it in the llms.txt file owned by that host.
- Error File has no H1 title Fix: Add exactly one # H1 at the top containing the site or project name.
- Warning File has no summary blockquote Fix: Add a short > blockquote summary immediately after the H1.
- Information Summary is not directly after the title Fix: Move the summary blockquote directly below the H1 before any section heading.
- Warning No sections contain links Fix: Add useful absolute HTTPS links beneath descriptive H2 section headings.
- Warning Optional section is not last Fix: Move the ## Optional section after every required or primary link section.
- Warning Link URL is duplicated Fix: Keep the URL once under its most relevant section and remove duplicate entries.
- Information File is too large for a concise map Fix: Trim low-value links and descriptions until the file is a concise map under roughly 20 KiB.
- Error File is empty Fix: Add one H1, a short summary, and grouped absolute HTTPS links to the site’s key resources.