Botverkeer is niet langer een probleem op de achtergrond voor eigenaren van WordPress-sites. In ons AI & Botverkeer Rapport hebben we meer dan 10 miljard verzoeken binnen de door Kinsta beheerde infrastructuur geanalyseerd, en we zagen dat geautomatiseerd verkeer tegenwoordig vooral een infrastructuurprobleem is, en niet langer slechts een randzaak bij beveiliging of analytics.
Crawlers bezoeken dynamische endpoints, raken verstrikt in query-string-loops, omzeilen de cache en creëren verkeerspatronen die minder op normale indexering lijken en meer op grootschalige, defecte automatisering.
Door die verschuiving is bescherming tegen bots een belangrijk onderdeel geworden van het beheren van een WordPress-site. Daarom hebben we Kinsta Botbescherming gelanceerd: een ingebouwde tool waarmee eigenaren van WordPress-sites ongewenst geautomatiseerd verkeer rechtstreeks vanuit MyKinsta kunnen identificeren en beheren.
Maar als je al Cloudflare gebruikt, vraag je je misschien af hoe Kinsta Botbescherming hierin past. Is het hetzelfde als de Bot Fight Mode van Cloudflare? Moet je beide gebruiken? Vervangt de een de ander? En als je je eigen Cloudflare-account voor je site gebruikt, wat gebeurt er dan als je ook de bescherming van Kinsta inschakelt?
Precies deze vragen kregen we vaak tijdens ons recente webinar ‘Botverkeer Reality Check’. In dit artikel geven we daarom direct antwoord, met input van Laszlo Farkas, onze Director of Engineering.
TL;DR
- Kinsta Botbescherming is niet zomaar de Cloudflare Bot Fight Mode met een Kinsta-label erop. Het maakt gebruik van de botdetectie- en challenge-mogelijkheden van Cloudflare, maar voegt daar Kinsta’s WordPress-specifieke afstemming en beheerde standaardinstellingen aan toe.
- Voor de meeste WordPress-sites die bij Kinsta worden gehost, is Kinsta Botbescherming het betere startpunt. Het zit ingebouwd in MyKinsta, is afgestemd op WordPress-verkeer en je hoeft geen eigen botregels aan te maken of bij te houden.
- Cloudflare Bot Management is wellicht beter voor gevorderde teams. Heb je regels op endpointniveau, custom bot-scores en diepgaand forensisch onderzoek nodig, en de expertise om zelf regels te beheren? Dan biedt Cloudflare je meer flexibiliteit.
- Het is meestal niet nodig om beide te gebruiken. Overlappende tools voor botbescherming kunnen dubbele challenges opleveren of voor echte bezoekers extra hinder veroorzaken.
- De belangrijkste afweging is die tussen controle en gebruiksgemak. Cloudflare biedt gevorderde teams meer controle. Kinsta biedt WordPress-teams een beheerde oplossing die voor de meeste situaties direct uit de doos werkt.
Kinsta Botbescherming en Cloudflare zijn niet hetzelfde
De hostingstack van Kinsta draait op Cloudflare voor CDN, WAF en DDoS-bescherming. Dat is niet iets wat we proberen te verbergen.
Botbescherming is op dezelfde basis gebouwd. Dus als de vraag is of Kinsta’s botbescherming onder de motorkap de detectie-engine van Cloudflare gebruikt, is het antwoord ja.
Maar ‘dezelfde engine gebruiken’ en ‘hetzelfde product zijn’ is niet hetzelfde, en door die twee door elkaar te halen ontstaat er verwarring. Zoals Laszlo het verwoordde toen we hem hier rechtstreeks naar vroegen:
We gebruiken dezelfde infrastructuur als Cloudflare. We hebben dezelfde kennis en dezelfde opties als Cloudflare, maar we beschikken over de diepgaande expertise om onze klanten betere standaardinstellingen te bieden voor het verwerken van WordPress-verkeer.
Kinsta voegt zijn eigen classificatieregels toe aan de botlijst van Cloudflare, en die toevoeging maakt in de praktijk écht verschil. Cloudflare kent aan elk verzoek een op machine learning gebaseerde botscore toe van 1 tot 99, waarbij 1 aangeeft dat het zeer waarschijnlijk geautomatiseerd is en 99 dat het hoogstwaarschijnlijk door een mens komt. Kinsta gebruikt die score als uitgangspunt, maar voegt daar zijn eigen logica aan toe. Zo kan een AI-crawler die een ongewoon hoog aantal verzoeken doet, worden geherclassificeerd als een ‘AI-crawler met buitensporig hoog verzoekvolume’ en worden tegengehouden, zelfs als de lijst van Cloudflare zelf hem als een geverifieerde bot markeert.
De bot-tools van Cloudflare zijn ontwikkeld voor een breed scala aan websites, applicaties en verkeerspatronen. Kinsta Botbescherming is specifiek afgestemd op WordPress-sites die bij Kinsta worden gehost, zodat de standaardinstellingen aansluiten bij de WordPress-verkeerspatronen, endpoints, automatiseringen en integraties die we dagelijks tegenkomen.
Inzicht in de botbeschermingsopties van Cloudflare
Voordat je Kinsta Botbescherming met die van Cloudflare vergelijkt, is het handig om precies te weten wat ‘Cloudflare-botbescherming’ eigenlijk inhoudt, aangezien Cloudflare niet slechts één product aanbiedt. Er zijn drie niveaus, elk met een ander niveau van controle en operationele complexiteit.
Cloudflare Bot Fight Mode
Bot Fight Mode is de eenvoudigste optie, beschikbaar als een simpele aan/uit-schakelaar, en zit bij elk Cloudflare-abonnement inbegrepen, ook bij het gratis abonnement. Het grootste voordeel is de eenvoud: je schakelt het in en krijgt direct basisbescherming tegen bots, zonder ook maar één regel te hoeven schrijven.
Het nadeel is dat je er geen controle over hebt. In de documentatie van Cloudflare staat duidelijk dat de Bot Fight Mode hele domeinen beschermt en niet kan worden omzeild of overgeslagen met custom WAF-regels of Page Rules, omdat het helemaal niet op de Ruleset Engine van Cloudflare draait. Praktisch gezien: houdt de Bot Fight Mode verkeer tegen dat je juist wel wilt doorlaten, dan zijn je enige echte opties om de modus helemaal uit te schakelen of te upgraden.
Deze afweging kan een probleem zijn voor WordPress-sites met legitiem geautomatiseerd verkeer, zoals API-clients, monitoringtools, plugin-integraties, betalingsworkflows of andere diensten die voorspelbare toegang nodig hebben.
Cloudflare Super Bot Fight Mode
De Super Bot Fight Mode (beschikbaar bij Pro-, Business- en Enterprise-abonnementen zonder de Bot Management add-on) geeft je meer controle dan de standaardschakelaar. Hiermee kun je aparte acties kiezen, zoals toestaan, controleren of blokkeren, voor brede verkeerscategorieën zoals ‘zeker geautomatiseerd’, ‘waarschijnlijk geautomatiseerd’ en ‘geverifieerde bots’.
In tegenstelling tot de Bot Fight Mode draait deze op de Ruleset Engine, wat betekent dat je custom WAF-regels met een ‘Skip’-actie kunt gebruiken om uitzonderingen te maken voor specifiek verkeer.
Die extra controle is handig, maar het blijft een tool voor brede toepassingen. Het biedt geen targeting per endpoint of de gedetailleerde bot-scoring per verzoek die Bot Management wel biedt. Voor dat niveau van controle verwijst Cloudflare zelf gebruikers door naar Bot Management.
Cloudflare Bot Management en custom regels
Bot Management is de meest flexibele optie van Cloudflare, beschikbaar als Enterprise-add-on. Het genereert voor elk verzoek een botscore van 1 tot 99 en laat je daarop actie ondernemen met behulp van custom WAF-regels of Workers, waarbij je gebruikmaakt van signalen zoals de botscore, het URI-pad, het land, het ASN, het IP-bereik, headers en de user agent.
Dit is waar Cloudflare echt krachtig wordt. Je kunt bijvoorbeeld verzoeken met een lage score op een inlogpagina tegenhouden, terwijl je een openbare blog met rust laat.
Maar die flexibiliteit brengt ook een echte verantwoordelijkheid met zich mee. Je moet je verkeer begrijpen, de regels opstellen, testen op valse positieven, de resultaten in de gaten houden en blijven bijstellen naarmate het gedrag van bots verandert.
Waar Kinsta Botbescherming past
Kinsta Botbescherming zit tussen de Cloudflare Bot Fight Mode en Cloudflare Bot Management met custom regels in. Het is beter afgestemd op WordPress dan een algemene aan/uit-schakelaar, maar je hoeft niet helemaal vanaf nul een eigen strategie voor botbeheer op te zetten en te onderhouden.
In plaats van te beginnen met ruwe bot-scores, regeluitdrukkingen of logica op endpointniveau, gaat Kinsta Botbescherming uit van de WordPress-hostingcontext: normale bezoekers, zoekcrawlers, AI-crawlers, uptime-monitors, WordPress-automatiseringen, plugin-integraties, e-commerce-activiteiten, admin-workflows en verdachte geautomatiseerde verzoeken.
Een simpele manier om het te omschrijven is:
| Aanpak | Wat het je oplevert | Wat het van je vraagt |
| Cloudflare Bot Fight Mode | Brede bescherming tegen bots | Heel weinig instellingen, maar beperkte controle |
| Kinsta Botbescherming | Beheerde bescherming specifiek voor WordPress | Kies het juiste beschermingsniveau en houd de impact in de gaten |
| Cloudflare Bot Management | Uitgebreide aanpassingsmogelijkheden | Bouw, test, controleer en onderhoud de regels zelf |
Wat Kinsta toevoegt aan de mogelijkheden van Cloudflare
Kinsta Botbescherming voegt een beheerde, WordPress-specifieke laag toe bovenop de botdetectie- en challenge-mogelijkheden van Cloudflare. Zo werkt dat in de praktijk.
Vier beveiligingsniveaus in plaats van één schakelaar
Kinsta Botbescherming biedt vier vooraf ingestelde niveaus, die per omgeving worden toegepast:
Deze vier niveaus zijn:
- Kwaadaardig verkeer blokkeren: De standaardinstelling die standaard op elke Kinsta-site wordt toegepast, zonder extra instellingen. Dit omvat DDoS-beperking en algemene regels voor IP-adressen en endpoints die uitsluitend door kwaadaardig verkeer worden gebruikt. Op zichzelf filtert deze basislaag doorgaans zo’n 15-20% van het duidelijk kwaadaardige verkeer voordat het je site bereikt.
- Automatiseringen blokkeren: Blokkeert zowel geautomatiseerd als kwaadaardig verkeer.
- Bots uitdagen: Blokkeert geautomatiseerd en kwaadaardig verkeer, en daagt vervolgens vermoedelijke bots en niet-geclassificeerd verkeer uit.
- Iedereen controleren: De strengste instelling. Blokkeert geautomatiseerd en kwaadaardig verkeer, en controleert vermoedelijke mensen, bots en niet-geclassificeerd verkeer. Het beste te gebruiken voor een site die actief wordt aangevallen of bij een ongebruikelijke piek die onmiddellijke afweer vereist.
Omdat deze niveaus per omgeving worden ingesteld, kun je in de productieomgeving een strengere instelling gebruiken terwijl je de testomgeving soepel houdt, of andersom.
Een controle betekent niet altijd een zichtbare CAPTCHA. Het kan een browsergebaseerde controle zijn, een validatie op de achtergrond of een interactieve test. Legitieme menselijke bezoekers komen er doorgaans zonder of met nauwelijks zichtbare onderbreking doorheen, en zodra een bezoeker een controle heeft doorstaan, wordt hij of zij minstens 10 dagen lang niet opnieuw gecontroleerd, zolang hij of zij dezelfde browser en hetzelfde IP-adres blijft gebruiken.
Verkeersclassificatie
De Analytics van MyKinsta laten zien hoe elk verzoek is geclassificeerd: waarschijnlijk mensen, geverifieerde bots, waarschijnlijk bots, niet-geclassificeerd verkeer, geautomatiseerd verkeer, kwaadaardig verkeer en AI-crawlers met een te hoge frequentie.
Het laat ook zien hoe elk verzoek uiteindelijk is afgehandeld: toegestaan, gecontroleerd of geblokkeerd.
Dit onderscheid is belangrijk, want ‘geautomatiseerd’ betekent niet automatisch ‘ongewenst’. Geautomatiseerd verkeer kan volkomen legitieme tools bevatten die nog niet op iemands geverifieerde botlijst staan, zoals custom API-integraties, uptime-monitors of deployscripts.
Een systeem dat alleen in ’toestaan of blokkeren’ denkt, is te grof voor hoe WordPress-sites echt werken.
Een beheerde toelatingslijst speciaal voor WordPress
WordPress-sites zijn afhankelijk van veel legitieme geautomatiseerde activiteiten, zoals REST API-verzoeken, geplande taken, plugin-integraties, formulierverzendingen, SEO-tools, synchronisatietools en e-commerce-workflows.
Als strengere botbescherming hiermee in de weg gaat staan, kun je ‘Typische WordPress-automatiseringen toestaan’ inschakelen. Hiermee activeer je Kinsta’s beheerde toelatingslijst met vertrouwde WordPress-endpoints en -diensten.
Of voeg een specifieke uitzondering toe onder ‘Altijd toestaan’ met behulp van een IP-adres, pad of user-agent.
We vragen niet van elke klant om zelf uit te zoeken welke integraties bescherming nodig hebben tegen strengere botregels. De allowlist wordt voor je bijgehouden en uitgebreid.
Een aparte instelling voor AI-crawlers
Het beheer van AI-crawlers is bewust losgekoppeld van het algemene beveiligingsniveau, omdat AI-crawlers niet automatisch hetzelfde zijn als kwaadaardige bots. Sommige identificeren zichzelf duidelijk en houden zich aan crawl-limieten. Andere zorgen voor belasting door simpelweg agressief te crawlen of dure, niet-gecachete paden te bezoeken.
Met de speciale schakelaar ‘AI-crawlers blokkeren’ van Kinsta blokkeer je AI-crawlers volledig, inclusief geverifieerde, zonder dat dit invloed heeft op crawlers van zoekmachines zoals Googlebot of Bing. Het is juist een aparte instelling omdat AI-crawlerverkeer en algemeen botverkeer vaak om verschillende beslissingen vragen.
Bulkacties voor meerdere omgevingen
Botverkeer is voor bureaus zelden een probleem dat zich tot één site beperkt. Kinsta ondersteunt bulkacties vanuit de lijst met WordPress-sites, zodat je beschermingsniveaus kunt aanpassen, AI-crawlers kunt toestaan of blokkeren en de WordPress-automatiserings-allowlist in meerdere omgevingen tegelijk kunt bijwerken, zonder elke site afzonderlijk te hoeven openen.
Ondersteuning van mensen die verstand hebben van WordPress-hosting
Problemen met botverkeer staan zelden los van de rest van de WordPress-stack. Een plotselinge piek kan het gevolg zijn van kwaadaardige bots, een AI-crawler, een verkeerd geconfigureerde integratie, een conflict tussen plugins, een WooCommerce-synchronisatietaak of een legitieme marketingcampagne.
Met Kinsta Botbescherming krijg je ondersteuning van hetzelfde team dat je hostingomgeving al door en door kent, in plaats van dat je twee aparte dashboards van twee verschillende leveranciers met elkaar moet vergelijken.
Als je al je eigen Cloudflare-account gebruikt
Dit is veruit de meest gestelde vraag die we tijdens het webinar kregen, dus het is de moeite waard om hier precies op in te gaan, in plaats van het af te doen met een algemene opmerking als “gebruik ze niet allebei”.
Over het gebruik van Cloudflares eigen bot-features (Bot Fight Mode, Super Bot Fight Mode of Bot Management) naast Kinsta Botbescherming, was Laszlo duidelijk: technisch gezien werkt dit wel, maar het is gewoon niet iets wat hij zou aanraden:
Technisch gezien werken ze samen, maar ik zou over het algemeen niet aanraden om beide in te schakelen… Als je beide gebruikt, kan dat ook onnodige wrijving veroorzaken. Een bezoeker zou bijvoorbeeld bij zijn eerste bezoek meerdere beheerde uitdagingen te zien kunnen krijgen in plaats van slechts één.
Toen onze CTO, Daniel Pataki, hier tijdens het webinar live naar werd gevraagd, zei hij het nog eenvoudiger: “Je kunt beide gebruiken, maar er is geen echte reden om dat te doen. Het is veel veiliger om gewoon het een of het ander te gebruiken.” In dit scenario is het nadeel dus wrijving en overbodige uitdagingen voor echte bezoekers, niet een kapotte configuratie.
We raden ook af om naast Kinsta Botbescherming nog een CDN, reverse proxy of WAF voor je site te plaatsen. Dit geldt ook voor je eigen Cloudflare-account als dat actief verkeer doorgeeft met ingeschakelde WAF- of bot-features, en voor andere diensten zoals AWS, Microsoft Azure, Sucuri of Fortinet die als reverse proxy fungeren. Zit er iets anders voor je verkeer dat dit als eerste verwerkt, dan kan Kinsta de echte herkomst van elk verzoek niet meer zien, wat betekent dat de botbescherming niet meer betrouwbaar automatisch verkeer van menselijk verkeer kan onderscheiden.
Gebruik je momenteel je eigen Cloudflare-account met custom bot- of WAF-regels voor een Kinsta-site en weet je niet zeker welke van deze twee situaties op jouw opzet van toepassing is? Neem dan het beste contact op met Kinsta Support voordat je wijzigingen aanbrengt, in plaats van te gissen.
Monitoring: Cloudflare vs. Kinsta
Waar moet je eigenlijk dagelijks je verkeer in de gaten houden? Dat hangt af van wat je zoekt.
Cloudflare biedt je aanzienlijk meer flexibiliteit om dingen te onderzoeken. Je kunt met custom filters dieper ingaan op individuele verzoeken en op vrijwel elk kenmerk van een verzoek zoeken. Maar de botanalyses van Cloudflare zijn gebaseerd op steekproefgegevens, niet op een volledige telling van elk verzoek. Daardoor zijn ze uitstekend geschikt voor het herkennen van patronen en het onderzoeken van incidenten, maar minder betrouwbaar als bron voor exacte verkeerscijfers.
Kinsta daarentegen rapporteert over 100% van de verzoeken die je site bereiken, met geaggregeerde statistieken per uur en per dag in MyKinsta. Dat maakt het de betere bron voor nauwkeurige tellingen en trends op platformniveau, ook al biedt het je niet de ad-hoc, gedetailleerde filtermogelijkheden van Cloudflare.
Heb je dus een diepgaand forensisch onderzoek naar een specifiek incident nodig, dan wint de tooling van Cloudflare. Wil je nauwkeurige, betrouwbare statistieken over wat er in de loop van de tijd daadwerkelijk op je site binnenkomt, dan heeft Kinsta de overhand.
Op welke laag werkt Kinsta Botbescherming?
Kinsta Botbescherming werkt aan de rand, op laag 7 (de applicatielaag), dezelfde laag waar HTTP-verzoeken worden geëvalueerd.
Als zowel de Cloudflare-bescherming van een klant als Kinsta Botbescherming actief zijn op hetzelfde verzoekpad, vindt de verwerking van Cloudflare eerst plaats en wordt de logica van Kinsta daarna uitgevoerd. Dit is nog een reden waarom het zelden iets oplevert om beide te combineren. Tegen de tijd dat een verzoek de logica van Kinsta bereikt, heeft Cloudflare zijn eigen beslissing al genomen.
Welke aanpak moet je kiezen?
De juiste keuze hangt af van hoeveel controle je nodig hebt en hoeveel van het botbeheer je team zelf wil doen.
Gebruik Kinsta Botbescherming als je beheerde WordPress-bescherming wilt
Host je WordPress bij Kinsta en wil je niet dat het tegengaan van bots een terugkerende taak op iemands agenda wordt? Dan is Kinsta Botbescherming de juiste standaardkeuze.
Dat geldt voor de meeste WordPress-sites: bureaus die het verkeer voor tientallen klanten beheren, teams zonder een speciale beveiligingsafdeling, en iedereen die liever tijd besteedt aan het runnen van het bedrijf dan aan het onderhouden van botregels.
Gebruik de geavanceerde bot-tools van Cloudflare als je volledige controle nodig hebt
Cloudflare is wellicht de betere keuze als je gebruikmaakt van de geavanceerdere botcontroles, zoals Super Bot Fight Mode in combinatie met WAF/custom regels, en je de tijd en expertise hebt om die opzet goed te beheren.
Dit is niet hetzelfde als de standaard Cloudflare Bot Fight Mode, die meer lijkt op een algemene aan/uit-regeling. De geavanceerde Cloudflare-aanpak is zinvol als je je verkeer tot in detail kent, specifieke endpoints hebt die anders behandeld moeten worden, en custom gedrag wilt instellen voor bepaalde verzoekpatronen.
Die precisie is er echt, maar er zijn wel doorlopende kosten aan verbonden, omdat het voortdurende aandacht vereist in plaats van een eenmalige configuratie. Zoals Laszlo het verwoordde:
Als je de kennis en de tijd hebt om dit zelf nauwkeurig af te stemmen, is dat waarschijnlijk de betere keuze voor jou. Als je die niet hebt en je je liever op je bedrijf wilt richten in plaats van op de fijne details van verkeersbeheer, is de oplossing van Kinsta de betere optie, omdat die wordt beheerd, speciaal is afgestemd op WordPress en voor je wordt onderhouden.
Gebruik niet beide, tenzij je daar een specifieke reden voor hebt
Kies in de meeste gevallen één primaire laag voor botbescherming:
- Gebruik je Cloudflare Bot Fight Mode of Super Bot Fight Mode op een door Kinsta gehoste site, dan is Kinsta Botbescherming meestal de betere keuze, omdat deze is afgestemd op WordPress en wordt beheerd binnen je hostingplatform.
- Gebruik je Cloudflare Bot Management met een bestaande set custom regels, dan hangt de beslissing meer af van de situatie: van wat die regels doen, hoe ze samenwerken met Kinsta Botbescherming en of ze nog nodig zijn zodra de beheerde bescherming van Kinsta is ingeschakeld. Bespreek deze opzet met Kinsta Support in plaats van af te gaan op een algemeen antwoord.
- Gebruik je je eigen, aparte Cloudflare-account als proxy vóór Kinsta, lees dan het bovenstaande gedeelte. Dit is het enige geval waarin het combineren van beide niet alleen “onnodige wrijving” oplevert, maar er ook actief voor kan zorgen dat de botbescherming niet werkt zoals de bedoeling is.
Bescherming tegen bots wordt een vast onderdeel van WordPress-beheer
Botbescherming is niet langer iets wat site-eigenaren kunnen afdoen als een eenmalige beveiligingsinstelling. Zoals Daniel Pataki tijdens ons webinar uitlegde, zijn bots een tweesnijdend zwaard: ze kunnen problemen veroorzaken op het gebied van prestaties, kosten en analytics, maar ze helpen ook om het web bruikbaar te maken.
Naarmate crawlers, AI-tools, scrapers en geautomatiseerde systemen steeds actiever worden op het web, hebben WordPress-teams een manier nodig om niet-menselijk verkeer te beheren zonder van elke site een project te maken waarbij je voor elke situatie aparte regels moet opstellen. Dat is precies waarvoor Kinsta Botbescherming is ontworpen: een beheerd startpunt met beschermingsniveaus, AI-crawlercontroles, WordPress-specifieke standaardinstellingen en inzicht via MyKinsta.
Wil je er meer over weten? Bekijk dan het webinar ‘Botverkeer Reality Check’, lees het AI & Botverkeer Rapport van Kinsta of schakel Kinsta Botbescherming in via je MyKinsta-dashboard om te zien welk geautomatiseerd verkeer je site daadwerkelijk bezoekt.
