Cloudflare valuta il vostro sito all'epoca degli agenti IA con lo Score Agent Readiness

I siti web hanno imparato a parlare con i browser, poi con i motori di ricerca. Cloudflare ritiene che ora debbano imparare a parlare con gli agenti IA e lancia uno strumento per aiutarli. Un'iniziativa ambiziosa, ma che solleva tante domande quante ne risolve.

Uno strumento di valutazione per un problema reale

Il punto di partenza di Cloudflare è solido. Quando un agente IA come Claude, Cursor o OpenCode cerca di accedere a un sito web per leggere documentazione, acquistare un prodotto o interagire con un'API, si trova davanti a un'infrastruttura pensata per gli esseri umani: HTML denso, moduli, sessioni di navigazione, captcha. Il risultato sono agenti lenti, costosi in token e spesso inesatti.

Per misurare l'entità del problema, Cloudflare ha scansionato i 200.000 domini più visitati del webfiltrando i reindirizzatori, i server pubblicitari e i servizi di tunneling per concentrarsi sui siti con cui gli agenti potrebbero ragionevolmente interagire.

Il bilancio è eloquente: il 78% dei siti ha un file robots.txtma la quasi totalità di essi è stata scritta per i crawler dei motori di ricerca tradizionali, non per gli agenti. Solo il 3,9% dei siti fornisce contenuto in Markdown quando richiesto. E gli standard emergenti come i Schede server MCP sono presenti in meno di 15 siti nell'intero dataset.

Svelata da Cloudflare, la soluzione isitagentready.com propone allora un punteggio strutturato attorno a quattro assi.

• La reperibilità (discoverability) verifica la presenza e la qualità del robots.txt, di un sitemap.xml, e degli header Link.
• Esso contenuto (content) valuta se il sito è in grado di servire una versione Markdown pulita su richiesta di un agente.
• Esso controllo accessi (bot access control) verifica se il sito esprime preferenze chiare su cosa le IA possono fare con i suoi contenuti.
• Infine, le capacità verificano la presenza di standard più avanzati come le MCP Server Cards, l'API Catalog o la scoperta OAuth affinché gli agenti possano autenticarsi correttamente.

Standard ancora agli albori e un'adozione quasi nulla

È qui che l'entusiasmo di Cloudflare va temperato. Molti degli standard messi in evidenza in questo score sono o in fase di stesura all'IETF, o proposte informali senza garanzia di adozione diffusa. L'API Catalog (RFC 9727), le MCP Server Cards o il Web Bot Auth sono standard recenti alcuni dei quali non hanno ancora raggiunto lo stato di RFC definitiva al momento della pubblicazione.

Questa situazione non è esclusiva di Cloudflare: questa è la realtà di un web in fase di evoluzione. Ma impone un'onestà che il post sul blog di Cloudflare adotta tende a minimizzare. Adottare oggi uno standard che sarà rielaborato o abbandonato fra diciotto mesi significa potenzialmente impegnarsi in un lavoro di integrazione che dovrà essere rifatto. I grandi attori, che hanno le risorse per seguire queste evoluzioni, ne trarranno vantaggio. Le squadre ridotte o gli sviluppatori indipendenti, meno.

Il caso di llms.txt è esemplare. Proposto nel settembre 2024, questo file standardizzato per presentare un sito a un LLM non è incluso di default nel punteggio di Cloudflare, solo come opzione. Per quale motivo? Lo standard è ancora oggetto di dibattito. È una decisione prudente, ma indica che anche Cloudflare non sa ancora esattamente su quali scommettere.

La negoziazione dei contenuti in Markdown: un guadagno reale e misurabile

Uno degli aspetti più concreti dell'iniziativa, e probabilmente il più immediatamente utile, riguarda la capacità di un server di rispondere in Markdown quando un agent invia un header Accept: text/markdownCloudflare afferma di aver misurato fino all'80% di riduzione del numero di token necessari per leggere una pagina, rispetto alla sua versione HTML.

Questa cifra merita di essere contestualizzata. L'HTML di una pagina di documentazione tecnica è spesso molto prolisso: navigazione, menu, script, tag annidati… tutto ciò rappresenta puro rumore per un LLM. Un file Markdown ben strutturato, è l'essenza del contenuto senza l'involucro. La conseguenza diretta è una riduzione del costo delle chiamate API per gli agenti, una riduzione della latenza e una maggiore probabilità che l'agente disponga del contesto completo senza troncare.

Per illustrare, Cloudflare spiega di aver testato il proprio sito di documentazione (developers.cloudflare.com) indirizzando un agente (Kimi-k2.5 via OpenCode) su diversi siti tecnici. Risultato: 31% di token consumati in meno e risposte corrette il 66% più veloci rispetto ad altri siti non ottimizzati. Queste cifre vanno prese con cautela, perché derivano da condizioni di test interne non verificate. Ma l'ordine di grandezza è coerente con ciò che si sa del sovraccarico strutturale dell'HTML.

L'implementazione tecnica su Cloudflare Docs: pragmatica e riproducibile

