20 prosent av alle «OK»-svar AI får fra nettet, er ikke OK

Mine nylige eksperimenter med AI-assistert nettskraping har gjort det tydelig for meg i hvor stor grad nettet blir «låst ned». Den utløsende årsaken til denne innstrammingen er naturligvis den eksplosive veksten innen AI-basert nettskraping, der den ubønnhørlige etterspørselen etter nye data kan ende med å sette nettsteder ut av spill.

Dette er en god anledning for nettsteder til å gjøre det mange av dem lenge har ønsket: å gjøre innholdet tilgjengelig bare når brukeren er logget inn (selv om Googlebot vanligvis slipper gjennom uten hinder). Facebook fullførte den gradvise innføringen av denne praksisen i 2023, og Twitter/X gjorde det samme samme år. Reddit innfører den senere denne måneden.

På denne måten blir det litt enklere for nettstedet å etterleve landsspesifikke krav til håndheving av aldersgrenser, siden brukeren allerede er registrert. Enda viktigere er det at brukerens data kan lagres, utnyttes til lokal analyse og – dersom lokal lovgivning tillater det – selges til datameglere og AI-selskaper.

Andre steder har tiltak som uttrykkelig er rettet mot å beskytte mot boter (i stedet for å registrere brukere), økt med mer enn 58 % fra året før, ifølge Cloudflare. Denne økende botaktiviteten får naturligvis nettsteder til å granske VPN- og proxyadresser, noe som potensielt kan nekte legitime brukere tilgang sammen med all «ondsinnet» trafikk.

Min egen erfaring er at jeg stadig oftere støter på «blokkerings»-svar eller utfordringer, i den grad at jeg kanskje til og med forlater et nettsted som begynner å laste dem inn. Og siden CAPTCHA-sperrer har vist seg å skremme bort brukere og potensielle kunder, kan man forestille seg hvilket press dette skaper på nettstedseiere for å ta dem i bruk til tross for ulempen.

En CAPTCHA fra archive.is, et av de mange nettstedene som har tatt i bruk utfordringer, ofte som svar på et for stort antall automatiserte forespørsler (i motsetning til menneskelige forespørsler).

All denne nye og økte friksjonen skyldes delvis praktiske hensyn (fordi ikke alle nettsteder tåler pågangen), men er også ofte en form for forhandlingstaktikk for å se om AI-selskaper vil tilby en individuell eller kollektiv godtgjørelse for alle dataene de så desperat ønsker seg, og som har vært gratis så lenge – helt fram til nå.

Siden AI-søkeroboter må arbeide i stor skala, bruker de gjerne «hodeløse» Chrome-instanser under Playwright-rammeverket. I stadig flere domener vil dette i dag gi deg en 403-feil («forbudt») (det vil si at verten vet at du er automatisert trafikk og ber deg pelle deg vekk):

En lokal installasjon av changedetection.io prøver å hente innhold fra et nettsted, men nettstedet godtar ikke nettleseren rammeverket bruker, og svarer med en 403-respons («Forbidden»).

Det man ønsker, er «200» («OK»), selv om man må betale en stor sum til et nettverk av boligbaserte proxyservere, i kombinasjon med andre varierte, utspekulerte ikke-menneskelige knep, for å få det til.

Det finnes ikke noe bedre enn en 200-respons; det vil si at ingen klientresponskode gir et sterkere positivt signal. Det er heller ikke en tvetydig respons; den er aldri «nesten grei», «kommer til å bli grei senere» eller «blir stadig mer grei»; den er «grei!». Hvis det ikke er greit, er det ikke en 200-respons.

Hei! Forsvinn

Men ifølge en ny artikkel kan denne mangelen på nyansering føre til betydelige skjevheter i AI-datasett og statistiske estimater, og medføre at «god» status rapporteres når det ikke er tilfelle.

Studien* anslår at omtrent en femtedel av svarene i 200-kategorien ikke inneholder noe brukbart sideinnhold i det hele tatt, men i stedet viser tomme nettskall, CAPTCHA-utfordringer, tilgangsbegrensninger eller erstatningssider.

