Wir stellen den Agententauglichkeitsscore vor. Ist Ihre Website agentenfähig?

Das Web musste sich schon immer an neue Standards anpassen. Erst lernte es, mit Webbrowsern zu kommunizieren, dann mit Suchmaschinen. Jetzt muss es sich mit KI-Agenten verständigen.

Deshalb freuen wir uns, heute isitagentready.com vorstellen zu können: ein neues Tool, das Betreibern von Websites eine bessere Vorstellung davon vermittelt, wie sich diese für Agenten optimieren lassen: Abgedeckt werden die Begleitung von Agenten bei der Authentifizierung, die Kontrolle der für Agenten einsehbaren Inhalte, das Format, in dem diese Inhalte Agenten verfügbar gemacht werden, sowie die Art und Weise, in der Agenten für die Inhalte bezahlen. Außerdem bieten wir ab sofort einen neuen Datensatz bei Cloudflare Radar, mit dem die allgemeine Einführung der einzelnen Agenten-Standards im Internet nachverfolgt wird.

Wir möchten mit gutem Beispiel vorangehen. Deshalb gehen wir näher darauf ein, wie wir vor Kurzem die Entwicklerdokumentation von Cloudflare überarbeitet haben, um sie so agentenfreundlich wie möglich zu gestalten, damit KI-Tools Fragen schneller und wesentlich sparsamer beantworten können.

Die kurze Antwort lautet: nicht besonders. Das ist nicht überraschend. Es zeigt aber auch, wie viel effektiver Agenten durch die Einführung von Standards arbeiten könnten.

Um dies zu analysieren, hat Cloudflare Radar bei den 200.000 Domains mit den meisten Besuchern im Internet die Kategorien herausgefiltert, bei denen Agententauglichkeit nicht von Bedeutung sind (wie Weiterleitungen, Adserver und Tunnel-Dienste). Der Fokus wurde damit auf Unternehmen, Verlage und Publisher sowie Plattformen gelegt, mit denen KI-Agenten realistischerweise eventuell interagieren müssen. Diese haben wir mit unserem neuen Tool gescannt.

Das Ergebnis ist ein neuer Graph mit dem Namen „Verbreitung von Standards für KI-Agenten“. Dieser findet sich jetzt auf der Seite Cloudflare Radar AI Insights (KI-Informationen von Cloudflare Radar), wo die Verbreitung der einzelnen Standards in verschiedenen Domain-Kategorien gemessen werden können.

Bei näherer Betrachtung stachen einige Dinge heraus:

• robots.txt ist nahezu allgegenwärtig – 78 % der Websites verfügen über eine solche Datei. In der überwiegenden Zahl der Fälle wurden diesen allerdings nicht für KI-Agenten, sondern für konventionelle Suchmaschinen-Crawler geschrieben.

• Content Signals: 4 % der Websites haben ihre Präferenzen bezüglich des KI-Einsatzes in ihrer robots.txt-Datei angegeben. Dabei handelt es sich um einen neuen Standard, der an Beliebtheit gewinnt.

• Die Markdown-Content-Negotiation (Bereitstellung von text/markdown bei „Accept: text/markdown“) funktioniert auf 3,9 % der Websites.

• Neue Standards wie MCP-Server-Karten und API-Kataloge (RFC 9727) finden sich zusammen bei weniger als 15 Websites im gesamten Datensatz. Diese Technologie steckt noch in den Kinderschuhen. Doch wer die neuen Standards als Erstes einführt und gut mit Agenten zusammenarbeitet, hat die besten Chancen, sich von der Masse abzuheben. 

Dieses Diagramm wird wöchentlich aktualisiert und die Daten können auch über den Data Explorer oder die Radar-API abgerufen werden.

Um einen Score für die Agententauglichkeit Ihrer Website ermitteln zu lassen, können Sie unter isitagentready.com die URL der Website eingeben.

Scores und Überprüfungen liefern hilfreiche Rückmeldungen und haben in der Vergangenheit bereits die Akzeptanz neuer Standards gefördert. Der Google Lighthouse-Score beispielsweise bewertet Websites nach Performance und Best Practices im Bereich Sicherheit und gibt Betreibern Hinweise für die Einführung der neuesten Standards für Web-Plattformen. Unserer Ansicht nach sollte es ein vergleichbares Angebot geben, das Website-Betreibern die Einführung von Best Practices in Bezug auf Agenten erleichtert.

