Bot-Traffic ist für WordPress-Websitebetreiber längst kein Problem mehr, das nur im Hintergrund läuft. In unserem „AI & Bot Traffic Report“ haben wir mehr als 10 Milliarden Anfragen in der von Kinsta verwalteten Infrastruktur analysiert und festgestellt, dass automatisierter Traffic mittlerweile ein Infrastrukturproblem ist – und nicht mehr nur eine Randnotiz in den Bereichen Sicherheit oder Analytik.

Crawler greifen dynamische Endpunkte an, geraten in Query-String-Schleifen, umgehen den Cache und erzeugen Traffic-Muster, die weniger nach normaler Indizierung aussehen, sondern eher nach fehlerhafter Automatisierung in großem Maßstab.

Diese Veränderung hat den Bot-Schutz zu einem wichtigen Bestandteil des Betriebs einer WordPress-Website gemacht. Das ist auch der Grund, warum wir den Kinsta-Bot-Schutz veröffentlicht haben – ein integriertes Tool, das WordPress-Websitebetreibern hilft, unerwünschten automatisierten Traffic direkt über MyKinsta zu identifizieren und zu verwalten.

Wenn du aber bereits Cloudflare nutzt, fragst du dich vielleicht, wie sich der Kinsta-Bot-Schutz in das Gesamtbild einfügt. Ist er dasselbe wie der „Bot Fight Mode“ von Cloudflare? Solltest du beide nutzen? Ersetzt das eine das andere? Und wenn du dein eigenes Cloudflare-Konto vor deiner Website betreibst, was passiert dann, wenn du zusätzlich den Schutz von Kinsta aktivierst?

Genau diese Fragen haben wir während unseres jüngsten Webinars „Bot Traffic Reality Check“ oft gehört, daher beantwortet dieser Beitrag sie direkt – mit Beiträgen von Laszlo Farkas, unserem Director of Engineering.

TL;DR

  • Der Kinsta-Bot-Schutz ist nicht einfach nur der „Bot Fight Mode“ von Cloudflare mit einem Kinsta-Label. Er nutzt die Bot-Erkennungs- und Challenge-Funktionen von Cloudflare, ergänzt diese jedoch um Kinstas WordPress-spezifische Feinabstimmung und verwaltete Standardeinstellungen.
  • Für die meisten auf Kinsta gehosteten WordPress-Websites ist der Kinsta-Bot-Schutz der bessere Ausgangspunkt. Er ist in MyKinsta integriert, auf WordPress-Traffic abgestimmt und erfordert nicht, dass du eigene Bot-Regeln erstellst oder pflegst.
  • Das Cloudflare-Bot-Management eignet sich möglicherweise besser für erfahrene Teams. Wenn du Regeln auf Endpunkt-Ebene, benutzerdefinierte Bot-Bewertungen und tiefgehende forensische Untersuchungen benötigst und über das nötige Fachwissen verfügst, um Regeln selbst zu verwalten, bietet dir Cloudflare mehr Flexibilität.
  • Beides zu nutzen, ist in der Regel unnötig. Der Einsatz sich überschneidender Bot-Schutz-Tools kann zu doppelten Herausforderungen führen oder echte Besucher behindern.
  • Der Hauptkompromiss liegt zwischen Kontrolle und einfacher Handhabung. Cloudflare bietet fortgeschrittenen Teams mehr Kontrolle. Kinsta bietet WordPress-Teams eine verwaltete Lösung, die für die meisten Anwendungsfälle sofort einsatzbereit ist.

Der Bot-Schutz von Kinsta und Cloudflare sind nicht dasselbe

Kinstas Hosting-Stack läuft auf Cloudflare für CDN, WAF und DDoS-Abwehr. Das versuchen wir gar nicht zu verheimlichen.

Ein Diagramm der WordPress-Hosting-Architektur von Kinsta
Ein Diagramm der WordPress-Hosting-Architektur von Kinsta

Der Bot-Schutz basiert auf derselben Grundlage. Wenn die Frage also lautet, ob der Bot-Schutz von Kinsta unter der Haube die Erkennungs-Engine von Cloudflare nutzt, lautet die Antwort: Ja.

