Websites, die Agenten lesen können

/llms.txt
/llms-full.txt
/en/blog/an-article/index.md

Diese drei Pfade beantworten drei unterschiedliche Fragen. Welche Inhalte bietet die Website? Wie sieht ihr vollständiger veröffentlichter Textbestand aus? Und was ist die Markdown-Quelle genau dieses Artikels? ContentKit erzeugt die Antworten zusammen mit dem HTML-Release – aus denselben veröffentlichten Revisionen.

Teil 7 der Serie „ContentKit – Publishing für Maschinen“.

Eine Website ist für ein Sprachmodell nicht unlesbar. Es kann HTML abrufen, Navigation überspringen und Text herauslösen. Doch bei jeder Seite erneut zu erraten, welcher Teil Inhalt, welcher Teil Layout und welcher Stand verbindlich ist, kostet Kontext und erzeugt Fehler. ContentKit veröffentlicht deshalb eigene maschinenlesbare Sichten. Sie sind kein nachträglicher SEO-Text, sondern Teil des Veröffentlichungsvertrags: Die maschinenlesbaren Ausgaben werden aus demselben freigegebenen Stand abgeleitet.

Ein technischer Support-Agent, eine Entwicklungsumgebung oder ein Build-Prozess kann so gezielt mit dem freigegebenen Stand arbeiten, ohne auf interne Entwürfe zuzugreifen und ohne eine Autorenoberfläche bedienen zu müssen.

Ein Inhaltsstand, mehrere Lesewege

Der Ausgangspunkt ist immer der freigegebene Inhaltsstand: die Menge veröffentlichter Revisionen mit ihren Sichtbarkeitsregeln. Daraus leitet der Release mehrere Lesewege ab – HTML für Leser, Markdown-Zwillinge für einzelne Dokumente, llms.txt und llms-full.txt als Übersicht und Volltext, die authentifizierte Read API für eine JSON-Darstellung sowie MCP für Zugriffe durch Agenten. Für Menschen, die Inhalte, Vorschauen und Releases verwalten, gibt es das ContentKit-Cockpit als eigenen Verwaltungsweg.

flowchart TD
    R["Freigegebener Inhaltsstand<br/>veröffentlichte Revisionen"] --> H["HTML<br/>für Leser"]
    R --> S["llms.txt<br/>kurzer Einstieg"]
    R --> F["llms-full.txt<br/>vollständiger Text"]
    R --> M["index.md<br/>ein Dokument"]
    R --> J["Read API<br/>JSON"]
    R --> A["MCP<br/>Zugriff durch Agenten"]
    P["Zugriffsregeln"] --> H
    P --> S
    P --> F
    P --> M
    P --> J
    P --> A

Wichtig ist, was diese Ableitung bedeutet – und was nicht. Die Oberflächen liefern keine bytegleichen Inhalte: Eine HTML-Seite enthält Navigation, ein JSON-Dokument bildet den veröffentlichten Zustand strukturiert ab, ein Markdown-Zwilling enthält den redaktionellen Text. Entscheidend ist, dass jede Darstellung auf dieselbe veröffentlichte Revision zurückführbar ist und denselben Zugriffsregeln unterliegt. Wer eine Antwort aus der Read API mit einer Antwort aus dem Markdown-Zwilling vergleicht, vergleicht zwei Projektionen desselben Standes, nicht zwei unabhängig gepflegte Bestände.

Eine kurze Inhaltsübersicht für den Einstieg

llms.txt beschreibt eine Website im Format der offenen llms.txt-Spezifikation. Die Datei dient als kompakter Einstieg. Sie nennt wichtige Bereiche und verweist auf weiterführende Inhalte. ContentKit erzeugt dafür pro Sprache eine eigene Fassung. /llms.txt und /llms-full.txt an der Wurzel sind Kopien der Standardsprache der Website.

Ein Agent kann zuerst die kurze Datei laden und daraus die für seinen Auftrag relevanten Bereiche auswählen. Bei einer Frage zur Installation lässt sich der Suchraum dadurch auf die verlinkte Dokumentation begrenzen, statt das gesamte Blogarchiv in den Kontext zu übernehmen. Die Datei gehört zum statischen Release und benötigt keinen API-Schlüssel, solange der Inhalt öffentlich ist.

locale=en
curl --fail "https://docs.example.com/${locale}/llms.txt"

Der vollständige veröffentlichte Text

llms-full.txt enthält den redaktionellen Markdown-Text des veröffentlichten Bestands. Ein Agent bekommt damit eine zusammenhängende Textquelle ohne Header, Cookie-Hinweise, Suchfeld und andere Seitenelemente. Auch diese Ausgabe entsteht pro Sprache.

Die vollständige Datei ist sinnvoll, wenn der Bestand klein genug ist oder ein nachgelagerter Prozess selbst Ausschnitte bildet. Für große Dokumentationen ist die kurze llms.txt zusammen mit einzelnen Markdown-Zwillingen oder der Read API sparsamer. Eine praktische Grenze ist das Kontextbudget des Abnehmers.

