So bereiten Sie Ihre selbst gehostete Website auf KI-Agenten vor

In einem Hacker-News-Thread über den Traffic von KI-Crawlern beschrieb ein Hosting-Administrator die Last aus Betreibersicht: „etwa 6 verschiedene ziemlich aggressive KI-Bots“, die sich regelmäßig auf Produktvarianten- oder Kategorieseiten festbeißen und diese mit rund einer Anfrage pro Sekunde bearbeiten, auf einer Site, bei der „jeder Seitenaufruf einen ganzen Roundtrip von 1 s dauern kann (das meiste davon in MySQL)“. Der kumulative Effekt, im selben Kommentar: „fast so, als würde die Site jeden einzelnen Tag geslashdottet“.

Die Vorbereitung Ihrer Website auf KI-Agenten ist in erster Linie ein Kapazitätsproblem. Der Großteil der Arbeit ist deshalb Serverkonfiguration und nur ein sehr kleiner Teil Content-Strategie. Das Praktische an diesem Traffic: Er ist überwiegend nicht anonym. Die Unternehmen, die ihn erzeugen, veröffentlichen die Namen ihrer Crawler, dokumentieren, wofür jeder gedacht ist, und erklären, wie man sie abschaltet. Im Folgenden geht es darum, was zu konfigurieren ist, was jeder Mechanismus in der Praxis durchsetzt und welche zwei Schritte ich auslassen würde: eine llms.txt zu veröffentlichen und Schema-Markup für KI hinzuzufügen.

Kurzfassung

• KI-Traffic fällt üblicherweise in Training, Indexierung für die KI-Suche und nutzerausgelöste Abrufe. OpenAI und Anthropic stellen für diese Zwecke getrennte Tokens bereit, sodass Sie sie unabhängig steuern können; manche Mehrzweck-Crawler bündeln mehrere Rollen unter einer Identität.
• OpenAI, Anthropic, Perplexity und Common Crawl dokumentieren robots.txt-Steuerungen für ihre automatischen Crawler. Nutzerausgelöste Abrufe sind die Ausnahme: Anthropic wendet robots.txt auch auf Claude-User an, OpenAI sagt, die Regeln gelten für ChatGPT-User möglicherweise nicht, und Perplexity-User ignoriert sie in der Regel.
• Die Datei robots.txt ist ein Einwilligungsmechanismus, keine Zugriffskontrolle. RFC 9309 verleiht ihr keine eigene Durchsetzungskraft; regelkonforme Bots können Ihre Last senken, indem sie sie beachten, aber sie kann nicht regelwidrigen Traffic drosseln oder stoppen.
• Über 137.210 Domains aus dem Analytics-Kundenstamm von Ahrefs hinweg erhielten 97 % der veröffentlichten llms.txt-Dateien im Mai 2026 null Anfragen. Veröffentlichen Sie ruhig eine, aber bauen Sie kein Tooling darum herum.
• Behalten Sie strukturierte Daten dort bei, wo sie klassische Suchfunktionen unterstützen. Googles Dokumentation sagt jedoch, dass für seine KI-Funktionen kein spezielles Schema und keine KI-Textdatei erforderlich ist.
• Rendern Sie kritische Inhalte serverseitig, wenn OpenAI, ClaudeBot, PerplexityBot oder CCBot sie lesen sollen. Vercel stellte fest, dass diese Crawler kein JavaScript ausführen; Gemini über Googlebot und AppleBot sind die Ausnahmen.
• Jenseits der kooperativen robots.txt-Regeln findet die Durchsetzung am Reverse Proxy statt, in einer WAF, die Sie selbst betreiben, oder hinter einer Proof-of-Work-Challenge, in dieser Reihenfolge der Kosten.

Was dieser Artikel nicht behandelt

Es geht hier um eine Website, die von Agenten besucht wird, nicht um eine Website, die mit ihnen Geschäfte abwickelt. Vier angrenzende Themen bleiben außen vor.

• Agentischer Handel und Checkout-Flows, ein anderes Problem für eine andere Art von Website.
• Die rechtliche und urheberrechtliche Debatte um Trainingsdaten, die eine unternehmerische Entscheidung ist und keine Serverkonfiguration.
• Eine Schritt-für-Schritt-Anleitung zur WebMCP-Implementierung, denn der Standard befindet sich noch im Origin Trial.
• CDN-spezifische Konfiguration über den einen Cloudflare-Abschnitt unten hinaus.