Artikkelen sier:

«20,9 % av sidene som en statisk klient mottar med status 200, inneholder ikke sidens hovedinnhold: app-skall, botutfordringer, blokkeringssider, feil- og plassholdersider samt delvis innhold.»

I denne sammenhengen går utålmodige automatiserte systemer i sin egen enkelthets felle, fordi 200-responsen kan likestilles med vellykkede forespørsler selv når forespørselen bare fører til en CAPTCHA-sperre, en betalingsmur eller et annet hinder.

Artikkelen beskriver de sju innholdstypene som ofte gjør en 200-respons mer komplisert:

De sju innholdskategoriene som slett ikke er «OK» i en 200-respons. Kilde

I løpet av tre dager ble 10 307 nettadresser testet i studien ved hjelp av både et enkelt program for innhenting av nettsider og en nettleser som kunne laste inn JavaScript. Svarene ble klassifisert ut fra innholdet som ble hentet, ikke HTTP-statuskodene.

De største kategoriene av «ubrukelige» 202-svar var tomme nettskall og feil- eller erstatningssider, som til sammen utgjorde mer enn to tredeler av feilene.

Når det gjelder tomme nettskall, kan et nettsted vise menyer og navigasjon, men la den etterspurte artikkelen eller produktlisten stå tom. I sistnevnte tilfelle kan en uvedkommende side eller nettstedets forside vises i stedet for det etterspurte innholdet. Begge deler kan likevel få samme HTTP 200-status som en vellykket innhenting med brukbart og nyttig innhold.

Som en mulig løsning anbefaler artikkelen at verktøy for innhenting av nettsider rapporterer hva som faktisk ble hentet, i stedet for å basere seg på HTTP-statuskoder. Enkle kontroller for uvanlig korte sider, mistenkelige viderekoblinger og innhold som ligner på sider som ikke finnes, kan nemlig avdekke de fleste feilene.

Mer ressurskrevende nettleserverktøy kan deretter brukes bare når det ser ut til at en side ikke er lastet inn som den skal. I tillegg kan evalueringer av KI kontrollere om kildene det vises til, faktisk inneholder den forventede informasjonen, i stedet for å anta at et HTTP 200-svar betyr at innholdet ble hentet inn på riktig måte.

Forfatteren av den nye studien påpeker også at «enkle heuristikker» uten videre kan identifisere rundt 86 % av ubrukelige svar ved hjelp av grunnleggende kontroller av sidelengde, viderekoblinger og likheter med sider som ikke finnes:

Sammenligning av strategier for innhenting av nettsider: Ved å gjengi bare sider som var flagget som mistenkelige, fikk man tilbake litt mer brukbart innhold (81,4 %) enn ved å gjengi alle sider (80,3 %), samtidig som den gjennomsnittlige innhentingstiden ble redusert fra 20,6 til 5,8 sekunder per side. 

Hvorfor er så mange 200-svar feilaktige?

Det har i årenes løp vært en viss diskusjon i utviklermiljøer om hvorvidt feilen 202 («Godtatt») (‘Forespørselen er godtatt, men ennå ikke fullført’) kunne skille ut disse «mislykkede» forespørslene med status 200. Men 202 kan i realiteten ikke dekke alle tilfellene som beskrives i den nye artikkelen, og det finnes ingen eksisterende kode som kan det.

Selv om artikkelen ikke går grundig inn på spørsmålet, kan årsakene til at domeneeiere tillater 200-feil være verdt å undersøke nærmere i framtidige, beslektede studier.

En grunn kan være at alt som ikke er 200, i praksis er en eller annen form for feilmelding eller hindring, inkludert de vanligste 404–«ikke funnet»-feilene – der målinnholdet ganske enkelt mangler. Noen brukere mener at et stort antall slike feil vil føre til sanksjoner innen SEO (og antakelig GEO), selv om Google avviser dette.

Google regner faktisk feilaktige 200-svar som «myke» 404-feil, og de vil trolig bli behandlet som et større problem enn vanlige 404-feil, ettersom de i praksis er «villedende» utfall, enten det er tilsiktet eller ikke.

