Kinsta hat mehr als 10 Milliarden HTTP-Anfragen in seiner Hosting-Infrastruktur analysiert und festgestellt, dass Bots innerhalb eines Zeitraums von 24 Stunden 7,67 Millionen Mal auf „In den Warenkorb“-URLs von WordPress-Websites zugegriffen haben. Ein einzelner Crawler generierte allein innerhalb von 30 Tagen 550 Millionen Anfragen, bevor eine Regel ihn stoppte.
Keine dieser Anfragen führte zu einer Konversion. Keine davon leitete einen Besucher zurück auf die Website. Sie spangen einfach immer weiter und griffen auf Warenkorb-Seiten, gefilterte Produkt-URLs, Suchanfragen und AJAX-Endpunkte zu – wobei jede einzelne den Server dazu zwang, PHP auszuführen, eine Datenbankabfrage zu stellen und eine Sitzung für Traffic zu verwalten, der niemals zu einem Kunden werden würde.
Die Websites, die diese Last aufnahmen, waren nicht ausgefallen. Die Seiten wurden geladen. Der Bezahlvorgang funktionierte. Nach allen herkömmlichen Maßstäben sahen sie einwandfrei aus. Genau darum geht es in diesem Artikel.
Bot-Traffic ist nicht mehr nur Hintergrundrauschen
Im Jahr 2025 machten Bots 53 % des gesamten Web-Traffics aus – damit überholte der automatisierte Traffic zum ersten Mal in einem Kalenderjahr den menschlichen Traffic. Im Juni 2026 bezifferte Cloudflare Radar diesen Anteil auf 57,5 % – ein Wendepunkt, der laut Cloudflares eigenem CEO Jahre früher eintrat, als er prognostiziert hatte.
Für WordPress-Betreiber ist die praktische Veränderung konkreter als ein Prozentsatz. Der heutige Bot-Traffic besteht nicht mehr nur aus Such-Crawlern, die ihre Arbeit verrichten. Er umfasst KI-Trainings-Crawler, Scraping-Tools, SEO-Audit-Bots, Verfügbarkeitsmonitore, gefälschte User-Agents und agentische KI-Tools, die Links aggressiver verfolgen, als es traditionelles Crawling jemals könnte.
Manche indexieren Inhalte. Manche scrapen sie. Manche testen Endpunkte. Andere behandeln jede Kombination aus URL-Parametern als eigenständige Seite und crawlen jede einzelne.
Gerade dieses letzte Verhalten ist für WordPress besonders kostspielig. Eine Produktseite mit Filtern für Farbe, Größe, Sortierung, Paginierung und Lagerbestand erscheint einem menschlichen Besucher als eine einzige Seite. Ein Bot sieht jedoch Hunderte einzigartiger URLs und crawlt jede einzelne davon.
Der KI-gesteuerte Bot-Traffic stieg innerhalb eines Jahres um 300 %. Bis Ende 2025 entfiel im Netzwerk von TollBit jeder 31. Webbesuch auf KI-Bots – zu Beginn des Jahres war es noch jeder 200. Die Richtung steht fest. Was noch unterschätzt wird, sind die tatsächlichen Kosten dieses Traffics.
Bandbreite ist der offensichtliche Kostenfaktor
Bandbreite ist die Datenmenge, die deine Website überträgt, wenn jemand eine Seite, ein Bild, ein Skript, eine Datei oder ein anderes Element anfordert. Menschliche Besucher nutzen sie. Bots tun das auch – und sie kaufen danach nichts.
Ein Crawler, der einmal auf einen Blogbeitrag zugreift, ist kein Problem. Ein Bot, der wiederholt Archive, Tag-Seiten, Bilddateien, Feeds, Skripte und gefilterte URLs durchforstet, kann echte Bandbreite verbrauchen, ohne einen geschäftlichen Nutzen zu generieren.
Laut den Daten von Cloudflare aus dem Jahr 2025, die im „AI & Bot Traffic Report“ von Kinsta zitiert werden, dienen 80 % der KI-Crawling-Aktivitäten dem Modelltraining und nicht der Suche oder von Nutzern ausgelösten Abfragen – und sie generieren keinen Referral-Traffic zurück zur Website. Bei inhaltsreichen WordPress-Seiten verwandelt diese Dynamik hochwertige Seiten in kostenintensive Ressourcen.
Das Tückische daran ist, dass sich die Bandbreitenverschwendung oft aufbaut, ohne dass ein sichtbares Leistungsproblem auftritt. Die Seite lädt immer noch. Der Server reagiert immer noch. Aber der Verbrauch steigt weiter an, weil der automatisierte Traffic ständig Seiten und Ressourcen anfordert, die kein menschlicher Besucher benötigt.
Bis die Kosten für die Bandbreite offensichtlich werden, hat die Seite möglicherweise bereits Tage oder Wochen damit verbracht, Traffic zu bedienen, der dem Unternehmen nie geholfen hat.
Die Backend-Auslastung ist der schwerer zu erkennende Kostenfaktor
Nicht jede Anfrage verursacht die gleichen Kosten. Ein zwischengespeicherter Blogbeitrag ist relativ günstig, da der Server eine gespeicherte Version zurückgibt und weitermacht. Dynamische Anfragen funktionieren anders.
Wenn ein Bot eine WooCommerce-Warenkorb-Aktion, eine gefilterte Produktseite, eine Suchanfrage-URL, eine Anmeldeseite oder einen AJAX-Endpunkt aufruft, kann der Server nicht aus dem Cache abrufen. Er muss jedes Mal von Grund auf arbeiten:
- PHP-Ausführung – ein Thread wird für die gesamte Dauer der Anfrage reserviert
- Datenbankabfragen – die Seite greift bei jedem Laden auf die Datenbank zu, ohne dass ein Cache dies auffangen könnte
- Sitzungsverwaltung – Warenkorb- und Checkout-Seiten erstellen oder validieren pro Anfrage eine Sitzung, selbst für Bots, die niemals einen Kauf abschließen werden
- Plugin-Logik – jedes Plugin, das sich in diese Anfragen einklinkt, führt seinen Code bei jedem Aufruf aus
- Cache-Umgehungen – die Anfrage gelangt nie in den Cache, sodass zukünftige identische Anfragen wieder denselben Aufwand verursachen
Genau hier wird Bot-Traffic teurer, als es den Anschein hat. Das Problem ist nicht nur, wie viele Daten ein Bot herunterlädt. Es geht darum, wie viel Arbeit die Infrastruktur leistet, bevor sie diese Daten zurücksendet.
Die Infrastrukturdaten von Kinsta verdeutlichen das Ausmaß: Bots haben innerhalb eines einzigen 24-Stunden-Zeitraums 7,67 Millionen Mal URLs zum Hinzufügen in den Warenkorb aufgerufen, darunter allein 3,75 Millionen Anfragen von ClaudeBot. Jede davon wurde als neue serverseitige Anfrage behandelt. Jede löste eine PHP-Ausführung und eine Datenbankabfrage aus. Keine davon diente einem Kunden.
Wie Kinsta-CTO Daniel Pataki bei der Einführung sagte: „Die meisten Ratschläge zum Bot-Management laufen darauf hinaus, ‚alles zu blockieren‘ oder ‚es einfach zu ignorieren‘. Beides funktioniert im großen Maßstab nicht.“
Warum „wir hatten keine Ausfallzeiten“ am Thema vorbeigeht
Verfügbarkeit bedeutet, dass die Website online bleibt. Es bedeutet nicht, dass die Website effizient läuft.
Eine WordPress-Website kann eine beträchtliche Menge an unnötigem Traffic verkraften, bevor Besucher bemerken, dass etwas nicht stimmt. Seiten werden weiterhin geladen. Der Checkout funktioniert weiterhin. Die Admin-Seiten reagieren weiterhin. Aber die Infrastruktur verarbeitet immer noch jede Bot-Anfrage, die auf einen dynamischen Endpunkt trifft, und diese Verarbeitung verursacht echte Kosten – selbst wenn die Website stabil erscheint.
Diese Kosten zeigen sich auf subtilere Weise als ein Ausfall:
- Höhere Bandbreitennutzung, die sich langsam den Grenzen des Tarifs nähert
- Mehr Belastung für PHP-Worker und Datenbankverbindungen
- Weniger Spielraum, wenn echte Traffic-Spitzen genau diese Ressourcen benötigen
- Verzerrte Analysedaten, die Bot-Sitzungen mit menschlichem Engagement vermischen
- A/B-Testergebnisse und Konversionsraten, die durch Traffic verzerrt werden, der gar nicht auf eine Konversion abzielte
- Infrastrukturentscheidungen, die auf Daten basieren, die das tatsächliche Nutzerverhalten nicht widerspiegeln
- Schwierigere Fehlerbehebung, wenn das Rauschen der Bot-Aktivitäten das Signal echter Leistungsprobleme überdeckt
Deshalb kann „keine Ausfallzeit“ Teams ein falsches Gefühl der Sicherheit vermitteln. Die Website wirkt stabil, weil die Infrastruktur die zusätzliche Last auffängt. Das Auffangen von Verschwendung ist dennoch mit Kosten verbunden; sie machen sich nur nicht bemerkbar.
Warum Agenturen das angehen sollten, bevor die Kunden es bemerken
Agenturen erfahren in der Regel erst von Bot-Traffic, wenn dieser bereits ein sichtbares Problem verursacht hat. Ein Kunde bemerkt eine höhere Hosting-Auslastung, langsamere Admin-Seiten, Verzögerungen beim Bezahlvorgang, ungewöhnliche Traffic-Muster oder Analysedaten, die nicht mehr mit seinen Geschäftsergebnissen übereinstimmen. Zu diesem Zeitpunkt ist das Gespräch bereits reaktiv. Die Agentur muss erklären, was passiert ist, warum es wichtig ist und welche Änderungen notwendig sind.
Bot-Traffic bietet Agenturen stattdessen die Möglichkeit für ein proaktives Gespräch.
Die Darstellung muss nicht alarmierend sein. Sie kann ganz praktisch bleiben:
- „Deine Website läuft vielleicht gut, aber ein Teil dieses Traffics stammt möglicherweise nicht von echten Besuchern.“
- „Manche Bot-Aktivitäten sind nützlich, wie Such-Crawler oder Überwachungstools, aber manche verbrauchen nur Ressourcen.“
- „Wir können Verschwendung reduzieren, ohne den Traffic zu beeinträchtigen, der wirklich zählt.“
- „Wenn wir das richtig angehen, sichern wir Leistungsreserven und sorgen dafür, dass die Nutzung vorhersehbar bleibt.“
Das verbindet das Bot-Management mit Anliegen, die Kunden bereits verstehen: Kosten, Effizienz, Zuverlässigkeit. Außerdem positioniert es die Agentur neu – weg vom reaktiven Problemlöser hin zum proaktiven Infrastrukturberater, was eine nachhaltigere Beziehung schafft.
Das Ziel ist nicht, jeden Bot zu blockieren
Es ist wichtig zu beachten, dass nicht jeder Bot-Traffic schlecht ist. Such-Crawler helfen dabei, dass Seiten in den Suchergebnissen erscheinen. Überwachungstools prüfen die Verfügbarkeit. SEO-Plattformen führen Seiten-Audits durch. Zahlungsanbieter, Integrationen, APIs und WordPress-Automatisierungen müssen möglicherweise ebenfalls auf die Website zugreifen, um legitime Aufgaben zu erledigen.
KI-Crawler sind komplizierter. Manche Website-Betreiber möchten vielleicht Einblick in KI-gestützte Erlebnisse haben. Andere kommen vielleicht zu dem Schluss, dass KI-Crawling mehr Kosten als Nutzen verursacht, besonders wenn es große Inhaltsbibliotheken abgreift, ohne dafür nennenswerten Referral-Traffic zurückzusenden.
Deshalb ist es nicht das Ziel, jede automatisierte Anfrage zu blockieren. Übermäßiges Blockieren kann SEO-Probleme verursachen, Integrationen unterbrechen, die Überwachung stören oder normale WordPress-Abläufe beeinträchtigen.
Ein besserer Ansatz ist die selektive Kontrolle:
- Nützlichen Traffic zulassen
- Blockiere eindeutig sinnlose Automatisierung
- Verdächtigen Traffic hinterfragen
- Schütze kostenintensive Pfade
- Überwache die Ergebnisse
So haben Teams mehr Kontrolle, ohne jeden Bot gleich zu behandeln. Es geht darum, Verschwendung zu reduzieren und gleichzeitig den Datentraffic, die Tools und die Arbeitsabläufe zu erhalten, die das Geschäft weiterhin unterstützen.
So funktioniert der Bot-Schutz von Kinsta in der Praxis
Sobald Bot-Traffic zu einem Infrastrukturproblem wird, muss die Reaktion auf die tatsächliche Situation der Website abgestimmt sein.
Der Bot-Schutz in MyKinsta ist auf diese Variabilität ausgelegt. Er ist in allen Tarifen ohne zusätzliche Kosten enthalten, arbeitet auf Umgebungsebene und greift sofort, sobald sich die Einstellungen ändern.
Schutzstufen
Gehe zu Websites > Webseitenname > Bot-Schutz > Ändern, um aus vier voreingestellten Stufen zu wählen, die jeweils unabhängig pro Umgebung angewendet werden, sodass Staging, Entwicklung und Produktion unterschiedliche Einstellungen verwenden können.
- Bösartigen Datentraffic blockieren – die Standardeinstellung auf jeder Website. Dient der DDoS-Abwehr und blockiert IPs und Endpunkte, die mit bekannten Angriffsmustern in Verbindung stehen. Auf jeder Kinsta-Website ist diese Funktion bereits aktiviert.
- Automatisierungen blockieren – der empfohlene Ausgangspunkt für die meisten Seiten, die unter Bot-Last leiden. Blockiert bestätigten automatisierten und böswilligen Traffic, lässt aber verifizierte Bots und echte Besucher durch. Wirksam für Websites, die wiederholte Zugriffe auf dynamische URLs verzeichnen, ohne den Traffic von echten Nutzern zu behindern.
- Bots herausfordern – fügt einen Verifizierungsschritt für mutmaßliche Bots und nicht klassifizierten Datentraffic hinzu. Ein Besucher, der die Herausforderung besteht, wird zehn Tage lang auf demselben Browser und derselben IP-Adresse nicht erneut herausgefordert. Nützlich bei Traffic-Spitzen, Verkaufsaktionen oder aktiven Scraping-Phasen, in denen das Gleichgewicht zwischen Blockierung und Reibung mehr Präzision erfordert.
- Alle herausfordern – die strengste Einstellung, gedacht für den kurzfristigen Einsatz während eines aktiven Angriffs oder anhaltenden Missbrauchs. Der gesamte nicht verifizierte Traffic wird herausgefordert, einschließlich mutmaßlicher menschlicher Nutzer. Keine dauerhafte Konfiguration.
Bevor du die Stufe über Bösartigen Datentraffic blockieren anhebst, überprüfe, ob deine geschäftskritischen Integrationen im Verzeichnis der verifizierten Bots von Cloudflare aufgeführt sind. Ab der Stufe Bots herausfordern oder höher wird jedes Tool, das sich programmgesteuert mit deiner Website verbindet und nicht verifiziert ist, herausgefordert oder blockiert.
KI-Crawler blockieren
Der Schalter KI-Crawler blockieren ist eine vom Schutzlevel unabhängige Steuerung. Er zielt speziell auf KI-Crawler ab, einschließlich verifizierter wie GPTBot, während Googlebot und Bingbot davon unberührt bleiben. Deine Suchindexierung läuft normal weiter.
Für inhaltsreiche Websites, Publisher, Dokumentationsbibliotheken und Premium-Content-Hubs, bei denen KI-Crawler wiederholt Artikelseiten, Archivseiten und nicht zwischengespeicherte Assets in großem Umfang abrufen, beseitigt dieser Schalter diese Belastung, ohne die Sichtbarkeit in Suchmaschinen zu beeinträchtigen.
Der Kompromiss ist real und erwähnenswert: Das Blockieren von KI-Crawlern verringert die Häufigkeit, mit der deine Inhalte in KI-generierten Antworten und Zusammenfassungen auftauchen. Für Websites, bei denen die Sichtbarkeit in KI-Ergebnissen eine strategische Priorität darstellt, sind Automatisierungen blockieren oder Bots herausfordern möglicherweise besser geeignet, da sie das schlimmste Verhalten herausfiltern und die Seite dennoch indexierbar bleibt. Für Websites, bei denen die Kosten für Serverressourcen und die Planauslastung wichtiger sind als die Sichtbarkeit in KI-Ergebnissen, ist das Blockieren die klarere Entscheidung.
Typische WordPress-Automatisierungen zulassen
Wenn du die Schutzstufe über den Standardwert anhebst, aktiviere gleichzeitig Typische WordPress-Automatisierungen zulassen.
Dadurch wird eine verwaltete Zulassungsliste mit gängigen WordPress-Pfaden und -Diensten aktiviert, wie z. B. REST-API-Anfragen, WooCommerce-Routen, Hintergrundaufgaben, geplante Jobs und Plugin-Integrationen, damit eine strengere Bot-Filterung nicht unbemerkt Arbeitsabläufe unterbricht, auf die die Website angewiesen ist.
Aktiviere diese Option immer, wenn du auf Automatisierungen blockieren oder höher umsteigst. Das Ziel ist es, unnötigen Datentraffic zu reduzieren, nicht legitime Vorgänge zu unterbrechen.
Immer zulassen
Manche Dienste sollten unabhängig von der Schutzstufe niemals blockiert werden. Im Abschnitt Immer zulassen kannst du bis zu 50 benutzerdefinierte Ausnahmen nach IP-Adresse, URL-Pfad oder User-Agent hinzufügen.
Verwende dies für:
- Webhooks von Zahlungsanbietern (Stripe, PayPal)
- Vertrauenswürdige Überwachungsdienste (UptimeRobot, Pingdom)
- Bekannte Partnerintegrationen oder API-Nutzer
- IP-Bereiche von Entwicklern oder Büros
- Spezifische WordPress-Pfade wie /wp-json/* oder /wp-admin/admin-ajax.php, sofern diese nicht bereits durch die Whitelist der WordPress-Automatisierungen abgedeckt sind
Aufschlüsselung der Anfragen und Ergebnisse des Bot-Schutzes
Bot-Traffic lässt sich nur schwer optimieren, wenn Teams nicht sehen können, wie Anfragen klassifiziert oder bearbeitet werden.
Bevor du irgendwelche Einstellungen anpasst, schau dir zuerst den Bildschirm Bot-Schutz an. Das Diagramm zur Aufschlüsselung der Anfragen zeigt alle Anfragen, die in den letzten 24 Stunden an deine Website gestellt wurden, klassifiziert in sieben Kategorien: „Wahrscheinlich Menschen“, „Verifizierte Bots“, „Wahrscheinlich Bots“, „KI-Crawler“, „KI-Crawler mit übermäßiger Zugriffsrate“, „Nicht klassifizierter Traffic“ und „Automatisierter Traffic“.
Die Frage hat sich geändert
Hosting wurde schon immer anhand einer kurzen Liste sichtbarer Ergebnisse bewertet: Ist die Website online? Lädt sie schnell? Können Besucher das erledigen, wofür sie gekommen sind?
Diese Fragen sind nach wie vor wichtig. Aber sie geben nicht mehr das ganze Bild wieder.
Eine Website kann online bleiben und dabei Bandbreite verschwenden. Sie kann schnell laden, während Bots die PHP-Threads und Datenbankverbindungen beanspruchen, die echte Besucher benötigen. Sie kann an einem Dienstagnachmittag einen Geschwindigkeitstest bestehen und dann am Donnerstag unter der Last eines Kampagnenstarts zusammenbrechen, weil die Reservekapazität, die eigentlich hätte verfügbar sein sollen, bereits für die Verarbeitung von Traffic aufgebraucht wurde, der dem Unternehmen nie geholfen hat.
Die Frage lautet nicht mehr nur: „Kann die Website die Last bewältigen?“ Sondern: „Wie viel von dieser Last sollte die Website überhaupt bewältigen?“
Bot-Traffic muss eine Website nicht offline nehmen, um Kosten zu verursachen. Er muss lediglich immer wieder die Pfade ansteuern, die echte Verarbeitung erfordern, und das in einem Umfang, der in jedem Dashboard wie normale Aktivität aussieht.
Einblick in diesen Datentraffic zu gewinnen und die Kontrollmöglichkeiten zu haben, um auf das Gesehene zu reagieren – genau das verändert die Situation. Du kannst nicht verwalten, was du nicht siehst, und du kannst nicht auf das reagieren, was du siehst, wenn deine einzigen Optionen darin bestehen, alles zu blockieren oder es einfach zu ignorieren.
Für WordPress-Teams, die inhaltsreiche Websites, WooCommerce-Shops oder große Kundenportfolios verwalten, bietet das Managed-WordPress-Hosting von Kinsta diese Kontrollmöglichkeiten in MyKinsta – ohne zusätzliche Kosten und pro Umgebung anpassbar, ganz ohne Support-Ticket. Beginne mit dem KI- & Bot-Traffic-Bericht, um dir ein umfassendes Bild davon zu machen, was deine WordPress-Infrastruktur belastet und welche Kosten dadurch entstehen.
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.
