- [ Startseite ](/de/) / - Wie es funktioniert # Wie llms.txt funktioniert Die Spezifikation im Detail, mit einem kommentierten Beispiel zum Kopieren. Zuletzt aktualisiert: 31. Juli 2026 ## Überblick Eine gültige `llms.txt` ist eine Markdown-Datei mit **fester, vorhersagbarer Struktur**. Sie ist darauf ausgelegt, von Menschen und von Maschinen gelesen zu werden: dieselbe Datei dient als Dokumentation und als parsebarer Vertrag. Die Spezifikation auf [llmstxt.org](https://llmstxt.org/) definiert eine kleine, deterministische Grammatik, die sich mit wenigen Zeilen Regex parsen lässt. Kein YAML, kein JSON, keine zusätzlichen Header. ## Aufbau einer gültigen Datei Die Struktur von oben nach unten: - **Ein H1** mit dem Namen der Site oder des Projekts. Das einzige strikt erforderliche Element. - Eine kurze **Zusammenfassung als Blockquote**, typischerweise ein bis zwei Sätze. - Optionaler **freier Markdown-Text**, Absätze und Listen, aber keine weitere Überschrift vor dem ersten H2. - Null oder mehr **H2-Abschnitte mit Dateilisten**. Jeder enthält eine Markdown-Liste von Links: `- [name](url)`, optional gefolgt von `: Notizen`. - Ein optionaler H2-Abschnitt mit exakt dem Namen **`Optional`**: dessen Einträge dürfen Clients mit knappem Kontext überspringen. llms.txt, vollständiges kommentiertes Beispiel Copy ``` # Acme > Acme ist eine gehostete Analytics-Plattform für Produktteams. Die folgenden Seiten decken Produkt, Preise, API und Integrationsleitfäden ab. Acme verarbeitet über 1 Mrd. Events pro Tag. Diese Karte ist für Assistenten kuratiert und nicht vollständig. Nutzen Sie sie für Fragen zu Produktfunktionen, Preisen, Integrationen, SDKs und Migration von anderen Tools. ## Produkt - [Überblick](https://acme.example/product): Funktionen und Screenshots. - [Anwendungsfälle](https://acme.example/use-cases): Szenarien für Produkt-, Marketing- und Support-Teams. - [Changelog](https://acme.example/changelog): monatliche Updates. ## Preise - [Tarife](https://acme.example/pricing): Pläne, Limits, Overage-Regeln. - [Abrechnungs-FAQ](https://acme.example/billing-faq): Rechnungen, Belege, Umsatzsteuer. ## Entwickler - [REST-API-Referenz](https://docs.acme.example/api): vollständiger Endpunkt-Katalog. - [JavaScript-SDK](https://docs.acme.example/sdk/js): Installation, Init, Events tracken. - [Python-SDK](https://docs.acme.example/sdk/python): Installation, Init, Events tracken. - [Webhooks](https://docs.acme.example/webhooks): Events, Signaturen, Retries. ## Optional - [Markenassets](https://acme.example/brand): Logos, Farbpalette. - [Pressemitteilungen](https://acme.example/press): Archiv der Ankündigungen. ``` ## Abschnitt für Abschnitt Vollständige Feldreferenz. Nur das H1 ist strikt erforderlich. Feld Pflicht? Anzahl Syntax H1, Name der Site bzw. des Projekts Ja Genau einer # Projektname Blockquote-Zusammenfassung Empfohlen Höchstens ein Block > Zusammenfassung in ein bis zwei Sätzen. Freier Markdown-Text Optional Beliebig viele Absätze/Listen Keine weitere Überschrift vor dem ersten H2 H2-Abschnitt mit Dateiliste Optional Beliebig viele ## Abschnittsname gefolgt von einer Liste Eintrag, Link Ja (innerhalb eines Abschnitts) Ein Link pro Eintrag - [name](url) Eintrag, Notizen Optional Nach einem Doppelpunkt - [name](url): Notiz hier Abschnitt „Optional“ Optional Höchstens einer H2 mit exakt dem Titel Optional ; Einträge dürfen bei knappem Kontext übersprungen werden ### Das H1 Genau ein H1, die erste nicht leere Zeile der Datei. Kein Präfix, keine Metadaten davor. Hat Ihr Projekt einen Claim, gehört er in das folgende Blockquote, nicht in den Titel. ### Die Blockquote-Zusammenfassung Optional, aber dringend empfohlen. Zielen Sie auf ein bis zwei Sätze, die ein LLM wörtlich zitieren könnte, um Ihr Projekt vorzustellen. Sachlich, im Aktiv, ohne Marketingversprechen, die Sie nicht halten können. ### Freier Markdown-Text Absätze, Aufzählungen, kurze Code-Snippets, die einem LLM den Kontext erklären. Führen Sie hier keine weitere Überschrift ein: die nächste muss das erste Abschnitts-H2 sein. ### H2-Listenabschnitte Jeder Abschnitt beginnt mit einem eigenen H2 (`## Abschnittsname`) und enthält eine Markdown-Liste. Jeder Eintrag muss ein Link sein (`- [name](url)`), optional gefolgt von `:` und einer kurzen Notiz. Absolute URLs sind dringend empfohlen: relative URLs sind technisch erlaubt, werden aber von den meisten Validatoren (auch von [unserem](/de/validator/)) als Warnung markiert, weil sie die Datei ausserhalb ihres Kontexts mehrdeutig machen. ### Der Abschnitt „Optional“ Ein Abschnitt mit exakt dem Titel `Optional` hat eine besondere Bedeutung: Clients mit knappem Kontext dürfen ihn überspringen, ohne den roten Faden zu verlieren. Nutzen Sie ihn für Nice-to-haves (Markenassets, Archive, tiefe technische Anhänge). ## Wie Parser die Datei lesen Der Referenzparser läuft linear durch die Datei und wendet vier Regeln an: - Die erste `# `-Zeile suchen, das ist der Titel. - Ist der nächste nicht leere Block ein Blockquote, ist das die Zusammenfassung. - Alles bis zum ersten `## ` ist der freie Text. - Jedes `## ` öffnet einen Abschnitt; bis zum nächsten `## ` werden Listeneinträge als `[name](url)` mit optionalen Notizen nach dem Doppelpunkt geparst. Unser [Validator](/de/validator/) implementiert genau diese Regeln, plus einige Plausibilitätsprüfungen: leeres H1, fehlerhafte Links, Inhalt ausserhalb von Abschnitten, Grössenwarnungen (ab etwa 50 kB lohnt der Umzug nach `llms-full.txt`). ℹ Tipp: Format strikt halten Der ganze Sinn von llms.txt ist die deterministische Parsebarkeit. Widerstehen Sie der Versuchung, Front Matter, eigenes HTML oder exotische Markdown-Erweiterungen hinzuzufügen: Clients lesen sie nicht, und Sie riskieren, striktere Parser als unseren zu brechen. ## llms.txt vs llms-full.txt `llms.txt` ist eine *Karte*. `llms-full.txt` ist das *Gebiet*: der tatsächliche Inhalt der verlinkten Seiten, als Markdown in einer Datei konkateniert. Die Konvention wurde von [Mintlify in Zusammenarbeit mit Anthropic](https://www.mintlify.com/blog/simplifying-docs-with-llms-txt) popularisiert und gehört heute zum weiteren `llms.txt`-Ökosystem. Beide sind Geschwister und werden im Root ausgeliefert: `/llms.txt` und `/llms-full.txt`. Sie können eine, beide oder keine veröffentlichen. Die meisten Dokumentationsplattformen veröffentlichen beide. ## Praktische Grenzen - **Grösse.** Keine harte Obergrenze, aber ab etwa 50 kB tun sich Clients mit knappem Kontext schwer. Verlagern Sie Volumen nach `llms-full.txt` oder in Varianten je Produkt. - **Anzahl Links.** Die Spezifikation kennt kein Limit, aber eine Liste mit 200+ Einträgen wird überflogen, nicht gelesen. Kuratieren Sie. - **Sprachen.** Zur Internationalisierung schweigt die Spezifikation. Zwei verbreitete Muster: eine einzige englische Datei, oder Varianten je Locale hinter einem Pfad (`/en/llms.txt`, `/de/llms.txt`). - **Auth und Personalisierung.** Ausserhalb des Scopes. Die Datei ist öffentlich. ## Weiterlesen - [llms.txt erstellen](/de/llms-txt-erstellen/), Vorlagen und Deployment je Stack. - [Best Practices](/de/best-practices/), zehn Regeln und häufige Fehler. - [Eine Datei validieren](/de/validator/). ## Quellen - [ llmstxt.org, vollständige Spezifikation ](https://llmstxt.org/) - [ llmstxt.org, the parsing core ](https://llmstxt.org/core.html) Auf dieser Seite - [ Überblick ](#ueberblick) - [ Aufbau einer gültigen Datei ](#aufbau) - [ Abschnitt für Abschnitt ](#abschnitte) - [ Wie Parser die Datei lesen ](#parsing) - [ llms.txt vs llms-full.txt ](#vs-full) - [ Praktische Grenzen ](#grenzen)