Welche KI-Crawler auf Ihre Website einprasseln

GPTBot und ClaudeBot sammeln Inhalte, die für das Modelltraining verwendet werden können. OAI-SearchBot und Claude-SearchBot unterstützen KI-Suche und -Abruf. ChatGPT-User und Claude-User holen Seiten als Reaktion auf Nutzeraktionen. Bei manchen Anbietern sind diese Aufgaben getrennt, aber nicht jeder Crawler im Web lässt sich sauber einem einzigen Zweck zuordnen.

Das Bild der Regeltreue ist genauer, als die verkürzte Darstellung nahelegt. Anthropics Crawler-Dokumentation sagt, dass ClaudeBot, Claude-User und Claude-SearchBot robots.txt beachten. OpenAIs Bot-Dokumentation sagt, dass seine automatischen Crawler unabhängige Steuerungen nutzen, die robots.txt-Regeln aber möglicherweise nicht für ChatGPT-User gelten, weil diese Anfragen von einer Person ausgelöst werden. Perplexitys Crawler-Dokumentation trifft eine ähnliche Unterscheidung: PerplexityBot befolgt Webmaster-Steuerungen, während Perplexity-User robots.txt in der Regel ignoriert. Die pauschale Behauptung, KI-Bots ignorierten robots.txt, wirft also dokumentierte Crawler, die die Datei beachten, mit nutzerausgelösten Abrufern zusammen, deren Verhalten je nach Anbieter variiert, sowie mit Scrapern, die sich überhaupt nie zu erkennen geben.

Die folgende Tabelle ist zum Zeitpunkt des Schreibens aktuell. Neue Tokens tauchen schneller auf, als ein Artikel sie verfolgen kann. Betrachten Sie sie also als Startkarte mit kurzer Haltbarkeit.

robots.txt-Regeln für KI-Crawler schreiben

RFC 9309 sagt, dass die Regeln in robots.txt keine Form der Zugriffsautorisierung sind. Die IETF hat im September 2022 Syntax, Parsing und Caching standardisiert; sie hat die Datei damit nicht zu einem Durchsetzungsmechanismus gemacht. Die Details, die in der Praxis wehtun, liegen unterhalb der Syntax: Die Datei muss UTF-8-kodiert sein, Parser müssen mindestens 500 Kibibyte verarbeiten, und bei widersprüchlichen Direktiven gewinnt die spezifischste Pfadübereinstimmung. Wo eine Regel in der Datei steht, spielt keine Rolle.

Eine robots.txt für KI-Bots nutzt dieselbe Datei und dieselbe Syntax, die Sie ohnehin haben; was sich ändert, ist die Token-Liste. Ordnen Sie die Regeln nach Absicht, dann überdauern sie die jeweilige Anbieterriege. Wenn Ihr Einwand dem Training gilt, blockieren Sie die Trainings-Tokens und lassen Sie die Indexer in Ruhe:

# Block training, keep AI search indexing
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Wenn Sie jedem in der Tabelle genannten Token ein sitewide Opt-out-Signal senden wollen, fassen Sie sie unter einer Regel zusammen. Das Disallow elfmal zu wiederholen ist unnötig:

# Send a site-wide opt-out signal to named AI tokens
User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: OAI-AdsBot
User-agent: ClaudeBot
User-agent: Claude-User
User-agent: Claude-SearchBot
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Google-Extended
User-agent: CCBot
Disallow: /

Das ist immer noch keine universelle Sperre. Anthropic wendet robots.txt auf Claude-User an, aber OpenAI sagt, die Regeln gelten für ChatGPT-User möglicherweise nicht, und Perplexity-User ignoriert sie in der Regel. Wenn diese nutzerausgelösten Abrufe gestoppt und nicht nur entmutigt werden sollen, setzen Sie diese Entscheidung am Proxy oder in der WAF durch.

Google-Extended ist das am häufigsten missverstandene Token, und die Unterscheidung zählt, wenn Suchtraffic Ihre Rechnungen bezahlt. Googles Crawler-Dokumentation beschreibt es als eigenständiges Produkt-Token, das steuert, ob gecrawlte Inhalte für Gemini-Training und -Grounding außerhalb der Suche verwendet werden dürfen, und sagt, dass es weder Aufnahme noch Ranking einer Website in der Google-Suche beeinflusst. Es zu blockieren rührt Googlebots Suchverhalten nicht an.