Nach Eingabe Ihrer Website sendet Cloudflare Anfragen an diese, um zu überprüfen, welche Standards sie unterstützt. Anschließend wird anhand von vier Kriterien eine Bewertung erstellt:

• Auffindbarkeit: robots.txt, sitemap.xml, Link-Header (RFC 8288)

• Inhalte: Markdown für Agenten

• Bot-Zugriffskontrolle: Content Signals, KI-Bot-Richtlinien in robots.txt, Web Bot-Authentifizierung

• Funktionen: Agent Skills, API-Katalog (RFC 9727), OAuth-Servererkennung über RFC 8414 und RFC 9728, MCP-Server-Karte und WebMCP

^{Screenshot mit den Ergebnissen einer Agententauglichkeitsprüfung einer Beispielwebsite.}

Wir überprüfen auch, ob die Website Standards des agentenbasierten Handels unterstützt, darunter x402, Universal Commerce Protocol und Agentic Commerce Protocol. Diese Standards werden aber derzeit nicht in die Bewertung einbezogen.

Bei jedem fehlgeschlagenen Test stellen wir Ihnen einen Prompt für Ihren Coding-Agenten zur Verfügung, mit dem dieser angewiesen wird, die entsprechende Unterstützung für Sie zu implementieren.

Die Website selbst ist auch agententauglich. Das heißt, dass wir die von uns vertretenen Prinzipien auch selbst anwenden. Sie legt einen zustandslosen MCP-Server (https://isitagentready.com/.well-known/mcp.json) mit einem scan_site-Tool über Streamable HTTP offen, damit alle mit MCP kompatiblen Agenten Websites auf Programmebene ohne Nutzung der Weboberfläche scannen können. Außerdem veröffentlicht sie einen Agent Skills-Index (https://isitagentready.com/.well-known/agent-skills/index.json) mit Skill-Dokumenten für jeden überprüften Standard. So wissen Agenten nicht nur, was sie ändern müssen, sondern auch, wie sie dabei vorgehen können.

Kommen wir jetzt zu den einzelnen Tests nach Kategorie – und warum diese für Agenten wichtig sind.

Das Konzept von robots.txt gibt es seit 1994, und die meisten Websites verfügen über eine solche Datei. Sie hat zwei Funktionen: Darin werden zum einen Crawling-Regeln (wer auf welche Inhalte zugreifen darf) festgelegt und zum anderen auf Sitemaps verwiesen. Eine Sitemap ist eine XML-Datei, die jeden Pfad auf einer Website auflistet. Im Grunde handelt es sich um eine Karte, die Agenten zu allen Inhalte einer Website führt, ohne dass dafür jedem Link einzeln gefolgt werden muss. In der Regel steuern Bots zunächst die robots.txt-Datei an.

Neben Sitemaps können Agenten auch wichtige Ressourcen direkt aus HTTP-Antwort-Headern ermitteln, insbesondere mit dem Antwort-Header-Link (RFC 8288). Im Gegensatz zu in HTML-Code eingebetteten Links ist der Link-Header Teil der HTTP-Antwort selbst. Das bedeutet, dass ein Client Links zu Ressourcen ermitteln kann, ohne dafür Markups analysieren zu müssen:

HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"

Einen Agenten zu Ihrer Website zu führen, ist eine Sache. Sicherzustellen, dass er die sich dort befindenden Inhalte auch tatsächlich lesen kann, ist eine andere.

Im September 2024 – was angesichts der rasanten Entwicklung der KI wie eine Ewigkeit erscheint – wurde llms.txt vorgeschlagen, um eine LLM-freundliche Darstellung einer Website zu ermöglichen, die in das Kontextfenster des Modells passt. llms.txt ist eine Klartextdatei im Stammverzeichnis Ihrer Website, die Agenten eine strukturierte Leseliste bereitstellt: Daraus geht hervor, worum es sich bei der Website handelt, was sie beinhaltet und wo die wichtigen Inhalte zu finden sind. Man kann sich das vorstellen wie eine Sitemap, die jedoch nicht zur Indexierung durch einen Crawler, sondern für ein LLM verfasst wurde.

# My Site
> A developer platform for building on the edge.
## Documentation
- [Getting Started](https://example.com/docs/start.md)
- [API Reference](https://example.com/docs/api.md)
## Changelog
- [Release Notes](https://example.com/changelog.md)

Marktdown-Content-Negotiation geht noch weiter. Wenn ein Bot eine Seite abruft und einen „Accept: text/markdown“-Header sendet, antwortet der Server mit einer bereinigten Markdown-Version anstelle von HTML. Die Markdown-Version erfordert weitaus weniger Token. Wir haben in einigen Fällen eine Verringerung der Token-Zahl von bis zu 80 % gemessen. Das macht die Antworten schneller und günstiger. Außerdem erhöht sich dadurch die Wahrscheinlichkeit, dass die Informationen vollständig erfasst werden, weil die Kontextfenster der meisten Agenten-Tools standardmäßig nur einen begrenzten Umfang haben.

Standardmäßig wird nur geprüft, ob die Website die Markdown-Content-Negotiation korrekt durchführt, während das Vorhandensein von llms.txt nicht überprüft wird. Die Überprüfung lässt sich bei Bedarf aber so anpassen, dass sie auch die llms.txt-Datei mit einschließt.

Da Agenten sich jetzt auf Ihrer Website bewegen und Ihre Inhalte konsumieren können, stellt sich die Frage: Wollen Sie diese Möglichkeit jedem Bot einräumen?

robots.txt macht mehr, als nur auf Sitemaps zu verweisen. In dieser Datei definieren Sie auch Ihre Zugriffsrichtlinien. Sie können hier explizit festlegen, welche Crawler zugelassen sind und worauf diese Zugriff haben, bis hin zu bestimmten Pfaden. Dieses Konzept hat sich bewährt und diese Datei ist immer noch der erste Ort, an dem ein seriöser Bot nachsieht, bevor er mit dem Crawling beginnt.

Content Signals ermöglicht eine größere Präzision. Damit können Sie nicht nur allgemein regeln, was zugelassen und was blockiert wird: Sie können genau festlegen, was die KI mit Ihren Inhalten tun darf. Mit einer Content Signals-Richtlinie in Ihrer robots.txt-Datei lassen sich drei Dinge unabhängig voneinander steuern: ob Ihre Inhalte für das KI-Training genutzt werden dürfen (ai-train), ob sie als Input für die Inferenz und als Bezugsbasis der KI verwendet werden dürfen (ai-input) und ob sie in den Suchergebnissen erscheinen sollen (search).

User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes

Umgekehrt ermöglicht der Web Bot Auth-Standardentwurf der IETF gutartigen Bots, sich zu authentifizieren, und Website-Betreibern, Bots zu identifizieren. Ein Bot signiert seine HTTP-Anfragen und die empfangende Website überprüft diese Signaturen mit den veröffentlichten öffentlichen Schlüsseln des Bots.

Diese öffentlichen Schlüssel sind in einem bekannten Endpunkt /.well-known/http-message-signatures-directory gespeichert, der im Rahmen des Scans überprüft wird.

Nicht alle Websites müssen diese Regelung anwenden. Sie ist nicht erforderlich, wenn Ihre Website nur Inhalte bereitstellt und keine Anfragen an andere Websites richtet. Wir gehen jedoch davon aus, dass diese Funktion mit der Zeit immer wichtiger werden wird, wenn mehr Websites mit ihren eigenen Agenten Anfragen an andere Websites stellen.

Neben dem passiven Konsum von Inhalten können Agenten auch direkt mit Ihrer Website interagieren: in Form von API-Aufrufen, der Nutzung von dort vorhandenen Tools und der eigenständigen Ausführung von Aufgaben.

Wenn Ihr Dienst über eine oder mehrere öffentliche API verfügt, bietet der API-Katalog (RFC 9727) Agenten eine gemeinsame bekannte Anlaufstelle, über die er sie alle ermitteln kann. In der Datei /.well-known/api-catalog sind Ihre API sowie Links zu ihren technischen Daten, ihrer Dokumentation und ihren Status-Endpunkten aufgeführt. Somit müssen Agenten nicht mehr Ihr Entwicklerportal durchsuchen oder Ihre Dokumentation lesen.

Wenn es um Agenten geht, kann das Thema MCP nicht unerwähnt bleiben. Bei dem Model Context Protocol handelt es sich um einen offenen Standard, mit dessen Hilfe KI-Modelle sich mit externen Datenquellen und -tools verbinden können. Es wird nicht für jedes einzelne KI-Tool eine benutzerdefinierte Integration geschaffen, sondern ein einziger gemeinsamer MCP-Server, den alle kompatiblen Agenten nutzen können.

Um Agenten bei der Suche nach Ihrem MCP-Server zu helfen, können Sie eine MCP-Server-Karte veröffentlichen (ein Vorschlag, der sich zurzeit im Entwurfstadium befindet). Diese JSON-Datei unter /.well-known/mcp/server-card.json beschreibt Ihren Server, bevor sich ein Agent verbindet: welche Tools er zur Verfügung stellt, wie er zu erreichen ist und wie die Authentifizierung erfolgt. Ein Agent liest diese Datei und erfährt alles, was für die Verwendung Ihres Servers benötigt wird:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/mcp-server-card/v1.json",
  "version": "1.0",
  "protocolVersion": "2025-06-18",
  "serverInfo": {
    "name": "search-mcp-server",
    "title": "Search MCP Server",
    "version": "1.0.0"
  },
  "description": "Search across all documentation and knowledge base articles",
  "transport": {
    "type": "streamable-http",
    "endpoint": "/mcp"
  },
  "authentication": {
    "required": false
  },
  "tools": [
    {
      "name": "search",
      "title": "Search",
      "description": "Search documentation by keyword or question",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": { "type": "string" }
        },
        "required": ["query"]
      }
    }
  ]
}

Agenten arbeiten am besten, wenn ihnen Agent Skills (agentenbezogene Fähigkeiten) geboten werden, die ihnen bei der Erledigung bestimmter Aufgaben helfen. Doch wie können sie herausfinden, welche Fähigkeiten eine Website bietet? Wir schlagen vor, dass Websites diese Informationen unter .well-known/agent-skills/index.json bereitstellen – einem Endpunkt, der dem Agenten mitteilt, welche Fähigkeiten verfügbar und wo diese zu finden sind. Vielleicht haben Sie schon festgestellt, dass der .well-known-Standard (RFC 8615) von vielen anderen Agenten- und Autorisierungsstandards verwendet wird. Vielen Dank an Mark Nottingham von Cloudflare, der den Standard verfasst hat, und an andere IETF-Mitwirkende!

Auf viele Websites kann man nur nach vorherigem Login zugreifen. Das erschwert es Menschen, Agenten die Möglichkeit zu geben, in ihrem Namen auf diese Websites zuzugreifen. Aus diesem Grund haben einige die fragwürdige und unsichere Notlösung gewählt, Agenten Zugriff auf den Webbrowser des Nutzers mit dessen Sitzung nach dem Login zu gewähren.

Es gibt aber eine bessere Möglichkeit zur Gewährung ausdrücklichen Zugriffs: Websites mit OAuth-Unterstützung können Agenten mitteilen, wo der Autorisierungsserver zu finden ist (RFC 9728). So können Menschen von Agenten durch einen OAuth-Prozess geleitet werden, im Rahmen dessen sie entscheiden können, dem Agenten ordnungsgemäß Zugriff zu gewähren. Wie wir während der Agents Week 2026 bekannt gegeben haben, unterstützt Cloudflare Access diesen OAuth-Ablauf jetzt vollständig. Wir haben gezeigt, wie Agenten wie OpenCode diesen Standard nutzen können, um ganz einfach Zugriff zu ermöglichen, wenn Nutzer Agenten geschützte URL zur Verfügung stellen:

Agenten können außerdem in Ihrem Namen Dinge kaufen, doch webbasierte Zahlungen sind für Menschen konzipiert: Artikel dem Warenkorb hinzufügen, Kreditkartendaten eingeben, auf „Bezahlen“ klicken. Wenn es sich bei den Käufern aber um KI-Agenten handelt, funktioniert diese Abläufe nicht mehr.

x402 löst dieses Problem auf Protokollebene durch Wiederbelebung des Statuscode „HTTP 402 Payment Required“, der seit 1997 existiert, aber noch nie weit verbreitet war. Der Ablauf ist einfach: Ein Agent fordert eine Ressource an, der Server antwortet mit dem Statuscode „402“ und einer maschinenlesbaren Nutzlast, in der die Zahlungsbedingungen beschrieben werden. Der Agent bezahlt und versucht es erneut. Cloudflare hat gemeinsam mit Coinbase die x402 Foundation gegründet, die sich die Verbreitung von x402 als offenem Standard für Internetzahlungen zum Ziel gesetzt hat.

Außerdem führen wir eine Überprüfung nach dem Universal Commerce Protocol und dem Agentic Commerce Protocol durch. Diese beiden neuen Standards für agentenbasierten Handel sollen es Agenten ermöglichen, Produkte aufzuspüren und zu kaufen, die Menschen normalerweise über E-Commerce-Seiten erwerben.

Mit der URL-Analyse von Cloudflare kann für jede beliebige URL ein detaillierter Bericht erstellt werden, der HTTP-Header, TLS-Zertifikate, DNS-Einträge, genutzte Technologien, Performance-Daten und Sicherheitswarnungen umfasst. Dieses Tool ist für Sicherheitsforscher und Entwickler von maßgeblicher Bedeutung, die verstehen wollen, was genau hinter einer bestimmten URL steckt.

Wir haben die Tests von isitagentready.com übernommen und der URL-Analyse einen neuen Reiter namens „Agent Readiness“ (Agententauglichkeit) hinzugefügt. Beim Scannen einer beliebigen URL sehen Sie jetzt den gesamten Agententauglichkeitsbericht als Ergänzung zu der bisherigen Analyse. Darin finden sich die bestandenen Tests, das Niveau der Website und praxistaugliche Empfehlungen zur Verbesserung ihres Scores.

Die Integration ist auch auf Progammebene über die URL-Analyse-API verfügbar. Wenn Agententauglichkeit in die Analyse einbezogen werden soll, geben Sie die Option „agentReadiness“ bei Ihrer Scan-Anfrage an:

curl -X POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/urlscanner/v2/scan \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    -d '{
          "url": "https://www.example.com",
          "options": {"agentReadiness": true}
        }'

