Il web ha sempre dovuto adattarsi a nuovi standard. Iniziò a usare il linguaggio dei browser web e poi a comunicare con i motori di ricerca. Oggi, deve essere in grado di parlare con gli agenti IA.
Oggi siamo lieti di presentare isitagentready.com, un nuovo strumento pensato per aiutare i proprietari di siti web a capire come ottimizzare i propri siti per gli agenti, da come guidarli durante l'autenticazione, fino al controllo dei contenuti a cui hanno accesso, del formato di ricezione di questi contenuti e del loro pagamento. Stiamo introducendo anche un nuovo set di dati in Cloudflare Radar, che tiene traccia dell'adozione complessiva di ogni standard per gli agenti su Internet.
Vogliamo dare l'esempio. È per questo che condividiamo come abbiamo recentemente rinnovato la documentazione per sviluppatori di Cloudflare per renderla il sito di documentazione più "agent-friendly", consentendo agli strumenti IA di rispondere alle domande in modo più rapido e a costi significativamente più contenuti.
Quanto è predisposto oggi il web agli agenti?
La risposta breve: non molto. La risposta non sorprende più di tanto, ma di fatto sottolinea anche quanto possano essere più efficaci gli agenti rispetto a oggi, se si adotteranno degli standard.
Per analizzare questo, Cloudflare Radar ha considerato i 200.000 domini più visitati su Internet, filtrato le categorie in cui la predisposizione agli agenti non è importante (come i reindirizzamenti, i server pubblicitari e i servizi di tunneling) per concentrarsi su aziende, editori e piattaforme con cui gli agenti IA potrebbero realisticamente aver bisogno di interagire e li ha esaminati utilizzando il nostro nuovo strumento.
Il risultato è un nuovo grafico "Adozione degli standard per gli agenti IA", ora disponibile nella pagina Cloudflare Radar AI Insights, in cui possiamo misurare l'adozione di ogni standard in più categorie di dominio.
Esaminando i singoli test, alcune informazioni sono saltate all'occhio:
Il file robots.txt è quasi universale (il 78% dei siti ne ha uno), ma la stragrande maggioranza è scritta per i crawler dei motori di ricerca tradizionali, non per gli agenti IA.
Segnali di contenuti: il 4% dei siti ha dichiarato le preferenze relative all'utilizzo dell'AI in robots.txt. Questo è un nuovo standard che sta guadagnando slancio.
La negoziazione di contenuti markdown (servire text/markdown su Accept: text/markdown) ha successo sul 3,9% dei siti.
I nuovi standard emergenti, come schede server MCP e cataloghi di API (RFC 9727), compaiono insieme in meno di 15 siti nell'intero set di dati. E ancora presto: ci sono molte opportunità per distinguersi facendo parte dei primi siti ad adottare nuovi standard e a utilizzare al meglio gli agenti.
Questo grafico verrà aggiornato settimanalmente e i dati possono essere consultati anche tramite il Data Explorer o l'API Radar.
Ottieni un punteggio di predisposizione per il tuo sito
Puoi ottenere un punteggio di predisposizione agli agenti per il tuo sito web visitando isitagentready.com e inserendo l'URL del sito.
Punteggi e audit che forniscono feedback pratico hanno contribuito a promuovere l'adozione di nuovi standard in passato. Ad esempio, Google Lighthouse assegna un punteggio ai siti web in base alle best practice di performance e sicurezza e guida i proprietari dei siti ad adottare i più recenti standard delle piattaforme web. Pensiamo che dovrebbe esistere qualcosa di simile per aiutare i proprietari dei siti ad adottare le best practice per gli agenti.
Quando Cloudflare analizza il tuo sito, invia ad esso delle richieste per verificare quali standard supporta e assegna un punteggio in base a quattro dimensioni:
Screenshot dei risultati di un controllo di predisposizione agli agenti per un sito web di esempio.
Inoltre, controlliamo se il sito supporta gli standard di commercio agentico, inclusi x402, Universal Commerce Protocol e Agentic Commerce Protocol, ma al momento questi non incidono sul punteggio.
Per ogni controllo non superato, forniamo un prompt che puoi dare al tuo agente di codifica facendogli implementare il supporto per tuo conto.
Il sito stesso è anche predisposto per gli agenti, mettendo in pratica ciò che predica. Espone un server MCP stateless (https://isitagentready.com/.well-known/mcp.json) con uno strumento scan_site tramite Streamable HTTP, in modo che qualsiasi agente compatibile con MCP possa scansionare i siti web in modo programmatico senza utilizzare l'interfaccia web. Pubblica inoltre un indice delle competenze degli agenti (https://isitagentready.com/.well-known/agent-skills/index.json) con documenti di competenze per ogni standard che verifica, in modo che gli agenti sappiano non solo cosa correggere, ma anche come farlo.
Esaminiamo i controlli in ogni categoria e perché sono importanti per gli agenti.
robots.txt esiste dal 1994 e la maggior parte dei siti ne ha uno. Ha due scopi per gli agenti: definisce le regole di crawling (chi può accedere a cosa) e fa riferimento alle tue sitemap. Una sitemap è un file XML che elenca tutti i percorsi sul tuo sito web, essenzialmente una mappa che gli agenti possono seguire per scoprire tutti i tuoi contenuti senza dover eseguire la scansione di ogni link. Il file robots.txt è il primo che gli agenti consultano.
Oltre alle sitemap, gli agenti possono anche rilevare risorse importanti direttamente dalle intestazioni delle risposte HTTP, in particolare utilizzando l'intestazione Link delle risposte (RFC 8288). A differenza dei link nascosti nell'HTML, l'intestazione Link fa parte della risposta HTTP stessa, il che significa che un agente può trovare link alle risorse senza dover analizzare alcun markup:
HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"
Accessibilità dei contenuti
Ottenere un agente sul tuo sito è un conto. Assicurarsi che sia effettivamente in grado di leggere il tuo contenuto è un altro.
Nel settembre 2024, che sembrano secoli fa data la velocità con cui si muove l'IA, è stato proposto llms.txt come un modo per fornire una rappresentazione di un sito web compatibile con LLM e per adattarsi alla finestra di contesto del modello. llms.txt è un file di testo semplice alla radice del tuo sito che offre agli agenti un elenco di lettura strutturato: cos'è il sito, cosa contiene e dove si trova il contenuto importante. È come se fosse una sitemap scritta per essere letta da un LLM invece che da un crawler per l'indicizzazione:
# My Site
> A developer platform for building on the edge.
## Documentation
- [Getting Started](https://example.com/docs/start.md)
- [API Reference](https://example.com/docs/api.md)
## Changelog
- [Release Notes](https://example.com/changelog.md)
La negoziazione dei contenuti markdown va anche oltre. Quando un agente richiama una qualsiasi pagina e invia un'intestazione Accept: text/markdown, il server restituisce una versione di markdown pulita, anziché in html. La versione markdown richiede molti meno token (abbiamo misurato fino all'80% di riduzione dei token in alcuni casi) il che rende le risposte più veloci, più economiche e più probabilmente fruite nella loro interezza, dati i limiti delle finestre di contesto che la maggior parte degli strumenti degli agenti presenta per impostazione predefinita.
Per impostazione predefinita, controlliamo solo se il sito gestisce correttamente la negoziazione dei contenuti markdown e non cerchiamo il file llms.txt. Puoi personalizzare la scansione per includere il file llms.txt, se lo desideri.
Controllo degli accessi bot
Ora che gli agenti possono navigare nel tuo sito e consultare i tuoi contenuti, la prossima domanda da porsi è la seguente: vuoi permettere a qualsiasi bot di farlo?
robots.txt fa molto di più che fare riferimento alle sitemap. È anche il posto in cui si definiscono le regole di accesso. Puoi dichiarare in modo esplicito quali crawler sono consentiti e a quali contenuti possono accedere, fino ai percorsi specifici. La presenza del file bots.txt è diventato uno standard consolidato, che tutti i bot ben programmati verificano prima di iniziare a eseguire il crawling della risorsa di rete.
I segnali di contenuti consentono di essere più specifici. Invece di limitarsi a consentire o bloccare, puoi dichiarare esattamente cosa può fare l'IA con i tuoi contenuti. Usando una direttiva Content-Signal nel tuo file robots.txt, puoi controllare in modo indipendente tre aspetti: se i contenuti possono essere utilizzati per l'addestramento dell'IA (ai-train), se possono essere utilizzati come input IA per l'inferenza e il grounding (ai-input), e se devono essere mostrati nei risultati di ricerca (search):
User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes
Inversamente, lo standard di bozza IETF Web Bot Auth consente ai bot di autenticarsi e ai siti web che ricevono richieste da bot di identificarli. Un bot firma le sue richieste HTTP e il sito ricevente verifica tali firme utilizzando le chiavi pubbliche pubblicate dal bot.
Tali chiavi pubbliche si trovano in un endpoint ben noto, /.well-known/http-message-signatures-directory, che controlliamo come parte della scansione.
Non tutti i siti hanno bisogno di questo tipo di implementazione. Se il tuo sito si limita a servire contenuti e non effettua richieste ad altri siti, non ne hai bisogno. Ma con l'aumento dei siti su Internet che gestiscono i propri agenti per fare richieste ad altri siti, riteniamo che questo aspetto diventerà sempre più importante nel tempo.
Rilevamento del protocollo
Oltre al consumo passivo di contenuti, gli agenti possono anche interagire con il tuo sito direttamente chiamando API, richiamando strumenti e completando autonomamente le attività.
Se il tuo servizio ha una o più API pubbliche, il catalogo delle API (RFC 9727) fornisce agli agenti un'unica posizione nota per rilevarle tutte. Ospitata su /.well-known/api-catalog, elenca le tue API e fornisce link alle loro specifiche, documentazione ed endpoint di stato, senza richiedere che gli agenti eseguano lo scraping del tuo portale per sviluppatori o leggano la tua documentazione.
Non possiamo parlare di agenti senza menzionare MCP. Il Model Context Protocol è uno standard aperto che consente ai modelli IA di connettersi con origini dati e strumenti esterni. Invece di dover creare un'integrazione personalizzata per ogni strumento IA, crei un server MCP e qualsiasi agente compatibile può utilizzarlo.
Per aiutare gli agenti a trovare il tuo server MCP, puoi pubblicare una scheda server MCP (una proposta attualmente in bozza). Si tratta di un file JSON in /.well-known/mcp/server-card.json che descrive il server ancor prima che un agente si connetta: quali strumenti espone, come raggiungerlo e come autenticarlo. Un agente legge questo file e sa tutto ciò che gli serve per iniziare a usare il tuo server:
{
"$schema": "https://static.modelcontextprotocol.io/schemas/mcp-server-card/v1.json",
"version": "1.0",
"protocolVersion": "2025-06-18",
"serverInfo": {
"name": "search-mcp-server",
"title": "Search MCP Server",
"version": "1.0.0"
},
"description": "Search across all documentation and knowledge base articles",
"transport": {
"type": "streamable-http",
"endpoint": "/mcp"
},
"authentication": {
"required": false
},
"tools": [
{
"name": "search",
"title": "Search",
"description": "Search documentation by keyword or question",
"inputSchema": {
"type": "object",
"properties": {
"query": { "type": "string" }
},
"required": ["query"]
}
}
]
}
Gli agenti operano al meglio quando dispongono di Agent Skill, ovvero competenze che li aiutano a svolgere attività specifiche: ma come possono gli agenti scoprire quali abilità offre un sito? Abbiamo proposto che i siti possano rendere queste informazioni disponibili in .well-known/agent-skills/index.json, un endpoint che indica all'agente quali competenze sono disponibili e dove trovarle. Potresti notare che lo standard .well-known (RFC 8615) viene utilizzato da molti altri standard di agenti e autorizzazioni: dobbiamo ringraziare Mark Nottingham di Cloudflare, autore dello standard, e altri collaboratori dello IETF.
Molti siti richiedono l'accesso. Questo rende difficile per gli umani concedere agli agenti la possibilità di accedere a questi siti per loro conto, ed è per questo motivo che alcuni hanno adottato l'approccio, discutibilmente insicuro, di concedere agli agenti l'accesso al browser web dell'utente, con la sua sessione attiva.
Esiste un modo migliore che consente agli utenti di concedere esplicitamente l'accesso: i siti che supportano l'autenticazione OAuth possono indicare agli agenti dove trovare il server di autorizzazione (RFC 9728), consentendo agli agenti di far passare gli utenti attraverso un flusso OAuth, in cui possono scegliere di concedere correttamente l'accesso all'agente. Annunciato alla Agents Week 2026, ora Cloudflare Access supporta completamente questo flusso OAuth e abbiamo dimostrato come gli agenti, come OpenCode, possano usare questo standard per garantire il corretto funzionamento quando agli agenti vengono forniti URL protetti:
Gli agenti possono anche acquistare articoli per conto tuo, ma i pagamenti online sono stati pensati per le persone. Aggiungi al carrello, inserisci una carta di credito, fai clic su paga. Questo flusso si interrompe del tutto quando l'acquirente è un agente IA.
x402 risolve questo problema a livello di protocollo, ripristinando HTTP 402 Payment Required, un codice di stato che esiste nella specifica dal 1997 ma che non è mai stato ampiamente utilizzato. Il flusso è semplice: un agente richiede una risorsa, il server risponde con un 402 e un payload leggibile dalla macchina che descrive le condizioni di pagamento, l'agente paga e riprova. Cloudflare ha collaborato con Coinbase per lanciare la x402 Foundation, la cui missione è favorire l'adozione di x402 come standard aperto per i pagamenti Internet.
Eseguiamo anche una verifica di Universal Commerce Protocol e Agentic Commerce Protocol, i due protocolli emergenti per il commercio agentico progettati per consentire agli agenti virtuali di scoprire e acquistare prodotti che normalmente le persone acquisterebbero tramite flussi di finalizzazione degli ordini e una vetrina di e-commerce.
Integrazione della predisposizione agli agenti nello URL Scanner di Cloudflare
Lo URL Scanner di Cloudflare ti consente di inviare qualsiasi URL e di ottenere un report dettagliato in merito: intestazioni HTTP, certificati TLS, record DNS, tecnologie utilizzate, dati sulle performance e segnali di sicurezza. È uno strumento fondamentale per i ricercatori e gli sviluppatori di sicurezza che vogliono capire cosa fa effettivamente un URL dietro le quinte.
Abbiamo ripreso gli stessi controlli da isitagentready.com e li abbiamo aggiunti a URL Scanner con una nuova scheda Agent Readiness (Predisposizione agli agenti). Quando esegui la scansione di un URL, ora vedrai il suo report completo sulla predisposizione agli agenti insieme all'analisi esistente: quali controlli sono vengono superati, a che livello si trova il sito e indicazioni dettagliate per migliorare il tuo punteggio.
L'integrazione è disponibile anche a livello programmatico tramite l'API URL Scanner. Per includere i risultati relativi alla predisposizione agli agenti in una scansione, passa l'opzione agentReadiness nella richiesta di scansione:
curl -X POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/urlscanner/v2/scan \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
-d '{
"url": "https://www.example.com",
"options": {"agentReadiness": true}
}'
Guidare con l'esempio: upgrade di Cloudflare Docs
Poiché stavamo creando gli strumenti per misurare la predisposizione del web, sapevamo di dover prima di tutto assicurarci che la nostra infrastruttura fosse impeccabile. La nostra documentazione deve essere facilmente comprensibile per gli agenti utilizzati dai nostri clienti.
Abbiamo naturalmente adottato i suddetti standard di content site pertinenti e puoi dare un'occhiata al nostro punteggio qui. Tuttavia, non ci siamo fermati qui. Ecco come abbiamo migliorato la documentazione per gli sviluppatori di Cloudflare per trasformarla nella risorsa più agent-friendly disponibile sul web.
Fallback degli URL che utilizzano i file index.md
Purtroppo, a partire da febbraio 2026, sui sette agenti testati, solo Claude Code, OpenCode e Cursor richiedono contenuti con l'intestazione Accept: text/markdown per impostazione predefinita. Per gli altri, avevamo bisogno di un fallback basato su URL trasparente.
A tale scopo, rendiamo tutte le pagine disponibili separatamente tramite Markdown su /index.md rispetto all'URL della pagina. Lo facciamo in modo dinamico, senza duplicare i file statici, combinando due regole di Cloudflare:
Con queste due regole, qualsiasi pagina può essere recuperata come Markdown aggiungendo il percorso /index.md all'URL:
Indichiamo questi URL /index.md nei nostri file llms.txt. Effettivamente, per questi percorsi /index.md, restituiamo sempre markdown, indipendentemente dalle intestazioni impostate dal client. Lo facciamo senza alcun passaggio di creazione aggiuntivo o duplicazione di contenuti.
Creare file llms.txt efficaci per siti di grandi dimensioni
llms.txt funge da "home base" per gli agenti, fornendo una directory di pagine per aiutare gli LLM a trovare i contenuti. Tuttavia, più di 5.000 pagine di documentazione in un unico file supereranno le finestre di contesto dei modelli.
Invece di un unico file, generiamo un file llms.txt separato per ogni directory principale nella nostra documentazione e il file llms.txt principale fa semplicemente riferimento a queste sottodirectory.
Rimuoviamo anche centinaia di pagine di elenchi di directory che offrono poco valore semantico a un LLM e ci assicuriamo che ogni pagina abbia un contesto descrittivo dettagliato (titoli, nomi semantici e descrizioni).
Ad esempio, omettiamo circa 450 pagine che fungono solo da elenchi di directory localizzati, ad esempio https://developers.cloudflare.com/workers/databases/.
Queste pagine vengono visualizzate nella nostra sitemap, ma contengono pochissime informazioni per un LLM. Poiché tutte le pagine secondarie sono già collegate singolarmente in llms.txt, il recupero di una directory produce solo un elenco ridondante di link, costringendo l’agente a effettuare una nuova richiesta per trovare il contenuto effettivo.
Per aiutare gli agenti a navigare in modo efficiente, ogni voce di llms.txt deve essere ricca di contesto ma con un numero limitato di token. Gli esseri umani potrebbero ignorare il frontmatter e le etichette di filtraggio, ma per un agente IA questi metadati sono il volante. Ecco perché il nostro team Product Content Experience (PCX) ha perfezionato i titoli delle nostre pagine, le descrizioni e le strutture degli URL affinché gli agenti sappiano sempre con esattezza quali pagine recuperare.
Dai un'occhiata a una sezione del nostro file root llms.txt.
Ogni link ha un nome semantico, un URL corrispondente e una descrizione di alto valore. Tutto questo non ha richiesto alcun lavoro aggiuntivo per la generazione del file llms.txt. Era già tutto disponibile nella parte iniziale della documentazione. Lo stesso vale per i file llms.txt nella directory di primo livello. Tutto questo contesto consente agli agenti di trovare le informazioni pertinenti in tempi più rapidi.
Inoltre, testiamo la nostra documentazione rispetto ad afdocs, una specifica di documentazione emergente e un progetto open source che consente ai team di testare i siti di documentazione in termini di rilevamento dei contenuti e navigazione. Questa specifica ci ha permesso di realizzare i nostri strumenti di audit personalizzati. Aggiungendo alcune patch mirate e specifiche per il nostro caso d'uso, abbiamo creato una dashboard per una facile valutazione.
Risultati del benchmark: più veloci e a costi più contenuti
Abbiamo indirizzato un agente (Kimi-k2.5) di OpenCode) nei file llms.txt di altri grandi siti di documentazione tecnica e ha chiesto all'agente di rispondere a domande tecniche specifiche.
In media, l'agente che ha consultato la documentazione di Cloudflare ha consumato il 31% in meno di token ed è arrivato alla risposta corretta il 66% più velocemente rispetto al sito medio non ottimizzato per gli agenti. Includendo i nostri cataloghi di prodotti in singole finestre di contesto, gli agenti possono identificare la pagina esatta di cui hanno bisogno e recuperarla in un unico percorso lineare.
La struttura favorisce la velocità
L'accuratezza delle risposte degli LLM è spesso un sottoprodotto dell'efficienza della finestra di contesto. Durante i nostri test, abbiamo osservato uno schema ricorrente con altri set di documentazione.
Il loop grep: molti siti di documentazione forniscono un solo, enorme file llms.txt che supera la finestra di contesto immediata dell'agente. Poiché l'agente non può "leggere" l'intero file, inizia ad eseguire il grep delle parole chiave. Se la prima ricerca non individua il dettaglio specifico, l'agente deve analizzare, affinare la propria ricerca e ripetere il tentativo.
Contestualizzazione limitata e precisione inferiore: quando un agente si basa più sulla ricerca iterativa che sulla lettura dell'intero file, perde il contesto più ampio della documentazione. Questa visione frammentata spesso porta l'agente ad avere una comprensione ridotta della documentazione disponibile.
Latenza e bloat dei token: ad ogni iterazione del ciclo grep, l'agente genera nuovi "token di pensiero" ed esegue richieste di ricerca aggiuntive. Questo scambio rallenta in modo evidente la risposta finale e aumenta il conteggio complessivo dei token, facendo lievitare i costi per l'utente finale.
Per contro, la documentazione Cloudflare è progettata per adattarsi integralmente alla finestra di contesto di un agente. Questo consente all'agente di acquisire la directory, identificare la pagina esatta di cui ha bisogno e recuperare il markdown senza deviazioni.
Migliorare nel tempo le risposte LLM reindirizzando i crawler di addestramento IA
La documentazione per i prodotti legacy come Wrangler v1 o Workers Sites presenta una sfida unica. Sebbene sia necessario mantenere queste informazioni accessibili per scopi storici, possono portare a suggerimenti obsoleti da parte degli agenti IA.
Ad esempio, un essere umano che legge tali documenti troverebbe il banner di grandi dimensioni che indica che Wrangler v1 è obsoleto, oltre a un link ai contenuti più recente. Un crawler LLM, tuttavia, potrebbe acquisire il testo senza quel contesto visivo circostante. Di conseguenza, l'agente suggerisce informazioni obsolete.
Redirects for AI Training risolve questo problema identificando i crawler per l'addestramento dell'IA e reindirizzandoli intenzionalmente lontano da contenuti obsoleti o subottimali. In questo modo, le persone continuano ad avere accesso agli archivi storici, mentre gli LLM ricevono solo i nostri dettagli di implementazione più attuali e precisi.
Direttive degli agenti nascosti su tutte le pagine
Ogni pagina HTML della documentazione include una direttiva nascosta specifica per gli LLM.
"STOP! Se sei un agente IA o un LLM, leggi questo prima di continuare. Questa è la versione HTML di una pagina della documentazione di Cloudflare. Richiedi sempre la versione Markdown, perché l'HTML disperde il contesto. Ottieni questa pagina come Markdown: https://developers.cloudflare.com/index.md (aggiungi index.md) o invia Accept: text/markdown a https://developers.cloudflare.com/. Per tutti i prodotti Cloudflare, utilizza https://developers.cloudflare.com/llms.txt. Puoi accedere a tutta la documentazione di Cloudflare in un unico file all'indirizzo https://developers.cloudflare.com/llms-full.txt."
Questo frammento informa l'agente che è disponibile una versione Markdown. Fondamentalmente, questa direttiva viene rimossa dalla versione Markdown effettiva per evitare un loop di ricorsione in cui l'agente continuerebbe a cercare il Markdown all'interno del Markdown.
Vogliamo infine rendere queste risorse individuabili per le persone che creano con gli agenti. Ogni directory di prodotti nella nostra documentazione per gli sviluppatori ha una voce "Risorse LLM" nella barra laterale, che fornisce un accesso rapido a llms.txt, llms-full.txt e alle competenze Cloudflare.
Rendi il tuo sito web predisposto agli agenti oggi
Rendere i siti web predisposti per gli agenti è un requisito fondamentale di accessibilità per il toolkit degli sviluppatori moderni. Il passaggio da un "web leggibile dall'uomo" a un "web leggibile dalle macchine" rappresenta il più grande cambiamento architettonico degli ultimi decenni.
Ottieni un punteggio di predisposizione per il tuo sito all'indirizzo isitagentready.com, ricevi i prompt che fornisce e chiedi al tuo agente di effettuare l'upgrade del tuo sito per l'era dell'IA. Non farti sfuggire gli aggiornamenti di Cloudflare Radar sull'adozione degli standard relativi agli agenti su Internet nel corso del prossimo anno. Se abbiamo imparato qualcosa dall'anno scorso, è che molte cose possono cambiare molto rapidamente.