JPKCom DB

llms.txt Generator — Tips & Tricks

Insider moves for the llms.txt Generator: write an effective llms.txt, weigh validator messages, link Markdown versions, serve it right, and the GEO score.

Back to the overview: llms.txt Generator · Open the tool: www.jpkc.com/tools/llms/

The manual explains every field and rule; the examples show the workflows. This page covers what both assume but rarely spell out: what actually makes an llms.txt useful, which validator messages really matter, and how the tool fits your GEO strategy. The tool's interface is in English, so the real tab and button names appear here exactly as you'll see them.

Write an llms.txt that AI systems actually use

The llms.txt is not an SEO trick but a curated table of contents for AI. The tool collects the best practices in its Tips tab — the most important ones:

  • The summary is the heart of it. The blockquote is often the first thing an agent reads. One precise sentence stating exactly what your project does — no marketing fluff. The spec doesn't require a summary, but the tool labels it as recommended and warns when it's missing.
  • Curate, don't dump. Link only your 5–20 most important pages. Quality beats quantity: AI systems benefit from focused, relevant context, not a complete listing. That's the core difference from a sitemap (more on that below).
  • Every link needs a note. The text after the colon (- [Title](URL): Note) tells the agent before fetching what a page contains — and that's what it picks pages by. Bare links force it to guess. The check counts how many of your links have a note.
  • Group logically. Use sections (## …) to bundle related pages — Docs, API, Guides, About. On a large site, H3 subsections (### …) subgroup further within a section; they are, however, a generator extension and not part of the spec (more on that below).
  • Use meaningful titles. "API Authentication Guide" beats "API". Vague titles like "Page 1" or "Click here" help no one.
  • Keep it updated. Stale links and notes undermine trust. Maintain the file after every major site rework — the generator makes that easy via Open File → edit → Download.

Pitfalls the validator flags

The Check tab and the check results in the generator use three levels. When you check your own file, it pays to know the most common hits and how much they weigh:

  • Missing or empty H1 = error. The title (#) is the only element the spec requires.
  • Text before the H1 = error. The file must start with # Name — even a comment before it counts; blank lines don't. A byte-order mark, on the other hand, is allowed since v2 (just an info note).
  • Link with an empty URL = error. A list item - [Title]() with no address. When writing by hand, watch for complete (URL) parentheses.
  • HTML instead of text = error. If the address returns an HTML page, there usually is no llms.txt there at all — the server is showing an error or start page with status 200.
  • Missing summary = warning. Since v2 the blockquote is recommended, not required. The file is valid, but agents miss the quick overview.
  • Relative URLs = warning. /docs/start instead of https://…/docs/start goes wrong when an agent reads the file detached from your domain. Write absolute URLs.
  • Wrong separator or wrong bullet = warning. Notes start with : (not -), list items with - (not * or +). When you load a file via Open File, the generator fixes both automatically.
  • Brackets in names or URLs = warning. The reference parser misreads a ] in a link name or ( ) in a URL. The generator encodes parentheses in URLs as %28 %29 on its own; square brackets in a name it escapes correctly, but only a name without ] keeps the reference parser happy.
  • No section or no links = warning. Two or three sections are usually enough — but there should be some structure.
  • Too large = warning, too small = info. Over 50,000 bytes the file no longer fits comfortably into the context window; under 100 bytes the tool only shows an info note. The recommendation from the Tips tab: llms.txt under 50 KB, ideally under 10 KB; 5–20 curated links; 2–5 sections.
  • Content type and charset = warning. The file should be served as text/plain or text/markdown, with charset=utf-8 as soon as it contains non-ASCII characters. The snippets under Serving & discovery take care of that.
  • Missing notes, http:// links = info. Not an error, but polish that makes the agent's choice easier.

Rule of thumb: an H1 at the top, no empty URLs, and a real text file are the red lines. A summary, absolute URLs, and clean link syntax make the file good; everything else is polish.

Reading the grey reference parser badge correctly

The badge below the output and the last row of the check summary tell you whether the parser from the llms-txt Python package can read the file. Grey does not mean invalid: since v2 that tool is no longer part of the proposal, and agents read the file directly. The reference parser already fails on running text under an H2 or on missing text between the H1 and the first section — things that occur in large, real-world llms.txt files, too.