Aber „nutzt dieselbe Engine“ und „ist dasselbe Produkt“ sind nicht dasselbe, und wenn man diese beiden Aussagen verwechselt, entsteht Verwirrung. Wie Laszlo es formulierte, als wir ihn direkt danach fragten:

Wir nutzen dieselbe Infrastruktur wie Cloudflare. Wir verfügen über dasselbe Wissen und dieselben Optionen wie Cloudflare, aber wir haben das fundierte Fachwissen, um unseren Kunden bessere Standardeinstellungen für den Umgang mit WordPress-Traffic anbieten zu können.

Kinsta legt seine eigenen Klassifizierungsregeln über die Bot-Liste von Cloudflare, und diese Überlagerung macht in der Praxis einen Unterschied. Cloudflare weist jeder Anfrage einen auf maschinellem Lernen basierenden Bot-Score von 1 bis 99 zu, wobei 1 für eine hohe Wahrscheinlichkeit von Automatisierung steht und 99 für eine hohe Wahrscheinlichkeit, dass es sich um einen Menschen handelt. Kinsta nutzt diesen Wert als Grundlage, fügt aber eigene Logik hinzu, sodass ein KI-Crawler, der ungewöhnlich viele Anfragen stellt, als „KI-Crawler mit übermäßiger Zugriffsrate“ neu klassifiziert und abgefragt werden kann – selbst wenn Cloudflares eigene Liste ihn als verifizierten Bot einstuft.

Die Bot-Tools von Cloudflare sind für eine breite Palette von Websites, Anwendungen und Traffic-Mustern ausgelegt. Der Bot-Schutz von Kinsta ist speziell auf WordPress-Websites abgestimmt, die bei Kinsta gehostet werden, sodass seine Standardeinstellungen die WordPress-Traffic-Muster, Endpunkte, Automatisierungen und Integrationen widerspiegeln, die wir täglich sehen.

Die Optionen des Cloudflare-Bot-Schutzes verstehen

Bevor du den Bot-Schutz von Kinsta mit dem von Cloudflare vergleichst, ist es hilfreich, genau zu klären, was „Cloudflare-Bot-Schutz“ eigentlich bedeutet, da Cloudflare nicht nur ein einziges Produkt anbietet. Es gibt drei Stufen, jede mit einem anderen Maß an Kontrolle und operativer Komplexität.

Cloudflare Bot Fight Mode

Der Bot-Fight-Modus ist die einfachste Option, die als einfacher Ein-/Aus-Schalter verfügbar ist und in jedem Cloudflare-Tarif enthalten ist, auch im kostenlosen. Sein Hauptvorteil ist die Einfachheit: Du kannst ihn aktivieren und erhältst grundlegenden Bot-Schutz, ohne auch nur eine einzige Regel schreiben zu müssen.

Cloudflare-Bot-Fight-Modus
Cloudflare-Bot-Fight-Modus

Der Nachteil ist die mangelnde Kontrolle. In der Cloudflare-Dokumentation wird ausdrücklich darauf hingewiesen, dass der Bot-Fight-Modus ganze Domains schützt und nicht mithilfe von benutzerdefinierten WAF-Regeln oder Page Rules umgangen oder übersprungen werden kann, da er überhaupt nicht auf der Ruleset Engine von Cloudflare läuft. Praktisch gesehen hast du, wenn der Bot-Fight-Modus Traffic überprüft, den du nicht überprüft haben wolltest, nur zwei echte Optionen: ihn komplett auszuschalten oder ein Upgrade durchzuführen.

Dieser Kompromiss kann für WordPress-Websites mit legitimem automatisiertem Traffic ein Problem darstellen, wie zum Beispiel API-Clients, Überwachungstools, Plugin-Integrationen, Zahlungsabläufe oder andere Dienste, die einen vorhersehbaren Zugriff benötigen.

Cloudflare Super-Bot-Fight-Modus

Der Super-Bot-Fight-Modus (verfügbar in den Tarifen Pro, Business und Enterprise ohne das Add-on „Bot Management“) bietet dir mehr Kontrolle als die einfache Ein-/Aus-Schaltung. Damit kannst du für breite Traffic-Kategorien wie „definitiv automatisiert“, „wahrscheinlich automatisiert“ und „verifizierte Bots“ separate Aktionen wie „zulassen“, „überprüfen“ oder „blockieren“ auswählen.