Während wir die Tools zur Messung der Agententauglichkeit des Webs entwickelt haben, war uns bewusst, dass wir auch vor unserer eigenen Haustür kehren mussten. Mit anderen Worten: Auch unsere Dokumentation muss für die Agenten unserer Kunden leicht zugänglich sein.

Deshalb haben wir natürlich die oben genannten relevanten inhaltsbezogenen Website-Standards übernommen. Unseren Score finden Sie hier. Doch damit haben wir uns nicht begnügt. So haben wir unsere Entwicklerdokumentation zur agentenfreundlichsten Ressource im Internet umgestaltet.

Leider fordern mit Stand von Februar 2026 unter sieben getesteten Agenten nur Claude Code, OpenCode und Cursor standardmäßig Inhalte mit dem Header „Accept: text/markdown“ an. Für den Rest benötigten wir eine nahtlose, URL-basierte Alternativlösung.

Dafür stellen wir jede Seite einzeln als Markdown unter /index.md relativ zur URL der Seite zur Verfügung. Dies erfolgt dynamisch, ohne die Duplizierung statischer Dateien, durch die Kombination von zwei Cloudflare-Richtlinien: 

• Eine „URL Rewrite“-Regel gleicht auf /index.md endende Anfragen ab und wandelt sie mit regex_replace automatisch in den Grundpfad um (/index.md wird gestrichen). 

