KI-Crawler-robots.txt-Prüfer
Verknüpft KI-lesbare Routenübersicht mit Crawler-Zugriffsregeln derselben Site.
Web / SEODeine Website agent-lesbar machen: robots.txt, llms.txt, Agent Cards und WebMCP
Ein wachsender Teil deines Traffics liest Metadaten vor dem Inhalt: KI-Crawler prüfen die Robots-Policy, Agents suchen llms.txt, Runtimes tasten nach Tool-Manifesten. Diese Schicht gut zu publizieren ist billig — sie unehrlich zu publizieren ist schlimmer als gar nicht.
Zuerst die Crawler-Policy: robots.txt in der KI-Ära
Die älteste Datei dieser Liste hat plötzlich neue Leser. Trainings-Crawler, Search-Preview-Fetcher und nutzerausgelöste Agent-Browser identifizieren sich mit jeweils eigenen User-Agents — und die Matching-Regeln aus RFC 9309 entscheiden, was deine Direktiven tatsächlich erlauben: Longest-Path-Matching, Gruppen-Zusammenführung und die Wildcard-Semantik, die die meisten handgeschriebenen Dateien subtil falsch machen. Eine Policy, von der du glaubst, sie blocke KI-Training, matcht womöglich nichts — und ein Pauschalblock hungert vielleicht genau die nutzerausgelösten Fetcher aus, die du eigentlich willst.
Triff die Policy bewusst — Trainings-Crawler, Such-Crawler und On-Demand-Agent-Fetcher sind verschiedene Populationen mit verschiedenen Tauschgeschäften — und verifiziere danach, dass die Datei sagt, was du entschieden hast. Der KI-Crawler-robots.txt-Prüfer wertet deine Regeln gegen die bekannte KI- und Such-Crawler-Population aus, mit RFC-9309-Matching-Evidenz — das schlägt das Schielen auf Wildcard-Regeln jedes Mal.
llms.txt: Navigation für Leser ohne DOM
Wo robots.txt sagt, ob gelesen werden darf, sagt llms.txt, was sich zu lesen lohnt: eine Markdown-Datei im Site-Root, die deine wichtigen Routen mit Ein-Zeilen-Beschreibungen listet — damit ein Agent mit kleinem Kontextbudget auf Substanz landet statt auf Navigations-Chrome. Das Format ist bewusst bescheiden — Titel, Kurzbeschreibung, Link-Sektionen mit Beschreibungen — und sein Wert steht und fällt mit Ehrlichkeit und Frische. Veraltete Einträge und tote Links lehren Agents dieselbe Lektion, die kaputte Sitemaps den Crawlern beigebracht haben.
Behandle sie wie das redaktionelle Geschwister der Sitemap: generiert aus demselben Routen-Inventar, aktualisiert vom selben Deploy, der Routen ändert, und validiert statt für korrekt gehalten — der llms.txt-Validator prüft Struktur, Sektionen und Link-Gesundheit. Halte Parität mit deinen kanonischen URLs und widersteh dem Auffüllen: Eine kuratierte Datei mit zwanzig Zeilen dient einem Agent besser als ein erschöpfender Dump.
Agent Cards: Identität, an der man dich messen kann
Das A2A-Ökosystem verlagert Discovery von Seiten auf Dienste: Eine Agent Card unter /.well-known/agent-card.json deklariert Identität, Skills, Endpunkte, Transporte und Authentifizierungsanforderungen — und konsumierende Agents parsen sie mechanisch. Die Card ist ein Vertrag: Jedes Feld ist etwas, worauf sich ein anderes System verlassen darf, und das schneidet in beide Richtungen. Skill-Beschreibungen werden von auswählenden Modellen gelesen — vage Beschreibungen sind funktional kaputte Links; deklarierte Auth-Schemes müssen dem Deployment exakt entsprechen, sonst zahlt jeder Konsument eine verwirrende gescheiterte Runde.
Wichtiger als jedes Einzelfeld ist die Integritätsregel: Bewirb nie, was nicht existiert. Keine OAuth-Metadaten ohne echte geschützte Ressource dahinter, keine Skills, die das Deployment nicht bedienen kann, keine internen Hostnamen oder Geheimnisse in einer Datei, die per Definition öffentlich ist. Validiere die Card so, wie sie ausgeliefert wird — von der echten Well-known-URL, wo Redirects, Caches und Content-Type-Umschreibungen wohnen — mit dem A2A-Agent-Card-Validator.
WebMCP: Tools in der Seite selbst
WebMCP schließt den Kreis: Eine Seite registriert aufrufbare Tools bei der Agent-Runtime des Browsers — Name, Beschreibung, JSON-Schema-Parameter und ein Ausführungspfad —, sodass ein Agent die Funktionalität deiner Site direkt ausführen kann, statt sie zu scrapen. Das Handwerk überträgt sich eins zu eins aus dem API-Design: präzise Namen, Beschreibungen für ein Modell geschrieben, das zwischen Tools wählen muss, streng validierende Parameter und ehrliche Read-only-Annotationen, wo sie zutreffen.
Linte die Contracts vor dem Ausliefern mit dem WebMCP-Tool-Validator — Namen, Beschreibungen, Parameter-Schemas, Labels und die Security-Hinweise, die Agents zunehmend prüfen. Und runde die Schicht mit den langweiligen, tragenden Dateien ab: einer aktuellen security.txt-Validator/Generator, damit Befunde dich erreichen, und konsistenten Canonicals, damit jeder Leser — Mensch, Crawler oder Agent — auf denselben URLs konvergiert. Agent-Lesbarkeit ist nicht eine Datei; sie ist die Disziplin, alle Dateien dieselbe wahre Geschichte erzählen zu lassen.