Je webshop deed het altijd prima. En dan, van de ene op de andere dag: pagina’s die seconden op zich laten wachten, klanten die klagen, en af en toe een kale witte pagina met “503 Service Unavailable”. Je hebt níks veranderd — geen update, geen nieuwe plugin. Wat is hier aan de hand?
Grote kans dat het geen mens is die je site plat trekt, maar een bot. Sinds AI-bedrijven en socialmediaplatformen op grote schaal het web afstruinen, is dit een van de vaakst voorkomende oorzaken van plotselinge traagheid — zeker bij webshops. In juni 2026 kwam er zelfs zo’n golf voorbij dat hosters er dagwerk aan hadden.
Wat die 503-fout eigenlijk betekent
Een 503 betekent: de server leeft nog, maar kan je verzoek nú even niet aan. Op shared hosting krijgt jouw pakket een vaste hoeveelheid rekenkracht en geheugen. Zit dat plafond vol — bijvoorbeeld omdat honderden verzoeken tegelijk binnenkomen — dan zet de server nieuwe bezoekers tijdelijk in de wacht of weigert ze met een 503.
Normaal verkeer haalt dat plafond zelden. Een agressieve crawler die duizenden pagina’s per uur opvraagt wél.
Waarom je cache hier niet tegen helpt
“Maar ik heb toch caching?” Terechte vraag. Caching werkt door kant-en-klare kopieën van pagina’s te serveren, zodat de server niet voor elke bezoeker opnieuw hoeft te rekenen. Dat vangt normaal gesproken ook botverkeer prima op.
Het probleem: veel crawlers volgen ook links die de cache omzeilen. De beruchtste bij webshops is de add-to-cart-link. Elke productpagina van een WooCommerce-shop staat vol links in de trant van ?add-to-cart=123. Voor een cache is elke variant een unieke, niet te cachen pagina — er wordt immers iets in een winkelwagen gelegd, dus de server móet aan het werk: PHP starten, database raadplegen, een sessie aanmaken.
Eén bot die systematisch al je producten “in zijn winkelwagen legt”, zet dus honderden zware processen in gang. Resultaat: je rekenplafond zit vol, echte klanten krijgen een trage site of een 503 — en je cache-plugin heeft niets kunnen doen.
Zo herken je de dader in je logboek
Elke bezoeker laat een regel achter in het toegangslogboek (access log) van je site. Dat vind je in je hostingpaneel, vaak onder “Logs” of “Site Summary / Statistics / Logs”. Zoek naar deze signalen:
- Heel veel regels vlak achter elkaar met dezelfde “user-agent” (de naam waarmee een browser of bot zich meldt, achteraan de logregel).
- Botnamen in die user-agent. Veelvoorkomende zelfverklaarde crawlers:
GPTBot,ClaudeBot,PerplexityBot,Bytespider,Amazonbot,meta-externalagent. Naast de AI-nieuwkomers zie je ook de klassiekers alsGooglebotenbingbot— die gedragen zich doorgaans netjes. - Verdachte URL-patronen: honderden verzoeken met
?add-to-cart=,?filter=of eindeloze combinaties van filterparameters die geen mens ooit zou aanklikken.
Zie je zo’n patroon rond het tijdstip van je traagheid of 503’s, dan heb je je dader.
Wat je eraan doet
Stap 1: vraag het netjes via robots.txt
Nette bots respecteren het robots.txt-bestand in de hoofdmap van je site. Twee dingen die je daar regelt: verbied de cache-omzeilende URL’s voor iedereen, en weer desgewenst specifieke bots helemaal:
User-agent: *
Disallow: /*?add-to-cart=
Disallow: /*?filter=
User-agent: Bytespider
Disallow: /Bedenk wel: robots.txt is een verzoek, geen slot. De grote namen (Googlebot, GPTBot, ClaudeBot) houden zich eraan; brutale crawlers negeren het.
Stap 2: blokkeer de hardleerse bots op de server
Bots die robots.txt negeren, weer je op serverniveau — dan komen ze de deur niet meer door. Dat kan met een user-agent-blokkade in je .htaccess, maar hier wordt het al snel specialistisch: één typfout en je site doet het niet meer, en botnamen veranderen bovendien regelmatig. Dit is typisch iets om je hoster te laten doen — die kan het vaak in één keer voor de hele server regelen en houdt de lijst bij.
Stap 3: overweeg een uitsmijter vóór je site
Een dienst als Cloudflare zet een filter vóór je website dat bekend botverkeer herkent en tegenhoudt vóórdat het je server bereikt. Voor webshops die structureel last houden is dat de duurzaamste oplossing. Hoe je dat gratis opzet, lees je in Cloudflare gratis voor je site instellen.
Wat je beter niet doet
- Nóg een cache-plugin installeren. Het probleem zit juist in verkeer dat niet te cachen is; een tweede plugin maakt het alleen maar complexer.
- Alle bots blokkeren. Googlebot en bingbot buitensluiten betekent: verdwijnen uit de zoekresultaten. Blokkeer gericht, niet alles.
- Paniekerig een zwaarder hostingpakket nemen. Meer rekenkracht verhoogt alleen het plafond; een agressieve bot vult ook dat weer. Eerst de oorzaak aanpakken.
Samengevat
- Plotselinge traagheid of 503’s zonder dat je iets veranderde? Denk aan botverkeer.
- AI- en social-crawlers omzeilen je cache via add-to-cart- en filterlinks; daarom helpt caching hier niet.
- Kijk in je access log naar user-agents en URL-patronen om de dader te vinden.
- Weer nette bots via robots.txt; hardleerse bots blokkeer je op serverniveau of met Cloudflare.
- Blokkeer nooit blind alle bots — je zoekmachineverkeer heb je nodig.
Wanneer schakel je hulp in?
Voel je je niet thuis in logbestanden en .htaccess-regels? Dit is bij uitstek een klus voor je hoster: die ziet het serverbrede beeld, herkent de actuele botgolven en kan een blokkade veilig doorvoeren. Bij een beheerde omgeving (bijvoorbeeld bij KeurigOnline) is zo’n botblokkade vaak al voor je geregeld — één telefoontje en je weet of jouw traagheid door een bot komt of dat er meer aan de hand is.