Cloudflare Super Bot Fight Mode
Cloudflare Super Bot Fight Mode

Im Gegensatz zum Bot-Fight-Modus läuft er auf der Ruleset Engine, was bedeutet, dass du benutzerdefinierte WAF-Regeln mit einer „Skip“-Aktion nutzen kannst, um Ausnahmen für bestimmten Datentraffic festzulegen.

Diese zusätzliche Kontrolle ist nützlich, aber es handelt sich dennoch um ein breit angelegtes Tool. Es bietet weder eine gezielte Steuerung pro Endpunkt noch die detaillierte Bot-Bewertung pro Anfrage, wie sie das Bot-Management bereitstellt. Für dieses Maß an Kontrolle verweist Cloudflare die Nutzer selbst auf das Bot-Management.

Cloudflare Bot Management und benutzerdefinierte Regeln

Bot Management ist Cloudflares flexibelste Option und als Enterprise-Add-on verfügbar. Es generiert für jede Anfrage einen Bot-Score von 1 bis 99 und ermöglicht es dir, anhand von WAF-benutzerdefinierten Regeln oder Workers darauf zu reagieren, wobei Signale wie Bot-Score, URI-Pfad, Land, ASN, IP-Bereich, Header und User-Agent herangezogen werden.

Cloudflare-benutzerdefinierte Regeln
Cloudflare-benutzerdefinierte Regeln

Genau hier zeigt Cloudflare seine wahre Stärke. Du könntest beispielsweise Anfragen mit niedrigem Score auf einer Anmeldeseite überprüfen, während du einen öffentlichen Blog unberührt lässt.

Doch diese Flexibilität bringt auch echte Verantwortung mit sich. Du musst deinen Traffic verstehen, die Regeln erstellen, auf Fehlalarme prüfen, die Ergebnisse überwachen und die Einstellungen kontinuierlich anpassen, wenn sich das Verhalten der Bots ändert.

Wo der Kinsta-Bot-Schutz ins Spiel kommt

Der Kinsta-Bot-Schutz liegt zwischen dem Cloudflare „Bot Fight Mode“ und dem Cloudflare-Bot-Management mit benutzerdefinierten Regeln. Er ist WordPress-spezifischer als ein allgemeiner Ein-/Aus-Schalter, verlangt aber nicht, dass du eine benutzerdefinierte Bot-Management-Strategie von Grund auf neu aufbaust und pflegst.

Anstatt mit rohen Bot-Bewertungen, Regelausdrücken oder Logik auf Endpunkt-Ebene zu beginnen, geht der Kinsta-Bot-Schutz vom WordPress-Hosting-Kontext aus: normale Besucher, Such-Crawler, KI-Crawler, Verfügbarkeitsmonitore, WordPress-Automatisierungen, Plugin-Integrationen, E-Commerce-Aktivitäten, Admin-Workflows und verdächtige automatisierte Anfragen.

Einfach ausgedrückt lässt sich das so zusammenfassen:

Ansatz Was du davon hast Was von dir erwartet wird
Cloudflare Bot Fight Mode Umfassende Bot-Abwehr Sehr wenig Einrichtungsaufwand, aber eingeschränkte Kontrolle
Kinsta-Bot-Schutz Verwalteter, WordPress-spezifischer Schutz Wähle die richtige Schutzstufe und beobachte die Auswirkungen
Cloudflare-Bot-Management Umfassende Anpassungsmöglichkeiten Erstelle, teste, überwache und pflege die Regeln selbst

Was Kinsta zusätzlich zu den Cloudflare-Funktionen bietet

Der Bot-Schutz von Kinsta ergänzt die Funktionen von Cloudflare zur Bot-Erkennung und -Abfrage um eine verwaltete, WordPress-spezifische Ebene. So sieht das in der Praxis aus.

Vier Schutzstufen statt eines einzigen Schalters

Der Kinsta-Bot-Schutz bietet vier voreingestellte Stufen, die pro Umgebung angewendet werden:

Kinsta-Bot-Schutzstufen
Kinsta-Bot-Schutzstufen

