llms.txt Generator — Tipps & Tricks

Zurück zur Übersicht: llms.txt Generator · Tool live öffnen: www.jpkc.com/tools/llms/

Das Manual erklärt jedes Feld und jede Regel, die Beispiele zeigen die Arbeitsabläufe. Hier geht es um das, was beides voraussetzt, aber selten dabeisteht: was eine llms.txt wirklich nützlich macht, welche Meldungen des Validators wirklich zählen und wie das Tool in deine GEO-Strategie passt. Die Oberfläche ist auf Englisch — die echten Tab- und Button-Namen stehen deshalb im Original, bei Bedarf mit deutscher Erläuterung.

Eine llms.txt schreiben, die KI-Systeme wirklich nutzen

Die llms.txt ist kein SEO-Trick, sondern ein kuratiertes Inhaltsverzeichnis für KI. Das Tool fasst die Best Practices im Tips-Tab zusammen — die wichtigsten:

Die Summary ist das Herzstück. Das Blockquote ist oft das Erste, was ein Agent liest. Ein präziser Satz, der exakt erklärt, was dein Projekt tut — keine Marketing-Floskel. Pflicht ist die Summary laut Spezifikation nicht, das Tool kennzeichnet sie aber als empfohlen und warnt, wenn sie fehlt.
Kuratieren statt dumpen. Verlink nur deine 5–20 wichtigsten Seiten. Qualität schlägt Quantität: KI-Systeme profitieren von fokussiertem, relevantem Kontext, nicht von einer Komplettliste. Das ist der Kernunterschied zur Sitemap (dazu unten mehr).
Jeder Link braucht eine Notiz. Der Text nach dem Doppelpunkt (- [Titel](URL): Notiz) sagt dem Agenten vor dem Abruf, was eine Seite enthält — danach wählt er aus. Nackte Links zwingen ihn zum Raten. Der Check zählt mit, wie viele deiner Links eine Notiz haben.
Logisch gruppieren. Nutz Sektionen (## …), um verwandte Seiten zu bündeln — Docs, API, Guides, Über uns. Bei einer großen Seite gliedern H3-Subsektionen (### …) innerhalb einer Sektion weiter; die sind allerdings eine Erweiterung des Generators und nicht Teil der Spezifikation (mehr dazu unten).
Aussagekräftige Titel. „API Authentication Guide" schlägt „API". Vage Titel wie „Seite 1" oder „Hier klicken" helfen niemandem.
Aktuell halten. Veraltete Links und Beschreibungen untergraben das Vertrauen. Pflege die Datei nach jedem größeren Site-Umbau — der Generator macht das per Open File → bearbeiten → Download leicht.

Stolperfallen, die der Validator meldet

Der Check-Tab und die Prüfhinweise im Generator unterscheiden drei Stufen. Wenn du eine eigene Datei prüfst, lohnt es, die häufigsten Treffer und ihr Gewicht zu kennen:

Fehlende oder leere H1 = Fehler. Der Titel (#) ist das einzige Pflichtelement der Spezifikation.
Text vor der H1 = Fehler. Die Datei muss mit # Name beginnen — schon ein Kommentar davor zählt; Leerzeilen stören nicht. Ein Byte-Order-Mark ist dagegen seit v2 erlaubt (nur ein Hinweis).
Link mit leerer URL = Fehler. Ein Listenpunkt - [Titel]() ohne Adresse. Achte beim Handschreiben auf vollständige (URL)-Klammern.
HTML statt Text = Fehler. Liefert die Adresse eine HTML-Seite, gibt es dort meist gar keine llms.txt — der Server zeigt eine Fehler- oder Startseite mit Status 200.
Fehlende Summary = Warnung. Seit v2 ist das Blockquote empfohlen, nicht Pflicht. Die Datei ist gültig, aber Agenten fehlt der schnelle Überblick.
Relative URLs = Warnung. /docs/start statt https://…/docs/start geht schief, wenn ein Agent die Datei losgelöst von deiner Domain liest. Schreib absolute URLs.
Falscher Trenner oder falsches Listenzeichen = Warnung. Notizen beginnen mit : (nicht mit -), Listenpunkte mit - (nicht * oder +). Beim Laden per Open File korrigiert der Generator beides automatisch.
Klammern in Namen oder URLs = Warnung. Ein ] im Linknamen oder ( ) in der URL liest der Referenz-Parser anders. Klammern in URLs kodiert der Generator beim Schreiben selbst als %28 %29; eckige Klammern im Namen maskiert er zwar korrekt, den Referenz-Parser stellt aber nur ein Name ohne ] zufrieden.
Keine Sektion oder keine Links = Warnung. Zwei bis drei Sektionen reichen meist — aber eine Struktur sollte da sein.
Zu groß = Warnung, zu klein = Hinweis. Über 50.000 Bytes passt die Datei nicht mehr bequem ins Kontextfenster; unter 100 Bytes meldet das Tool nur einen Hinweis. Die Empfehlung aus dem Tips-Tab: llms.txt unter 50 KB, ideal unter 10 KB; 5–20 kuratierte Links; 2–5 Sektionen.
Content-Type und Zeichensatz = Warnung. Ausgeliefert werden sollte die Datei als text/plain oder text/markdown, mit charset=utf-8, sobald Umlaute vorkommen. Die Schnipsel unter Serving & discovery erledigen das.
Fehlende Notizen, http://-Links = Hinweis. Kein Fehler, aber Feinschliff, der Agenten die Auswahl erleichtert.

