Discovery-Files konsistent halten, damit AI-Crawler nicht alte Bullshit-Bios zitieren

Du hast eine Website, klar. Du hast vielleicht auch eine llms.txt weil das letztes Jahr groß wurde. Vielleicht läuft bei Dir ein MCP-Server der eine about-Funktion exportiert. Vielleicht hast Du agents.json oder mcp.llmfeed.json rumliegen weil Du mal experimentiert hast. Und in Deinem Agent-Code stehen Knowledge-Files mit Firmen-Bio, Tagline, Founding-Year.

Jeder dieser Files ist eine Quelle die ein AI-Crawler oder ein anderer Bot zitieren kann. Wenn die untereinander widersprechen oder gegen die Website driften, kann das Folgendes passieren: ein User fragt Grok "wer ist StudioMeyer", Grok zieht die MCP-Server-Bio, da steht "seit 2017 auf Mallorca aktiv" und "Firma seit 2010". Beides falsch. Beides nie auf der Website. Beides irgendwann aus Marketing-Synthese in den Discovery-File gewandert. Genau das ist mir am 21. Mai 2026 passiert. Drei Halluzinationen, alle aus eigenen Discovery-Files, die über Monate Drift akkumuliert hatten.

Das hier ist die Reihenfolge die ich seitdem fahre wenn ich eine neue Site oder einen neuen MCP-Server publishe. Zehn Schritte, einmal durchziehen dauert eine halbe Stunde, danach weißt Du wo Du driftest.

Schritt 1, Inventar machen

Bevor Du anfaengst zu konsolidieren brauchst Du eine Liste was ueberhaupt da ist. Such in Deinem Repo nach den ueblichen Verdaechtigen:

find . -type f \( \
  -name "llms.txt" -o \
  -name "agents.json" -o \
  -name "agent-card.json" -o \
  -name "mcp.llmfeed.json" -o \
  -name "*-product.ts" -o \
  -name "*-knowledge.ts" \
\) -not -path "*/node_modules/*"

Dazu kommen MCP-Server-Tools die Strings zurückgeben (such nach about, team_info, get_brand, whoami). Bei mir war die Liste länger als gedacht: llms.txt an der Root, agents.json in public/, drei Agent-Knowledge-Files in agents/lib/, eine mcp.llmfeed.json die ich vor sechs Monaten experimentell angelegt hatte und nie wieder angeschaut habe. Schreib die Liste auf Papier, Du brauchst sie in den nächsten Schritten.

Schritt 2, Source of Truth definieren

Eine einzige Stelle muss die Wahrheit sein. Bei mir sind das die i18n-Files messages/de.json, messages/en.json, messages/es.json weil aus denen die Website rendert. Was da nicht steht, steht nirgends. Punkt.

Definier das für Dich klar bevor Du weitermachst. Mach Dir einen Block in CLAUDE.md oder einer .cursorrules-Datei der sagt: "Source of Truth für Brand-Claims ist X. Alle anderen Files müssen 1:1 oder semantisch identisch sein. Kein Erfinden, kein Marketing-Synthese, kein Anreichern." Das ist die Regel an die sich jede zukuenftige Session halten muss, sonst driftest Du in einer Woche wieder.

Schritt 3, die hoechsten Risiko-Claims aus der Source of Truth ziehen

Aus Deinen Website-Texten ziehst Du jetzt eine kleine Faktentabelle. Bei einer Agentur sind das typischerweise: Gruendungsjahr, Sitz, Anzahl Mitarbeiter, Hauptservices, Tagline, Hauptpersonen. Jede Zahl, jedes Jahr, jede Stadt.

Bei mir kamen vier verifizierte Facts raus: "StudioMeyer ist eine AI-Agentur", "Sitz ist Palma de Mallorca", "Founder ist Matthias Meyer", "Wir bauen Websites, MCP-Server und Agent-Fleets". Mehr nicht. Alles andere ist Marketing-Sprache die nicht in Discovery-Files gehört.

Schritt 4, llms.txt gegen die Liste prüfen

llms.txt ist die simpelste Datei, ein einziges Markdown-File an der Root. Spec gibt es auf https://llmstxt.org und sie ist absichtlich klein. Mach auf, lies Zeile für Zeile, jeden Claim gegen Deine vier Facts halten.

Bei mir stand da "AI agency since 2017" obwohl die Firma StudioMeyer in dieser Form erst 2024 wirklich AI-fokussiert war. Klassischer Drift, irgendwann mal hineingerutscht weil "lange Erfahrung" gut klingt. Raus damit. Wenn ein Datum nicht aus der Website kommt, kommt es nicht in llms.txt.

Schritt 5, agents.json und agent-card.json checken

Falls Du A2A oder MCPize benutzt hast Du diese Files. Format ist JSON mit description, instructions, oft bio oder about. Gleiche Methode: jeden String prüfen.