• Eine „Request Header Transform“-Regel gleicht den ursprünglichen Anfragepfad vor der Neuschreibung (raw.http.request.uri.path) ab und setzt automatisch den „Accept: text/markdown“-Header. 

Mit diesen beiden Regeln kann jede Seite durch Anfügen des Pfads /index.md an ihre URL als Markdown abgerufen werden:

• https://developers.cloudflare.com/r2/get-started/index.md

Wir verweisen in unseren llms.txt-Dateien auf diese /index.md-URL. De facto liefern wir für diese /index.md-Pfade immer die Markdown-Version, unabhängig davon, welche Header vom Client gesetzt werden. Dabei kommen wir ohne zusätzliche Build-Schritte und der Verdopplung von Inhalten aus.

Die Datei llms.txt dient als Ausgangspunkt für Agenten und bietet ein Seitenverzeichnis, das LLM beim Auffinden von Inhalten hilft. Allerdings dürften mehr als 5.000 Seiten Dokumentation in einer einzigen Datei die Kontextfenster der Modelle sprengen.

Anstatt einer einzigen riesigen Datei erstellen wir deshalb für jedes oberste Verzeichnis in unserer Dokumentation eine gesonderte llms.txt-Datei und die llms.txt-Stammdatei verweist einfach auf die entsprechenden Unterverzeichnisse.

