La responsabilità continua di Cloudflare per i bot verificati trasforma l’identità in un test costante
Il 16 ottobre Cloudflare ha introdotto la responsabilità continua per i bot verificati, aggiungendo una verifica costante del comportamento a un programma in precedenza incentrato sull’identità. Il cambiamento affronta un conflitto fondamentale: un crawler può dimostrare chi lo gestisce e continuare comunque a ignorare le regole dei siti web.
Il nuovo sistema osserva se l’automazione verificata rispetta le preferenze pubblicate e reagisce quando un sito le chiede di rallentare. Cloudflare trasforma poi tali osservazioni in una fascia di affidabilità spiegabile, anziché trattare la verifica come un sigillo di approvazione permanente.
Questa distinzione assume rilievo dopo che Cloudflare ha rimosso Perplexity dal suo elenco di Verified Bots nel 2025. Cloudflare ha sostenuto che Perplexity avesse avuto accesso a contenuti con restrizioni e modificato le proprie tattiche di crawling quando veniva bloccata. Perplexity ha contestato questa ricostruzione. L’episodio ha evidenziato la debolezza che Cloudflare ora vuole affrontare: l’autenticazione può identificare un bot, ma l’identità da sola non può garantire una buona condotta.
La responsabilità continua per i bot verificati aggiunge un livello comportamentale
Cloudflare sta trasformando la verifica da una decisione una tantum sull’identità in una valutazione continua della condotta.
Storicamente, il programma Verified Bots di Cloudflare ha aiutato i siti web a distinguere l’automazione riconosciuta dal traffico sconosciuto o potenzialmente dannoso. Crawler dei motori di ricerca, servizi di monitoraggio, strumenti di accessibilità e agenti diretti dagli utenti possono tutti richiedere lo stato di verifica.
Un bot deve identificarsi mediante un metodo accettato. Questi metodi includono firme crittografiche, intervalli IP pubblicati abbinati a user agent stabili e controlli reverse DNS.
La policy sui bot verificati di Cloudflare richiede inoltre comportamenti non abusivi. I servizi verificati dovrebbero rispettare le istruzioni di robots.txt, mantenere frequenze di richiesta ragionevoli ed evitare di aggirare le preferenze dei siti web.
Il problema è temporale. Un operatore può soddisfare tali condizioni durante l’iscrizione e poi distribuire un aggiornamento che modifica il comportamento del suo crawler. Anche un errore di configurazione può produrre traffico dannoso senza intenzioni malevole.
Il nuovo sistema di Cloudflare monitora questo divario. Misura con quale coerenza un crawler segue nel tempo le preferenze dei siti e registra il comportamento alla base della sua valutazione.
Il risultato è una fascia di affidabilità spiegabile. Cloudflare la descrive come un intervallo che riflette un comportamento sostenuto, non un giudizio permanente su un’azienda o un operatore.
Questa impostazione separa il rischio dall’affidabilità. Il rischio riguarda il potenziale danno associato a una particolare richiesta o a un singolo momento. L’affidabilità riflette uno schema ripetuto in molte interazioni.
Un crawler verificato potrebbe generare una singola violazione accidentale delle policy senza diventare categoricamente inaffidabile. Al contrario, un bot che ignora ripetutamente le restrizioni non dovrebbe conservare un trattamento speciale solo perché ha superato un precedente controllo dell’identità.
Cloudflare afferma che i suoi primi segnali di valutazione pongono due domande. Il bot ha rispettato le istruzioni pubblicate e ha reagito al feedback diretto del sito web?
Questi segnali si concentrano sul comportamento di rete osservabile. Non richiedono a Cloudflare di dedurre le intenzioni private dell’operatore di un crawler.
Questo approccio offre anche agli operatori una strada per recuperare. Una fascia di affidabilità può migliorare quando un bot modifica costantemente il proprio comportamento dopo aver ricevuto istruzioni o risposte di limitazione della frequenza.
Cloudflare sta già utilizzando il sistema internamente. L’azienda afferma di prevedere di esporre la valutazione ai clienti dopo aver raccolto una storia comportamentale sufficiente e perfezionato le proprie indicazioni.
I clienti potranno infine scegliere una soglia di affidabilità per gestire il traffico dei Verified Bot. Cloudflare non ha annunciato una data di disponibilità generale né divulgato la formula esatta del punteggio.
Queste omissioni sono importanti. L’annuncio definisce l’idea guida e i segnali iniziali, ma non fornisce ancora una specifica completa del prodotto.
Tuttavia, la direzione è chiara. Lo stato di verifica significherà sempre più che un bot resta identificabile e continua a comportarsi entro limiti accettati.
Perché l’identità non poteva più sostenere da sola l’intera decisione di fiducia
Un’identità crittografica risponde alla domanda su chi abbia inviato una richiesta, ma non a quella se tale richiesta debba essere accolta.
Cloudflare ha trascorso diversi anni a rafforzare l’identificazione dei bot. I segnali tradizionali, come le stringhe user-agent e gli indirizzi IP, presentano serie limitazioni.
Un user-agent è semplicemente un’etichetta inviata con una richiesta HTTP. Può essere copiata da un altro programma. Gli intervalli IP possono cambiare, servire più sistemi o essere compromessi.
Web Bot Auth migliora questo livello di identità. Consente a un bot di firmare le richieste mediante HTTP Message Signatures, che forniscono prove crittografiche del fatto che un operatore autorizzato abbia creato la richiesta.
Cloudflare convalida la firma e associa il traffico a una voce in BotBase, la sua directory pubblica di bot e agenti. Ciò riduce la dipendenza da identificatori facili da contraffare.
Il formato di firma sottostante non è un’invenzione esclusiva di Cloudflare. HTTP Message Signatures è stato standardizzato tramite RFC 9421, mentre le specifiche Web Bot Auth continuano a essere sviluppate apertamente.
La convalida della firma risolve comunque solo l’autenticazione. Una firma valida può stabilire che una richiesta provenga da un operatore noto. Non può stabilire che l’operatore abbia rispettato le restrizioni di un editore.
Si consideri un bot di monitoraggio che firma correttamente ogni richiesta, ma dopo una distribuzione difettosa inizia a richiedere pagine a una frequenza centinaia di volte superiore. La sua identità resta valida anche mentre la sua condotta genera costi operativi.
Lo stesso problema si applica ai crawler AI. Un crawler può identificarsi accuratamente mentre richiede contenuti che il sito ha contrassegnato come non disponibili per il suo scopo.
Questo divario diventa più rilevante man mano che l’automazione assume più ruoli. Cloudflare ora classifica i sistemi verificati in ambiti quali ricerca, addestramento di modelli, agenti diretti dagli utenti, transazioni, test di sicurezza, raccolta dati e altre attività.
Alcuni bot agiscono anche come intermediari. La loro infrastruttura appartiene a un’azienda, ma molti utenti possono avviare azioni attraverso di essa.
Ciò crea quello che Cloudflare definisce affidamento transitivo. Un sito potrebbe fidarsi dell’operatore della piattaforma senza fidarsi di ogni utente che dirige l’agente della piattaforma.
La responsabilità continua per i bot verificati non risolve completamente questo problema di delega. Tuttavia, offre a Cloudflare un modo per valutare il traffico risultante anziché fare affidamento interamente sull’identità dell’operatore.
Il cambiamento spinge inoltre gli operatori dei bot a integrare la conformità nei sistemi di produzione. Il buon comportamento non può più restare una promessa registrata durante l’iscrizione.
Gli operatori necessitano di un recupero affidabile di robots.txt, di una selezione degli URL consapevole delle policy, di identità specifiche per finalità e di un controllo adattivo della frequenza. Hanno inoltre bisogno di monitoraggio che intercetti le regressioni prima che una CDN registri uno schema dannoso.
Questo innalza lo standard ingegneristico per l’automazione verificata. L’autenticazione diventa il requisito di accesso, mentre la conformità osservabile determina se l’affidabilità risultante dura nel tempo.
Robots.txt e HTTP 429 diventano prove, non suggerimenti
Il meccanismo di Cloudflare trasforma due segnali web familiari in prove del livello di affidabilità continuativa di un crawler.
Il primo segnale è robots.txt, un file di testo collocato nel percorso di primo livello di un sito web. Pubblica istruzioni di accesso per i crawler automatizzati.
Il protocollo organizza le regole per user-agent e utilizza le direttive Allow o Disallow per identificare i percorsi accessibili. Ai sensi di RFC 9309, un crawler che scarica correttamente il file deve seguirne le regole interpretabili.
Robots.txt presenta limitazioni pratiche. Comunica preferenze, ma non le applica come farebbero un controllo di autenticazione o una regola firewall.
Inoltre, dice poco sul motivo per cui un crawler desidera contenuti specifici. Un operatore può utilizzare bot separati per la ricerca, l’addestramento di modelli e il recupero richiesto dagli utenti. Un altro può combinare tali finalità.
Cloudflare valuta se il traffico osservato resti coerente con le regole pubblicate dal sito. Il sistema enfatizza gli schemi ripetuti invece di considerare ogni discrepanza isolata come decisiva.
Questa distinzione riduce la probabilità che un errore temporaneo distrugga automaticamente la reputazione di un bot. Rende inoltre più difficile liquidare un persistente mancato rispetto come un’anomalia.
Cloudflare avverte che robots.txt rappresenta un confine minimo, non un’autorizzazione generale per tutto ciò che non vieta. Un sito web può comunicare che l’accesso continuato non è gradito attraverso altre risposte.
HTTP 429 è il secondo segnale iniziale. Un server utilizza questo codice di stato per indicare che un client ha inviato troppe richieste in un determinato periodo.
La risposta può includere un header Retry-After, che indica al client per quanto tempo attendere. Tuttavia, tale indicazione è facoltativa.
Il pertinente standard HTTP lascia ai server flessibilità su come identificare il traffico eccessivo e contare le richieste. I server possono applicare limiti per risorsa, credenziali o altre misure.
Cloudflare osserva ciò che il bot fa successivamente. Un bot che rallenta o si interrompe dopo aver ricevuto ripetute risposte 429 dimostra capacità di adattamento. Uno che continua alla stessa frequenza perde affidabilità.
Questo rende la gestione dei limiti di frequenza parte della responsabilità dei bot verificati. Colma inoltre un’importante scappatoia, poiché un crawler può rimanere interamente nei percorsi consentiti pur sovraccaricando l’origine.
Il meccanismo combinato crea un ciclo di feedback comportamentale. Un editore dichiara le preferenze di accesso, l’origine fornisce feedback in tempo reale e Cloudflare osserva la risposta del crawler.
Bot Preference Sync supporta il lato di pubblicazione di questo ciclo. Traduce le preferenze configurate da un cliente sul traffico AI nelle corrispondenti voci di robots.txt.
Gli strumenti Bot Management di Cloudflare forniscono il lato dell’applicazione. I clienti possono utilizzare categorie riconosciute e altri segnali per consentire, bloccare, sottoporre a verifica o limitare la frequenza del traffico.
La valutazione continua si colloca tra questi componenti. Chiede se un bot noto si comporti effettivamente come previsto dopo aver incontrato le policy pubblicate e applicate.
Il sistema misura quindi la conformità su due diverse scale temporali. Robots.txt riflette una policy del sito relativamente duratura, mentre HTTP 429 comunica una pressione immediata.
Un crawler affidabile deve gestire entrambe. Dovrebbe pianificare le richieste rispettando le restrizioni permanenti e adattare il proprio comportamento quando cambiano le condizioni correnti.
Perplexity mostra perché la responsabilità dei bot verificati è controversa
La controversia su Perplexity mostra sia il valore delle prove comportamentali sia il pericolo di lasciare a un singolo fornitore di infrastruttura la definizione dell’affidabilità.
Cloudflare ha dichiarato di aver avviato un’indagine dopo che i clienti avevano segnalato che Perplexity continuava ad accedere a siti i cui operatori avevano cercato di bloccare i crawler AI.
L’azienda ha creato domini di prova nuovi, non indicizzati e protetti da restrizioni robots.txt. Cloudflare ha quindi inviato a Perplexity prompt che richiedevano informazioni provenienti da tali domini.
Secondo Cloudflare, Perplexity ha recuperato informazioni dettagliate nonostante tali restrizioni. Cloudflare ha inoltre sostenuto che il crawling si fosse spostato su infrastrutture non dichiarate e identità generiche dei browser quando gli agenti dichiarati incontravano blocchi.
Cloudflare ha confrontato tale comportamento con test che coinvolgevano OpenAI. Ha affermato che ChatGPT si fermava quando robots.txt vietava l’accesso e si fermava anche quando incontrava un blocco di rete.
Cloudflare ha successivamente rimosso il bot di Perplexity dal suo elenco dei bot verificati. Ha inoltre aggiunto regole di rilevamento gestite, pensate per bloccare il presunto crawling furtivo.
Perplexity ha respinto l’accusa. Secondo quanto riferito, l’azienda ha definito la versione di Cloudflare un argomento commerciale e ha sostenuto che il traffico identificato da Cloudflare non apparteneva a Perplexity.
Quel disaccordo non è scomparso semplicemente perché Cloudflare ora offre una fascia di affidabilità. Qualsiasi valutazione comportamentale dipende comunque dall’attribuzione, dalla progettazione della misurazione e dall’interpretazione delle policy.
L’attribuzione è particolarmente difficile quando un servizio AI utilizza più livelli di recupero delle informazioni. Una risposta potrebbe basarsi su un crawler dichiarato, un indice di terze parti, un browser guidato dall’utente o un’infrastruttura gestita da un altro fornitore.
Una CDN può osservare i modelli di richiesta su molti siti web, ma non può sempre vedere il rapporto commerciale o l’intento dell’utente dietro ogni richiesta.
Allo stesso modo, un operatore può considerare diversamente un recupero guidato dall’utente rispetto a un crawling autonomo su vasta scala. Un editore può respingere tale distinzione quando entrambe le azioni copiano la stessa pagina soggetta a restrizioni.
La fascia di affidabilità proposta da Cloudflare è più adatta a queste controversie di un’etichetta binaria. Può rappresentare modelli e identificare quali comportamenti hanno influenzato la valutazione.
Tuttavia, la spiegabilità deve andare oltre una breve etichetta. Gli operatori hanno bisogno di dettagli sufficienti per identificare le richieste, le policy, le finestre temporali e le misure correttive alla base di una valutazione inferiore.
Sarà importante anche una procedura di ricorso. Un’attribuzione errata potrebbe danneggiare un bot legittimo inducendo i clienti a bloccarlo su molti siti protetti da Cloudflare.
La concentrazione di autorità solleva un’altra preoccupazione. Cloudflare fornisce gli strumenti per le preferenze, osserva il traffico, calcola la valutazione di affidabilità e offre il prodotto di applicazione.
Questa integrazione rende pratico il ciclo di responsabilità. Ma conferisce anche a Cloudflare un’influenza significativa sui servizi automatizzati che possono raggiungere un’ampia parte del web.
L’azienda dovrebbe quindi chiarire come gestisce i casi ambigui, gli agenti con finalità miste, l’infrastruttura condivisa e le interruzioni temporanee. Un punteggio senza garanzie procedurali potrebbe trasformarsi in un sistema reputazionale opaco.
La responsabilità dei bot verificati richiede inoltre chiarezza simmetrica da parte degli operatori. Le aziende dovrebbero documentare i propri user agent, le finalità, gli intervalli IP, le chiavi di firma e le risposte alle restrizioni dei siti.
Identità separate per ricerca, addestramento e recupero guidato dall’utente possono ridurre l’ambiguità. Consentono agli editori di permettere una scoperta utile senza concedere lo stesso accesso a ogni finalità automatizzata.
Il caso Perplexity rimane un monito, non un verdetto universale. Cloudflare ha presentato osservazioni tecniche, mentre Perplexity ha contestato la titolarità e l’interpretazione del traffico.
Questo conflitto irrisolto è precisamente il motivo per cui il nuovo sistema necessita di prove trasparenti. La misurazione continua è preziosa solo quando le parti coinvolte possono esaminarne e contestarne le conclusioni.
La fascia di affidabilità lascia ancora senza risposta domande critiche
Cloudflare ha descritto ciò che vuole misurare, ma non abbastanza di come funzioneranno i giudizi risultanti.
L’azienda non ha pubblicato regole di ponderazione per le violazioni di robots.txt, le risposte 429 ignorate o altri segnali futuri. Non ha nemmeno definito i confini tra le sue fasce di affidabilità.
Senza questi dettagli, i clienti non possono prevedere in modo indipendente come il comportamento di un crawler si tradurrà in una valutazione. Anche gli operatori dei bot non dispongono di un obiettivo tecnico completo per la conformità.
Cloudflare afferma che valuterà modelli persistenti anziché incidenti isolati. È una protezione sensata, ma “persistente” richiede una finestra misurabile.
Un crawler che invia milioni di richieste può generare molte violazioni accidentali a un tasso percentuale minimo. Un crawler più piccolo può causare danni seri con molte meno richieste contro una singola origine.
I conteggi grezzi distorcerebbero questi casi. Anche le percentuali possono nascondere picchi gravi che sovraccaricano temporaneamente un sito vulnerabile.
Un modello di punteggio credibile necessita di contesto. Questo include volume delle richieste, capacità dell’origine, aggiornamento delle policy, istruzioni Retry-After, coerenza delle risposte e prove che il crawler abbia ricevuto il segnale.
Robots.txt introduce un’altra fonte di ambiguità. I file possono essere indisponibili, configurati in modo errato, contraddittori, modificati durante un crawl o alterati da un intermediario.
Bot Preference Sync di Cloudflare riduce parte della deriva di configurazione allineando le impostazioni del dashboard alle preferenze pubblicate. Non può eliminare ogni conflitto con regole personalizzate o con il comportamento dell’origine.
Anche HTTP 429 è imperfetto. Alcuni siti web generano questa risposta a causa di impostazioni di sicurezza generiche, infrastrutture condivise o traffico identificato erroneamente.
La specifica HTTP non richiede ai server di utilizzare 429 in condizioni di carico elevato. Un sito può interrompere le connessioni o impiegare altri controlli, lasciando al crawler un feedback meno esplicito.
Cloudflare ha quindi bisogno di garanzie contro il trattamento di ogni 429 come prova di cattiva condotta. La prova importante è il ripetuto mancato adattamento in condizioni in cui il segnale sia attribuibile e comprensibile.
Le soglie selezionate dai clienti introducono ulteriore complessità. Due siti web potrebbero trattare la stessa fascia di affidabilità in modo diverso, il che supporta il controllo locale ma complica le aspettative degli operatori.
Questo modello è probabilmente preferibile a una decisione universale di consentire o bloccare. Gli editori hanno modelli di business, limiti infrastrutturali e atteggiamenti diversi verso la scoperta tramite AI.
Un rivenditore può accogliere visite frequenti degli agenti che supportano le raccomandazioni di prodotto. Un editore finanziato dalla pubblicità può limitare i crawler di addestramento consentendo al contempo sistemi di ricerca che inviano referral misurabili.
Cloudflare dovrebbe preservare tali distinzioni anziché comprimere ogni comportamento in un’unica classificazione morale globale. Un’affidabilità specifica per finalità offrirebbe un controllo più utile di un singolo punteggio combinato.
L’azienda deve inoltre spiegare il recupero. Un operatore di bot dovrebbe sapere quanto rapidamente un comportamento corretto migliora la sua valutazione e se gli incidenti storici perdono peso nel tempo.
Altrimenti, la responsabilità continua può diventare una punizione permanente sotto un altro nome. Ciò contraddirebbe la descrizione di Cloudflare della fiducia come qualcosa che si costruisce attraverso comportamenti ripetuti.
La rendicontazione pubblica sarà la prova decisiva. Cloudflare afferma di voler condividere i punteggi tramite Radar, ma l’annuncio non specifica né la presentazione né le prove che saranno disponibili.
Un sistema pubblico credibile dovrebbe distinguere le osservazioni dalle conclusioni. Dovrebbe mostrare intervalli temporali pertinenti, livelli di confidenza, segnali misurati e cambiamenti sostanziali nel comportamento.
Dovrebbe inoltre etichettare le attribuzioni contestate. La visibilità di Cloudflare è ampia, ma la visibilità non elimina l’incertezza.
Cosa dovrebbero osservare ora i proprietari di siti web e gli operatori dei bot
Il prossimo test sarà verificare se Cloudflare trasformerà il proprio principio di responsabilità in un sistema operativo trasparente e contestabile.
Il primo segnale da osservare è il rilascio pubblico di Radar. Cloudflare afferma di voler pubblicare informazioni sull’affidabilità, rendendo il punteggio visibile oltre i suoi sistemi interni.
La domanda utile non è se Radar aggiungerà un altro badge. I lettori dovrebbero esaminare se ciascuna fascia di affidabilità includa comportamenti specifici, finestre temporali e prove sufficienti a spiegare i cambiamenti.
Una rendicontazione dettagliata rafforzerebbe l’affermazione centrale di Cloudflare. Una semplice etichetta la indebolirebbe, chiedendo al mercato di fidarsi del valutatore senza vedere la logica di valutazione.
Il secondo segnale è la disponibilità per i clienti. Cloudflare prevede di consentire ai clienti di scegliere la soglia che determina come viene gestito il traffico dei Verified Bot.
Quel rilascio rivelerà se l’affidabilità agisce come campo informativo, input per la creazione di regole o meccanismo di applicazione automatica. Queste opzioni comportano rischi operativi diversi.
Un campo visibile supporta la revisione umana, ma aggiunge lavoro. L’applicazione automatizzata scala meglio, sebbene gli errori possano bloccare l’indicizzazione della ricerca, il monitoraggio, i servizi di accessibilità o gli agenti guidati dall’utente.
I clienti dovrebbero inoltre osservare come il sistema interagisce con le allowlist esistenti. Storicamente, i bot verificati hanno ricevuto un trattamento favorevole perché Cloudflare li riconosceva già.
Una soglia di affidabilità dinamica può restringere questo privilegio quando il comportamento cambia. Può anche rendere più difficile la gestione delle policy se gli amministratori presumono che “verificato” significhi ancora universalmente sicuro.
Il terzo segnale è la risposta degli operatori. I principali fornitori di crawler possono convalidare il modello di Cloudflare adottando identità firmate, separando le finalità e pubblicando pratiche di conformità più chiare.
Possono anche contestare il modello con prove tecniche. Le controversie sull’attribuzione delle richieste, l’interpretazione di robots.txt e la gestione dei limiti di frequenza esporranno le debolezze della metodologia.
Osservate la documentazione che descrive il comportamento di backoff dopo le risposte 429. Osservate anche identificatori separati per ricerca, addestramento e recupero guidato dall’utente.
Queste pratiche rafforzerebbero l’idea che un’automazione responsabile possa operare attraverso standard web condivisi. Un’ambiguità persistente rafforzerebbe invece la necessità di un’applicazione di rete più severa.
Per i proprietari di siti web, la responsabilità continua dei bot verificati offre un modello di fiducia più realistico della verifica permanente. Riconosce che modifiche software ed errori operativi si verificano dopo l’approvazione.
Non dovrebbe sostituire i controlli diretti. Gli editori hanno ancora bisogno di preferenze chiare, limiti di frequenza adeguati, registri del traffico e regole di applicazione allineate ai propri obiettivi aziendali.
Per gli sviluppatori di bot, il messaggio è altrettanto diretto. L’identità crittografica può ottenere riconoscimento, ma la condotta continua determina se tale riconoscimento rimane utile.
I team che sviluppano agenti dovrebbero trattare le policy di accesso al web come requisiti di produzione. Dovrebbero testare il parsing di robots.txt, rispettare le restrizioni di accesso, implementare un backoff adattivo e monitorare i cambiamenti tra le distribuzioni.
Gli sviluppatori necessitano inoltre di registri duraturi che spieghino perché un agente ha effettuato l’accesso a una risorsa. Ciò diventa essenziale quando piattaforme, editori e intermediari non concordano sulla finalità di una richiesta.
I knowledge worker affrontano una questione correlata. Le risposte generate dagli agenti dipendono sempre più da sistemi di recupero delle informazioni che operano al di fuori della visuale dell’utente.
Un migliore livello di responsabilità può aiutare gli utenti a comprendere se tali sistemi accedano alle fonti in modo trasparente. Può inoltre rivelare quando la comodità dipende da comportamenti che gli editori hanno esplicitamente respinto.
Il web ora ha bisogno di più della semplice identificazione dei bot. Ha bisogno di un modo per collegare identità, finalità dichiarata, condotta osservata e conseguenze proporzionate.
Cloudflare ha proposto un sistema di questo tipo, ma la sua legittimità dipenderà da prove e dal giusto processo. L’azienda deve dimostrare che le fasce di affidabilità sono accurate, comprensibili e aperte alla correzione.
Nei prossimi mesi, osservate i punteggi pubblici, i controlli per i clienti e le risposte degli operatori dei crawler. Insieme, mostreranno se la responsabilità continua diventerà uno standard condiviso o un altro livello privato di controllo degli accessi.
I proprietari di siti web dovrebbero confrontare le future valutazioni di Cloudflare con i propri log prima di automatizzare l’applicazione. Gli operatori di bot dovrebbero verificare già ora la propria risposta sia a robots.txt sia a HTTP 429.
La questione centrale non è più se un bot possa dimostrare la propria identità. È se tale identità rimanga responsabile dopo migliaia di richieste, policy in evoluzione e inevitabili aggiornamenti software.
