20 procent van alle webreacties met ‘OK’ die AI ontvangt, is niet oké

Mijn recente experimenten met AI-ondersteund webscrapen hebben me duidelijk gemaakt hoe snel het web steeds verder wordt afgesloten. De aanleiding voor deze terugtrekkende beweging is natuurlijk de schokkende groei van AI-webscraping, waarvan de onverzadigbare behoefte aan nieuwe gegevens ertoe kan leiden dat domeinen offline gaan.

Dit is een goede aanleiding voor domeinen om te doen wat veel ervan al lange tijd willen: hun content alleen toegankelijk maken voor gebruikers die zijn ingelogd (hoewel Googlebot doorgaans vrij spel krijgt). Facebook rondde de geleidelijke invoering van dit beleid af in 2023, en Twitter/X deed hetzelfde in datzelfde jaar. Reddit voert het later deze maand in.

Zo wordt het voor het domein iets eenvoudiger om te voldoen aan de landspecifieke handhaving van leeftijdsbeperkingen, omdat de gebruiker al geregistreerd is. Belangrijker nog: de gegevens van de gebruiker kunnen worden opgeslagen, worden benut voor lokale analyses en – voor zover de lokale wetgeving dat toestaat – worden verkocht aan databrokers en AI-bedrijven.

Elders zijn maatregelen die specifiek gericht zijn op de bestrijding van bots (in plaats van het registreren van gebruikers) met meer dan 58% op jaarbasis toegenomen, volgens Cloudflare. Al die toenemende botactiviteit moedigt websites vanzelfsprekend aan om kritisch te controleren wie er achter VPN- en proxyadressen zit, waardoor legitieme gebruikers mogelijk net als al het ‘kwaadaardige’ verkeer de toegang wordt ontzegd.

Anekdotisch gezien lijkt het erop dat ik steeds vaker te maken krijg met ‘blokkeer’-reacties of -uitdagingen, zozeer zelfs dat ik een website die daarmee begint misschien al verlaat. En omdat is gebleken dat CAPTCHA-muren gebruikers en potentiële klanten afschrikken, kun je je voorstellen onder welke druk domeineigenaren staan om ze ondanks dat nadeel toch in te voeren.

Een captcha van archive.is, een van de vele websites die uitdagingen inzetten, vaak als reactie op een buitensporig aantal geautomatiseerde (in plaats van menselijke) verzoeken.

Al deze nieuwe en toegenomen drempels zijn deels van logistieke aard (omdat niet alle domeinen de stortvloed aankunnen), maar vormen ook vaak een soort onderhandelingstactiek: kijken of AI-bedrijven een individuele of collectieve vergoeding willen bieden voor al die gegevens waar ze zo naar hunkeren en die tot nu toe, en jarenlang, gratis waren.

Omdat AI-crawlers op grote schaal moeten werken, gebruiken ze doorgaans ‘headless’ instanties van Chrome binnen het Playwright-framework. Tegenwoordig levert dat voor een steeds groter aantal domeinen een foutmelding 403 (‘verboden’) op (oftewel: de host weet dat je geautomatiseerd verkeer bent en zegt dat je moet oprotten):

Een lokale installatie van changedetection.io probeert een website te bevragen, maar de website accepteert de browser die het framework gebruikt en die als zodanig is herkend niet. De website geeft daarom een 403-reactie (‘Verboden’) terug.

Wat je wilt, is de clientreactie ‘200’ (‘OK’), zelfs als je daarvoor een flinke som geld moet neertellen aan een netwerk van residentiële proxyservers, in combinatie met allerlei andere slinkse trucs om je als niet-menselijk verkeer voor te doen.

Er is niets beter dan de 200-reactie; met andere woorden, er bestaat geen clientreactiecode met een sterker positief signaal. Het is ook geen dubbelzinnige reactie: het is nooit ‘bijna in orde’, ‘komt later wel goed’ of ‘steeds meer in orde’; het is ‘in orde!’. Als het niet in orde is, is het geen 200-reactie.

Hallo! Wegwezen

Toch kan dit gebrek aan nuance volgens een nieuw artikel de datasets en statistische schattingen van AI aanzienlijk vertekenen en ten onrechte een ‘goede’ status rapporteren.

De studie* schat dat ongeveer een vijfde van de reacties in de 200-categorie helemaal geen bruikbare pagina-inhoud bevat, maar in plaats daarvan lege websiteskeletten, CAPTCHA-uitdagingen, toegangsbeperkingen of vervangende pagina’s laat zien.

In het artikel staat:

‘20,9% van de pagina’s die een statische client met status 200 ontvangt, bevat niet de hoofdinhoud van de pagina: app-skeletten, botuitdagingen, blokkeringspagina’s, fout- en placeholderpagina’s en gedeeltelijke inhoud.’

Hierdoor lopen ongeduldige geautomatiseerde systemen vast door hun eigen schaarse mogelijkheden: de ‘200’-reactie mag immers worden opgevat als een geslaagde ophaalactie, zelfs wanneer die alleen een CAPTCHA-muur, een betaalmuur of een ander obstakel oplevert.

Het artikel beschrijft de zeven soorten inhoud die een 200-reactie vaak bemoeilijken:

De zeven categorieën inhoud die in een 200-reactie allesbehalve ‘in orde’ zijn. Bron

Voor het onderzoek werden gedurende drie dagen 10.307 webadressen getest met zowel een eenvoudig programma voor het ophalen van webpagina’s als een browser die JavaScript kon laden. De reacties werden geclassificeerd op basis van de opgehaalde inhoud, en niet op basis van hun HTTP-statuscodes.

De grootste categorieën ‘onbruikbare’ 202-responsen waren lege websiteskeletten en fout- of vervangende pagina’s; samen waren die goed voor meer dan twee derde van de mislukte verzoeken.

Bij lege websiteskeletten kan een website de menu’s en navigatie tonen, maar het opgevraagde artikel of productoverzicht leeg laten. In het laatste geval kan in plaats van de gevraagde inhoud een niet-gerelateerde pagina of de startpagina verschijnen. Toch kunnen beide dezelfde HTTP-status 200 krijgen als een geslaagde ophaling die bruikbare en nuttige inhoud oplevert.

Als oplossing beveelt het artikel aan dat tools voor het ophalen van webpagina’s rapporteren wat er daadwerkelijk is opgehaald, in plaats van af te gaan op HTTP-statuscodes. Eenvoudige controles op ongebruikelijk korte pagina’s, verdachte omleidingen en inhoud die lijkt op pagina’s die niet bestaan, zouden namelijk de meeste fouten kunnen opsporen.

Browsertools die meer middelen vergen, kunnen vervolgens alleen worden ingezet wanneer een pagina niet goed lijkt te zijn geladen. Daarnaast kunnen AI-evaluaties controleren of geciteerde bronnen daadwerkelijk de verwachte informatie bevatten, in plaats van ervan uit te gaan dat een HTTP 200-respons betekent dat de inhoud succesvol is opgehaald.

De auteur van het nieuwe onderzoek merkt ook op dat ‘goedkope heuristieken’ met eenvoudige controles op paginalengte, omleidingen en overeenkomsten met pagina’s die niet bestaan, gemakkelijk ongeveer 86% van de onbruikbare responsen kunnen herkennen:

Vergelijking van strategieën voor het ophalen van webpagina’s: door alleen pagina’s te renderen die als verdacht waren aangemerkt, werd iets meer bruikbare inhoud teruggevonden (81,4%) dan door elke pagina te renderen (80,3%). Tegelijkertijd daalde de gemiddelde ophaaltijd van 20,6 naar 5,8 seconden per pagina. 

Waarom zijn er zoveel foutieve 200-responsen?

In ontwikkelaarsgemeenschappen is door de jaren heen enige discussie geweest over de vraag of de 202-fout (‘geaccepteerd’) (‘Verzoek geaccepteerd, maar nog niet voltooid’) deze ‘mislukte’ verzoeken met status 200 zou kunnen onderscheiden. Maar 202 kan niet alle gevallen uit het nieuwe artikel ondervangen, en er bestaat geen bestaande code die dat wel kan.

Hoewel het artikel hier niet diep op ingaat, is de reden waarom domeineigenaren 200-fouten toestaan mogelijk een onderwerp dat in toekomstig verwant onderzoek nader kan worden onderzocht.

Een reden kan zijn dat alles wat geen 200-status heeft in feite een soort foutpagina of belemmering is, waaronder de meest voorkomende: 404-fouten (‘niet gevonden’) — waarbij de gezochte inhoud simpelweg ontbreekt. Sommige gebruikers denken dat een overmaat aan zulke fouten tot SEO-sancties leidt (en vermoedelijk ook tot sancties voor GEO), maar Google ontkent dit.

Google beschouwt foutieve 200-responsen zelfs als ‘soft 404’s’. Ze worden waarschijnlijk eerder als een probleem gezien dan gewone 404-fouten, omdat het in wezen om misleidende uitkomsten gaat, al dan niet opzettelijk.