Markdown-Zwillinge für einzelne Seiten

Veröffentlichte Beiträge und Reports erhalten neben der HTML-Darstellung einen rohen Markdown-Zwilling. Ein Leser oder Agent kann damit gezielt die Markdown-Fassung eines einzelnen Dokuments abrufen. Die Datei ist leichter zu zitieren, zu vergleichen und in einer Entwicklungsumgebung zu verwenden als das gerenderte HTML.

curl --fail \
  https://docs.example.com/en/docs/v2/getting-started/index.md

Der Zwilling enthält nicht den zufälligen Zustand einer lokalen Datei, sondern gehört zum aktiven Release. Wird eine neue Revision veröffentlicht, wechselt die Markdown-Fassung zusammen mit dem HTML. Ein Agent kann deshalb Antwort und Quellenstand auf dieselbe Veröffentlichung beziehen.

Öffentliche Datei oder geschützte API?

Öffentliche Markdown- und LLM-Dateien eignen sich für Inhalte, die ohnehin jeder lesen darf. Für authentifizierte Abnehmer gibt es zusätzlich die Read API. Sie liefert denselben veröffentlichten Zustand als JSON, während die öffentliche Website weiterhin aus statischen Release-Dateien besteht.

async function loadPublishedState(readApiUrl: string, token: string) {
  const response = await fetch(readApiUrl, {
    headers: { Authorization: `Bearer ${token}` }
  });

  if (!response.ok) {
    throw new Error(`Content read failed: ${response.status}`);
  }

  return response.json();
}

Die richtige Wahl hängt vom Abnehmer ab:

• Ein allgemeiner Web-Agent beginnt mit llms.txt und folgt öffentlichen Links.
• Eine Entwicklungsumgebung lädt den Markdown-Zwilling einer konkreten Referenzseite.
• Eine interne Build-Pipeline ruft den veröffentlichten Zustand über die authentifizierte Read API ab.
• Eine Offline-Suche übernimmt freigegebenes Markdown in einen eigenen Index.

Keine dieser Varianten erfordert, dass ContentKit selbst ein Modell ausführt. ContentKit erzeugt die veröffentlichten Dateien und die JSON-Darstellung; Modell, Kontextfenster und Suchverfahren liegen beim Abnehmer.

Geschützt heißt auch für Maschinen geschützt

Eine Zugriffssperre nur auf der HTML-Seite wäre wertlos, wenn Titel und Text weiterhin in öffentlichen Agentendateien stünden. ContentKit leitet die öffentlichen Entdeckungsflächen aus derselben Sichtbarkeitsentscheidung ab. Geschützte Inhalte fehlen in öffentlicher Navigation, Suche, Sitemap, Feeds, llms.txt und llms-full.txt. Der Schutz gilt damit auch für die maschinenlesbaren Einstiege.

Für authentifizierte Integrationen steht die Read API als eigener Leseweg bereit. Öffentliche Dateien und authentifizierter JSON-Zugriff dürfen dabei nicht als austauschbare Zugriffswege behandelt werden: Ob ein Inhalt öffentlich sichtbar ist, ergibt sich aus den Zugriffsregeln des veröffentlichten Standes und nicht aus dem verwendeten Ausgabeformat.

So kann eine Website eine öffentliche Produktübersicht und ein geschütztes Handbuch im selben Inhaltsbestand führen. Ein allgemeiner Agent findet nur den öffentlichen Teil. Eine ausdrücklich authentifizierte Integration kann den dafür freigegebenen Zustand über die Read API beziehen. Die Trennung entsteht durch Veröffentlichung und Zugriff, nicht durch eine Anweisung im Prompt.

Beispielhafter Ablauf: Antwort aus dem freigegebenen Runbook

Ein möglicher Integrationsentwurf beginnt mit Runbooks in einer versionierten Dokumentation. Ein interner Agent soll bei einem Alarm den passenden Ablauf finden, aber keine unveröffentlichten Entwürfe oder alten Wiki-Kommentare verwenden.

Nach einem Release kann ein externer Indexdienst den veröffentlichten JSON-Zustand über die authentifizierte Read API abrufen und in einen eigenen Suchbestand übernehmen. Beim Alarm sucht der Agent ausschließlich in diesem Bestand. Die Synchronisation, die Suche und die Protokollierung des Abrufs gehören dabei zur externen Integration, nicht zu einer zugesagten Automatik von ContentKit.

Wird eine Anleitung korrigiert und neu veröffentlicht, muss die Integration ihren Index aus dem neuen veröffentlichten Stand aktualisieren. Ob sie frühere Stände als Nachweis aufbewahrt, ist eine eigene Betriebsentscheidung und kann nicht aus der Read API abgeleitet werden.

Support-Antworten und sichtbare Dokumentation greifen damit auf denselben veröffentlichten Inhaltsstand zurück. Der Agent muss keine internen Quellsysteme mit jeweils eigenen Berechtigungen durchsuchen, wenn die benötigte Projektion bereits kontrolliert bereitsteht.