Die vier Stufen sind:

  • Bösartigen Datentraffic blockieren: Die Basisstufe, die standardmäßig auf jede Kinsta-Website angewendet wird, ohne zusätzliche Einrichtung. Dazu gehören DDoS-Abwehr sowie globale Regeln für IP-Adressen und Endpunkte, die ausschließlich von bösartigem Datentraffic genutzt werden. Allein diese Basisstufe filtert in der Regel etwa 15–20 % des eindeutig bösartigen Traffics heraus, bevor er überhaupt deine Website erreicht.
  • Automatisierungen blockieren: Blockiert sowohl automatisierten als auch bösartigen Datentraffic.
  • Bots abfragen: Blockiert automatisierten und bösartigen Traffic und fragt dann mutmaßliche Bots und nicht klassifizierten Traffic ab.
  • Alle herausfordern: Die strengste Einstellung. Blockiert automatisierten und böswilligen Datentraffic und fordert mutmaßliche Menschen, Bots und nicht klassifizierten Traffic heraus. Am besten für eine Website reserviert, die aktiv angegriffen wird, oder bei einem ungewöhnlichen Anstieg, der sofortige Abwehrmaßnahmen erfordert.

Da diese Stufen pro Umgebung festgelegt werden, kannst du in der Produktionsumgebung eine strengere Einstellung verwenden, während du die Staging-Umgebung großzügiger belässt – oder umgekehrt.

Eine Überprüfung bedeutet nicht immer ein sichtbares CAPTCHA. Es kann sich um eine browserbasierte Überprüfung, eine Hintergrundvalidierung oder einen interaktiven Test handeln. Legitime menschliche Besucher bestehen die Überprüfung in der Regel mit geringer oder gar keiner sichtbaren Unterbrechung, und sobald ein Besucher eine Überprüfung bestanden hat, wird er mindestens 10 Tage lang nicht erneut überprüft, solange er denselben Browser und dieselbe IP-Adresse verwendet.

Traffic-Klassifizierung

Die Analytics von MyKinsta zeigen, wie jede Anfrage klassifiziert wurde: wahrscheinlich Menschen, verifizierte Bots, wahrscheinlich Bots, unklassifizierter Datentraffic, automatisierter Traffic, böswilliger Datentraffic und KI-Crawler mit übermäßiger Zugriffsrate.

Kinsta-Bot-Anfragen-Diagramm
Kinsta-Bot-Anfragen-Diagramm

Außerdem wird angezeigt, wie jede Anfrage letztendlich behandelt wurde – ob sie zugelassen, abgefragt oder blockiert wurde.

Kinsta-Bot-Schutz-Ergebnisdiagramm
Kinsta-Bot-Schutz-Ergebnisdiagramm

Diese Unterscheidung ist wichtig, denn „automatisiert“ bedeutet nicht automatisch „unerwünscht“. Automatisierter Traffic kann durchaus legitime Tools umfassen, die noch auf keiner verifizierten Bot-Liste stehen, wie zum Beispiel benutzerdefinierte API-Integrationen, Verfügbarkeitsmonitore oder Bereitstellungs-Skripte.

Ein System, das nur in „zulassen oder blockieren“ denkt, ist zu pauschal für die tatsächliche Funktionsweise von WordPress-Websites.

Eine verwaltete Zulassungsliste speziell für WordPress

WordPress-Websites sind auf viele legitime automatisierte Aktivitäten angewiesen, wie zum Beispiel REST-API-Anfragen, geplante Aufgaben, Plugin-Integrationen, Formularübermittlungen, SEO-Tools, Synchronisierungstools und E-Commerce-Workflows.

Sollte ein strengerer Bot-Schutz diese Aktivitäten beeinträchtigen, kannst du Typische WordPress-Automatisierungen zulassen aktivieren. Damit wird Kinstas verwaltete Zulassungsliste mit vertrauenswürdigen WordPress-Endpunkten und -Diensten aktiviert.

Typische WP-Automatisierungen mit dem Kinsta-Bot-Schutz-Tool zulassen
Typische WP-Automatisierungen mit dem Kinsta-Bot-Schutz-Tool zulassen

Oder füge unter Immer zulassen eine spezifische Ausnahme hinzu, indem du eine IP-Adresse, einen Pfad oder einen User-Agent angibst.

Ausnahme zum Kinsta-Bot-Schutz hinzufügen
Ausnahme zum Kinsta-Bot-Schutz hinzufügen