Eine Token-Liste von Hand aktuell zu halten ist keine sinnvolle Nachmittagsbeschäftigung. Das von der Community gepflegte Repository ai.robots.txt verfolgt KI-User-Agents und erzeugt Konfigurationen für robots.txt, nginx, Caddy, HAProxy, Lighttpd und Apache. Apache-Betreiber können den generierten Block neben ihre übrigen .htaccess-Regeln auf Verzeichnisebene stellen.

Profi-Tipp: Vertrauen Sie dem User-Agent-String nicht. Er ist ein Header, und Header lassen sich kostenlos fälschen. Die CCBot-Dokumentation von Common Crawl warnt davor, dass Crawler sich fälschlich als CCBot ausgeben. Prüfen Sie bei IPv4 mit forward-confirmed Reverse DNS unter *.crawl.commoncrawl.org; für IPv6 nutzen Sie die von Common Crawl veröffentlichten IP-Bereiche, da Reverse DNS dort derzeit nicht unterstützt wird. Die oben genannten Anbieterseiten veröffentlichen ebenfalls aktuelle IP-Bereiche für die anderen genannten Crawler. Das ist ein dokumentierter Prüfweg bei diesen Anbietern, keine Eigenschaft von KI-Crawlern im Allgemeinen.

Bringt llms.txt überhaupt etwas?

Nach der aktuellen Datenlage: so gut wie nichts. llms.txt ist eine vorgeschlagene Textdatei im Wurzelverzeichnis Ihrer Site, die Sprachmodellen eine kuratierte Zusammenfassung Ihrer Inhalte anbietet. Eine zu veröffentlichen ist billig, aber die aktuelle Datenlage gibt Ihnen wenig Grund, dort zu investieren, und Googles Dokumentation sagt, dass Sie sie für seine KI-Suchfunktionen nicht brauchen.

Das Format ist minimal. Der llms.txt-Vorschlag stammt vom September 2024, liegt unter /llms.txt, und macht eine H1 mit dem Site- oder Projektnamen zum einzigen erforderlichen Abschnitt.

Das Urteil kommt aus den Messungen. Die Ahrefs-Studie zu 137.210 Domains ergab, dass 28 % der gemessenen Domains eine llms.txt-Datei veröffentlichten und dass 97 % dieser Dateien im Mai 2026 null Anfragen erhielten. Von den Anfragen, die tatsächlich eintrafen, kamen 19,5 % von namentlich bekannten KI-Tools. Ahrefs warnt außerdem, dass ein Abruf nicht beweist, dass die Datei auch genutzt wurde.

Meine Lesart dieser Daten: llms.txt ist eine Wette auf eine Konvention, die die Systeme, für die sie geschrieben wurde, nicht breit übernommen haben. Veröffentlichen Sie sie, wenn Sie aufgeräumte Wurzelverzeichnisse mögen. Aber bauen Sie keine Generierungspipeline darum, lassen Sie sie nicht zum blockierenden Schritt in Ihrem Deployment werden, und halten Sie jeden, der sie als Ranking- oder Zitations-Hebel verkauft, für ein gutes Stück den Belegen voraus.

Wichtigste Erkenntnis: In der Ahrefs-Studie erhielten 97 % der veröffentlichten llms.txt-Dateien im Mai 2026 überhaupt keine Anfragen.

Ihre Seiten maschinenlesbar machen

Vercels Crawler-Messung ergab, dass die Crawler von OpenAI, ClaudeBot, PerplexityBot, Meta-ExternalAgent, Bytespider und CCBot kein JavaScript ausführen. Gemini über Googlebot und AppleBot tun es. Für die nicht rendernden Crawler ist Inhalt, der erst nach clientseitiger Hydration erscheint, unsichtbar. Rendern Sie also alles Kritische serverseitig. Beim Markup ist die Sache einfacher, und Googles eigene Empfehlung dazu ist ungewöhnlich direkt:

„Sie müssen keine neuen maschinenlesbaren Dateien, KI-Textdateien oder Markup erstellen, um in diesen Funktionen zu erscheinen. Es gibt auch keine speziellen strukturierten schema.org-Daten, die Sie hinzufügen müssten.“

