Markdown per agenti AI: il nuovo linguaggio del web

Il web è sempre stato costruito per gli esseri umani. Pagine HTML cariche di menu, script, banner pubblicitari, tag di tracciamento: tutto pensato per un browser che sa come renderizzare ogni elemento visivamente. Per anni la SEO si è occupata di risolvere o aggirare i problemi di accessibilità dei contenuti, molti dei quali sono stati progressivamente superati grazie all’evoluzione delle tecniche di crawling, in particolare di Google. Con l’avvento di crawler AI, agenti autonomi e assistenti conversazionali il problema è tornato a presentarsi sotto una forma diversa: per loro quella struttura a base di contenuti annegati nel codice è rumore puro.

In questo scenario sta emergendo un concetto che chi lavora in ambito SEO, content e digital marketing non può più ignorare: il markdown per agenti. Non è un formato nuovo in assoluto, ma il modo in cui viene usato, proposto come standard e servito dall’infrastruttura web lo rende uno dei potenziali elementi chiave del passaggio dal web tradizionale al web agentico. Un passaggio che, come vedremo, è già in corso – ma molto più disomogeneo di quanto i titoli entusiasti degli ultimi mesi lascino intendere.

Cos’è il markdown (e perché interessa agli agenti AI)

Il markdown è un linguaggio di formattazione testuale inventato nel 2004 da John Gruber. La sua logica è semplice: usare caratteri ASCII per indicare struttura e gerarchia di un testo, senza bisogno di tag complessi. Un ## indica un titolo di secondo livello, un asterisco crea un elemento di lista, due asterischi mettono in grassetto. Leggibile da un umano anche senza rendering, interpretabile da una macchina con estrema efficienza.

Per molto tempo è rimasto uno strumento da sviluppatori: README su GitHub, documentazione tecnica, note personali. Poi gli LLM – i modelli linguistici alla base di ChatGPT, Claude, Gemini e degli altri assistenti AI – hanno iniziato a usarlo come formato preferenziale per la propria comunicazione. Non è un caso: il markdown è strutturato quanto basta per dare contesto semantico al testo, ma abbastanza leggero da non sprecare token – le unità minime di elaborazione su cui si basa il lavoro di un modello linguistico, e che hanno un costo reale a ogni chiamata.

Alimentare un agente AI con una pagina HTML grezza è un po’ come dargli da leggere un manuale con metà delle parole sostituite da codice burocratico: capisce comunque, ma a un costo molto più alto. I numeri lo confermano in modo netto: questo post del blog di Cloudflare pesa 16.180 token in HTML e solo 3.150 token convertiti in markdown – una riduzione dell’80%. Moltiplicato per milioni di richieste al giorno, il risparmio computazionale – e quindi economico – diventa enorme.

Questo potrebbe avere conseguenze dirette per chi si occupa di SEO e contenuti digitali. Il posizionamento tradizionale su Google rimane importante, ma accanto ad esso sta emergendo un nuovo tipo di visibilità: quella nei confronti degli agenti AI che sintetizzano contenuti, rispondono a domande degli utenti, o alimentano sistemi di ricerca generativa.

Le applicazioni concrete: non solo un formato, un ecosistema

L’adozione del markdown nel web agentico si sta articolando in almeno tre filoni distinti, con maturità e impatto molto diversi tra loro.

1. Il file llms.txt: una proposta interessante, con limiti reali

La proposta llms.txt, formulata da Jeremy Howard nel settembre 2024, suggerisce di aggiungere un file /llms.txt in formato markdown alla radice dei siti web, per fornire agli LLM un punto di accesso strutturato e curato alle informazioni del sito. Il file llms.txt è un documento che solitamente presenta una sezione introduttiva volta alla descrizione del sito, seguita da link alle principali pagine interne corredati da una sintetica descrizione del loro contenuto.

L’analogia con robots.txt è suggestiva: anche quello è un file di testo collocato nella root del sito, pensato per guidare i robot. Ma mentre robots.txt è uno standard consolidato rispettato da tutti i principali crawler – almeno quelli “buoni” – llms.txt è ancora una proposta che, almeno per il momento, non risulta utilizzata dai principali sistemi AI. Inoltre, lo scopo di llms.txt non è quello di interdire aree più o meno circoscritte del sito alla scansione, bensì quello di fornire una mappa per l’accesso alle risorse più importanti del sito, un po’ come fa la sitemap.xml.

A metà 2025, John Mueller di Google ha dichiarato esplicitamente che i sistemi AI di Google non usano llms.txt – e lo stesso vale per i crawler di OpenAI e Anthropic, che non lo richiedono in volumi significativi. La ricerca più rigorosa disponibile è quella di SE Ranking (novembre 2025), condotta su circa 300.000 domini: il 10,13% aveva un file llms.txt, con una distribuzione sorprendentemente piatta tra fasce di traffico – siti piccoli al 9,88%, medi al 10,54%, grandi all’8,27%. Non c’è quindi una correlazione tra autorevolezza del sito e adozione del file. Soprattutto, rimuovendo llms.txt come variabile dal modello predittivo delle citazioni AI, l’accuratezza del modello migliorava: il file sembra introdurre rumore più che un segnale. Tra i 50 domini più citati nei risultati di AI search, solo uno aveva un file llms.txt.