Kontext gezielt klein halten

llms-full.txt ist bequem, kann bei einem großen Bestand aber mehr Text liefern, als eine konkrete Aufgabe benötigt. Ein Abnehmer sollte deshalb zunächst die kleinste Sicht wählen, die das benötigte Dokument, die erforderlichen Quellen und genügend Metadaten für die Auswahl enthält. Das verfügbare Kontextbudget setzt eine weitere Grenze: Zuerst reicht häufig die kurze Übersicht, danach folgt eine einzelne Markdown-Seite. Der vollständige Bestand ist für Aufgaben gedacht, die tatsächlich mehrere Bereiche übergreifen.

Question
  -> read /llms.txt
  -> select documentation section
  -> fetch one index.md
  -> answer with source URL

Dieser Ablauf begrenzt die übertragene Textmenge und reduziert die Zahl konkurrierender Belege im Kontext. Er entspricht einer gezielten Recherche: erst den Bestand überblicken, dann die zuständige Quelle lesen. ContentKit unterstützt diesen Weg mit den veröffentlichten LLM-Dateien und Markdown-Zwillingen.

Die Auswahl bleibt Aufgabe des Abnehmers. Rechtliche Hinweise, alte Changelogs und themenfremde Blogartikel können für eine Installationsfrage irrelevant sein. Wenn mehrere versionsbezogene Seiten infrage kommen, braucht die Integration ein ausdrückliches Auswahlkriterium aus ihrem eigenen fachlichen Kontext. Fehlt dieses Kriterium, sollte das Modell die passende Version nicht allein aus sprachlicher Ähnlichkeit ableiten.

Quellenangaben müssen den Release überleben

Ein Agent sollte Text und Herkunft zusammen bewahren. Für eine sichtbare Antwort genügt häufig die kanonische Seiten-URL. Für einen auditierbaren internen Prozess reicht diese URL allein nicht, weil sie nach einem späteren Release einen anderen Stand anzeigen kann.

Benötigt eine Integration einen dauerhaften Nachweis, muss sie ihn beim Abruf selbst erzeugen und aufbewahren. Dafür kommen beispielsweise ein Hash des abgerufenen Inhalts, der Abrufzeitpunkt oder eine vom jeweiligen API-Vertrag tatsächlich gelieferte Versionskennung infrage. Die Integration darf Revisions- oder Release-Felder nicht voraussetzen, solange der konkrete Vertrag sie nicht zusichert.

In Antworten an Leser reicht oft der Link auf die lesbare Seite. Betriebs- oder Compliance-Prozesse müssen dagegen festlegen, welcher interne Nachweis für den verwendeten Stand erforderlich ist und wie lange er erhalten bleibt.

Größenstrategie und Grenzen

Mit wachsendem Bestand kann llms-full.txt groß werden. ContentKit stellt die vollständige Datei bereit, doch ein Abnehmer muss sie nicht bei jeder Frage erneut laden. HTTP-Caching, lokale Indizes und die Auswahl einzelner Markdown-Zwillinge reduzieren Übertragung und Kontextverbrauch. Große Anhänge oder Rohdaten gehören nicht in den vollständigen Textbestand, wenn eine geprüfte Zusammenfassung und ein gezielter Download reichen.

Die Qualitätsfrage lautet daher nicht „Ist alles maschinenlesbar?“, sondern „Findet ein Abnehmer mit wenigen Schritten die zuständige, veröffentlichte Quelle?“. ContentKit liefert die technischen Sichten; klare Titel, Zusammenfassungen, Hierarchien und Metadaten machen daraus einen brauchbaren Informationsbestand.

Maschinenlesbarkeit nützt dabei auch ohne Sprachmodell. Markdown-Zwillinge eignen sich für Archivierung und Diffs, strukturierte Darstellungen können weitere Generatoren oder Anwendungen versorgen. Damit bleibt der Veröffentlichungsdienst unabhängig vom verwendeten Modell. Fällt ein Agent aus oder wird ersetzt, bleiben Website und maschinenlesbare Quellen erreichbar.

Fazit

Der Release sollte der Übergabepunkt sein, weil er veröffentlichte Revisionen, Sichtbarkeit und abgeleitete Ausgaben festlegt. HTML, Markdown, llms.txt, llms-full.txt, die authentifizierte Read API und MCP bleiben dadurch auf den zuvor beschriebenen Inhaltsstand zurückführbar. Abnehmer wählen daraus die kleinste geeignete Sicht; geschützte Inhalte bleiben aus öffentlichen Ausgaben ausgeschlossen.

Weiterführende Quellen

• llms.txt-Spezifikation
• ContentKit: LLM-Ausgaben
• ContentKit: Architektur von Release und Read API
• ContentKit: Veröffentlichung und Schutzregeln

Wie fandest du diesen Beitrag?

Kommentare