Die KI-Leitlinien von Google Search Central

Der Sichtbarkeitszuwachs von 40 %, der manchmal zur Rechtfertigung von FAQ-Schema zitiert wird, stammt aus dem GEO-Paper , angenommen zur KDD 2024. Das Paper berichtet Zuwächse von bis zu 40 %, doch die getesteten Eingriffe betreffen inhaltliche Änderungen wie Quellenangaben, Zitate, Statistiken, Fachterminologie und flüssige Formulierungen, nicht FAQPage oder irgendein anderes Schema.org-Markup. Die Zahl stimmt; ihre Verknüpfung mit Schema-Markup nicht.

Behalten Sie strukturierte Daten dort, wo sie eine klassische Suchfunktion unterstützen und zur sichtbaren Seite passen. Google sagt, die Eignung für seine KI-Funktionen laufe über die normale Suchindexierung, ohne gesonderte Markup-Anforderung. Es ist bloß nicht belegt, dass sie KI-Zitationen bewegt.

Wenn robots.txt nicht reicht: Rate Limiting und WAF auf dem Server

Direktiven wirken bei den Bots, die sich darauf eingelassen haben. In demselben Hacker-News-Threadbeschrieben mehrere Betreiber den Traffic, der das nicht tut: Crawler, die ihre Anfragen über riesige Pools von IP-Blöcken streuen und User Agents rotieren lassen, um wie gewöhnliche Besucher auszusehen. Das hebelt naive Per-IP-Limits ebenso aus wie User-Agent-Abgleiche. Behandeln Sie das als Community-Berichte; niemand im Thread veröffentlichte Messwerte. Aber es beschreibt genau jene Gruppe, die robots.txt nie erreichen sollte.

Bevor Sie diese Leiter erklimmen, gibt es einen billigeren Zug für Traffic, der noch kooperiert. Bremsen Sie ihn aus:

User-agent: ClaudeBot
Crawl-delay: 1

Profi-Tipp: drosseln, bevor Sie blockieren. Anthropics Dokumentation unterstützt Crawl-delay für ClaudeBot , sodass Sie einen schweren, aber wohlerzogenen Crawler ausbremsen und trotzdem behalten können. Dieselbe Seite sagt, dass IP-Blocking kein dauerhafter Opt-out-Mechanismus ist. Beide Punkte gelten speziell für Anthropic; Crawl-delay ist keine universelle Direktive, prüfen Sie also zuerst die Dokumentation des jeweiligen Anbieters.

Alles darüber hinaus ist Durchsetzung, die Sie selbst betreiben, in drei Sprossen mit steigenden Kosten und steigender Wirksamkeit. Jede erkauft etwas und gibt etwas auf.

Sprosse 1: Reverse-Proxy-Direktiven und Rate Limiting

Rate Limiting für KI-Crawler beginnt am Reverse Proxy, dem ersten Element Ihres Stacks, das eine Anfrage sieht und sie ausbremsen kann, bevor Anwendung oder Datenbank überhaupt arbeiten. Die Rate-Limit-Dokumentation von NGINX besagt, dass Anfragen mit leerem Schlüssel nicht gezählt werden. Eine map kann nur den Crawler-Tokens, die Sie drosseln wollen, einen Rate-Limit-Schlüssel geben und lässt nicht passende Anfragen außerhalb von limit_req_zone.

# /etc/nginx/nginx.conf, inside the http block
map $http_user_agent $ai_rate_key {
    default              "";
    ~*GPTBot             $binary_remote_addr;
    ~*OAI-SearchBot      $binary_remote_addr;
    ~*ClaudeBot          $binary_remote_addr;
    ~*Claude-SearchBot   $binary_remote_addr;
    ~*PerplexityBot      $binary_remote_addr;
    ~*CCBot              $binary_remote_addr;
}

limit_req_zone $ai_rate_key zone=ai_slowlane:10m rate=20r/m;