Wir erwarten nicht, dass jeder Kunde selbst herausfinden muss, welche Integrationen vor strengeren Bot-Regeln geschützt werden müssen. Die Zulassungsliste wird für dich gepflegt und erweitert.

Eine separate Steuerung für KI-Crawler

Die Verwaltung von KI-Crawlern wurde bewusst von der allgemeinen Schutzstufe getrennt, da KI-Crawler nicht automatisch mit bösartigen Bots gleichzusetzen sind. Einige identifizieren sich eindeutig und halten sich an Crawling-Limits. Andere verursachen einfach durch aggressives Crawling oder das Aufrufen teurer, nicht zwischengespeicherter Pfade eine hohe Auslastung.

Kinstas spezieller Schalter KI-Crawler blockieren sperrt KI-Crawler vollständig, einschließlich verifizierter, ohne Suchmaschinen-Crawler wie Googlebot oder Bing zu beeinträchtigen. Es handelt sich um einen separaten Regler, gerade weil der Datentraffic von KI-Crawlern und der allgemeine Bot-Datentraffic oft unterschiedliche Entscheidungen erfordern.

Kinsta-Bot-Schutz blockiert KI-Crawler
Kinsta-Bot-Schutz blockiert KI-Crawler

Massenaktionen über alle Umgebungen hinweg

Bot-Traffic ist für Agenturen selten ein Problem, das nur eine einzelne Website betrifft. Kinsta unterstützt Massenaktionen über die WordPress-Websiteliste, sodass du Schutzstufen ändern, KI-Crawler zulassen oder blockieren und die WordPress-Automatisierungs-Whitelist über mehrere Umgebungen hinweg gleichzeitig aktualisieren kannst, ohne jede Website einzeln öffnen zu müssen.

Bot-Schutz-Einstellungen in Mykinsta massenweise anpassen
Bot-Schutz-Einstellungen in Mykinsta massenweise anpassen

Support von Leuten, die sich mit WordPress-Hosting auskennen

Probleme mit Bot-Traffic lassen sich selten vom Rest des WordPress-Stacks isolieren. Ein plötzlicher Anstieg kann durch bösartige Bots, einen KI-Crawler, eine falsch konfigurierte Integration, einen Plugin-Konflikt, einen WooCommerce-Synchronisierungsauftrag oder eine legitime Marketingkampagne verursacht werden.

Mit dem Kinsta-Bot-Schutz erfolgt der Support durch dasselbe Team, das deine Hosting-Umgebung bereits kennt – du musst also nicht zwei separate Dashboards von zwei verschiedenen Anbietern miteinander abgleichen.

Wenn du bereits dein eigenes Cloudflare-Konto nutzt

Das ist die mit Abstand häufigste Frage, die wir während des Webinars bekommen haben, daher lohnt es sich, hier genau darauf einzugehen, anstatt sie in eine allgemeine Aussage wie „Lass nicht beides gleichzeitig laufen“ zu verpacken.

Was den gleichzeitigen Einsatz der Cloudflare-eigenen Bot-Funktionen (Bot Fight Mode, Super Bot Fight Mode oder Bot Management) neben dem Kinsta-Bot-Schutz angeht, stellte Laszlo klar, dass dies technisch zwar funktioniert, er es aber nicht empfehlen würde:

Technisch gesehen funktionieren sie zusammen, aber ich würde generell nicht empfehlen, beides zu aktivieren… Beides gleichzeitig zu nutzen, kann zudem unnötige Reibungsverluste verursachen. So könnte es beispielsweise passieren, dass ein Besucher bei seinem ersten Besuch mehrere verifizierte Herausforderungen statt nur einer angezeigt bekommt.

Auf eine Frage während des Webinars brachte es unser CTO, Daniel Pataki, noch einfacher auf den Punkt: „Man kann beides nutzen, aber es gibt keinen wirklichen Grund dafür. Es ist viel sicherer, nur das eine oder das andere zu nutzen.“ In diesem Szenario sind also Reibungsverluste und überflüssige Herausforderungen für echte Besucher der Nachteil, nicht eine fehlerhafte Konfiguration.

