llms.txt in Footnoted: Einstieg, Dateinetz und Matrix

Eine Selbstauskunft: Was diese Seite über das Archiv sagt, stützt sich auf die Dateien im Repository. Was sie über andere sagt, trägt eine Fußnote auf eine fremde Quelle, mit deren Wortlaut. Die Zahlen setzt der Build bei jeder Veröffentlichung aus dem Bestand ein.

Ein Sprachmodell, das eine Frage über Geschichte beantworten soll, liest Websites anders als ein Mensch. Diese Seite beschreibt, was Footnoted dafür bereitstellt, warum es so gebaut ist und was der Betrieb bisher gezeigt hat. Was andere über llms.txt gemessen haben, steht auf einer eigenen Seite: llms.txt in Messungen und Studien.

Wovon die Datei ausgeht

Jeremy Howard schlug im September 2024 vor, dass Websites unter /llms.txt eine Markdown-Datei mit kurzer Einführung und Links auf ausführlichere Markdown-Dateien anbieten.¹ Begründet wird das damit, dass eine HTML-Seite ihren Inhalt zwischen Navigation, Werbung und JavaScript verteilt und sich schlecht in reinen Text zurückführen lässt.² Dazu kommt, dass die meisten Websites als Ganzes nicht in das Kontextfenster eines Modells passen.²

Eine Studie über KI-Agenten auf einem Dokumentationsportal fand, dass sie eine Navigation über mehrere Seiten auf eine oder zwei Anfragen verdichten.³ Für Footnoted folgt daraus die Bauregel: Jede Frage, die man an das Archiv stellen kann, soll mit wenigen Abrufen beantwortet sein, und jeder Abruf soll sagen, ob er vollständig war.

Was Footnoted bereitstellt

• /llms.txt ist der Einstieg. Er nennt den Stand als Commit und Datum, beschreibt die Wege durch das Archiv und listet die Dateien, die weiterführen.
• Je Bereich eine Datei unter /de/<bereich>/llms.txt. Darin steht jeder Eintrag als Block mit Datum, Belegstufe und Zusammenfassung, dazu seine Querverweise in beide Richtungen, jeweils mit Begründung. Wird eine Datei größer als 60 KB, teilt sie sich entlang der Ordnung, die der Bestand schon hat: Epoche, Thema, Jahrzehnt, Jahr.
• Je Zeitalter eine Datei unter /de/zeitalter/<zeitalter>/llms.txt, über alle Bereiche hinweg. Ein Eintrag steht dort nur in der feinsten Stufe, die auf ihn zutrifft.
• Die Matrix kreuzt beides: 26 Bereiche als Zeilen, die Zeitalter als Spalten. Jede Zahl ist ein Link auf eine Datei mit genau diesen Einträgen, nach einem festen Muster: /de/matrix/<zeitalter>/<bereich>.md. Ein leeres Feld steht als 0 ohne Link.
• Jeder Eintrag als Volltext mit Fußnoten (.md) und als Daten mit Quellen, Prüfstand und Querverweisen (.json).
• /de/neu.md nennt, was dazukam, je Monat eine Datei; ein großer Monat teilt sich in Wochen, eine große Woche in Tage. Wer seinen letzten Stand kennt, holt nur das Neue.
• WebMCP: In Browsern, die es anbieten, meldet jede Seite Werkzeuge an, mit denen ein Agent suchen, seitenweise auflisten, einen Eintrag abrufen, zu einem Satz die Quellen erfragen und das Umfeld eines Eintrags oder eines Wikidata-Objekts abfragen kann. Die Liste kommt in Seiten wie in der Abfrage-API, mit denselben Fehlercodes.

Alle Dateien entstehen bei jedem Build aus denselben 743 Einträgen, den Angaben der Bereiche und Zeitalter und, für das Neue, der Versionsgeschichte. Keine wird von Hand gepflegt.

Woran ein Agent erkennt, dass er alles hat

Ein Modell, das eine abgeschnittene Liste liest, hält sie leicht für vollständig. Deshalb sagt jede Datei für einen Bereich, ein Zeitalter oder ein Feld der Matrix im Kopf, ob sie den ganzen Bestand ihres Ausschnitts enthält oder nur einen Teil. Sie endet, wie /llms.txt, die Matrix und neu.md, mit der Zeile „Ende der Datei“. Fehlt die Zeile, war der Abruf abgeschnitten.

