Bots generieren mittlerweile mehr Web-Traffic als Menschen, aber noch interessanter ist die Art von Bots, die diese Interaktionen antreiben. Außerdem lohnt es sich, zu untersuchen, was diese Bots tun, wenn sie auf deiner Website landen.

Die typische Diskussion über KI-Traffic dreht sich um Crawler, die deine Inhalte abgreifen, um ein Modell zu trainieren – was dich Ressourcen kostet. Es gibt jedoch noch eine zweite Kategorie: KI-Agenten, die im Auftrag einer Person deine Website besuchen, um sie zu lesen und dort wie ein Kunde zu interagieren. Das birgt Umsatzpotenzial, doch die derzeitige Technologie blockiert ohne Anpassungen beide Arten von Bots – statt nur die Ressourcenfresser.

Lerne den Besucher kennen, der wie ein Bot liest und wie ein Kunde kauft

Während des größten Teils der Geschichte des Internets hat eine WordPress-Seite drei Arten von Besuchern empfangen: Menschen, Such-Crawler und Skripte, die wiederholbare Aufgaben ausführen.

KI-Agenten sind nun eine vierte Art. Diese lesen die Struktur einer Seite wie ein Crawler, interagieren aber wie ein Mensch. Für einen KI-Agenten ist es relativ einfach, den Preis eines Produkts zu prüfen, ihn zu vergleichen und den Kaufvorgang abzuschließen.

Angesichts dessen verdienen agentische Bots deine Aufmerksamkeit. Die Traffic-Daten von Cloudflare zeigen nun, dass automatisierte Anfragen zum ersten Mal die menschlichen Anfragen überwiegen. Innerhalb dieses automatisierten Anteils hat die Studie „State of AI Traffic“ von HUMAN Security festgestellt, dass der Traffic von KI-Agenten und agentischen Browsern in einem Tempo wächst, das jede andere Kategorie in den Schatten stellt.

Tatsächlich sind KI-Agenten bei einigen beliebten Produkten bereits im Einsatz:

Diese und viele weitere werden bereits in den Produktionstraffic deiner Website eingespeist, doch die Einstellungen, die dazu dienen, Crawler am Trainieren zu hindern, sind nicht für sie ausgelegt.

Durch KI generierter Traffic konvertiert besser als menschlicher Traffic

Adobes Einzelhandelsdaten für das erste Quartal 2026, die auf über einer Billion Besuche auf US-Einzelhandels-Websites basieren, erzählen eine Geschichte, die vor einem Jahr noch unmöglich vorherzusagen war.

Im März 2025 war die Conversionrate des von KI vermittelten Traffics um 38 % schlechter als bei Standardkanälen wie bezahlter Suche und E-Mail. Im März 2026 war die Conversionrate desselben Traffics um 42 % besser. Das ist eine Umkehr um 80 Prozentpunkte innerhalb von zwölf Monaten. Durch KI weitergeleitete Käufer generierten zudem 37 % mehr Umsatz pro Besuch als der nicht durch KI generierte Traffic, verbrachten 48 % mehr Zeit auf der Website und sahen sich 13 % mehr Seiten pro Besuch an. Das Traffic-Volumen aus KI-Quellen stieg allein im ersten Quartal 2026 im Vergleich zum Vorjahr um 393 %.

Der Grund dafür liegt im Verhalten. Ein Mensch, der über die organische Suche auf deine Seite gelangt, könnte sich in jeder beliebigen Phase einer Kaufentscheidung befinden. Einem Agenten, der auf deine Seite geschickt wird, wurde bereits eine bestimmte Aufgabe zugewiesen.

Genau diesen Traffic wollen WooCommerce-Shops, Mitgliederplattformen sowie Angebots- oder Buchungsformulare für sich gewinnen:

  • Käufer, die nach einem Plugin suchen, schicken einen Agenten, der deine Preise prüft und mit einer Empfehlung zurückmeldet.
  • Jemand, der die Leistungsumfänge prüft, lässt einen Agenten dein Angebotsformular ausfüllen und wartet auf eine Antwort.
  • Käufer, die Abonnementstufen vergleichen, lassen einen Agenten die Anmeldung abschließen, sobald der Vergleich abgeschlossen ist.