Siteringsglidning

Hvis alt dette virker som flisespikkeri, bør man ta hensyn til petabyteskalaen på dataene som rutinemessig samles inn – eller forsøkes samlet inn – for å trene KI. Hvis en full femtedel av disse dataene er upålitelige eller direkte villedende, er det vanskelig å avfeie konsekvensene senere i prosessen som en form for «tilfeldig unøyaktighet». Slike feilaktige svar kan i stedet ha betydelig negativ innvirkning på fordelingen i datasett og på resultatene når slike data brukes til å trene KI-modeller.

Et eksempel på et viktig problem knyttet til feilaktige 200-svar er «siteringsglidning», der et KI-generert svar ikke lenger støttes av nettsiden som opprinnelig ble sitert som dokumentasjon. Siden kan ha blitt endret, den relevante teksten kan ha blitt fjernet, eller lenken kan nå føre et annet sted.

Den nye studien fant at det som så ut som siteringsglidning, økte fra 5,8 % til 21,9 % når alle HTTP 200-svar ble godkjent som vellykkede innhentinger, uavhengig av hva de inneholdt.

Det betyr at en kilde feilaktig kan bli vurdert som endret, forsvunnet eller ikke lenger egnet til å støtte en KI-generert påstand, ganske enkelt fordi en CAPTCHA, en tom side eller en annen hindring ble hentet inn i stedet for det opprinnelige materialet.

Bare si at det stemmer!

Problemet ble også vist gjennom tester med nettadresser som bevisst ikke eksisterte. Da tilfeldige, oppdiktede stier ble forespurt fra nettsteder, returnerte 13,1 % av nettstedene som svarte, statusen 200 («OK»), selv om de etterspurte sidene ikke fantes^†.

«13,1 % av nettstedene som svarte på testen med tilfeldige stier, returnerte 200 (S1 10,5 %, S2 13,3 %, S3 17,3 %, S4 13,7 %, S5 13,1 %). Alle slike svar er per definisjon myke 404-feil, men ikke alle oppgir det.»

«I en utforskende gjennomgang av de 172 soft 404-responsene kalte annotatøren 98 for en feil- eller erstatningsside, 32 for et skall og 28 for innhold: En startside eller listevisning som vises på en tilfeldig sti, ser ut som en vanlig side.»

Konklusjon

Hvis problemet ble erkjent på et høyere nivå, kunne IANA tenkes å opprette en ny og mer passende HTTP-statuskode, for eksempel [X] («Forespørselen lyktes, men det etterspurte innholdet ble ikke levert»). Selv om dette faktisk ville beskrive det som skjer, ville det naturligvis kreve en usannsynlig grad av innsikt i transaksjonen på vertens side.

Det finnes allerede lignende koder, men ingen passer egentlig: 451 («Utilgjengelig av juridiske grunner») er tvetydig og temmelig alarmerende (!); 206 («Delvis innhold») passer teknisk sett, men er ment for ufullstendige data (hentinger); og den overraskende eksisterende 203 («Informasjon fra en ikke-autoritativ kilde»), som ble opprettet i 1997, er bare indirekte relevant for bruksområdet her.

Kanskje er den nærmeste kandidaten faktisk den lite intuitive 103 («Tidlige hint»), som angir at ikke alle ressursene på URL-en er lastet ennå (selv om dette åpenbart ville være en grov feiltolkning av hva koden er ment å bety).

* Med tittelen ‘Når 200 OK ikke er et svar: Stille hentefeil ved agentisk innhenting av nettinnhold.‘ Vær oppmerksom på at artikkelen tilsynelatende først og fremst er skrevet for å kunne leses av maskiner, kanskje for at AI skal kunne søke i den, og at den i seg selv ikke er lettlest.

^† Jeg beklager det mekanistiske sitatet, men hele artikkelen er skrevet på denne måten, som jeg nevner ovenfor, for å være «maskinlesbar» snarere enn forståelig for mennesker, selv om den ikke går så langt som å presenteres i JSON-format.

Først publisert onsdag 4. november 2026