• https://developers.cloudflare.com/llms.txt

• https://developers.cloudflare.com/r2/llms.txt

• https://developers.cloudflare.com/workers/llms.txt

Wir entfernen außerdem Hunderte von Verzeichnislistenseiten, die für ein LLM nur geringen semantischen Nutzen bieten. Darüber hinaus stellen wir sicher, dass jede Seite einen umfassenden beschreibenden Kontext (Titel, semantische Namen und Beschreibungen) aufweist.

Wir verzichten beispielsweise auf etwa 450 Seiten, die nur als lokalisierte Verzeichniseinträge dienen, wie https://developers.cloudflare.com/workers/databases/.

Diese Seiten sind zwar in unserer XML-Sitemap enthalten, bieten für LLM aber nur wenige Informationen. Da alle untergeordneten Seiten bereits einzeln in llms.txt verlinkt sind, liefert der Abruf einer Verzeichnisseite lediglich eine redundante Liste von Links. Das zwingt den Agenten, eine weitere Anfrage zu stellen, um die eigentlichen Inhalte zu finden.

Um Agenten eine effiziente Navigation zu ermöglichen, sollte jeder llms.txt-Eintrag viel Kontext aufweisen, aber wenig Token erfordern. Menschen ignorieren Vorspann-Metadaten und Filterbezeichnungen möglicherweise, doch einem KI-Agenten weisen diese Metadaten den Weg. Deshalb hat unser Product Content Experience (PCX)-Team unsere Seitentitel, Beschreibungen und URL-Strukturen so überarbeitet, dass die Agenten immer ganz genau wissen, welche Seiten sie abrufen müssen.