Jede dieser Aufgaben kann nun von einem Agenten von Anfang bis Ende erledigt werden, sofern deine Website dies zulässt.

Cloudflare unterteilt die Blockierung von KI-Bots in drei Kategorien

Die Traffic-Steuerung von Cloudflare zeigt die Kategorieoptionen „Suche“, „Agent“ und „Training“ an.
Die Traffic-Steuerung von Cloudflare zeigt die Kategorieoptionen „Suche“, „Agent“ und „Training“ an.

Die infrastrukturellen Ebenen holen langsam auf. Die aktuelle Konfiguration von Cloudflare ersetzt den bisherigen einzelnen KI-Bot-Schalter durch drei unabhängig voneinander steuerbare Kategorien, die jedem Kunden zur Verfügung stehen.

  • „Search“ umfasst Crawler, die deine Inhalte indexieren, damit sie später in einer KI-generierten Antwort angezeigt werden können, wobei in der Regel ein Teil des Datenverkehrs zu dir zurückgeleitet wird.
  • „Training“ umfasst Crawler, die deine Inhalte aufnehmen, um ein Modell aufzubauen oder zu verfeinern, ohne dass dabei Rückverkehr oder Transaktionsabsicht entsteht.
  • „Agent“ umfasst Echtzeit-Traffic, der von Nutzern gesteuert wird und im Auftrag einer bestimmten Person erfolgt, einschließlich Sitzungen zum Abschluss eines Kaufvorgangs.

Cloudflare blockiert „Training“ und „Agent“ standardmäßig auf Seiten, die Werbung enthalten, während „Search“ aktiviert bleibt. Bei bestehenden Websites bleiben die aktuellen Einstellungen erhalten, sofern du sie nicht änderst. Mehrzweck-Crawler (einschließlich Googlebot) werden jedoch anhand der strengsten Regel bewertet. Ein pauschaler Block von „Training“ kann also dazu führen, dass auch deine Sichtbarkeit in den Suchergebnissen beeinträchtigt wird.

Der Bot-Schutz von Kinsta trifft diese Art von Ermessensentscheidung bereits für dich. Derzeit fasst er KI-Crawler unter einem Schalter zusammen, anstatt die für das Cloudflare-Dashboard typische Dreiteilung zu übernehmen. Du musst jedoch wissen, wie du mit dem umgehst, was dir zur Verfügung steht.

3 Faktoren, die darüber entscheiden, ob ein Agent deinen Checkout abschließt

Ob ein Agent seine Aufgabe auf deiner Seite abschließt, hängt von drei Faktoren ab, die alle eher auf der Infrastruktur- als auf der Inhaltsseite liegen. In vielen dieser Fälle können Kinstas Funktionen und Infrastruktur von Vorteil sein.

Preise und Verfügbarkeit müssen im HTML-Code enthalten sein

Ein Agent liest die zugrunde liegende Struktur einer Seite und nicht ihr visuelles Layout. In Fällen, in denen der Preis erst nach einem Klick angezeigt wird oder deine Lagerbestände über einen AJAX-Aufruf nach dem Rendern geladen werden, sieht ein Agent, der anhand des Barrierefreiheitsbaums arbeitet, diese Informationen nicht.

Allerdings gibt es hier verschiedene Ebenen. Eine Studie, in der ein KI-Agent bei realen Webaufgaben getestet wurde, ergab beispielsweise, dass er in fast 80 % der Fälle erfolgreich war. Bei der Interaktion ausschließlich über die Tastatur (was die Navigation eines Screenreader-Nutzers simuliert) sank die Erfolgsquote auf 42 %.