# /etc/nginx/sites-available/example.conf, inside the server block
location / {
    limit_req zone=ai_slowlane burst=10 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

Das zu justierende Paar ist burst=10 nodelay: Anfragen oberhalb der Durchschnittsrate können den Burst sofort aufbrauchen, und Anfragen darüber hinaus erhalten standardmäßig einen 503 in der Voreinstellung. Stellen Sie es zu eng ein, werfen Sie einen legitimen Crawler mitten im Durchlauf hinaus, ein Problem, das sich langsamer diagnostizieren lässt als ein Ausfall. Caddy drückt dieselben zwei Ideen mit einem Matcher und einem Handler aus. Wenn Sie zwischen beiden schwanken, sind die Konfigurationsdateien im direkten Vergleich nützlicher als eine synthetische Durchsatzzahl.

Die Grenze dieser Sprosse: Die Slow Lane hängt weiterhin vom deklarierten User Agent ab. Ein Scraper im Chrome-Kostüm umgeht diesen crawler-spezifischen Schlüssel vollständig; um solchen Traffic zu erwischen, braucht es ein breiteres Rate Limit auf Basis von IP-/Pfad-Verhalten oder die WAF-Sprosse weiter unten.

Sprosse 2: Eine Web Application Firewall, die Sie selbst betreiben

Eine WAF verlagert die Entscheidung von einem einzelnen Header auf ein Regelwerk, das Anfragemuster, Pfade und Raten zusammen liest, und genau das brauchen Sie, sobald der Traffic sich nicht mehr zu erkennen gibt. Sie auf der eigenen Maschine zu betreiben hält Regeln und Logs auf Ihrer eigenen Platte, wo Sie sie um drei Uhr morgens greppen können. BunkerWeb ist eines dieser Projekte, SafeLine ist ein weiteres, und beide laufen auf einem VPS, sofern der Host die Architektur- und Ressourcenanforderungen des Projekts erfüllt. Wir liefern von beiden Ein-Klick-Versionen, damit Sie sich die Einrichtung sparen, auch wenn das Verpacken nicht der interessante Teil ist.

Genau das ist auch der Preis dieser Sprosse. Regeln brauchen Pflege, und eine Regel, die eng genug ist, um einen entschlossenen Scraper zu fangen, fängt irgendwann einen Menschen. Die Modi Monitor, Balanced und Strict von SafeLine machen diesen Kompromiss explizit: Beobachten Sie den Traffic zuerst lange genug, um Fehlalarme zu finden, bevor Sie die WAF automatisch 403-Antworten zurückgeben lassen.

Sprosse 3: Proof-of-Work-Challenges

Anubis umgeht das Identifikationsproblem vollständig. Für Traffic, den Sie zur Challenge auswählen, lässt es die Anfrage einen kleinen Rechenaufwand bezahlen, bevor der Origin sie bedient. Sein Policy-System kann Anfragen anhand von Übereinstimmungsregeln außerdem erlauben, ablehnen oder mit einer Challenge belegen. Die README des Projekts nennt es ein Web AI Firewall Utility, das um Challenges herum gebaut ist, um Upstream-Ressourcen vor Scraper-Bots zu schützen. Es funktioniert, ohne dass jeder Bot sich korrekt zu erkennen geben muss.

Das Projekt selbst nennt den Ansatz eine nukleare Antwort, und die Einschränkung ist verdient. Die Steuer trifft jeden Traffic, den Ihre Policy zur Challenge schickt, und das können Menschen auf langsamen Geräten oder legitime Crawler sein, wenn die Regeln zu breit sind. Halten Sie diese Sprosse für wirklich feindseligen Traffic in Reserve. Ein übereifriger Crawler ist meist ein Rate-Limit-Problem, und das Rate Limit haben Sie bereits.

Für den Burst dimensionieren

Crawler-Last kommt oft in Schüben, aber ob sie CPU-, Datenbank- oder I/O-lastig ist, hängt von der Anwendung und den gecrawlten URLs ab. Im WordPress-Beispiel oben führte der Betreiber den Großteil der Sekunde Seitenzeit auf MySQL zurück. Jener konkrete Vorfall war also ein Datenbank-Engpass im Kostüm eines Traffic-Problems.

Damit wird Dimensionierung zur Allokationsfrage, und zu einer unbequemen: Sie zahlen laufend für Reserve, und die verdient ihr Geld nur während eines Spitzenwerts, den Sie nicht steuern. Planen Sie den Spitzenwert trotzdem ein. Wenn BunkerWeb sich einen Host mit Anwendung und Datenbank teilt, behandeln Sie 8 GB nicht als Empfehlung für den gesamten Stack. Der Quickstart-Leitfaden von BunkerWeb empfiehlt 2 vCPUs und 8 GB RAM für Tests oder Deployments mit sehr wenigen Diensten und mindestens 4 vCPUs mit 16 GB RAM für Produktionsumgebungen, die viele Dienste schützen. Rechnen Sie die CPU-Spitze der Anwendung selbst, den Datenbankspeicher und I/O-Reserve obendrauf.

Kerne mit höherem Takt helfen, wenn Request-Handling oder Query-Ausführung CPU-gebunden sind; mehr Kerne helfen, wenn Sie mehr gleichzeitige Arbeit in der Luft halten müssen. Dimensionieren Sie nach Spitzen-Parallelität, p95-Antwortzeit, Datenbank-CPU und I/O-Wartezeit sowie Cache-Miss-Rate statt allein nach Crawler-Traffic.

Diese Schicht selbst zu betreiben verlangt von der Maschine darunter zwei Dinge: Root-Zugriff, denn jeder Mechanismus oben ist eine Konfigurationsdatei, die Sie bearbeiten, und ein Dienst, den Sie neu starten, und genug Reserve, damit ein Burst die Site nicht umwirft, während die Regeln ihre Arbeit tun. Wenn Sie dafür eine Maschine dimensionieren oder umziehen, unser Linux VPS gibt Ihnen den Root-Zugriff, den dieser Stack verlangt, und lässt Sie das Proxy-und-WAF-Setup testen, bevor Sie sich langfristig auf eine Größe festlegen.

Entwickeln Sie auf einem Linux-VPS mit Root-Zugriff, NVMe und AMD-EPYC-Power.

Linux-Pläne ansehen

Cloudflares neue Standardeinstellungen für KI-Traffic

Cloudflare hat den KI-Traffic in die Kategorien Search, Agent und Training aufgeteilt, und zwar in seiner Ankündigung zum KI-Traffic vom Juli 2026. Ab dem 15. September 2026 werden bei neuen Domains, die zu Cloudflare kommen, Training und Agent auf Seiten mit Werbung standardmäßig blockiert, während Search erlaubt bleibt. Bestandskunden können die Einstellung vorher ändern, und die Steuerungen sind über alle Tarife hinweg verfügbar.

Übernehmen sollte man die Komplikation, die Cloudflare in seiner eigenen Ankündigung benennt. In Cloudflares Klassifikation vereinen Googlebot, Applebot und Bingbot jeweils Such- und Trainingsarbeit, wer also die Kategorie Training blockiert, blockiert auch diese Crawler, samt dem Suchverhalten, das er behalten wollte. Genau diese Falle lauert bei jeder Steuerung auf Kategorieebene, die einen Mehrzweck-Crawler behandelt, als hätte er nur eine Aufgabe.

Wenn Ihre Site nicht hinter Cloudflare steht, ist nichts davon ein Hebel, den Sie ziehen können. Wissen Sie trotzdem, dass es kommt, denn im September werden sich Traffic-Muster verschieben. Ihre Steuerungen bleiben die robots.txt-Tokens und die Proxy-Schicht weiter oben.

WebMCP: beobachtenswert, aber noch nichts zum Draufbauen

WebMCP ist das browserseitige Gegenstück zum Model Context Protocol, der Konvention, mit der Agenten strukturierte Tools aufrufen, statt zu raten. Chromes Ankündigung des WebMCP-Origin-Trials formuliert das Ziel direkt: Statt dass ein Agent errät, was ein Button oder Formularfeld tut, kann eine Site strukturierte Funktionen und annotierte Steuerelemente bereitstellen, die der Agent direkt aufruft.

Es ist der erste glaubwürdige Versuch, Agenten auf Ihrer Site etwas anderes zu tun zu geben als zu lesen, und damit das Interessanteste in diesem Artikel. Es ist zugleich experimentell und unfertig: ein Origin Trial in Chrome 149, gestartet im Juni 2026. Beobachten Sie die Spezifikation. Bauen Sie noch keine Produktionsabhängigkeit darum, und lassen Sie es aus Ihrer Kapazitätsplanung heraus.

Häufig gestellte Fragen

User-agent: GPTBot
Disallow: /

grep -ohE 'GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|ChatGPT-User' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn