20 procent av alla webbsvar med statusen ”OK” som AI får är inte okej

Mina senaste experiment med AI-assisterad webbskrapning har gjort det tydligt för mig i vilken utsträckning webben blir allt mer ”låst”. Det som förstås ligger bakom den här åtstramningen är den explosiva ökningen av AI-driven webbskrapning, vars omättliga efterfrågan på nya data kan leda till att webbplatser slås ut.

Det här är ett bra skäl för domäner att göra det som många av dem länge har velat göra: göra innehållet tillgängligt endast för inloggade användare (även om Googlebot vanligtvis får frikort). Facebook slutförde det gradvisa införandet av den här policyn år 2023, och Twitter/X gjorde likadant samma år. Reddit kommer att införa den senare den här månaden.

På så sätt blir det lite enklare för webbplatsen att följa landspecifika krav på ålderskontroller, eftersom användaren redan är registrerad. Ännu viktigare är att användarens data kan sparas, användas för lokal analys och – om lokal lagstiftning tillåter det – säljas till datamäklare och AI-företag.

På andra håll har åtgärder som uttryckligen syftar till att skydda mot bottar, snarare än att registrera användare, ökat med mer än 58 procent jämfört med året innan, enligt Cloudflare. Den ökande botaktiviteten får naturligtvis webbplatser att granska VPN- och proxyadresser, vilket kan leda till att även legitima användare nekas åtkomst, tillsammans med all ”skadlig” trafik.

Det anekdotiska i det här är att jag verkar stöta på blockeringssvar eller utmaningar allt oftare, så pass ofta att jag kanske till och med lämnar en webbplats när den börjar visa sådana. Och eftersom det har visat sig att CAPTCHA-väggar avskräcker användare och potentiella kunder kan man föreställa sig vilket tryck det skapar på webbplatsägare att införa dem trots nackdelen.

En CAPTCHA från archive.is, en av de många webbplatser som har infört utmaningar, ofta som svar på alltför många automatiserade (snarare än mänskliga) förfrågningar.

Alla dessa nya och ökade hinder beror delvis på praktiska omständigheter (eftersom inte alla webbplatser klarar anstormningen), men handlar också ofta om en förhandlingstaktik: ett sätt att se om AI-företagen kommer att erbjuda en individuell eller gemensam ersättning för all den data de så desperat vill ha och som har varit gratis så länge – ända fram till nu.

Eftersom AI-sökarrobotar måste arbeta i stor skala använder de ofta ”huvudlösa” Chrome-instanser med ramverket Playwright. För allt fler webbplatser leder det numera till ett 403-fel (”åtkomst nekad”) (det vill säga: värden ser att trafiken är automatiserad och säger åt dig att dra vidare):

En lokal installation av changedetection.io försöker kontrollera en webbplats, men webbplatsen godtar inte den identifierade webbläsare som ramverket använder och returnerar svaret 403 (”åtkomst nekad”).

Det man vill ha är klientsvaret ”200” (”OK”), även om man måste betala en rejäl summa till en gård med bostadsproxyservrar och kombinera det med andra varierade, lömska knep som inte bygger på mänsklig aktivitet för att få det.

Det finns inget bättre än svaret 200; det finns alltså ingen klientstatuskod som signalerar något mer positivt. Det är inte heller ett tvetydigt svar: det är aldrig ”nästan okej”, ”kommer att bli okej senare” eller ”blir allt mer okej”; det är ”okej!”. Om det inte är okej är svaret inte 200.

Hej! Försvinn!

Men enligt en ny artikel kan den här bristen på nyanser leda till betydande snedvridningar i AI-datamängder och statistiska uppskattningar, och få system att rapportera statusen ”bra” när så inte är fallet.

Studien* uppskattar att ungefär en femtedel av svaren i 200-kategorin inte innehåller något användbart sidinnehåll alls, utan i stället visar tomma webbplatsskal, CAPTCHA-utmaningar, åtkomstbegränsningar eller ersättningssidor.