Die typischen Ursachen lassen sich leicht erkennen, sobald man weiß, worauf man achten muss:

  • FAQs im Akkordeon-Format verbergen Antworten hinter einem Klick, den ein Agent möglicherweise nie auslöst.
  • Preistabellen mit Registerkarten rendern oft nur eine Registerkarte im ursprünglichen Markup der Seite.
  • Über JavaScript geladene Aktienindikatoren existieren möglicherweise nicht mehr, wenn ein Agent die Seite ausliest.

Der von Google vorgeschlagene WebMCP-Standard ist ein Versuch, dies auf Browserebene zu beheben. Er ermöglicht es einer Website, ihre Checkout- und Preisangaben-Funktionen direkt bereitzustellen, anstatt es einem Agenten zu überlassen, diese aus der Seite abzuleiten. Da es sich jedoch noch um einen Test in einem frühen Stadium handelt, ist semantisches HTML derzeit die zuverlässige Lösung.

Deine Seite muss reagieren, bevor der Bot das Zeitlimit erreicht

Ein Agent, der eine mehrstufige Aufgabe abarbeitet, wartet nicht so lange auf eine langsame Seite wie ein Mensch es vielleicht tun würde. Stattdessen bricht er den Vorgang bei einer stockenden Seite einfach ab und kostet dich eine Conversion.

Die Schwellenwerte der Core Web Vitals sind ein vernünftiger Anhaltspunkt dafür, was ein Agent toleriert, auch wenn sie ursprünglich auf der menschlichen Erfahrung beim Surfen auf einer Seite basieren. Ein „Largest Contentful Paint“ unter 2,5 Sekunden gibt sowohl einem Menschen als auch einem Agenten genügend Spielraum, um eine Aufgabe in derselben Sitzung abzuschließen.

Außerdem kannst du all die Zeit, die du eigentlich sparen willst, damit verschwenden, dass du wild nach Lösungen für langsame Seiten rätst. Hier kannst du das APM-Tool von Kinsta nutzen, um einen Checkout- oder Produkt-Prozess zu analysieren – so lässt sich die Verzögerung auf das jeweilige Plugin, die Datenbankabfrage oder den Drittanbieter-Aufruf eingrenzen, der dafür verantwortlich ist.

Der Reiter „Transactions“ des APM-Tools bei laufender Überwachung einer WordPress-Website.
Der Reiter „Transactions“ des APM-Tools bei laufender Überwachung einer WordPress-Website.

Sobald ein Überwachungsfenster läuft, zeigt die Ansicht „Transactions“ an, welche Seite oder welcher Endpunkt langsam ist. Du kannst dann nachvollziehen, welches Plugin oder welche Abfrage dahintersteckt, das richtige Element beheben und Zeit sparen – damit Mitarbeiter aus den richtigen Gründen bei dir bleiben.

Deine Bot-Schutz-Einstellungen müssen die konvertierenden Sitzungen durchlassen

Wenn deine Bot-Schutz-Einstellungen jeden automatisierten Besucher als Trainings-Crawler behandeln, erreichen die richtigen Bots deine Website möglicherweise gar nicht erst. Für ein System, das sie nicht unterscheiden kann, sehen diese Bot-Sitzungen gleich aus.

Deshalb bietet dir der Bot-Schutz von Kinsta vier separate Steuerungsmöglichkeiten, um diese Entscheidung zu treffen:

  • Vier Schutzstufen – von „Bösartigen Datentraffic blockieren“ bis hin zu „Alle abfragen“ – steuern, wie aggressiv nicht klassifizierter und vermutlich von Bots stammender Datentraffic auf deiner gesamten Website abgefragt wird.
  • Ein spezieller Schalter zum „Blockieren von KI-Crawlern“ entfernt den Datentraffic von KI-Crawlern sofort, einschließlich Agent-Sitzungen, die den Bezahlvorgang abschließen, und Trainings -Crawlern.
  • Mit „Typische WordPress-Automatisierungen zulassen“ stellst du sicher, dass deine REST-API, Plugin-Integrationen und Hintergrundaufgaben auch bei einer strengeren Schutzstufe weiterlaufen. Das ist wichtig für Agent-Sitzungen, die auf deine Checkout- und API-Endpunkte zugreifen.
  • Mit „Ausnahmen immer zulassen“ (hinzufügbar nach IP, Pfad oder User-Agent) kannst du bestimmten Datentraffic benennen, der unabhängig von deiner Schutzstufe niemals blockiert oder abgefragt werden soll.

