Il 20% di tutte le risposte web «OK» ricevute dall’IA non è «OK»

I miei recenti esperimenti di estrazione di dati dal web con l’ausilio dell’IA mi hanno fatto toccare con mano quanto il web stia diventando sempre più «blindato». La causa di questa chiusura, naturalmente, è la crescita impressionante dell’estrazione di dati dal web tramite IA, la cui domanda incessante di nuovi dati può finire per mandare fuori linea i domini.

È un buon motivo per cui i domini facciano ciò che molti di loro desiderano fare da tempo: rendere accessibili i propri contenuti solo agli utenti che hanno effettuato l’accesso (anche se, naturalmente, Googlebot di solito non incontra ostacoli). Facebook ha completato la graduale adozione di questa politica nel 2023 e Twitter/X ha fatto lo stesso quello stesso anno. Reddit la adotterà più avanti questo mese.

In questo modo, per il dominio diventa un po’ più facile conformarsi all’applicazione dei limiti di età prevista nei singoli paesi, poiché l’utente è già registrato. Ancora più importante, i dati dell’utente possono essere salvati, utilizzati per analisi locali e, se la legislazione locale lo consente, venduti a broker di dati e aziende di IA.

Altrove, le misure mirate proprio a difendersi dai bot (anziché a registrare gli utenti) sono aumentate di oltre il 58% su base annua, secondo Cloudflare; e tutta questa crescente attività dei bot induce naturalmente i siti web a esaminare con attenzione gli indirizzi VPN e proxy, rischiando di negare l’accesso agli utenti legittimi insieme al traffico «malevolo».

Dal punto di vista aneddotico, mi sembra di imbattermi sempre più spesso in risposte di «blocco» o in verifiche, al punto che potrei persino abbandonare un sito che comincia a mostrarle; e, dato che è stato dimostrato che i muri di CAPTCHA scoraggiano gli utenti e i potenziali clienti, si può immaginare la pressione che spinge i proprietari dei domini ad adottarli, nonostante questo svantaggio.

Un CAPTCHA di archive.is, uno dei tanti siti che hanno adottato queste verifiche, spesso in risposta a un numero eccessivo di richieste automatizzate (anziché umane).

Tutto questo nuovo e maggiore attrito è in parte dovuto a ragioni logistiche (perché non tutti i domini riescono a resistere all’assalto), ma spesso è anche una sorta di tattica negoziale, per vedere se le aziende di IA offriranno una forma di remunerazione unica o collettiva per tutti quei dati che desiderano tanto e che sono stati gratuiti per così tanto tempo, fino a oggi.

Poiché i crawler di IA devono operare su larga scala, tendono a usare istanze «headless» di Chrome basate sul framework Playwright. Oggi, per un numero crescente di domini, questo comporta un errore 403 («vietato») (ossia: il server sa che il tuo traffico è automatizzato e ti intima di andartene):

Un’installazione locale di changedetection.io cerca di interrogare un sito, ma il sito non gradisce il browser rilevato utilizzato dal framework e restituisce una risposta 403 («Forbidden», ovvero «Vietato»).

Quello che si cerca è la risposta del client «200» («OK»), anche se per ottenerla bisogna sborsare un mucchio di soldi a una rete di proxy residenziali, ricorrendo insieme a una serie di altri espedienti diversificati e subdoli, non umani.

Non c’è niente di meglio della risposta 200: in altre parole, non esiste un codice di risposta del client con un segnale positivo più forte. E non è nemmeno una risposta ambigua: non è mai «quasi a posto», «sarà a posto più tardi» o «sta migliorando»; è «a posto!». Se non è a posto, non è una risposta 200.

Ciao! Vattene

Eppure, secondo un nuovo articolo, questa mancanza di granularità potrebbe distorcere in misura significativa i set di dati dell’IA, le stime statistiche e la segnalazione di uno stato «positivo» quando non lo è.

Lo studio* stima che circa un quinto delle risposte di categoria 200 non contenga alcun contenuto di pagina utilizzabile, ma restituisca invece scheletri di siti web vuoti, verifiche CAPTCHA, restrizioni di accesso o pagine sostitutive.

L’articolo afferma:

«Il 20,9% delle pagine che un client statico riceve con stato 200 non contiene il contenuto principale della pagina: scheletri di app, verifiche anti-bot, pagine di blocco, pagine di errore e segnaposto, e contenuti parziali.»

A questo proposito, i sistemi automatizzati impazienti inciampano nella propria semplicità, perché la risposta «200» viene considerata equivalente a un recupero riuscito anche quando il recupero restituisce soltanto un muro di CAPTCHA, un paywall o qualche altro ostacolo.

L’articolo illustra le sette tipologie di contenuti che spesso complicano una risposta 200:

Le sette categorie di contenuti che in una risposta 200 sono tutt’altro che «a posto». Fonte

Nel corso dello studio, nell’arco di tre giorni, sono stati testati 10.307 indirizzi web usando sia un semplice programma per recuperare pagine web sia un browser in grado di caricare JavaScript; le risposte sono state classificate in base al contenuto recuperato, anziché ai relativi codici di stato HTTP.

Le categorie più numerose di risposte 202 «inutilizzabili» erano costituite da strutture vuote di siti web e da pagine di errore o sostitutive, che insieme rappresentavano oltre due terzi dei casi problematici.

Nel caso delle strutture vuote dei siti, un sito web potrebbe mostrare menu e strumenti di navigazione, lasciando però vuoto l’articolo o l’elenco di prodotti richiesto; in quest’ultimo caso, al posto del contenuto richiesto potrebbe comparire una pagina non pertinente o la homepage. Entrambe le situazioni potrebbero tuttavia ricevere lo stesso stato HTTP 200 di un recupero riuscito, con contenuti utilizzabili e utili.

Come rimedio, l’articolo raccomanda che gli strumenti per recuperare pagine web segnalino che cosa è stato effettivamente recuperato, anziché affidarsi ai codici di stato HTTP, poiché semplici controlli sulle pagine insolitamente brevi, sui reindirizzamenti sospetti e sui contenuti simili a quelli di pagine inesistenti potrebbero individuare la maggior parte dei casi problematici.

Gli strumenti basati su browser, più dispendiosi in termini di risorse, potrebbero quindi essere usati soltanto quando una pagina sembra non essersi caricata correttamente. Inoltre, le valutazioni dell’IA potrebbero verificare se le fonti citate contengono effettivamente le informazioni attese, anziché presumere che una risposta HTTP 200 significhi che il contenuto è stato recuperato correttamente.

L’autore del nuovo studio osserva inoltre che semplici «euristiche a basso costo» possono individuare facilmente circa l’86% delle risposte inutilizzabili, ricorrendo a controlli di base sulla lunghezza delle pagine, sui reindirizzamenti e sulle somiglianze con pagine inesistenti:

Confronto tra strategie per recuperare pagine web: eseguire il rendering solo delle pagine segnalate come sospette ha permesso di recuperare una quantità leggermente maggiore di contenuti utilizzabili (81,4%) rispetto all’esecuzione del rendering di tutte le pagine (80,3%), riducendo al contempo il tempo medio di recupero da 20,6 a 5,8 secondi per pagina. 

Perché così tante risposte 200 errate?

Nel corso degli anni, nelle comunità di sviluppatori si è discusso di una possibile soluzione: l’errore 202 («Accettato») («Richiesta accettata ma non ancora completata») potrebbe distinguere queste richieste con stato 200 «fallite». In realtà, però, il codice 202 non può coprire tutti i casi descritti nel nuovo articolo, e non esiste alcun codice già disponibile che possa farlo.

Sebbene l’articolo non affronti la questione in modo approfondito, potrebbe valere la pena indagare ulteriormente, in futuri studi correlati, perché i proprietari dei domini consentano risposte 200 errate.

Una possibile ragione è che qualsiasi risposta diversa da 200 corrisponda essenzialmente a una pagina di errore o a un ostacolo di qualche tipo, compresi gli errori più comuni, i 404 («non trovato»), nei quali il contenuto cercato è semplicemente assente. Alcuni utenti ritengono che un numero eccessivo di errori di questo tipo comporti penalizzazioni SEO (e, presumibilmente, GEO), ma Google nega che sia così.