Aus demselben Grund steht in der Matrix eine 0, wo es nichts gibt. Ein leeres Feld ohne Zahl ließe offen, ob dort nichts ist oder ob nur nichts geladen wurde. Und das Werkzeug footnoted_liste antwortet mit einer leeren Liste, wenn kein Eintrag passt. Die Suche dagegen rät, und sie sagt das auch.

Dieselben Dateien verweisen zurück auf die Ebene darüber und nennen im Kopf die Lizenz, mit der Bitte, beim Zitieren „Footnoted — footnoted.net“ zu nennen und die verwendeten Einträge zu verlinken; /llms.txt nennt sie in einem eigenen Abschnitt. Ein Agent, der nur eine dieser Dateien liest, hat damit beides: den Weg zurück und die Bedingung.

Was der Betrieb gezeigt hat

• Der Dateityp entscheidet mit. Das Abrufwerkzeug von ChatGPT wies Dateien ab, die als text/markdown ausgeliefert wurden. Seitdem gehen sie als text/plain hinaus. Der Inhalt bleibt Markdown.
• Ein Agent öffnet nicht jede Adresse, die er liest. Am 13. Oktober 2026 meldete ChatGPT, im Browser Safari genutzt, für zwölf Adressen des Archivs, sie seien für sein Werkzeug nicht zugänglich. Darunter waren Links, die wörtlich in der geöffneten llms.txt standen. Der Dienst öffnete dabei nur Adressen, die er aus seiner Suche kannte oder die ihm der Nutzer gab. Seitdem stehen die Dateien für Agenten in einer eigenen Sitemap, und jeder Deploy meldet neue und weggefallene Adressen per IndexNow. Ob das reicht, ist noch offen.
• Agenten raten Adressen. Weil die Adressen einem Muster folgen, leitet ein Agent die Adresse eines Eintrags manchmal aus dem Titel ab, statt sie in einer Liste nachzuschlagen. Trifft er, ist das der kürzeste Weg. Trifft er nicht, landet er auf der Fehlerseite, und die verwies nur auf die Suche der Startseite. Die läuft im Browser; ein Abrufwerkzeug ohne JavaScript kommt an sie nicht heran. Seit dem 19. Oktober 2026 nennt die Fehlerseite deshalb die Stichwortsuche der API und llms.txt, und der Agententest vermerkt jede Antwort, die auf einer geratenen Adresse beruht.
• Ob die Dateien gelesen werden, ist bisher nicht gemessen. Was über Abrufe von llms.txt bekannt ist, stammt aus fremden Messungen.

Was übertragbar ist

Nichts davon setzt ein Archiv voraus. Wer Inhalte für Agenten aufbereiten will, kann diese Regeln übernehmen:

• Eine Datei je Frage, nicht je Seite. Bereich, Zeitraum und beides gekreuzt sind die Fragen, die an dieses Archiv gestellt werden. Andere Bestände haben andere Achsen.
• Adressen nach einem Muster, das sich bilden lässt, ohne vorher eine Liste zu laden. Wer eine Adresse so bildet, rät. Die Fehlerseite braucht deshalb einen Weg, der ohne JavaScript geht.
• Vollständigkeit ausweisen: im Kopf jeder Datei und mit einer letzten Zeile, an der man das Ende erkennt.
• Null hinschreiben. Ein „nichts gefunden“ ist eine Antwort, eine Lücke ist keine.
• Die Bedingung in jede Datei, nicht nur auf eine Lizenzseite.
• Aus dem Bestand berechnen. Eine von Hand gepflegte Übersicht weicht irgendwann vom Bestand ab, und dann widerspricht die Übersicht dem Inhalt.
• Die Dateien auffindbar machen. Ein Link in llms.txt allein genügt nicht, wenn ein Dienst nur Adressen aus seinem Suchindex öffnet.

Was sich nicht übertragen lässt, ist der Inhalt dahinter. Eine gut gebaute Datei auf unbelegtem Text macht Fehler nur leichter auffindbar. Wie in Footnoted belegt wird, steht unter Wie Footnoted belegt.

Text zuletzt gegen den Stand geprüft: 19. Oktober 2026.