Ein praktischer Mittelweg für einen WooCommerce-Shop oder eine Buchungsseite ist es, „Typische WordPress-Automatisierungen zulassen“ zu aktivieren, damit der Traffic beim Checkout und der REST-API nicht von einer strengeren Schutzstufe erfasst wird. Es ist außerdem ratsam, „KI-Crawler blockieren“ eher als vorübergehendes Diagnosetool zu betrachten und nicht als Einstellung, die dauerhaft aktiviert bleiben sollte.

Der Bildschirm „Bot-Schutz“ zeigt die vier verfügbaren Schutzstufen an.
Der Bildschirm „Bot-Schutz“ zeigt die vier verfügbaren Schutzstufen an.

Wenn du versuchst, Crawler gezielt am Training zu hindern, ohne dabei agentengesteuerte Käufe zu verlieren, bieten dir Ausnahmen für bekannte User-Agents immer zulassen mehr Präzision, als der Schalter allein bieten kann.

Überprüfe in MyKinsta, was auf deiner eigenen Website vor sich geht

Bevor du jedoch irgendwelche Einstellungen änderst, solltest du lieber überprüfen, wie der Traffic deiner Website aussieht, anstatt einfach davon auszugehen, dass du Agent-Sitzungen bereits korrekt handhabst. MyKinsta bietet dir dazu mehrere Möglichkeiten.

Zunächst bietet dir der Bildschirm „Websites > [Name der Website] > Bot-Schutz“ zwei Arten von Einblicken, die in einem Diagramm zusammengefasst sind. Die „Anfragen-Aufschlüsselung“ zeigt alle Anfragen an deine Website in den letzten 24 Stunden mit verschiedenen Klassifizierungen an. So kannst du die Anteile und Verhältnisse des Datenverkehrs erkennen, mit dem du es zu tun hast.

Das Diagramm „Bot-Schutz-Ergebnisse“ zeigt, wie dieser Traffic behandelt wurde: entweder zugelassen, überprüft oder blockiert:

Die „Anfragenaufschlüsselung“ von MyKinsta zeigt den Traffic nach Kategorien geordnet.
Die „Anfragenaufschlüsselung“ von MyKinsta zeigt den Traffic nach Kategorien geordnet.

Die Aufschlüsselung der Anfragen bezieht sich im Wesentlichen auf sich selbst. Wenn beispielsweise ein Teil deines automatisierten Datentraffics überprüft oder blockiert wird, kannst du sehen, dass diese Werte mit der Kategorie „KI-Crawler“ zusammenfallen. Du kannst jedoch nicht erkennen, ob es sich dabei um Crawler im Training oder um konvertierte Agentensitzungen handelt.

Hier kannst du den Zeitpunkt von Spitzen im blockierten Datentraffic im Verhältnis zu deinem Bestell- oder Lead-Volumen im gleichen Zeitraum betrachten; ein Rückgang des einen bei gleichzeitigem Anstieg des anderen deutet darauf hin, dass legitime Agentensitzungen mitgefiltert werden.

Teste deinen Checkout ohne JavaScript

Ein Agent, der anhand der zugrunde liegenden Struktur einer Seite arbeitet, hat eine ähnliche Erfahrung wie jemand, der einen Screenreader nutzt. Es gibt zwei schnelle Tests, die dir zeigen, wo der Ablauf ins Stocken gerät.

Öffne zunächst deine DevTools im Browser und gehe dann zu „Einstellungen“ > „Debugger“. Aktiviere anschließend „JavaScript deaktivieren“. Lade die Seite dann neu und versuche, einen Artikel hinzuzufügen oder zur Kasse zu gehen.