If you still want maximum compatibility, skip Add Text (section text) and H3 subsections, and write at least a summary or details between the title and the first section. If you need the structure for humans and agents, keep it: the validator lists both only as info notes, and the result then reads "No errors or warnings — minor deviations from the spec are listed as notes".

What does not belong in the llms.txt

  • No sitemap dump. A sitemap lists every URL; the llms.txt is a curated selection. Leave out login pages, search results, profile and admin areas.
  • Nothing behind a login. Don't link authenticated pages, internal tools, or anything not meant for the public. The file itself must be publicly reachable without auth.
  • No keyword stuffing. The llms.txt provides context for AI; it's not a ranking lever. A summary stuffed with keywords is counterproductive.
  • Don't over-section. One section per page is too much — group them. Two or three sections are often enough.

Where the file goes — and llms-full.txt

  • Default location: https://yourdomain.com/llms.txt, public, without a login, as UTF-8 text (a byte-order mark is allowed), served as text/plain or text/markdown.
  • Subpaths: https://yourdomain.com/docs/llms.txt covers everything under /docs/; the most specific file applies. In the Check tab, enter the directory with a trailing slash (yourdomain.com/docs/); under Serving & discovery, the path /docs/.
  • Make it discoverable: let your pages point to the llms.txt with rel="describedby" — as a Link header or a <link> in the <head>. The Serving & discovery card in the generator produces the matching configuration for nginx, Apache, or HTML, including the correct content type.
  • Optional: an llms-full.txt holding the merged full text of all linked pages — for LLM clients with large context windows that would rather fetch one file than make many individual requests. It may be large (100 KB – 5 MB). It isn't prescribed by the spec but a widespread convention. In the generator you only enter the URL and, optionally, a note; the tool puts the link into the ## Optional section. The best way to produce it is during your build, by concatenating the Markdown versions of the linked pages.

Agents cope far better with clean Markdown than with HTML full of navigation, scripts, and ads. That's why spec v2 recommends offering a Markdown version of every important page at the same URL (page.html.md or page.md) and linking exactly those in the llms.txt.

  • Don't rewrite by hand: enter your normal page URLs and set Link targets to Markdown version, appended or replaced. The tool only rewrites the output; your input stays as it is — switching back to As entered is all it takes.
  • Provide first, then switch: the Markdown URLs must exist on your server. Then test them with the link check in the Check tab — "Broken link" reveals missing twins, "HTML page" links that still lead to HTML.
  • Don't forget the content type: .md files should be served as text/markdown; charset=utf-8. The nginx and Apache snippets under Serving & discovery include the matching rule.

Combining with the SEO & GEO Analyzer

The strongest pairing: build here, check it in the GEO score there. The SEO & GEO Analyzer rates a whole page and lets the llms.txt feed into the GEO score via two checks:

  • llms.txt Present (3 points) — only requires a reachable, non-empty file.
  • llms.txt Valid Structure (2 points) — full marks only at 0 errors and 0 warnings; warnings alone earn one point, errors none.

Both tools use the same validator module — so a file checked green in the llms.txt Generator also turns both llms.txt checks green in the GEO score. Info notes, such as those about the reference parser or H3 subsections, cost no points there. Keep in mind that the analyzer only looks for /llms.txt in the domain's root; a file that exists only under a subpath doesn't count towards the score. The workflow:

  1. Build the file in the llms.txt Generator (or load and fix the old one via Open File) until the Check tab reports green.
  2. Upload it to your web root.
  3. Analyze the page in the SEO & GEO Analyzer and read the jump in llms.txt Present and llms.txt Valid Structure under AI Discoverability in the GEO Score tab.

That turns a single file into a measurable contribution to your whole page's AI readiness. While you're at it, don't lock out AI crawlers — the analyzer checks that separately via AI Crawlers Allowed, which you get right with robots.txt & Sitemap.

More context: the overview for the big picture, the manual for every field and rule, and the examples for the step-by-step workflows. You can try all of it directly in the tool.