\u201eAus Sicht der Infrastruktur gibt es so etwas wie \u201anur Bot-Traffic\u2018 nicht\u201c, sagt Daniel Pataki, CTO bei Kinsta. \u201eJede Anfrage bedeutet echte Arbeit. In gro\u00dfem Ma\u00dfstab ist ineffizientes Crawling kein Traffic-Problem mehr, sondern wird zu einem Ressourcenproblem.\u201c<\/p>\n
Dieser Artikel erkl\u00e4rt, warum dieser Wandel stattgefunden hat, was er WordPress-Seitenbetreiber tats\u00e4chlich kostet und wie sich die Sichtweise \u00e4ndern muss.<\/p>\n
Das alte Modell funktioniert nicht mehr<\/h2>\n
Das traditionelle Bot-Management basierte auf einer einfachen Pr\u00e4misse: Die b\u00f6sartigen blockieren und die guten durchlassen. Jahrelang reichte das aus. Googlebot crawlt deine Seiten, indexiert deine Inhalte und macht weiter. B\u00f6sartige Bots versuchten, sich Zugang zu deiner Anmeldeseite zu verschaffen. Zwei sehr unterschiedliche Probleme, zwei sehr unterschiedliche L\u00f6sungen.<\/p>\n
Was keines der beiden Modelle ber\u00fccksichtigte, war eine dritte Kategorie: automatisierter Traffic, der weder b\u00f6sartig ist noch blockiert wird, aber in gro\u00dfem Umfang messbaren Schaden an der Leistung deiner Website verursacht.<\/p>\n
KI-Crawler<\/a> \u2013 also Bots, die nicht nur dazu dienen, Seiten f\u00fcr Suchergebnisse zu indexieren, sondern auch Inhalte f\u00fcr das Modelltraining, die abrufgest\u00fctzte Generierung und Echtzeit-Anfragen von Nutzern zu erfassen \u2013 arbeiten in einem grundlegend anderen Ma\u00dfstab als alles, was es bisher gab. Allein GPTBot verzeichnete zwischen Mai 2024 und Mai 2025 ein Wachstum von 305 %. Zu Beginn des Jahres 2025 war etwa jeder 200. Webbesuch ein KI-Bot. Bis zum Jahresende hatte sich dieses Verh\u00e4ltnis auf jeden 31. erh\u00f6ht.<\/p>\n Ende 2025 machten KI-Crawler 4,2 % aller HTML-Anfragen im Cloudflare-Netzwerk aus \u2013 eine Zahl, die von 2,4 % Anfang April auf 6,4 % Ende Juni schwankte und sich innerhalb eines Jahres fast verdreifachte.<\/p>\n Diese Crawler sind hartn\u00e4ckig und treten h\u00e4ufig auf, und sie verhalten sich nicht wie herk\u00f6mmliche Suchmaschinen-Bots. Viele generieren gro\u00dfe Mengen an Anfragen an nicht zwischengespeicherte, dynamische Endpunkte, was deinem Server \u201eechte Arbeit\u201c beschert.<\/p>\n Hier wird das Infrastrukturproblem deutlich \u2013 und genau das geht in den meisten Analysen zum Bot-Traffic unter.<\/p>\n Wenn ein Besucher eine zwischengespeicherte Seite auf einer WordPress-Seite l\u00e4dt, hat dein Server kaum etwas zu tun. Er gibt eine vorgefertigte HTML-Datei<\/a> zur\u00fcck, genauso wie er ein Bild oder eine CSS-Datei<\/a> ausliefern w\u00fcrde. Der Ursprungsserver merkt davon kaum etwas. Das ist ja gerade der Sinn des Cachings.<\/p>\n Aber ein erheblicher Teil der Anfragen auf einer echten WordPress-Seite und insbesondere in WooCommerce-Shops kann nicht aus dem Cache bedient werden. Zu diesen Anfragen geh\u00f6ren:<\/p>\n Wenn ein Bot diese Endpunkte aufruft, passiert auf deinem Server Folgendes:<\/p>\n Das ist der Mechanismus, durch den Bot-Traffic zu einem Infrastrukturproblem wird. Das ist keine Theorie. Es ist die konkrete Abfolge von Ereignissen, die eintritt, wenn automatisierte Anfragen dynamische Endpunkte auf einer aktiven WordPress-Seite \u00fcberfluten.<\/p>\n Das Abstrakte wird konkret, wenn man sich die realen Daten aus der Infrastruktur ansieht, die wir in gro\u00dfem Ma\u00dfstab verwalten.<\/p>\n Ein Datenpunkt, den wir besonders auff\u00e4llig fanden, ist, dass ein einzelner Bot (ClaudeBot) innerhalb von 24 Stunden 3,75 Millionen \u201eIn den Warenkorb\u201c-Anfragen generierte.<\/strong> Das entspricht etwa einer Anfrage alle 23 Millisekunden (den ganzen Tag und die ganze Nacht), wobei jede vom Server als neue Anfrage behandelt wird, da Warenkorb-Endpunkte von Natur aus dynamisch sind.<\/p>\n Um das in den Kontext zu setzen: \u201eIn den Warenkorb\u201c-Anfragen geh\u00f6ren zu den ressourcenintensivsten Endpunkten eines WooCommerce-Shops. Sie erstellen Sitzungen, f\u00fchren Abfragen durch und aktualisieren den Warenkorbstatus. Jede einzelne bedeutet echten Arbeitsaufwand. Die 3,75 Millionen Anfragen, die wir an einem Tag von einer einzigen Quelle verzeichneten, sind genau die Art von Traffic-Muster, die eine Website lahmlegen kann.<\/p>\n Ein zweiter Datenpunkt unterstreicht, wie hartn\u00e4ckig diese Muster sein k\u00f6nnen: Ein fehlerhaftes Schleifenmuster erzeugte innerhalb von 30 Tagen 550 Millionen Anfragen<\/strong> \u2013 genug Traffic, um eine eigene, dedizierte Abwehrregel in unserer Infrastruktur zu rechtfertigen. Das ist kein DDoS-Angriff und keine Malware-Kampagne, sondern ein Bot, der in einer Crawling-Schleife feststeckt und immer wieder URLs abfragt, die er bereits gesehen hat.<\/p>\n Das sind keine Ausnahmef\u00e4lle. Es sind Muster, die wir plattformweit beobachten.<\/p>\n Einer der am meisten untersch\u00e4tzten Aspekte des aktuellen Problems mit Bot-Traffic ist, dass das meiste, was Sch\u00e4den an der Infrastruktur verursacht, \u00fcberhaupt nicht b\u00f6swillig ist. Es handelt sich um ineffiziente Automatisierung in gro\u00dfem Ma\u00dfstab.<\/p>\n Moderne Websites, insbesondere E-Commerce-Shops, generieren leicht unterschiedliche URLs f\u00fcr im Grunde dieselbe Seite:<\/p>\n F\u00fcr einen Menschen sind das alles \u201edieselbe Seite\u201c. F\u00fcr einen Bot, der URLs folgt, sieht jede davon wie eine brandneue Seite aus, die gecrawlt werden muss.<\/p>\n Also folgt der Bot dem ersten Link. Diese Seite generiert eine weitere URL-Variante, der der Bot folgt. Dann noch eine. Und noch eine. Er verf\u00fcgt \u00fcber keinen Mechanismus, um zu erkennen, dass er sich im Kreis dreht, und einige dieser Schleifen liefen auf der \u00fcberwachten Infrastruktur mehrere Tage lang unentdeckt, bevor sie von Abwehrregeln abgefangen wurden.<\/p>\n In dem k\u00fcrzlich ver\u00f6ffentlichten Bericht zu KI- und Bot-Traffic erkl\u00e4rte David Belson<\/a>, ehemaliger Leiter des Bereichs Data Insights bei Cloudflare: \u201eDa gibt es jemanden, der gestern noch keine Ahnung hatte, was er da eigentlich tat, aber heute aus einer Laune heraus einen Bot programmiert und losgeschickt hat. Der macht sich nicht einmal die M\u00fche, Dieses Verhalten geht nicht immer auf b\u00f6swillige Akteure zur\u00fcck. Es stammt von KI-Crawler-Systemen, die nicht unter Ber\u00fccksichtigung von facettierter Navigation, der Ausbreitung von URL-Parametern oder sitzungsgenerierten URLs entwickelt wurden \u2013 alles Standardfunktionen moderner WordPress-Seiten.<\/p>\n Google selbst identifiziert facettierte Navigation<\/a> und parameterbasierte URLs ausdr\u00fccklich als Ursache f\u00fcr ineffizientes Crawling und weist darauf hin, dass Bots nahezu unendliche Variationen derselben Seite durchsuchen k\u00f6nnen.<\/p>\n Bis vor kurzem orientierten sich viele Hosting-Pakete an der Besucherzahl, was als N\u00e4herungswert f\u00fcr die tats\u00e4chliche Nutzung durch Menschen recht gut funktionierte. Man ging davon aus, dass die Besucherzahlen in etwa mit der Interaktion der Nutzer auf deiner Website korrelierten.<\/p>\n Diese Annahme hat sich nicht mehr bew\u00e4hrt.<\/p>\n Automatisierter Traffic hat die Besucherzahlen in einer Weise in die H\u00f6he getrieben, die mit der tats\u00e4chlichen Gesch\u00e4ftst\u00e4tigkeit kaum noch etwas zu tun hat. Bot-Anfragen k\u00f6nnen Besucherzahlen generieren, ohne dass es zu entsprechender Interaktion, Konversionen oder Umsatz kommt. Website-Betreiber erhielten bei besuchszahlbasierten Tarifen \u00dcberschreitungsbenachrichtigungen, die durch Bot-Aktivit\u00e4ten verursacht wurden, die sie weder kontrollieren konnten noch selbst eingeladen hatten.<\/p>\n Dies zeigte sich so deutlich als systemisches Muster, dass Kinsta bandbreitenbasierte Hosting-Tarife<\/a> einf\u00fchrte \u2013 als direkte Reaktion auf eine Kategorie von Websites, deren Besuchszahlen sich zunehmend deutlich von ihrem tats\u00e4chlichen Ressourcenverbrauch abkoppelten. Wenn die Besucherzahlen einer Website stiegen, die Bandbreite aber nicht Schritt hielt, war das fast immer ein Anzeichen f\u00fcr Bots. Der Wechsel zu einem bandbreitenbasierten Modell entkoppelte die Abrechnung effektiv von einer Kennzahl, die Bots zu manipulieren gelernt hatten.<\/p>\n Das Abrechnungsproblem ist messbar und behebbar. Das schwierigere Problem ist, dass die meisten Website-Betreiber gar nicht merken, dass all das passiert, weil ihre Dashboards nicht das volle Bild zeigen.<\/p>\n Eine Folge des Bot-Traffics in dieser Gr\u00f6\u00dfenordnung ist, dass Standard-Analysetools zu unzuverl\u00e4ssigen Indikatoren f\u00fcr die tats\u00e4chliche Leistung deiner Website geworden sind.<\/p>\n Wenn deine Besucherzahlen steigen, sich aber Umsatz, Verweildauer auf der Seite und Absprungverhalten nicht proportional dazu entwickeln, sind Bots wahrscheinlich mit im Spiel. Wenn dein Server Leistungseinbu\u00dfen aufweist, die nicht mit den Traffic-Spitzen korrelieren, die du aufgrund von Inhalten oder Marketingaktivit\u00e4ten erwarten w\u00fcrdest, lohnt es sich, den Bot-Traffic zu nicht zwischengespeicherten Endpunkten zu untersuchen.<\/p>\n Kinsta filtert bekannte Bot-User-Agents automatisch aus den Analysen und den Berechnungen zur Planauslastung heraus. Aber automatisierter Traffic, der dem menschlichen Verhalten sehr \u00e4hnlich ist, kann dennoch in deinen Metriken auftauchen.<\/p>\n Die Muster, auf die du achten solltest:<\/p>\n Keines dieser Anzeichen ist f\u00fcr sich genommen ausschlaggebend, aber jede Kombination rechtfertigt eine Untersuchung, bevor man die Zahlen dem Gesch\u00e4ftswachstum zuschreibt.<\/p>\n Der h\u00e4ufigste Reflex beim Anblick von Bot-Traffic-Daten ist, einfach alles zu blockieren. Andere lassen vielleicht alles zu, weil \u201eKI die Zukunft ist\u201c.<\/p>\n Beides funktioniert nicht!<\/p>\n Wahlloses Blockieren bedeutet, dass auch verifizierte Crawler blockiert werden, darunter Googlebot, dessen Crawling-Abdeckung dar\u00fcber entscheidet, ob deine Inhalte \u00fcberhaupt in den Suchergebnissen erscheinen. Es bedeutet, KI-Entdeckungs-Bots zu blockieren, die deine Inhalte m\u00f6glicherweise in dialogorientierten Suchergebnissen, KI-gest\u00fctzten Empfehlungen oder Antwort-Engines anzeigen. F\u00fcr einen WooCommerce-Shop<\/a> oder einen Content-Anbieter sind das erhebliche Vertriebskosten.<\/p>\n Alles durchzulassen bedeutet, Infrastrukturkosten in Kauf zu nehmen, die keinen Ertrag bringen. Und bei den dynamischen Endpunkten, die von Bots besonders stark beansprucht werden, sind diese Kosten nicht marginal. Sie summieren sich und verst\u00e4rken sich, insbesondere bei anhaltender automatisierter Auslastung.<\/p>\n Die eigentliche Antwort liegt irgendwo dazwischen und erfordert ein Verst\u00e4ndnis f\u00fcr die Unterschiede zwischen den Traffic-Kategorien, anstatt alle Bots als eine einzige Klasse zu behandeln.<\/p>\n Wie Cristian Lopez, Chefredakteur bei HostingAdvice, in dem Bericht<\/a> erkl\u00e4rte: \u201eDas Missverst\u00e4ndnis besteht darin, zu glauben, Bot-Traffic sei ein einfaches \u201aBlockieren-oder-Zulassen\u2018-Problem. In Wirklichkeit geht es um Richtlinien, Transparenz und wirtschaftliche Kontrolle.\u201c<\/p>\n Verifizierte Bots, darunter Googlebot, Bing und legitime \u00dcberwachungstools, sollten grunds\u00e4tzlich zugelassen werden, wobei m\u00f6glicherweise Pfadbeschr\u00e4nkungen f\u00fcr Endpunkte gelten, die keinen Crawling-Wert haben (deine Checkout-Seite tr\u00e4gt nichts zu deinen Suchrankings bei). Unverifizierte Bots ohne identifizierende Informationen oder Zweck erfordern eine genauere Pr\u00fcfung. KI-Trainings-Crawler, die hohe Anfragemengen an dynamische Endpunkte generieren, stellen eine spezielle Kategorie dar, die je nach Art deiner Website und deinen Priorit\u00e4ten eine Blockierung oder Ratenbegrenzung rechtfertigen kann.<\/p>\n In unserem Bericht zu KI- und Bot-Traffic<\/a> haben wir ein interaktives Entscheidungsmodell entwickelt, das den richtigen Ansatz f\u00fcr verschiedene Website-Typen aufzeigt. Das folgende Beispiel zeigt die empfohlene Konfiguration f\u00fcr einen WooCommerce-Shop, bei der der Schwerpunkt auf der Leistung und Stabilit\u00e4t der Website liegt:<\/p>\n Genau diese differenzierte, kategoriespezifische Kontrolle bieten die meisten bestehenden Tools nicht.<\/p>\n Was wir mit dem Bot-Schutz von Kinsta<\/a> entwickelt haben, wurde speziell f\u00fcr die oben beschriebenen infrastrukturellen Herausforderungen konzipiert.<\/p>\n Das System klassifiziert den Traffic<\/a> in Kategorien wie verifizierte Bots, wahrscheinlich Menschen, wahrscheinlich Bots, automatisierter Traffic und b\u00f6swilliger Traffic und erm\u00f6glicht es dir, Schutzstufen festzulegen, die den tats\u00e4chlichen Anforderungen deiner Website entsprechen.<\/p>\n Die Stufen sind nicht bin\u00e4r. \u201eBlock automations\u201c zielt auf best\u00e4tigten automatisierten Datenverkehr ab, w\u00e4hrend verifizierte Bots unber\u00fchrt bleiben. \u201eChallenge bots\u201c f\u00fcgt einen Verifizierungsschritt f\u00fcr nicht verifizierte Automatisierungen hinzu, ohne legitime Besucher zu st\u00f6ren. \u201eChallenge everyone\u201c ist f\u00fcr Zeiten mit akutem Datentrafficdruck verf\u00fcgbar, bringt aber die zu erwartenden Kompromisse mit sich.<\/p>\n Entscheidend ist, dass das Tool auf Cloudflares Bot-Scoring auf Enterprise-Niveau basiert \u2013 einer Echtzeit-Klassifizierung mittels maschinellem Lernen, die jedem Besucher anhand von Verhaltenssignalen und nicht nur anhand von User-Agent-Strings eine Punktzahl von 1 bis 99 zuweist. Das ist wichtig, weil der Abgleich von User-Agents allein zunehmend unwirksam ist, da mittlerweile 12,9 % der KI-Bots \u201e Au\u00dferdem gibt es ein \u201eAlways Allow<\/a>\u201c-Ausnahmesystem f\u00fcr vertrauensw\u00fcrdige Integrationen, \u00dcberwachungsdienste und gesch\u00e4ftskritische Automatisierungen, die nicht von den Schutzregeln erfasst werden sollten \u2013 denn \u00fcberm\u00e4\u00dfiges Blockieren verursacht ebenfalls echte Kosten, insbesondere f\u00fcr WooCommerce-Shops, die auf automatisierte Bestellsynchronisation, Zahlungsgateway-Integrationen oder Verf\u00fcgbarkeits\u00fcberwachung angewiesen sind.<\/p>\n Der Schalter zum Blockieren von KI-Crawlern<\/a> zielt speziell auf KI-Trainings-Bots ab, ohne Suchmaschinen-Crawler wie Googlebot oder Bingbot zu beeintr\u00e4chtigen. F\u00fcr Websites, bei denen KI-Crawler-Aktivit\u00e4ten als Leistungsfaktor identifiziert wurden, ist dies eine einfache Abhilfema\u00dfnahme, die keine Konfiguration einzelner Regeln erfordert.<\/p>\n Zu wissen, dass es das Tool gibt, ist eine Sache. Zu wissen, wann und wie man es einsetzt, ist eine andere.<\/p>\n Wenn du die oben beschriebenen Muster feststellst, findest du hier einen praktischen Ansatzpunkt, geordnet nach Auswirkung:<\/p>\n Erstens: \u00dcberpr\u00fcfe die Quelle.<\/strong> Nutze die Aufschl\u00fcsselung der Anfragen<\/a> in der Bot-Schutz-Ansicht von MyKinsta, um zu verstehen, wie der Traffic auf deiner Website klassifiziert wird.<\/p>\n Wenn ein erheblicher Teil automatisiert oder nicht verifiziert ist, ist das dein Signal zum Handeln. \u00dcberspringe diesen Schritt nicht, denn Schutzma\u00dfnahmen vorzunehmen, ohne zu wissen, wogegen du dich sch\u00fctzt, f\u00fchrt zu Fehlkonfigurationen.<\/p>\n Zweitens: Passe die Schutzstufe an den Website-Typ an.<\/strong> Ein WooCommerce-Shop hat andere Priorit\u00e4ten als eine Content-Website, die wiederum andere Priorit\u00e4ten hat als eine Staging-Umgebung. Das Blockieren von automatisiertem Datentraffic und das \u00dcberpr\u00fcfen potenzieller Bots ist f\u00fcr einen Shop mit dynamischen Endpunkten sinnvoll. Eine Content-Website k\u00f6nnte es vorrangig zulassen, dass KI-Entdeckungs-Bots zugreifen, w\u00e4hrend KI-Trainings-Crawler blockiert werden. Eine Staging-Umgebung sollte in jedem Fall vollst\u00e4ndig abgesichert sein.<\/p>\n Drittens: Sch\u00fctze zuerst die kritischen Pfade.<\/strong> Bevor du pauschale Schutzregeln anwendest, \u00fcberlege, ob deine kostenintensivsten Endpunkte \u2013 wie Warenkorb, Kasse und AJAX-Handler \u2013 f\u00fcr Crawler zug\u00e4nglich sind, die dort nichts zu suchen haben. Das Blockieren bekannter Bot-User-Agents von Viertens: \u00dcberwachen, dann anpassen.<\/strong> Die Muster des Bot-Traffics \u00e4ndern sich schneller, als den meisten Website-Betreibern bewusst ist. Der Traffic-Anteil von GPTBot hat sich innerhalb eines einzigen Jahres verdreifacht. Schutzregeln einmal festzulegen und sie dann zu ignorieren, ist keine Strategie. Das Diagramm zu den Bot-Schutz-Ergebnissen<\/a> in MyKinsta verfolgt, was im Laufe der Zeit blockiert, \u00fcberpr\u00fcft und zugelassen wird.<\/p>\n Diese Daten sollten dir als Grundlage dienen, um deine Einstellungen anzupassen.<\/p>\n Wenn Bots bei einem besuchsbasierten Tarif zu \u00dcberschreitungen der Besuchszahl f\u00fchren, lohnt es sich m\u00f6glicherweise, parallel dazu die bandbreitenbasierten Hosting-Tarife<\/a> von Kinsta in Betracht zu ziehen. Der Wechsel zu einem bandbreitenbasierten Tarif l\u00f6st zwar nicht das zugrunde liegende Bot-Problem, spiegelt aber die tats\u00e4chlichen Infrastrukturkosten deines Traffic-Mixes besser wider, die oft deutlich niedriger sind, als die Besucherzahlen vermuten lassen.<\/p>\n Agentischer Traffic taucht bereits in den Infrastruktur-Logs auf. Google hat einen speziellen User-Agent<\/a> angek\u00fcndigt, der zum Einsatz kommt, wenn seine KI-Agenten mit Websites interagieren. Dabei handelt es sich um automatisierte Systeme, die auf Links klicken, Formulare ausf\u00fcllen und Anfragen stellen, die dem Verhalten menschlicher Nutzer immer \u00e4hnlicher werden.<\/p>\n Die Signale, die derzeit zur Bot-Klassifizierung dienen \u2013 wie User-Agent-Strings, Anfrageh\u00e4ufigkeit und Verhaltensbewertung \u2013, lassen sich immer schwerer eindeutig anwenden, da die Grenze zwischen automatisierter und menschlicher Interaktion immer mehr verschwimmt.<\/p>\nWas \u201eechte Arbeit\u201c f\u00fcr eine WordPress-Seite bedeutet<\/h2>\n
\n
?add-to-cart=<\/code>, \/cart<\/code>, \/checkout<\/code>)<\/li>\n\n
![\"Wie](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/how-bot-talk-to-server.png\")
Was die Infrastrukturdaten von Kinsta tats\u00e4chlich zeigen<\/h2>\n
![\"7,67](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bots-hit-add-to-cart-url.png\")
Das Schleifenproblem: Bots greifen nicht an, sie stecken fest<\/h2>\n
\n
![\"Bots](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-causing-loop-problem.png\")
robots.txt<\/code> zu \u00fcberpr\u00fcfen.\u201c<\/p>\nDeine Serverrechnung ist jetzt ein Problem des Bot-Managements<\/h2>\n
![\"Kinsta-Hosting-Tarife](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/kinsta-bandwidth-hosting-plans.png\")
Was dir deine Analysedaten sagen (und was nicht)<\/h2>\n
\n
Warum das Problem schwieriger ist, als es aussieht<\/h2>\n
![\"Interaktives](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/ai-bot-traffic-report-decision-framework.png\")
Der Ansatz von Kinsta zum Bot-Schutz<\/h2>\n
![\"MyKinsta-Botschutzstufen.\"](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-protection-levels-mykinsta.png\")
robots.txt<\/code>\u201c-Anweisungen ignorieren \u2013 ein Anstieg von 3,3 % gegen\u00fcber dem vorangegangenen Quartal. Die verhaltensbasierte Klassifizierung erfasst das, was User-Agent-basierte Regeln \u00fcbersehen.<\/p>\n![\"Bot-Schutz](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/always-allow-exception-bot-protection-mykinsta.png\")
![\"KI-Crawler](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/mykinsta-bot-protection-ai-crawlers.png\")
Was tun, wenn Bot-Traffic dein Problem ist<\/h2>\n
![\"Diagramm](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-request-breakdown-mykinsta.png\")
\/cart<\/code> und ?add-to-cart=<\/code> \u00fcber robots.txt<\/code> ist ein erster Schritt; die Durchsetzung auf WAF-Ebene (und nicht nur die Signalisierung) ist es, was die Belastung tats\u00e4chlich verhindert.<\/p>\n![\"Diagramm](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-protection-results.png\")
Das gro\u00dfe Ganze: Dieses Problem wird noch schwieriger werden<\/h2>\n