Merksatz: H1 am Anfang, keine leeren URLs und eine echte Textdatei sind die roten Linien. Summary, absolute URLs und saubere Link-Syntax machen die Datei gut, alles andere ist Feinschliff.

Den grauen Referenz-Parser-Badge richtig lesen

Das Badge unter der Ausgabe und die letzte Zeile der Check-Zusammenfassung sagen, ob der Parser aus dem Python-Paket llms-txt die Datei lesen kann. Grau heißt nicht ungültig: Seit v2 gehört dieses Werkzeug nicht mehr zum Vorschlag, und Agenten lesen die Datei direkt. Der Referenz-Parser scheitert schon an Fließtext unter einer H2 oder an fehlendem Text zwischen H1 und erster Sektion — Dinge, die auch in großen, realen llms.txt-Dateien vorkommen.

Willst du trotzdem maximale Kompatibilität, verzichte auf Add Text (Section-Text) und H3-Subsektionen und schreib mindestens eine Summary oder Details zwischen Titel und erste Sektion. Brauchst du die Gliederung für Menschen und Agenten, behalt sie: Der Validator führt beides nur als Hinweis, und das Ergebnis lautet dann „No errors or warnings — minor deviations from the spec are listed as notes".

Was nicht in die llms.txt gehört

Kein Sitemap-Abklatsch. Eine Sitemap listet jede URL; die llms.txt ist eine kuratierte Auswahl. Lass Login-Seiten, Suchergebnisse, Profil- und Admin-Bereiche weg.
Nichts hinter einem Login. Verlink keine authentifizierten Seiten, internen Tools oder Inhalte, die nicht für die Öffentlichkeit gedacht sind. Die Datei selbst muss ohne Auth öffentlich erreichbar sein.
Kein Keyword-Stuffing. Die llms.txt liefert Kontext für KI, sie ist kein Ranking-Hebel. Eine mit Keywords vollgestopfte Summary ist kontraproduktiv.
Nicht über-sektionieren. Eine Sektion pro Seite ist zu viel — gruppiere. Zwei bis drei Sektionen sind oft genug.

Wo die Datei liegt — und llms-full.txt