Browser-DevTools mit der aktivierten Einstellung „Debugger“ > „JavaScript deaktivieren“.
Browser-DevTools mit der aktivierten Einstellung „Debugger“ > „JavaScript deaktivieren“.

Jede Störung oder jeder Fehler ist ein Zeichen dafür, dass der Schritt von einem Skript abhängt, das möglicherweise nie ausgeführt wird. Beispielsweise hat eine Schaltfläche „In den Warenkorb“, die als anklickbares ` <div> ` erstellt wurde, ohne ihr Skript oft kein Fallback-Verhalten.

Du kannst denselben Checkout-Ablauf auch mit einem Barrierefreiheits-Scanner wie axe oder WAVE überprüfen. Jedes fehlende Label, jedes versteckte Feld oder jede unerreichbare Schaltfläche ist für einen Mitarbeiter dann nicht sichtbar. Anhand dieser beiden Tests erhältst du eine konkrete Liste der Elemente, die korrigiert werden müssen.

Beobachte die Antwortzeiten unter gleichzeitiger Belastung

Eine Agent-Sitzung, in der mehrere Tabs geöffnet oder mehrere Produktseiten kurz hintereinander aufgerufen werden, gleicht eher einem kleinen Ansturm gleichzeitiger Zugriffe. Viele Leistungstests erkennen dieses Lastmuster nicht, sodass ein Test mit einer einzigen Anfrage problemlos bestanden wird.

Schau dir in den MyKinsta-Analysen (Seiten > Seitenname > Analytics > Performance) die durchschnittliche PHP- und MySQL-Antwortzeit an . Diese (zusammen mit der detaillierten Liste am unteren Bildschirmrand) kann dir helfen, die langsamsten Pfade auf deiner Website zu finden, anstatt dich auf einen siteweiten Durchschnitt zu verlassen, der das Problem verschleiert.

Die Leistungsanalyse von MyKinsta zeigt die durchschnittliche PHP- und MySQL-Antwortzeit an.
Die Leistungsanalyse von MyKinsta zeigt die durchschnittliche PHP- und MySQL-Antwortzeit an.

Führe anschließend das APM-Tool aus und öffne mehrere Sitzungen gleichzeitig für deine Warenkorb- und Such-Endpunkte. So kannst du nachverfolgen, an welcher Stelle die Antwortzeit anfängt anzusteigen.

Wenn das Diagramm zum PHP-Thread-Limit im Bereich „Leistung“ der Analytics anzeigt, dass deine Website an ihre Obergrenze stößt, kannst du das beheben. Eine einfache Möglichkeit, deiner Website mehr Spielraum für die gleichzeitige Bearbeitung mehrerer Agent-Sitzungen zu geben, ist die Erhöhung der Thread-Zuweisung unter „Websites > [Name der Website] > Info > PHP-Leistung  > Ändern .

Agenten-Traffic ist kein Bot-Rauschen mehr, sondern ein vollwertiger Kanal

Beim Training von Crawlern ist das Blockieren und Zurückgewinnen der Ressourcen nach wie vor der richtige Schritt. Bei KI-Agenten, die Kaufvorgänge abschließen, ist das jedoch nicht angebracht – daher musst du alle dir zur Verfügung stehenden Tools nutzen, um Bots korrekt zu filtern.

Die Lösung besteht darin, zu überprüfen, ob deine Preis- und Bestandsdaten im ursprünglichen HTML der Seite gerendert werden. Indem du deine langsamsten Seiten identifizierst und deine Bot-Schutz-Einstellungen überprüfst, kannst du den bestehenden Traffic präzise behandeln und die Serverressourcen effizient nutzen.

Um zu sehen, wie Bot-Schutz, APM und die Cloudflare-Integration von Kinsta zusammenwirken, damit deine Infrastruktur für beide Arten von Besuchern bereit ist, schau dir das Managed-WordPress-Hosting von Kinsta an.

Joel Olawanle Kinsta

Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.