Wir raten außerdem davon ab, neben dem Kinsta-Bot-Schutz ein weiteres CDN, einen Reverse-Proxy oder eine WAF vor deiner Website zu schalten. Dazu gehört auch dein eigenes Cloudflare-Konto, wenn es den Datentraffic aktiv über einen Proxy weiterleitet und dabei die WAF- oder Bot-Funktionen aktiviert sind, sowie andere Dienste wie AWS, Microsoft Azure, Sucuri oder Fortinet, die als Reverse-Proxys fungieren. Wenn etwas anderes vor eurem Datentraffic steht und diesen zuerst verarbeitet, kann Kinsta den tatsächlichen Ursprung jeder Anfrage nicht mehr erkennen, was bedeutet, dass der Bot-Schutz automatisierten Traffic nicht zuverlässig von menschlichem unterscheiden kann.

Wenn du derzeit dein eigenes Cloudflare-Konto mit benutzerdefinierten Bot- oder WAF-Regeln vor einer Kinsta-Website betreibst und dir nicht sicher bist, welche dieser beiden Situationen auf deine Konfiguration zutrifft, ist es am sichersten, dich vor Änderungen beim Kinsta-Support zu erkundigen, anstatt zu raten.

Überwachung: Cloudflare vs. Kinsta

Wo solltest du deinen Datentraffic eigentlich täglich überwachen? Das hängt davon ab, wonach du suchst.

Cloudflare bietet dir deutlich mehr Flexibilität bei der Analyse. Du kannst mit benutzerdefinierten Filtern einzelne Anfragen genauer unter die Lupe nehmen und nach fast jedem Anfrageattribut suchen. Allerdings basieren die Bot-Analysen von Cloudflare auf Stichprobendaten und nicht auf einer vollständigen Zählung aller Anfragen. Das eignet sich hervorragend, um Muster zu erkennen und Vorfälle zu untersuchen, ist aber als Quelle für exakte Traffic-Zahlen weniger zuverlässig.

Kinsta hingegen erfasst 100 % der Anfragen, die auf deiner Website eingehen, und stellt in MyKinsta aggregierte Stunden- und Tagesstatistiken bereit. Damit ist Kinsta die bessere Quelle für genaue Zahlen und Trends auf Plattformebene, auch wenn es dir nicht die Ad-hoc-Filter und Detailansichten von Cloudflare bietet.

Wenn du also eine gründliche forensische Untersuchung eines bestimmten Vorfalls benötigst, haben die Tools von Cloudflare die Nase vorn. Wenn du genaue, vertrauenswürdige Kennzahlen darüber willst, was im Laufe der Zeit tatsächlich auf deine Website gelangt, hat Kinsta die Nase vorn.

Auf welcher Ebene läuft der Kinsta-Bot-Schutz?

Der Kinsta-Bot-Schutz läuft am Edge, auf Layer 7 (der Anwendungsschicht) – derselben Schicht, in der HTTP-Anfragen ausgewertet werden.

Wenn sowohl der Cloudflare-Schutz eines Kunden als auch der Kinsta-Bot-Schutz auf demselben Anfragepfad aktiv sind, erfolgt die Verarbeitung durch Cloudflare zuerst, und die Logik von Kinsta wird danach ausgeführt. Das ist ein weiterer Grund, warum eine Überschneidung der beiden selten einen Mehrwert bringt. Bis eine Anfrage die Logik von Kinsta erreicht, hat Cloudflare bereits seine eigene Entscheidung getroffen.

Welchen Ansatz solltest du wählen?

Die richtige Wahl hängt davon ab, wie viel Kontrolle du benötigst und wie viel von der Bot-Verwaltung dein Team selbst übernehmen möchte.

Nutze den Kinsta-Bot-Schutz, wenn du einen verwalteten WordPress-Schutz wünschst

Wenn du WordPress bei Kinsta hostest und nicht möchtest, dass die Bot-Abwehr zu einer wiederkehrenden Aufgabe im Kalender eines Mitarbeiters wird, ist der Kinsta-Bot-Schutz die richtige Standardwahl.

Das deckt die meisten WordPress-Seiten ab: Agenturen, die den Traffic für Dutzende von Kunden verwalten, Teams ohne eigene Sicherheitsabteilung und alle, die ihre Zeit lieber mit dem Betreiben des Unternehmens verbringen möchten, als Bot-Regeln zu pflegen.

Nutze die erweiterten Bot-Tools von Cloudflare, wenn du volle Kontrolle benötigst