I artikeln står det:

”20,9 % av de sidor som en statisk klient tar emot med statuskod 200 innehåller inte sidans huvudinnehåll: appskal, botutmaningar, blockeringssidor, fel- och platshållarsidor samt ofullständigt innehåll.”

I det här avseendet snubblar otåliga automatiserade system på sin egen enkelspårighet, eftersom svaret ”200” får likställas med en lyckad hämtning även när hämtningen bara leder till en CAPTCHA-vägg, en betalvägg eller något annat hinder.

Artikeln beskriver de sju typer av innehåll som ofta gör ett svar 200 mer komplicerat:

De sju innehållskategorier som inte alls är ”okej” i ett svar 200. Källa

Under studien testades 10 307 webbadresser under tre dagar med både ett grundläggande program för att hämta webbsidor och en webbläsare som kunde läsa in JavaScript. Svaren klassificerades utifrån det hämtade innehållet, inte HTTP-statuskoderna.

De största kategorierna av oanvändbara svar med status 202 var tomma webbplatsskal och fel- eller ersättningssidor, som tillsammans stod för mer än två tredjedelar av misslyckandena.

När det gäller tomma webbplatsskal kan en webbplats visa sina menyer och sin navigering men lämna den efterfrågade artikeln eller produktlistan tom. I det senare fallet kan en orelaterad sida eller startsida visas i stället för det efterfrågade innehållet – men båda kan få samma HTTP-status 200 som en lyckad hämtning med användbart och relevant innehåll.

Som en möjlig lösning rekommenderar artikeln att verktyg för att hämta webbsidor rapporterar vad som faktiskt hämtades i stället för att förlita sig på HTTP-statuskoder, eftersom enkla kontroller av ovanligt korta sidor, misstänkta omdirigeringar och innehåll som liknar innehåll på sidor som inte finns skulle kunna identifiera de flesta misslyckandena.

Mer resurskrävande webbläsarverktyg skulle därefter kunna användas endast när det verkar som att en sida inte har lästs in korrekt. AI-utvärderingar skulle dessutom kunna kontrollera om citerade källor faktiskt innehåller den förväntade informationen, i stället för att anta att ett HTTP 200-svar innebär att innehållet hämtades korrekt.

Författaren till den nya studien påpekar också att ”enkla tumregler” utan svårighet kan identifiera omkring 86 % av de oanvändbara svaren genom grundläggande kontroller av sidlängd, omdirigeringar och likheter med sidor som inte finns:

Jämförelse av strategier för att hämta webbsidor: Genom att bara återge sidor som flaggats som misstänkta hämtades något mer användbart innehåll (81,4 %) än genom att återge alla sidor (80,3 %), samtidigt som den genomsnittliga hämtningstiden minskade från 20,6 till 5,8 sekunder per sida. 

Varför förekommer så många felaktiga 200-svar?

Under årens lopp har det förts en viss diskussion i utvecklargemenskaper om huruvida 202-felet (”Accepterad”) (”Begäran accepterad men ännu inte slutförd”) skulle kunna skilja ut dessa ”misslyckade” förfrågningar med status 200. Men 202 kan i själva verket inte hantera alla de fall som beskrivs i den nya artikeln, och det finns ingen befintlig kod som kan göra det.

Även om artikeln inte behandlar frågan ingående kan det vara värt att undersöka närmare i framtida studier varför domänägare tillåter 200-fel.

En anledning kan vara att allt som inte är ett 200-svar i princip är någon form av felsida eller hinder, däribland det vanligaste, 404–”hittades inte”-felet – då målinnehållet helt enkelt saknas. Vissa användare tror att ett överflöd av sådana fel leder till SEO-straff (och förmodligen även GEO-straff), men Google förnekar detta.

Google betraktar faktiskt felaktiga 200-svar som ”mjuka” 404-fel, och de lär tydligt ses som ett större problem än vanliga 404-fel, eftersom de i grunden är ”vilseledande” resultat, avsiktliga eller inte.