Standard-Ort: https://deinedomain.de/llms.txt, öffentlich, ohne Login, als UTF-8-Text (ein Byte-Order-Mark ist erlaubt), ausgeliefert als text/plain oder text/markdown.
Unterpfade: https://deinedomain.de/docs/llms.txt gilt für alles unter /docs/; die spezifischste Datei hat Vorrang. Im Check-Tab gibst du dafür das Verzeichnis mit Schrägstrich ein (deinedomain.de/docs/), unter Serving & discovery den Pfad /docs/.
Auffindbar machen: Lass deine Seiten per rel="describedby" auf die llms.txt zeigen — als Link-Header oder <link> im <head>. Die Karte Serving & discovery im Generator erzeugt die passende Konfiguration für nginx, Apache oder HTML samt korrektem Content-Type.
Optional: eine llms-full.txt mit dem zusammengeführten Volltext aller verlinkten Seiten — für LLM-Clients mit großem Kontextfenster, die lieber eine Datei als viele Einzel-Requests holen. Sie darf groß sein (100 KB – 5 MB). Sie ist keine Vorgabe der Spezifikation, sondern eine verbreitete Konvention. Im Generator trägst du nur URL und optional eine Notiz ein, das Tool setzt den Link in die ## Optional-Sektion. Erzeugen lässt sie sich am besten beim Build, indem du die Markdown-Versionen der verlinkten Seiten aneinanderhängst.

Markdown-Versionen verlinken statt HTML

Agenten kommen mit sauberem Markdown besser zurecht als mit HTML voller Navigation, Skripten und Werbung. Die Spezifikation v2 empfiehlt deshalb, zu jeder wichtigen Seite eine Markdown-Fassung unter derselben URL anzubieten (page.html.md oder page.md) und in der llms.txt genau diese zu verlinken.

Nicht von Hand umschreiben: Trag deine normalen Seiten-URLs ein und stell Link targets auf Markdown version, appended oder replaced. Das Tool schreibt nur die Ausgabe um, deine Eingaben bleiben erhalten — ein Wechsel zurück auf As entered genügt.
Erst bereitstellen, dann umstellen: Die Markdown-URLs müssen auf dem Server existieren. Danach mit dem Link-Check im Check-Tab testen — „Broken link" zeigt fehlende Zwillinge, „HTML page" Links, die noch auf HTML führen.
Content-Type nicht vergessen: .md-Dateien sollten als text/markdown; charset=utf-8 ausgeliefert werden. Die nginx- und Apache-Schnipsel unter Serving & discovery enthalten die passende Regel.

Mit dem SEO-&-GEO-Analyzer kombinieren

Das stärkste Tandem: hier bauen, dort im GEO-Score prüfen. Der SEO & GEO Analyzer bewertet eine ganze Seite und lässt die llms.txt mit zwei Prüfungen in den GEO-Score einfließen:

llms.txt Present (3 Punkte) — verlangt nur eine erreichbare, nicht-leere Datei.
llms.txt Valid Structure (2 Punkte) — die vollen Punkte gibt es nur bei 0 Fehlern und 0 Warnungen; nur Warnungen ergeben einen Punkt, Fehler keinen.

Beide Tools nutzen dasselbe Validator-Modul — eine im llms.txt Generator grün geprüfte Datei macht also auch im GEO-Score beide llms.txt-Prüfungen grün. Hinweise (Info), etwa zum Referenz-Parser oder zu H3-Subsektionen, kosten dort keine Punkte. Beachte: Der Analyzer sucht nur nach /llms.txt im Wurzelverzeichnis der Domain; eine Datei allein in einem Unterpfad zählt für den Score nicht. Der Workflow:

Im llms.txt Generator die Datei bauen (oder per Open File die alte laden und reparieren), bis der Check-Tab grün meldet.
Hochladen ins Web-Root.
Im SEO & GEO Analyzer die Seite analysieren und im GEO Score-Tab unter AI Discoverability den Sprung bei llms.txt Present und llms.txt Valid Structure ablesen.

So wird aus einer einzelnen Datei ein messbarer Beitrag zur KI-Readiness deiner ganzen Seite. Sperr nebenbei keine KI-Crawler aus — das prüft der Analyzer separat über AI Crawlers Allowed, das du mit robots.txt & Sitemap sauber stellst.

Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jedes Feld und jede Regel und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.