Cloudflare ist möglicherweise die bessere Wahl, wenn du die erweiterten Bot-Steuerungsfunktionen wie den „Super Bot Fight Mode“ in Kombination mit WAF- und benutzerdefinierten Regeln nutzt und über die Zeit sowie das Fachwissen verfügst, um diese Konfiguration ordnungsgemäß zu verwalten.

Das ist nicht dasselbe wie der einfache Cloudflare-Bot-Fight-Modus, der eher einer pauschalen Ein-/Aus-Steuerung ähnelt. Der erweiterte Cloudflare-Ansatz ist sinnvoll, wenn du deinen Datentraffic im Detail kennst, bestimmte Endpunkte hast, die unterschiedlich behandelt werden müssen, und für bestimmte Anfragemuster ein benutzerdefiniertes Verhalten festlegen möchtest.

Diese Präzision ist echt, bringt aber laufende Kosten mit sich, da sie kontinuierliche Aufmerksamkeit erfordert und nicht nur eine einmalige Konfiguration. Wie Laszlo es formulierte:

Wenn du das Fachwissen und die Zeit hast, das selbst fein abzustimmen, ist das wahrscheinlich die bessere Wahl für dich. Wenn du das nicht hast und dich lieber auf dein Geschäft konzentrieren möchtest, anstatt dich mit den technischen Details der Traffic-Steuerung zu beschäftigen, ist die Lösung von Kinsta die bessere Option, da sie verwaltet, für WordPress optimiert und für dich gewartet wird.

Vermeide es, beides zu nutzen, es sei denn, du hast einen bestimmten Grund dafür

Wähle in den meisten Fällen eine primäre Bot-Schutzebene:

  • Wenn du den Cloudflare Bot Fight Mode oder den Super Bot Fight Mode auf einer von Kinsta gehosteten Website nutzt, ist der Kinsta-Botschutz in der Regel die bessere Wahl, da er auf WordPress abgestimmt ist und innerhalb deiner Hosting-Plattform verwaltet wird.
  • Wenn du das Cloudflare-Bot-Management mit einem festgelegten benutzerdefinierten Regelsatz betreibst, hängt die Entscheidung eher von der jeweiligen Situation ab; es kommt darauf an, was diese Regeln bewirken, wie sie mit dem Kinsta-Bot-Schutz interagieren würden und ob sie noch benötigt werden, sobald der verwaltete Schutz von Kinsta aktiviert ist. Besprich diese Konfiguration lieber mit dem Kinsta-Support, anstatt dich auf eine pauschale Antwort zu verlassen.
  • Wenn du dein eigenes, separates Cloudflare-Konto als Proxy vor Kinsta betreibst, lies dir den obigen Abschnitt durch; dies ist der einzige Fall, in dem die Kombination beider Lösungen nicht nur „unnötigen Reibungsverlust“ bedeutet, sondern sogar aktiv verhindern kann, dass der Bot-Schutz wie vorgesehen funktioniert.

Der Bot-Schutz wird zum festen Bestandteil des WordPress-Betriebs

Bot-Schutz ist nicht mehr etwas, das Website-Betreiber als einmalige Sicherheitseinstellung abtun können. Wie Daniel Pataki in unserem Webinar erklärte, sind Bots ein zweischneidiges Schwert: Sie können Probleme bei Leistung, Kosten und Analysen verursachen, tragen aber auch dazu bei, das Web nützlich zu machen.

Da Crawler, KI-Tools, Scraper und automatisierte Systeme im Web immer aktiver werden, brauchen WordPress-Teams eine Möglichkeit, nicht-menschlichen Traffic zu verwalten, ohne jede Website in ein Projekt zur Erstellung individueller Regeln zu verwandeln. Genau dafür wurde der Bot-Schutz von Kinsta entwickelt: als verwalteter Ausgangspunkt mit Schutzstufen, KI-Crawler-Kontrollen, WordPress-optimierten Standardeinstellungen und Transparenz in MyKinsta.

Um mehr darüber zu erfahren, schau dir das Webinar „Bot Traffic Reality Check“ an, lies den KI- und Bot-Traffic-Bericht von Kinsta oder aktiviere den Bot-Schutz über dein MyKinsta-Dashboard, um zu sehen, welcher automatisierte Traffic tatsächlich auf deine Website gelangt.

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.