In het afgelopen jaar is botverkeer verschoven van iets dat site-eigenaren konden negeren naar iets dat direct invloed heeft op hoe je infrastructuur zich gedraagt. Die verandering draait niet alleen om volume. Het gaat om de manier waarop geautomatiseerd verkeer omgaat met moderne websites, en met WooCommerce winkels in het bijzonder.
Op het eerste gezicht lijkt een verzoek simpelweg een verzoek. Maar niet alle verzoeken zijn gelijk, en WooCommerce maakt dat verschil alleen maar duidelijker.
In dit artikel lees je waarom WooCommerce sites gevoeliger zijn voor botverkeer, wat er onder de motorkap gebeurt wanneer bots belangrijke endpoints raken, en waarom algemene aannames over verkeer en prestaties niet opgaan in de context van e-commerce.
Waarom WooCommerce van elk verzoek werk maakt
Op een typische WordPress site worden de meeste pagina’s aan de edge gecachet op een CDN zoals Cloudflare, zodat verzoeken worden afgehandeld zonder de origin server aan te spreken. Zelfs bij grotere volumes blijven de kosten relatief laag, omdat het systeem is geoptimaliseerd om de gecachete uitvoer te hergebruiken.
WooCommerce werkt anders. Een groot deel van de verzoeken hangt af van realtime gegevens en gebruikersspecifieke context en kan niet uit de cache worden geleverd. Elk verzoek moet op de origin server volledig opnieuw worden verwerkt. Dat houdt onder meer in:
- PHP uitvoeren om de logica van het verzoek te verwerken
- De database raadplegen voor product-, prijs- of sessiegegevens
- Het antwoord dynamisch opbouwen voordat het wordt teruggestuurd
PHP uitvoeren voor elk verzoek bezet een PHP thread zolang het proces duurt, en het aantal beschikbare threads per site is beperkt. Zijn ze allemaal in gebruik, dan moeten nieuwe verzoeken wachten. Het kan ook gebeuren dat je site steeds opnieuw tegen de limiet van PHP threads aanloopt.
Tegelijkertijd wordt de database geraadpleegd voor gegevens en sessie-informatie. Op de achtergrond vindt ook sessieafhandeling plaats.
Zelfs voordat je botgedrag meerekent, is duidelijk dat verzoeken op WooCommerce sites inherent duur zijn. Zodra geautomatiseerd verkeer in beeld komt, lopen die kosten verder op.
Waar bots de meeste schade aanrichten op WooCommerce sites
De impact van botverkeer op WooCommerce sites concentreert zich meestal op een klein aantal endpoints die zijn ontworpen voor interactie met echte gebruikers.
Dit zijn de onderdelen van de site waar verzoeken het duurst zijn en zich het minst laten cachen:
- Endpoints voor winkelwagen en checkout (
/cart,/checkout,?add-to-cart=) - Zoekopdrachten
- Gefilterde en op parameters gebaseerde productpagina’s
- AJAX-gestuurde interacties en dynamische componenten
Ze gedragen zich allemaal anders, maar elk verzoek leidt tot echte verwerking op de server.
Cart- en checkout-endpoints zijn de duidelijkste voorbeelden. Een verzoek aan /cart of iets met ?add-to-cart= activeert applicatielogica om de sessie te valideren, de status van de winkelwagen bij te werken, productgegevens op te halen en een specifiek antwoord voor te bereiden. Gebeurt dit herhaaldelijk en op grote schaal, dan verbruikt het al snel resources.
In ons onlangs gepubliceerde rapport “AI & Botverkeer Realitycheck” ontdekte ons engineeringteam dat in 24 uur tijd meer dan zeven miljoen botverzoeken add-to-cart-URL’s op de Kinsta-infrastructuur raakten.
Om die getallen in perspectief te plaatsen: 3,75 miljoen verzoeken in 24 uur van ClaudeBot komt neer op ongeveer één verzoek elke 23 milliseconden, dag en nacht, waarbij elk verzoek als een nieuw verzoek wordt behandeld.
Naast de endpoints voor winkelwagen en checkout zorgen zoeken en filteren voor een ander soort druk. In WooCommerce winkels kunnen gebruikers producten vaak filteren op kenmerken als prijs, categorie, maat of beschikbaarheid. Elke combinatie levert een net iets andere URL op, en vanuit het perspectief van een crawler is elke variatie het onderzoeken waard.
In ons rapport zagen we dat de meta-externalagent (de AI-crawler van Facebook/Meta) dagenlang vastzat op WooCommerce vergelijkingspagina’s en afdwaalde naar betekenisloze variaties op kalenderpagina’s.
Dit gebeurt omdat crawlers de context niet begrijpen. De crawler volgt de eerste variatie, vindt dan weer een net iets andere versie, dan nog een, en blijft zo zijn pad uitbreiden. Op geen enkel moment heeft hij door dat hij in feite steeds dezelfde pagina bezoekt.
Op WooCommerce sites wordt dit extra problematisch, omdat veel van die variaties gekoppeld zijn aan dynamische functionaliteit.
Waarom botverkeer er niet uitziet als een aanval (maar zich wel zo gedraagt)
Een van de redenen waarom dit probleem gemakkelijk over het hoofd wordt gezien, is dat het niet op een kwaadaardige aanval lijkt.
Bij een kwaadaardige aanval zie je pieken vanuit één bron, met duidelijke tekenen van misbruik en mogelijk schadelijke payloads. Bij botverkeer zien de verzoeken er juist normaal uit: ze volgen de sitestructuur, gaan naar geldige URL’s en krijgen geldige antwoorden terug.
Van buitenaf lijkt het vaak op legitieme crawlactiviteit, maar het systeem beoordeelt de intentie niet. Het verwerkt alleen verzoeken.
Wanneer inefficiënte of zich slecht gedragende crawlers op grote schaal actief zijn, ontstaan er patronen die op misbruik lijken, ook al was dat nooit de bedoeling. Herhaalde verzoeken, loops en hoogfrequente toegang tot dynamische endpoints vertalen zich allemaal naar een aanhoudende belasting van de server.
Daarom wordt het onderscheid tussen “goede” en “slechte” bots in de praktijk minder bruikbaar.
Een crawler kan legitiem zijn en tóch verkeerspatronen veroorzaken die ten koste gaan van de prestaties. Het gaat er niet alleen om wie het verzoek doet, maar ook om waartoe dat verzoek het systeem dwingt.
Wat dit betekent voor de prestaties van WooCommerce
Als dit soort verkeer toeneemt, worden de effecten gemakkelijk verkeerd toegeschreven.
- Pagina’s laden langzamer, vooral tijdens piekmomenten
- Het afrekenen voelt traag of inconsistent aan
- In sommige gevallen belanden verzoeken in een wachtrij, omdat PHP-workers vastzitten in het afhandelen van herhaalde, geautomatiseerde interacties
Aan de buitenkant lijkt het een prestatieprobleem, maar de onderliggende oorzaak is vaak aanhoudende druk van geautomatiseerd verkeer dat niet-gecachete endpoints raakt.
Dit beïnvloedt ook hoe verkeer wordt geïnterpreteerd. Grote hoeveelheden geautomatiseerde verzoeken kunnen het aantal bezoeken opdrijven zonder dat ze bijdragen aan de werkelijke gebruikersactiviteit. Een piek in verkeer hoeft niet samen te vallen met meer betrokkenheid, conversies of omzet. Zonder inzicht in wat dat verkeer veroorzaakt, wordt het lastig om de echte vraag te scheiden van de geautomatiseerde belasting.
Op schaal wordt dit zowel een prestatie- als een besluitvormingsprobleem.
Waarom bots blokkeren geen volledige oplossing is
Als je nog niet bekend bent met botverkeer, is je natuurlijke reactie op dit gedrag om het te blokkeren. In sommige gevallen werkt dat. Maar meestal levert het nieuwe afwegingen op.
De waarheid is dat niet al het geautomatiseerde verkeer schadelijk is. Crawlers van zoekmachines zijn essentieel voor je zichtbaarheid. AI-crawlers spelen een rol in hoe content wordt weergegeven door AI-agenten, wat tegenwoordig GEO & AEO-praktijken wordt genoemd.
Alles blokkeren neemt het verkeersprobleem weg, maar ook de voordelen. Alles toestaan voorkomt verstoring, maar stelt het systeem bloot aan onnodige belasting.
De uitdaging is dat WooCommerce sites niet één regel nodig hebben voor al het verkeer. Ze hebben verschillend gedrag nodig, afhankelijk van waar het verzoek naartoe gaat en waar het verkeer vandaan komt.
Een praktischere manier om over botverkeer na te denken
In plaats van je af te vragen of bots moeten worden toegestaan of geblokkeerd, is dit de nuttigere vraag: welke soorten verkeer moeten toegang krijgen tot welke delen van de site?
Endpoints voor winkelwagen en checkout hoeven helemaal niet toegankelijk te zijn voor crawlers. Zoek- en filterpagina’s kun je beperken zonder de kernfunctionaliteit aan te tasten. Product- en categoriepagina’s moeten ondertussen wél toegankelijk blijven voor zoekmachines.
Juist dit soort scheiding maakt botverkeer beheersbaar.
In onze analyse van meer dan 10 miljard verzoeken op de door Kinsta beheerde infrastructuur komen deze patronen telkens terug op echte WooCommerce sites. Wil je de volledige dataset onderzoeken en zien hoe deze patronen zich op verschillende typen sites ontwikkelen? Dan vind je meer details in het AI & Botverkeer Rapport.
Tegelijkertijd is dit handmatig beheren zelden praktisch. Het vraagt om aanpassingen van tijd tot tijd, duidelijk inzicht in verkeerspatronen en een manier om beslissingen door te voeren zonder legitiem gebruik te verstoren. Dit is precies het gat dat de Botbescherming feature van Kinsta moet dichten: site-eigenaren krijgen er de mogelijkheid mee om te bepalen hoe verschillende soorten verkeer worden afgehandeld, zonder te vertrouwen op uniforme regels.
Bekijk gerust onze documentatie en neem contact op met support als je meer uitleg wilt over hoe dit voor jouw site of bureau kan werken.