Un test indipendente di OtterlyAI ha rilevato che, su 62.100 visite totali di crawler AI in 90 giorni, solo 84 erano richieste dirette al file llms.txt – circa lo 0,1% del traffico. Un’analisi di Ahrefs (maggio 2026) su oltre 137.000 domini conferma il quadro: il 97% dei siti dotati di un llms.txt valido non ha ricevuto alcuna richiesta del file nel mese osservato.

Vale però la pena ricordare che un endorsement al file llms.txt arriva da Addy Osmani, Director of Engineering di Google Cloud AI, che in un articolo dello scorso aprile sull’Agentic Engine Optimization (da non confondere con l’Answer Engine Optimization, con cui condivide l’acronimo AEO) ne caldeggia l’adozione, spiegando anche come andrebbe costruito. Lo stesso Osmani, però, circoscrive il consiglio: il suo pubblico sono gli sviluppatori e la documentazione tecnica consumata dai coding agent, e precisa che Google Search non raccomanda ufficialmente llms.txt come standard.

Inoltre, la sua presenza e correttezza formale viene considerata dalla nuova categoria Agentic Browsing di Lighthouse (introdotta con la versione 13.3), che valuta la predisposizione del sito all’interazione con i bot. Il peso di questo controllo va però ridimensionato: la categoria è dichiaratamente sperimentale, non produce un punteggio 0-100 ma un semplice rapporto di controlli superati, e l’assenza del file non è considerata un errore – viene marcata come Not Applicable, perché il file resta opzionale. Nello stesso periodo, peraltro, Google Search ha pubblicato una guida che elenca llms.txt tra le cose non necessarie per comparire nelle funzionalità di AI generativa: due team di Google, due indicazioni divergenti – il segnale più eloquente di quanto lo scenario sia ancora fluido.

2. Il file AGENTS.md: istruzioni per i coding agent

Nel mondo dello sviluppo software, un altro standard parallelo sta prendendo piede: il file AGENTS.md. Si tratta di un formato semplice e aperto per guidare i coding agent – un README dedicato agli agenti, un posto chiaro e prevedibile dove fornire il contesto e le istruzioni necessari affinché gli strumenti AI possano lavorare su un progetto.

La distinzione rispetto al README.md tradizionale è precisa: il README è per gli umani – descrizioni del progetto, istruzioni di installazione, guide per i contributor. AGENTS.md contiene il contesto più dettagliato di cui i coding agent hanno bisogno: build step, test, convenzioni di codice, che potrebbero appesantire un README o non essere rilevanti per i contributor umani.

Il formato – proposto da OpenAI nell’agosto 2025 e da dicembre 2025 gestito dall’Agentic AI Foundation della Linux Foundation – è adottato, secondo i dati pubblicati su agents.md, da oltre 60.000 progetti open source, ed è supportato nativamente da strumenti come Codex, GitHub Copilot, Cursor, Devin, Windsurf e molti altri. L’eccezione rilevante è Claude Code, che legge solo il proprio file CLAUDE.md: la stessa documentazione Anthropic suggerisce, per i repository che usano AGENTS.md, di creare un CLAUDE.md che lo importi. La direzione è comunque chiara: ogni progetto avrà presto la sua documentazione “per umani” e la sua documentazione “per agenti”, e le due non coincideranno.

3. La conversione on-the-fly: l’approccio Cloudflare

Il terzo filone è il più interessante dal punto di vista dell’infrastruttura web, perché non richiede che i webmaster facciano nulla di nuovo: è Cloudflare a farlo per loro.

A febbraio 2026, infatti, Cloudflare ha annunciato una funzionalità in beta chiamata Markdown for Agents, attivabile dal proprio dashboard per i piani Pro, Business ed Enterprise (oltre che per i clienti SSL for SaaS), senza costi aggiuntivi.

Il meccanismo appare elegante. Quando un sistema AI richiede una pagina da un sito che usa Cloudflare con questa funzionalità abilitata, può esprimere la preferenza per text/markdown attraverso l’header HTTP Accept. La rete Cloudflare rileva questa preferenza, recupera la versione HTML originale dall’origin server e la converte in markdown in tempo reale, a livello di CDN – senza che il server di origine debba fare nulla di speciale.

La funzione di Cloudflare serve davvero?

Di seguito, i principali punti di forza di questa funzionalità:

• Riduzione del costo computazionale il risparmio sui token è reale e misurabile – fino all’80% su pagine molto pesanti di markup, con valori attorno al 30% su pagine di contenuto tipiche. Cloudflare espone anche gli header x-markdown-tokens e x-original-tokens, che permettono di stimarlo pagina per pagina. Per chi gestisce pipeline AI che fanno crawling e analisi massiva di contenuti web, la differenza economica è immediata.
• Miglioramento della qualità di lettura una pagina HTML contiene inevitabilmente navigazione, sidebar, footer, script di terze parti. La conversione in markdown rimuove tutto questo rumore, lasciando solo il contenuto semanticamente rilevante. Un agente che legge la versione markdown potrebbe produrre risposte più accurate.
• Scalabilità senza oneri editoriali la conversione automatica di Cloudflare funziona su tutto il sito senza interventi. È una soluzione infrastrutturale, non editoriale.
• Segnalazione dell’intento d’uso le risposte convertite includono un header Content-Signal che indica se il contenuto può essere usato per il training AI, la ricerca o come input per agenti – un primo passo verso un sistema in cui i publisher possono esprimere preferenze sull’uso dei propri contenuti. Attenzione però al default: se l’origin non specifica una propria policy, l’header viene impostato su ai-train=yes, search=yes, ai-input=yes. Chi ha scelte restrittive sull’uso AI dei propri contenuti dovrebbe rivedere questi valori prima di attivare la funzione.

Occorre considerare anche dei potenziali punti deboli:

• La qualità della conversione dipende dalla qualità dell’HTML un sito ben strutturato, con una gerarchia di heading coerente e contenuto semanticamente pulito, si converte in markdown di buona qualità. Un sito con HTML disordinato – titoli usati per scopi grafici anziché semantici, contenuto sparso in div anonimi ecc. – produrrà un markdown di qualità inferiore. In buona sostanza, la funzionalità traduce il contenuto esistente, non lo ottimizza.
• Il comportamento degli agenti non è ancora standardizzato pochissimi agenti AI inviano l’header Accept: text/markdown. Molti crawler continuano a lavorare con HTML grezzo. Allo stato attuale (luglio 2026) secondo Cloudflare Radar – dato confermato dal nostro osservatorio Fortop – la percentuale di richieste di Bot AI servite con markdown è inferiore allo 0,1%. La funzionalità è oggi utile per chi vuole essere pronto, non una soluzione universale.
• Limiti tecnici della beta il controllo granulare, inizialmente assente, è stato introdotto – oggi è possibile limitare la conversione a specifici sottodomini o percorsi tramite configuration rule – ma restano vincoli operativi documentati: la conversione riguarda solo documenti HTML, non avviene se la risposta dell’origin non include un header Content-Length (caso frequente con il chunked transfer encoding di alcuni hosting gestiti) e nemmeno se la pagina supera 1MB. Se attivata, va quindi verificata pagina per pagina, non data per scontata.
• Il nodo cloaking non è ancora sciolto servire ai bot un contenuto diverso da quello mostrato agli utenti evoca inevitabilmente il cloaking penalizzato da Google. Le critiche di John Mueller riguardavano però le pagine markdown separate, non la content negotiation standard usata da Cloudflare, sulla quale Google non si è ancora pronunciata. Il contenuto informativo resta identico e cambia solo il formato di consegna – un argomento solido a favore della legittimità.

Uno scenario in evoluzione per la GEO

Gli LLM non “leggono” il web come lo leggiamo noi. Quando un agente naviga una pagina, ogni elemento HTML deve essere trasformato in token, elaborato, contestualizzato. Il rumore – tutto ciò che non è contenuto informativo – ha un costo reale. Il markdown risponde a questa esigenza meglio di HTML perché è stato progettato per essere scritto e letto da esseri umani, ma ha abbastanza struttura per essere elaborato efficientemente dalle macchine.

Le iniziative descritte in questo articolo non sono eventi isolati ma segnali di una direzione: il web si sta preparando – in modo disomogeneo e senza ancora uno standard unico – a servire due tipi di lettori contemporaneamente. E qui sta la tesi che vale la pena enunciare chiaramente: il markdown per agenti non è ancora un fattore SEO misurabile, ma potrebbe rappresentare un primo mattone su cui si fonderà la fase successiva. Chi costruisce oggi contenuti ben strutturati, semanticamente coerenti, leggibili da una macchina quanto da un umano, non sta inseguendo una moda tecnica: sta investendo in un potenziale vantaggio competitivo a scadenza differita.

La visibilità nei sistemi di ricerca generativa dipende dalla qualità con cui un contenuto viene “compreso” da un LLM. Un contenuto strutturato in modo pulito ha molte più probabilità di essere sintetizzato correttamente – e quindi citato – da un assistente AI rispetto a un contenuto equivalente sepolto sotto strati di HTML decorativo. Non si tratta di abbandonare l’ottimizzazione per i motori di ricerca tradizionali: si tratta di aggiungere uno strato che oggi è ancora opzionale, ma potrebbe non restarlo a lungo.

Da dove partire, concretamente? Dal monitoraggio dei log di accesso dei crawler AI, per definire l’incidenza delle richieste che accettano risposte in formato markdown. Sulla base delle rilevazioni, potremo valutare se e come implementare un sistema di conversione in markdown in specifiche aree del sito. Con quali criteri? Questa è un’altra storia.