Waarom je webscraper steeds stuk gaat

De meeste bedrijven die concurrentiedata scrapen, hebben al een oplossing draaien, zoals een zelfgebouwde scraper of een betaalde tool. Het probleem is niet dat scraping niet werkt, maar dat het meer tijd, geld en gedoe kost dan het zou moeten, en dat de data niet betrouwbaar genoeg is om prijs- of assortimentsbeslissingen op te baseren.

Het verschil tussen "het werkt" en "het werkt betrouwbaar, tegen voorspelbare kosten, zonder dat iemand er wakker van ligt" verklaart waarom teams die een half jaar geleden nog een prima werkende scraper hadden, nu met een stapel uitdagingen zitten.

Waarom gaat een scraper die het altijd goed deed, stilletjes stuk?

Een webscraper die crasht en een duidelijke foutmelding geeft, is zeldzaam. Veel vaker blijft de scraper gewoon draaien, geeft netjes HTTP 200 terug, en levert stilletjes verkeerde of onvolledige data omdat de onderliggende website is veranderd.

Dit fenomeen heet selector drift: een scraper vindt data via CSS-selectors of XPath die vastzitten aan één specifieke versie van de HTML van een website. Verandert die website (bijvoorbeeld een nieuwe klassennaam, een herschikte tabel, of een verplaatst veld) dan matchen de selectors niet meer. Selector drift is de belangrijkste reden waarom scrapers na verloop van tijd achteruitgaan: één kleine wijziging aan de kant van de doelsite kan een prijsveld uit de feed halen zonder dat er een alarm afgaat.

Dat verklaart ook waarom "we hebben een scraper gebouwd en hij werkt" weinig zegt over de toekomst: een scraper wordt gebouwd tegen een momentopname van een website, en elke herontwerp, A/B-test of framework-migratie aan de kant van die website creëert een nieuwe situatie waar de scraper niet op voorbereid is.

Waarom worden ook zorgvuldig gebouwde scrapers steeds vaker tegengehouden door anti-botsystemen?

Naast selector drift spelen anti-botsystemen een steeds grotere rol: sites maken het bewust lastiger om geautomatiseerd data te verzamelen, niet omdat ze een specifieke partij willen tegenhouden, maar omdat botverkeer in het algemeen zoveel geld kost dat vrijwel elk e-commerce- en retailplatform inmiddels een eigen botmanagementsysteem draait.

Waar simpele IP-gebaseerde rate limiting vroeger volstond, combineren moderne botmanagementsystemen tientallen signalen tot één doorlopende vertrouwensscore: hoe een verbinding TLS opzet, hoe HTTP-requests eruitzien, wat een browser via JavaScript prijsgeeft, en hoe muisbewegingen en scrollgedrag zich verhouden tot een echt mens. Partijen als Cloudflare, Akamai, DataDome en HUMAN (voorheen PerimeterX) wegen deze signalen elk anders, en trainen hun detectiemodel soms zelfs per klant — waardoor een aanpak die op de ene beveiligde site werkt, op een andere volledig kan falen.

Dit betekent niet dat scraping onmogelijk is geworden, maar wel dat het een vak apart is geworden met voortdurend veranderende spelregels: wat vandaag werkt, kan morgen stuk zijn omdat een leverancier een update pusht, en een aanpak die perfect werkt op de ene site, kan volledig falen op een andere omdat de detectielogica anders in elkaar zit.

Waarom wordt scraping duurder, terwijl proxy's juist goedkoper worden?

Scraping wordt voor veel teams duurder, ondanks dat de basisprijs van proxy's al jaren daalt door toenemende concurrentie tussen aanbieders. De daadwerkelijke proxykosten stijgen namelijk niet doordat een request duurder wordt, maar doordat de mix van gebruikte proxy's verandert.

Naarmate teams meer monitoren en doelsites zich beter wapenen, kan een steeds groter deel van de requests niet meer via goedkope datacenter-IP's verlopen en zijn residentiële of mobiele IP's nodig, die per geslaagde request aanzienlijk meer kosten. Op enige schaal kan dit dure proxyvolume uiteindelijk meer kosten dan wat een gespecialiseerde scrapingpartij voor dezelfde data zou rekenen, zeker als de uren worden meegerekend die engineers kwijt zijn aan het uitzoeken van blokkades en het wisselen van providers.

De echte, verborgen kostenpost zit in het handmatige werk eromheen: elke geblokkeerde request die uitgezocht moet worden, elke providerwissel omdat een IP-pool "verbrand" is, en elke noodreparatie na een site-update. Deze tijd staat nergens als aparte begrotingspost, waardoor scraping duurder aanvoelt dan het zou moeten zijn zonder dat er een concreet bedrag op te plakken is.