Es folgt ein Abschnitt aus unserer llms.txt-Stammdatei.

Jeder Link verfügt über einen semantischen Namen, eine passende URL und eine hochwertige Beschreibung. Für die Erstellung der llms.txt-Datei hat dies keinen zusätzlichen Aufwand erfordert. Die Informationen waren alle schon in den Metadaten der Dokumentation enthalten. Gleiches gilt für Seiten in den llms.txt-Dateien im Hauptverzeichnis. All dies macht es Mitarbeitenden leichter, relevante Informationen zu finden.

Darüber hinaus testen wir unsere Dokumentation anhand von afdocs. Dabei handelt es sich um eine neue, agentenfreundliche Dokumentationsspezifikation und ein Open Source-Projekt, mit dem bei Dokumentations-Websites Aspekte wie Inhaltserkennung und Navigation getestet werden können. Dank dieser Spezifikation konnten wir eigene benutzerdefinierte Audit-Werkzeuge entwickeln. Durch die Erweiterung um ein paar auf unseren spezifischen Anwendungsfall zugeschnittene Patches haben wir ein Dashboard zur einfachen Beurteilung erstellt.

Wir haben einen Agenten (Kimi-k2.5 über OpenCode) auf die llms.txt-Dateien anderer großer Websites für technische Dokumentation ausgerichtet und ihn damit beauftragt, sehr spezifische technische Fragen zu beantworten.

Dieser verbrauchte im Schnitt 31 % weniger Token und gelangte 66 % schneller zur richtigen Antwort, wenn er auf die Dokumentation von Cloudflare ausgerichtet wurde, als bei Ausrichtung auf durchschnittliche, nicht speziell auf Agenten zugeschnittene Webauftritte. Weil wir unsere Produktverzeichnisse in einem einzigen Kontextfenster unterbringen, können Agenten die benötigte Seite genau identifizieren und über einen einzigen, linearen Pfad abrufen.

Wie zutreffend LLM-Antworten sind, hängt oft von der Effizienz des Kontextfensters ab. Während unserer Tests haben wir ein wiederkehrendes Muster bei anderen Dokumentationssätzen beobachtet.

1. Die Suchschleife: Viele Dokumentations-Websites stellen eine einzige, riesige llms.txt-Datei bereit, die das unmittelbare Kontextfenster des Agenten sprengt. Weil der Agent nicht die ganze Datei „lesen“ kann, beginnt er, nach Schlüsselwörtern zu suchen. Wenn beim ersten Durchsuchen die gewünschte Information übersehen wird, muss der Agent nachdenken, die Suche verfeinern und es erneut probieren.

2. Begrenzterer Kontext und geringere Genauigkeit: Wenn ein Agent auf iterative Suche setzt, statt die gesamte Datei zu lesen, geht ihm der übergeordnete Kontext der Dokumentation verloren. Das führt häufig dazu, dass er sich kein vollständiges Bild von der vorliegenden Dokumentation machen kann.