Citatiedrift

Als dit allemaal muggenzifterij lijkt, bedenk dan dat er routinematig gegevens op petabyteschaal worden verzameld (of geprobeerd te verzamelen) voor het trainen van AI. Als een volledig vijfde van die gegevens onbetrouwbaar of ronduit misleidend is, zijn de gevolgen verderop in de keten moeilijk af te doen als een soort ‘bijkomende onnauwkeurigheid’. Zulke foutieve responsen kunnen de verdeling van gegevens in datasets en de resultaten van het trainen van AI-modellen met die gegevens namelijk aanzienlijk en nadelig beïnvloeden.

Een opmerkelijk probleem rond foutieve 200-responsen is bijvoorbeeld ‘citatiedrift’: een door AI gegenereerd antwoord wordt dan niet langer ondersteund door de webpagina die oorspronkelijk als bewijs werd aangehaald. De pagina kan bijvoorbeeld zijn gewijzigd, de relevante tekst kan zijn verwijderd of de link kan inmiddels ergens anders naartoe leiden.

Uit het nieuwe onderzoek bleek dat schijnbare citatiedrift toenam van 5,8% naar 21,9% wanneer alle HTTP 200-responsen als succesvolle ophalingen werden beschouwd, ongeacht wat ze bevatten.

Dit betekent dat ten onrechte kan worden geconcludeerd dat een bron is gewijzigd, verdwenen of niet langer een door AI gegenereerde bewering ondersteunt, simpelweg omdat er in plaats van het oorspronkelijke materiaal een CAPTCHA, een lege pagina of een andere belemmering was opgehaald.

Zeg gewoon dat het zo is!

Het probleem bleek ook uit tests met opzettelijk niet-bestaande webadressen. Wanneer websites werden benaderd via willekeurige, verzonnen paden, gaf 13,1% van de websites die antwoordden een status 200 (‘OK’) terug, hoewel de opgevraagde pagina’s niet bestonden^†.

‘13,1% van de websites die antwoord gaven op de test met willekeurige paden, retourneerde status 200 (S1 10,5%, S2 13,3%, S3 17,3%, S4 13,7%, S5 13,1%). Elke dergelijke respons is per definitie een soft 404, maar niet elke respons vermeldt dat ook.’

‘Bij een verkennende analyse van de 172 soft-404-responsen bestempelde de annotator er 98 als een fout- of vervangingspagina, 32 als een omhulsel en 28 als inhoud: een startpagina of overzichtspagina die op een willekeurig pad wordt weergegeven, ziet eruit als een gewone pagina.’

Conclusie

Als het probleem op een hoger niveau werd onderkend, zou de IANA wellicht een nieuwe en toepasselijkere HTTP-statuscode kunnen invoeren, zoals [X] (‘Verzoek geslaagd, maar de gevraagde inhoud is niet geleverd’). Hoewel deze code nauwkeurig zou beschrijven wat er gebeurt, zou daarvoor aan de kant van de host wel een onwaarschijnlijk groot inzicht in de transactie nodig zijn.

Er bestaan al vergelijkbare codes, maar geen daarvan past echt: 451 (‘Niet beschikbaar om juridische redenen’) is dubbelzinnig en nogal alarmerend (!); 206 (‘Gedeeltelijke inhoud’) is technisch gezien passend, maar bedoeld voor onvolledige gegevens (opvragingen); en de verrassend genoeg bestaande code 203 (‘Niet-gezaghebbende informatie’), die in 1997 werd ingevoerd, staat slechts zijdelings in verband met de usecase in kwestie.

Misschien is de code met de onintuïtieve naam 103 (‘Vroege hints’) eigenlijk de beste kandidaat. Deze geeft aan dat nog niet alle bronnen van de URL zijn geladen (al zou dat duidelijk een grove verkeerde interpretatie zijn van de bedoeling van de code).

* Getiteld ‘Wanneer 200 OK geen antwoord is: stille mislukte ophaalverzoeken bij het agentische verzamelen van webinhoud.‘ Houd er rekening mee dat het artikel kennelijk vooral is geschreven om door machines te worden gelezen, mogelijk om door AI te worden geraadpleegd, en op zichzelf niet gemakkelijk te lezen is.

^† Mijn excuses voor het mechanisch klinkende citaat, maar zoals ik hierboven al opmerk, is het hele artikel op deze manier geschreven om ‘machinaal leesbaar’ te zijn in plaats van begrijpelijk voor mensen, al wordt het niet in JSON-formaat gepresenteerd.

Voor het eerst gepubliceerd op woensdag 4 november 2026