Wat heb je nodig voor een betrouwbare opzet?

Een betrouwbare scrapingopzet vraagt niet om een slimmere eenmalige build, maar om een werkwijze die ervan uitgaat dat dingen kapot gaan en die daar snel en goedkoop op reageert. Dat bestaat uit de volgende bouwstenen:

• Controleer de inhoud van een extractie, niet alleen de statuscode van de request. Een pagina kan keurig HTTP 200 teruggeven terwijl de inhoud eronder allang is veranderd. Toets daarom elke extractie tegen een schema: velden die leeg, ontbrekend of onwaarschijnlijk zijn, worden geweigerd. Signaleer daarnaast opvallende schommelingen in het aantal records of in waardes. Dat vangt zowel selector drift als verlopen challenge-pagina's op, twee problemen die een statuscode-check zelf niet detecteert.
• Gebruik canary-checks om structurele wijzigingen vroeg te signaleren. Een canary-check herhaalt periodiek de scrape van een klein, vast setje referentiepagina's en vergelijkt het resultaat met een opgeslagen baseline. Zo wordt een structurele wijziging aan de doelsite zichtbaar voordat die de hele dataset heeft besmet.
• Herken velden op betekenis, niet op positie. Een scraper die vastzit aan één CSS-selector is per definitie kwetsbaar voor lay-outwijzigingen. Een veld herkennen aan omliggende tekst, relatieve positie of een herkenbaar patroon overleeft veel meer wijzigingen aan de doelsite dan een vaste selector.
• Bouw een automatisch reparatiepad met een mens als vangnet. Een model kan een nieuwe selector voorstellen zodra de oude niet meer matcht, en die kandidaat eerst testen in een sandbox tegen live HTML. Gevallen die geen enkele kandidaat succesvol valideert (zoals een pagina die in werkelijkheid een lege JavaScript-shell blijkt) horen bij een mens terecht te komen, niet bij eindeloos automatisch gokken.
• Prioriteer meldingen op daadwerkelijke impact, niet op elke afwijking. Niet elk probleem verdient een melding om 3 uur 's nachts: een tijdelijke piek in retries kan op een dashboard blijven staan, terwijl een aanhoudend gat in data die live prijsbeslissingen voedt direct iemand moet alarmeren. Dit onderscheid bepaalt of een monitoringsysteem gebruikt blijft worden of na een paar weken genegeerd wordt.
• Beheer het proxybudget actief in plaats van het als vaste kostenpost te behandelen. Standaard overal zware, dure proxy's en browserautomatisering inzetten verspilt geld op sites die dat niet nodig hebben, en is op de lastigste sites nog steeds onvoldoende. Een escalatiemodel (goedkoop en simpel als uitgangspunt, alleen opschalen waar een site dat daadwerkelijk afdwingt) houdt de kosten in verhouding tot het risico.
• Spreid het proxyverkeer over meerdere providers. Geen enkel proxynetwerk presteert op elke site even goed, en een storing of ban bij één provider mag nooit de volledige monitoring platleggen.

Zelf bouwen, een tool kopen, of uitbesteden?

Een betrouwbare scrapingopzet zelf bouwen is mogelijk, genoeg sterke techteams doen dit. De vraag is wat het kost om dit vol te houden: een validatie- en monitoringlaag, een geautomatiseerd reparatiepad met de juiste vangnetten, een proxystrategie die meebeweegt met steeds slimmere verdediging, en iemand die dit blijvend eigenaarschap geeft. Dit is geen project met een einddatum, maar een permanente operationele verantwoordelijkheid.

Een scraping-API of SaaS-tool lost slechts een deel van dit probleem op: het levert infrastructuur en ruwe extractie, maar de gebruiker blijft zelf verantwoordelijk voor wat er precies wordt geëxtraheerd, of dat klopt voor de eigen use case, en voor de lastige sites waar de generieke aanpak van de tool op vastloopt. Het verkleint het probleem, maar lost het niet op.

Wat het probleem wél wegneemt, is een team dat hier fulltime mee bezig is: drift signaleren, escalatielogica onderhouden, de proxymix per site afstemmen, en de kosten van elke site-redesign of nieuwe anti-botmaatregel absorberen als onderdeel van een doorlopende managed service. Dit is fundamenteel iets anders dan het draaien van een tool, en verklaart waarom organisaties die op schaal betrouwbare concurrentiedata nodig hebben, scraping steeds vaker uitbesteden.

Bij Competify is scraping het dagelijkse werk: scrapers die gebouwd, gemonitord en gerepareerd worden als onderdeel van een abonnement, met kosten die beheersbaar blijven dankzij de gelaagde aanpak hierboven. Herken je deze situatie in je eigen organisatie? Neem gerust contact op voor een vrijblijvende afspraak.