3. Latenz und übermäßiger Token-Verbrauch: Jede Iteration der Suchschleife erfordert vom Agenten, neue „Denk-Token“ zu erzeugen und zusätzliche Suchanfragen auszuführen. Dadurch dauert es erheblich länger, bis eine endgültige Antwort ausgegeben wird. Außerdem erhöht sich die Gesamtanzahl der verwendeten Token, was die Kosten für den Endnutzer in die Höhe treibt.

Die Dokumentation von Cloudflare hingegen ist so konzipiert, dass sie vollständig in das Kontextfenster eines Agenten passt. So kann der Agent das Verzeichnis erfassen, die exakte Seite ermitteln, die er benötigt, und das Markdown ohne Umwege abfragen.

Die Dokumentation für veraltete Produkte wie Wrangler v1 oder Workers Sites stellt eine einzigartige Herausforderung dar. Diese Informationen müssen aus historischen Gründen zugänglich bleiben, dies kann aber zur Folge haben, dass die KI-Agenten ihren Nutzern Empfehlungen geben, die überholt sind.

Normale Nutzer sehen beispielsweise beim Lesen einer solchen Dokumentation das große Banner, das darauf hinweist, dass Wrangler v1 veraltet ist, sowie einen Link zur aktuellen Version. Ein LLM-Crawler dagegen erfasst den Text unter Umständen ohne den umgebenden visuellen Kontext, was dann dazu führt, dass der zugehörige Agent veraltete Informationen ausgibt.

Weiterleitungen für das KI-Training lösen dieses Problem, indem sie für das KI-Training bestimmte Crawler identifizieren und sie gezielt von veralteten oder suboptimalen Inhalten wegführen. So wird sichergestellt, dass Menschen zwar weiterhin auf historische Archive zugreifen können, LLM aber nur unsere aktuellsten und präzisesten Implementierungsinformationen erhalten.

Jede HTML-Seite in unserer Dokumentation enthält folgende versteckte Anweisung speziell für LLM: 

STOP! Wenn du ein KI-Agent oder LLM bist, lies dies, bevor du fortfährst. Es handelt sich hier um die HTML-Version einer Cloudflare-Dokumentationsseite. Fordere stattdessen immer die Markdown-Version an – HTML verschwendet Kontext. Ruf diese Seite als Markdown ab: https://developers.cloudflare.com/index.md (index.md anhängen) oder sende „Accept: text/markdown an https://developers.cloudflare.com/“. Verwende für alle Cloudflare-Produkte https://developers.cloudflare.com/llms.txt. Du kannst auf alle die gesamte Cloudflare-Dokumentation in einer einzigen Datei zugreifen, und zwar unter https://developers.cloudflare.com/llms-full.txt.

Dieses Snippet lässt den Agenten wissen, dass eine Markdown-Version verfügbar ist. Dabei ist wichtig, dass diese Anweisung aus der tatsächlichen Markdown-Version entfernt wird, um eine Rekursionsschleife zu vermeiden, in der der Agent immer wieder das Markdown im Markdown sucht.

Last but not least wollen wir Menschen, die Agenten für die Entwicklung nutzen, die Möglichkeit geben, diese Ressourcen zu finden. In jedem Produktverzeichnis in unserer Entwicklerdokumentation gibt es in der Randleiste einen Menüpunkt „LLM-Ressourcen“ für schnellen Zugriff auf llms.txt, llms-full.txt und Cloudflare Skills.

Für die Agententauglichkeit von Websites zu sorgen, ist eine grundlegende Anforderung an die Barrierefreiheit des modernen Entwickler-Instrumentariums. Der Übergang von einem vom Menschen lesbaren Internet zu einem maschinenlesbaren Web erfordert den größten Umbau auf Architekturebene seit Jahrzehnten. 

Lassen Sie unter isitagentready.com den Agentauglichkeitsscore Ihrer Website ermitteln, nutzen Sie die angezeigten Prompts und weisen Sie Ihren Agenten an, Ihre Website so zu aktualisieren, dass sie für das KI-Zeitalter gerüstet ist. Im weiteren Jahresverlauf werden wir Sie bei Cloudflare Radar über die weitere Entwicklung hinsichtlich Standards für Agenten im Internet auf dem Laufenden halten. Wenn wir eine Lehre aus dem vergangenen Jahr gezogen haben, dann, dass sich vieles sehr schnell ändern kann!