Immer öfter liest nicht ein Mensch unsere Website, sondern sein KI-Agent — und der sah bisher vor allem leere Hüllen aus Kachel-Markup. Jetzt gibt es jede Inhaltsseite in einer zweiten Ausgabe für Maschinen: llms.txt als kuratierter Index, generierte Markdown-Fassungen unter /md/. Warum, wie — und was dabei fast schiefgegangen wäre.
Immer öfter: niemand. Gelesen wird trotzdem — nur eben von einem KI-Agenten, der die Frage eines Menschen beantwortet. „Wie binde ich in Power BI eine Excel-Datei an?", „Welches Visual kann IBCS-Varianzen?", „Was kostet ein klimaneutrales Stromsystem?" Der Mensch fragt seinen Assistenten, der Assistent holt sich die Antwort — idealerweise bei der Quelle.
Und da beginnt das Problem. Unsere Website ist für Menschen gebaut: Kachel-Layouts, klickbare Detail-Karten, Scrollytelling, interaktive Regler. Der Power-BI-Einsteiger-Guide ist als HTML-Datei 388 KB groß, und der eigentliche Inhalt — 87 Detail-Karten mit Schritt-für-Schritt-Anleitungen — steckt in einem JavaScript-Block, der erst beim Klick ein Modal öffnet. Ein Agent, der diese Seite abruft, sieht: eine leere Hülle aus Navigations-Markup. Wir hatten eine Website, die für ihre neuen Leser unsichtbar ist.
const DETAILS-Block und werden erst per Klick gerendert — für ein Sprachmodell unsichtbar.Seit dieser Woche gibt es jede Inhaltsseite der Kitchen in zwei Ausgaben: die HTML-Fassung für Menschen — unverändert, mit allem Klickbaren — und eine Markdown-Fassung für Maschinen unter /md/. Der 388-KB-Guide wird darin zu 200 KB purem Inhalt: alle 87 Karten aufgelöst, alle 56 Code-Beispiele als korrekt ausgezeichnete DAX- und Power-Query-Blöcke.
Den Einstieg macht eine Datei namens llms.txt im Wurzelverzeichnis — eine Konvention von llmstxt.org, die sich gerade als das robots.txt des KI-Zeitalters etabliert. Sie ist ein kuratierter Index: was es auf der Site gibt, was in welcher Markdown-Datei steht, und welche Regeln bei der Weiterverwendung gelten. Dazu ein Volltext-Bündel (llms-full.txt) für Agenten, die lieber einmal alles laden.
Jede Seite verweist außerdem selbst auf ihre Maschinen-Ausgabe: unsichtbar im Head (<link rel="alternate" type="text/markdown">) und sichtbar als kleiner „📄 Als Markdown"-Link im Footer — den kann man auch einfach kopieren und seinem Agenten in den Chat werfen.
Die naive Lösung wäre: Inhalte einmal von Hand nach Markdown kopieren, fertig. Die Falle daran ist nicht der Aufwand — es ist die Drift. Die Website ändert sich ständig (allein der Podcast-Guide wächst mit jeder Folge), und eine Handkopie ist ab Tag eins ein zweites Pflegeobjekt, das leise veraltet. Eine veraltete Maschinen-Ausgabe ist schlimmer als keine: Der Agent zitiert dann mit voller Überzeugung den Stand von vorletztem Monat.
Deshalb sind die Markdown-Fassungen generiert, nicht geschrieben. Zwei Skripte im Repo lesen die HTML-Seiten bzw. die Episodendaten und erzeugen daraus die /md/-Dateien — deterministisch (zweimal bauen ergibt byte-identische Dateien) und mit einem Prüfmodus, der Abweichungen meldet. Der Episoden-Guide mit seinen 143 Folgen entsteht direkt aus derselben Datenkonstante, aus der auch die Webseite rendert — inklusive Kapitel-Sprungmarken als YouTube-Links mit Zeitstempel.
GitHub Pages jagt Markdown durch eine Template-Engine. Standardmäßig rendert Jekyll jede .md-Datei — und schickt sie dabei durch Liquid. Diese Power-Query-Zeile ist gültiges M und gleichzeitig eine Liquid-Variable:
Ergebnis: eine harmlose Warnung im Build-Log und stillschweigend verstümmelter Code auf der Seite. Kein Abbruch, kein roter Balken. Die Lösung ist eine Zeile in der _config.yml, die .md zur statischen Datei erklärt; die ausführliche Begründung steht in unserem md/README.md.
Zwei Ausgaben, eine Wahrheit. Die Schnellstart-Seite zeigt die Versionsnummer des ChartKitchen-Visuals dynamisch aus einer JSON an — im statischen Markup steht eine alte Nummer. Eine naive Konvertierung hätte also eine falsche Version behauptet. Der Generator löst das, indem er beim Bauen dieselbe JSON liest wie die Webseite. Die Regel dahinter ist allgemein: Wo eine Seite ihre Zahlen zur Laufzeit lädt, muss die Maschinen-Ausgabe aus denselben Daten gebaut werden — nicht aus dem Markup.
Der Teil, der uns am wichtigsten ist: Die llms.txt transportiert nicht nur Links, sondern Regeln. Unsere datenjournalistischen Arbeiten tragen je Zahl eine Konfidenzstufe (A mehrfach belegt bis M Modellsetzung) — und der Index sagt Agenten ausdrücklich, dass eine Zahl ohne ihre Konfidenzstufe die Aussage verfälscht. Ob sich jedes Modell daran hält, können wir nicht erzwingen. Aber wir können die ehrliche Weitergabe so leicht wie möglich machen — und die unehrliche zumindest zu einer aktiven Entscheidung.
Angefangen hat das alles übrigens eine Nummer kleiner: mit dem AGENT-GUIDE für unser ChartKitchen-Visual — einer maschinenlesbaren Referenz, mit der ein KI-Agent Power-BI-Berichte korrekt konfigurieren kann. Die Erfahrung daraus: Wenn man Maschinen gute Dokumente gibt, machen sie gute Arbeit. Die MD-Ausgabe der ganzen Site ist nur die konsequente Fortsetzung.
Eine Handkopie veraltet leise, ein Skript nicht. Deterministisch bauen (zweimal laufen = byte-identisch) und einen Prüfmodus mitliefern, der Abweichungen zwischen Website und Maschinen-Ausgabe meldet.
Nicht jede Seite, sondern die mit Substanz — Werkzeuge und Spiele bleiben draußen. Jeder Eintrag eine Zeile, die sagt, was drinsteht, nicht wie schön es ist.
Markdown muss roh ankommen, nicht durch eine Template-Engine gedreht. Einmal mit curl gegenlesen, was der Server wirklich liefert — sonst verstümmelt Liquid den Code, ohne dass ein Build rot wird.
Zitierweise, Datenstand, Konfidenzstufen — direkt in die llms.txt und in die Kopfblöcke der Dateien. Agenten lesen das tatsächlich.
URL kopieren, dem Lieblings-Agenten geben, eine Frage zu Power BI, Fabric oder unseren Analysen stellen: datenwgknowledgekitchen.com/llms.txt