La parte più istruttiva del post è forse quella che descrive come Cloudflare ha rivisto la propria documentazione: l'approccio è interessante perché aggira un problema reale: a febbraio 2026, soltanto tre strumenti su sette testati (Claude Code, OpenCode e Cursor) inviano automaticamente l'header Accept: text/markdownPer gli altri, è necessaria un'alternativa.

La soluzione adottata combina due regole Cloudflare:

• Una riscrittura degli URL che trasforma una richiesta a /r2/get-started/index.md in richiesta a /r2/get-started/,
• E una trasformazione dell'header che aggiunge automaticamente Accept: text/markdown a queste richieste riscritte.

Risultato : qualsiasi agente può accedere alla versione Markdown di qualsiasi pagina semplicemente aggiungendo /index.md all'URL, senza dover gestire header speciali.

Altra decisione notevole: invece di un unico file llms.txt gigante (la documentazione di Cloudflare conta più di 5.000 pagine), ogni directory di primo livello dispone del proprio file, e il file radice punta a questi sotto-directory. Questo evita il “grep loop” descritto nell'articolo: un agente di fronte a un file troppo lungo per entrare nella sua finestra di contesto comincia a cercare per parole chiave, perde la visione d'insieme, moltiplica le chiamate e degrada la qualità delle sue risposte.

Anche la granularità è stata curata : circa 450 pagine che sono solo elenchi di link (pagine di indice) sono state escluse dal llms.txt, poiché non apportano alcun valore semantico a un LLM le cui pagine figlie sono già elencate singolarmente.

Un attore che attribuisce punteggi e vende la preparazione ai punteggi

La posizione di Cloudflare merita un esame attento. L’azienda pubblica lo score di riferimento per l’"agent readiness", integra questo punteggio nel suo URL Scanner, propone prompt pronti all'uso per correggere ogni punto di malfunzionamento… e vende i prodotti (Workers, Rules, Access) che permettono di implementare queste correzioni. Il isitagentready.com è esso stesso servito da Cloudflare ed espone un server MCP.

Non è necessariamente problematico: Google ha fatto la stessa cosa con Lighthouse e i Core Web Vitals, diventando al contempo giudice della performance e fornitore di strumenti per migliorarla (tramite Google Cloud, Firebase, ecc.). Ma ciò significa che i criteri del punteggio possono evolvere in funzione degli interessi commerciali dell'azienda tanto quanto delle reali esigenze degli agenti. Uno standard portato avanti da un'unica azienda, anche con buone intenzioni, rimane uno standard le cui direttrici possono essere influenzate.

È anche significativo che Cloudflare spinga attivamente standard legati ai pagamenti agentici (x402, Universal Commerce Protocol), di cui alcuni coinvolgono partner diretti come Coinbase. Questi standard non sono ancora conteggiati nello score, ma la loro presenza nello strumento segnala già una direzione.

Cosa possono fare concretamente oggi gli sviluppatori

Nonostante queste riserve, diverse azioni offrono un ritorno sull'investimento chiaro e immediato, indipendentemente dall'evoluzione degli standard:

• Fornire Markdown su richiesta è tecnicamente semplice, riduce i costi per i consumatori dell'API e migliora la qualità delle risposte degli agenti. È la priorità.
• Curare il robots.txt per gli agenti IA (aggiungendo direttive per i crawler come GPTBot, ClaudeBot, CCBot, ecc.) è una buona igiene che non costa nulla e chiarisce i diritti di accesso.
• Strutturare un llms.txt per sezione per i siti con molti contenuti è una buona pratica documentale che avvantaggia sia gli agenti sia le persone che cercano di comprendere rapidamente l'architettura di un sito.

Al contrario, implementare MCP Server Cards o API Catalogs per un sito che non ha ancora API pubbliche o un caso d'uso agent chiaramente definito sarebbe come costruire una sala d'attesa prima di avere visitatori.

L'adozione come indicatore di mercato, non come obbligo

Il vero valore dell'iniziativa di Cloudflare potrebbe essere nel dataset Radar che introduce: un monitoraggio settimanale dell'adozione di ogni standard tra i 200.000 siti più visitati, segmentato per categoria di dominio. Questo tipo di dato permetterà di misurare se gli standard "vincono" davvero, oppure se la maggior parte dei siti rimane passiva aspettando che gli agenti si adattino a loro, come si adattano già all'HTML da trent'anni.

La risposta a questa domanda dirà molto sulla dinamica di potere tra gli editori di siti e gli sviluppatori di agenti. Se gli agenti più popolari finiranno per integrare capacità di parsing HTML sufficientemente robuste, la pressione sui siti per adattarsi diminuirà. Se invece i costi e i tempi legati al consumo di HTML non ottimizzato diventeranno un vantaggio competitivo misurabile per i siti che si adattano, l'adozione seguirà naturalmente.

L'articolo «Cloudflare valuta il vostro sito all'epoca degli agenti IA con lo Score Agent Readiness" è stato pubblicato sul sito Abondance.