Wichtig: Tools in MCP-Servern haben oft eine description die im Client als Tooltipp erscheint. Auch das ist ein Marketing-Anschein wenn da steht "Mit jahrelanger Mallorca-Erfahrung". Streich das. Tool-Descriptions sollen sagen was das Tool tut, nicht wer Du bist.

Schritt 6, MCP-Server-Tools die Strings zurückgeben

Die echte Falle. Tools wie sm_get_team_info, andibot_about, almabot_about geben strukturierte JSON-Bloecke zurück die ein AI-Client direkt in seine Antwort einbaut. Wenn da "founded": "2010" steht weil das jemand vor zwei Jahren reingeschrieben hat, sagt Grok "Firma seit 2010".

Such in Deinem MCP-Server-Code nach hardcodierten Strings. Bei mir lagen die in mcp-servers/sm-service/team.ts und in mcp-servers/almabot/about.ts. Bei jeder Zeile fragen: kommt das genauso auf der Website vor? Wenn nein, raus oder umformulieren.

Schritt 7, Agent-Knowledge-Files in agents/lib/

Wenn Du eigene Agents hast (CEO-Worker, Multi-Agent-Setup) haben die meistens ein *-product.ts oder *-knowledge.ts mit Long-Form-Bio. Das wird in System-Prompts injiziert. Wenn da Marketing-Drift drin ist, halluziniert Dein eigener Agent dasselbe Maerchen wie Grok.

Lies jeden String. Vergleich mit Website. Streich, kuerze, korrigier. Mach am Ende des Files einen Kommentar // Source of Truth: messages/de.json | Letzter Audit: 2026-05-21 damit der nächste Session-Claude weiß woran er ist.

Schritt 8, mcp.llmfeed.json und sonstige Experimentier-Files

Files die Du mal angelegt hast und vergessen hast sind die schlimmsten. Sie liegen in public/ oder an der Root, sie tauchen in der Sitemap auf, sie sind für Crawler erreichbar, aber Du editierst sie nie weil Du sie vergessen hast.

Entscheid pro File: ist das noch aktiv und gewollt? Wenn ja, in Schritt 4 bis 7 mitpruefen. Wenn nein, geh radikal vor und loesch das File komplett. Ein nicht-existierender File ist nicht-driftbar.

Schritt 9, mit echten Crawlern testen

Du hast aufgeraeumt. Jetzt frag drei verschiedene AI-Clients dieselbe Frage und schau was zurückkommt: ChatGPT, Grok, Claude, vielleicht Perplexity. "Wer ist [Dein Brand]". "Was macht [Dein Brand]". "Wo sitzt [Dein Brand]".

Wenn eine Antwort etwas behauptet was nicht in Deinen vier Facts steht, hast Du noch einen Drift-Quell den Du nicht entdeckt hast. Suche weiter, der Crawler hat den Source-Pfad in den Citations meistens dabei. Klick drauf, dann weißt Du welcher File noch flunkert.

Schritt 10, Audit-Cadence einbauen

Einmal aufraeumen bringt Dir nichts wenn in drei Wochen wieder Drift drin ist. Drei Regeln die ich seitdem fahre.

Erstens, jeder neue MCP-Server-Build läuft durch ein grep -rE "(seit \d{4}|since \d{4}|founded|gegruendet|years|Jahre)" mcp-servers/ und wenn da was Neues auftaucht, manuelle Pruefung gegen Website. Zweitens, eine Pflicht-Regel in CLAUDE.md die sagt "kein Erfinden, kein Marketing-Synthese, Source of Truth ist Website". Drittens, alle zwei Wochen ein 10-Minuten-Audit mit den Crawler-Tests aus Schritt 9, vor allem nach größeren Inhalts-Sessions.

Die Regel klingt strenger als sie ist. In der Praxis bedeutet sie nur: wenn Du nicht beweisen kannst dass eine Behauptung auf Deiner Website steht, kommt sie nicht in einen Discovery-File. Marketing ist auf der Website, nicht im JSON.

Was als nächstes

Wenn Du beim Audit gemerkt hast dass Du gar keine llms.txt hast, lies die Spec auf https://llmstxt.org und schreib eine. Eine Mini-Datei mit Deinen vier Facts und ein paar Link-Targets ist besser als gar nichts und besser als eine die driftet. Für eigene MCP-Server lohnt sich der Playbook erster-mcp-server-in-90-minuten plus mcp-server-publishen wenn Du das Discovery-Modell von Anfang an sauber ziehen willst. Und wenn Du Multi-Agent-Setups mit Knowledge-Files faehrst, lies tool-sprawl-vermeiden, dort steht das gleiche Drift-Pattern aus Tool-Perspektive.

Source

Hook-Spec und Discovery-Patterns: https://llmstxt.org und https://code.claude.com/docs/en/hooks (für Hook-basierte Audit-Automation).