In effetti, Google considera le risposte 200 errate come falsi errori 404, e con ogni probabilità le tratta come un problema più grave dei normali errori 404, perché si tratta essenzialmente di risultati «ingannevoli», intenzionali o meno.

Deriva delle citazioni

Se tutto questo sembra un eccesso di pignoleria, bisogna considerare la scala, dell’ordine dei petabyte, dei dati che vengono regolarmente raccolti (o che si cerca di raccogliere) per addestrare i sistemi di IA. Se un quinto di quei dati è inaffidabile o apertamente ingannevole, è difficile liquidare le conseguenze a valle come una sorta di «imprecisione collaterale»; risposte false di questo tipo potrebbero invece influire in modo significativo e negativo sulla distribuzione nei set di dati e sui risultati dell’addestramento dei modelli di IA con tali dati.

Per esempio, un problema rilevante legato alle risposte 200 errate riguarda la «deriva delle citazioni»: una risposta generata dall’IA non è più supportata dalla pagina web citata in origine come prova, perché la pagina potrebbe essere cambiata, il testo pertinente potrebbe essere stato rimosso oppure il link potrebbe ora rimandare altrove.

Lo studio ha rilevato che l’apparente deriva delle citazioni passava dal 5,8% al 21,9% quando tutte le risposte HTTP 200 venivano considerate recuperi riusciti, indipendentemente dal loro contenuto.

Ciò significa che si potrebbe giudicare erroneamente che una fonte sia cambiata, scomparsa o non supporti più un’affermazione generata dall’IA, semplicemente perché al posto del materiale originale è stato recuperato un CAPTCHA, una pagina vuota o un altro ostacolo.

Basta dire che è così!

Il problema è stato dimostrato anche con test che prevedevano indirizzi web deliberatamente inesistenti. Quando venivano richiesti percorsi casuali e inventati sui siti web, il 13,1% di quelli che rispondevano restituiva uno stato 200 («OK»), benché le pagine richieste non esistessero^†.

«Il 13,1% dei siti che hanno risposto al test dei percorsi casuali ha restituito 200 (S1 10,5%, S2 13,3%, S3 17,3%, S4 13,7%, S5 13,1%). Per definizione, ogni risposta di questo tipo è un falso 404, ma non tutte lo dichiarano.»

«In un’analisi esplorativa delle 172 risposte soft 404, l’annotatore ne ha classificate 98 come errori o pagine sostitutive, 32 come pagine scheletro e 28 come contenuti: una homepage o una pagina di elenco servita a un percorso casuale sembra una pagina normale.»

Conclusione

Se il problema fosse riconosciuto a un livello superiore, la IANA potrebbe forse creare un nuovo codice di stato HTTP più appropriato, come [X] («La richiesta è riuscita, ma il contenuto richiesto non è stato fornito»). Sebbene descriva effettivamente ciò che sta accadendo, richiederebbe naturalmente al server un livello di comprensione della transazione difficilmente raggiungibile.

Esistono già codici simili, anche se nessuno è davvero adatto: 451 («Non disponibile per motivi legali») è ambiguo e piuttosto allarmante (!); 206 («Contenuto parziale») è tecnicamente appropriato, ma è destinato ai dati incompleti (fetch); e il sorprendente 203 («Informazioni non autorevoli»), creato nel 1997, è pertinente solo marginalmente al caso in questione.

Forse il candidato più vicino è proprio il codice 103, dal nome poco intuitivo («Suggerimenti preliminari»), che indica che non tutte le risorse dell’URL sono ancora state caricate (anche se ciò rappresenterebbe chiaramente una grave interpretazione errata dello scopo del codice).

* ‘Intitolato «Quando 200 OK non è una risposta: errori silenziosi nel recupero agentico di contenuti web.‘ Si tenga presente che il documento è scritto, a quanto pare, principalmente per essere leggibile dalle macchine, forse per essere interrogato dall’IA, e non è di facile lettura.

^† Mi scuso per la citazione meccanica, ma l’intero documento è scritto in questo modo, come osservato sopra, per essere «leggibile dalle macchine» anziché interpretabile dagli esseri umani, anche se non arriva a essere presentato in formato JSON.

Pubblicato per la prima volta mercoledì 4 novembre 2026