Citeringsglidning

Om allt detta verkar vara hårklyverier bör man tänka på den petabyteomfattande datamängd som regelbundet samlas in (eller försöker samlas in) för AI-träning. Om en hel femtedel av dessa data är opålitliga eller direkt vilseledande är det svårt att vifta bort följderna som någon sorts ”biverkningar i form av felaktigheter”. Sådana felaktiga svar skulle i stället kunna påverka både datafördelningen i dataset och resultaten av att träna AI-modeller på dessa data på ett betydande och negativt sätt.

Ett exempel på ett uppmärksammat problem med felaktiga 200-svar är ”citeringsglidning”, då ett AI-genererat svar inte längre stöds av den webbsida som ursprungligen citerades som belägg. Det kan bero på att sidan har ändrats, att den relevanta texten har tagits bort eller att länken nu leder någon annanstans.

Den nya studien visade att den skenbara citeringsglidningen ökade från 5,8 % till 21,9 % när alla HTTP 200-svar godtogs som lyckade hämtningar, oavsett vad de innehöll.

Det innebär att en källa felaktigt kan bedömas ha ändrats, försvunnit eller slutat stödja ett AI-genererat påstående, helt enkelt för att en CAPTCHA, en tom sida eller något annat hinder hämtades i stället för det ursprungliga materialet.

Säg bara att det är så!

Problemet visades också i tester med avsiktligt obefintliga webbadresser. När webbplatser fick förfrågningar om slumpmässiga, påhittade sökvägar svarade 13,1 % av dem som svarade med status 200 (”OK”), trots att de efterfrågade sidorna inte fanns^†.

”13,1 % av webbplatserna som svarade på testet med slumpmässiga sökvägar returnerade status 200 (S1 10,5 %, S2 13,3 %, S3 17,3 %, S4 13,7 %, S5 13,1 %). Varje sådant svar är per definition ett mjukt 404-fel, men alla svar anger inte det.”

‘I en explorativ genomgång av de 172 soft 404-svaren klassificerade annotatören 98 som fel- eller ersättningssidor, 32 som skal och 28 som innehåll: en startsida eller listningssida som visas på en slumpmässig sökväg ser ut som en vanlig sida.’

Slutsats

Om problemet uppmärksammades på en högre nivå skulle IANA möjligen kunna skapa en ny och mer passande HTTP-statuskod, till exempel [X] (‘Begäran lyckades, men det begärda innehållet levererades inte’). Även om detta faktiskt skulle beskriva vad som händer, skulle det naturligtvis kräva osannolikt mycket insikt i transaktionen från värdens sida.

Liknande statuskoder finns redan, men ingen passar riktigt: 451 (‘Otillgänglig av juridiska skäl’) är tvetydig och ganska alarmerande (!); 206 (‘Delvis innehåll’) är tekniskt sett lämplig, men avsedd för ofullständiga data (hämtningar); och det förvånansvärt nog existerande 203 (‘Icke-auktoritativ information’), som skapades 1997 och bara har en perifer koppling till det aktuella användningsfallet.

Den närmaste kandidaten är kanske egentligen det kontraintuitivt benämnda 103 (‘Tidiga tips’), som anger att inte alla resurser i URL:en har laddats ännu (även om detta uppenbart skulle vara en grov feltolkning av kodens avsikt).

* ‘Med titeln ‘När 200 OK inte är ett svar: Tysta hämtningsfel vid agentbaserad insamling av webbinnehåll.‘ Observera att artikeln tydligen är skriven främst för att kunna läsas av maskiner, kanske för att användas i AI-sökningar, och att den inte är lättläst i sig.

^† Jag ber om ursäkt för det mekanistiska citatet, men hela artikeln är skriven på det här sättet, som jag nämner ovan, för att vara ”maskinläsbar” snarare än begriplig för människor, även om den inte går så långt som att presenteras i JSON-format.

Först publicerad onsdagen den 4 november 2026