SEO & IA

La verità sul file llms.txt

Tutti i grandi attori dell'IA pubblicano un llms.txt sui propri siti di documentazione. Nessuno si impegna a leggere il vostro. Ho testato le URL una per una, ripreso le dichiarazioni ufficiali e gli studi sui log. Ecco il risultato, tenendo rigorosamente separati fatti, dichiarazioni e ipotesi.

Fred Gaveau4 agosto 2026~11 min di lettura

Si parte da una stranezza. Da due anni llms.txt viene presentato come il file che parla alle intelligenze artificiali. E in effetti lo pubblicano tutte: Anthropic, OpenAI, Mistral, Perplexity, xAI, Google in parte. Se qualcuno sa a cosa serve questo file, sono proprio loro.

Solo che nessuno di loro ha mai scritto che i propri robot lo leggono sul vostro sito. E l'unica azienda che si è espressa chiaramente sull'argomento — Google — ha detto di no.

È da qui che parte questa inchiesta. Ho testato ogni URL a mano, recuperato le dichiarazioni ufficiali dove esistono, e letto gli studi sui log pubblicati. Il testo è volutamente diviso in tre: ciò che è provato, ciò che è dichiarato, e ciò che resta speculazione — compresa la mia.

Ciò che ho verificato di persona

Ho interrogato diciassette URL da riga di comando il 4 agosto 2026 alle 13:24 UTC, seguendo i reindirizzamenti e annotando il codice HTTP e il peso del corpo restituito. Tutti i link della tabella sono attivi: verificate voi stessi, è esattamente il punto.

Istantanea del 4 agosto 2026, 13:24 UTC. Un file può comparire o sparire domani — è precisamente ciò che è successo a Google.

Dalla tabella saltano fuori tre cose.

Uno: il file vive sui sottodomini di documentazione, mai sul sito generalista. docs., developers., platform. rispondono 200. Le radici anthropic.com e google.com rispondono 404. Un'unica eccezione nel panel: Vercel, il cui /docs/llms.txt reindirizza a vercel.com/llms.txt, realmente servito alla radice come chiede la specifica.

Due: Google è frammentato. Firebase ce l'ha, Google Cloud no, il sito dei modelli Gemini nemmeno. Non è una politica, è un incidente — ci torno tra poco.

Tre: il formato è esploso in volo. La specifica descrive un indice breve. Firebase serve 1,7 MB, xAI 1,3 MB, la variante completa di Vercel 7,4 MB. Un indice da 1,7 MB non è più un indice: è il corpus che doveva riassumere.

Da dove viene questo file

FATTO llms.txt è una proposta pubblicata il 3 settembre 2024 da Jeremy Howard (Answer.AI, cofondatore di fast.ai) su llmstxt.org. L'idea: un file Markdown strutturato alla radice del sito — un titolo #, un riassunto come citazione, sezioni ## di link annotati — per offrire ai modelli una mappa pulita del contenuto, invece di far loro indovinare la struttura di un sito moderno saturo di JavaScript.

L'analogia con robots.txt e sitemap.xml è dichiarata, ed è ciò che ha fatto il successo dell'idea. Ma è ingannevole su un punto decisivo: robots.txt e sitemap.xml sono stati adottati dai motori prima di diventare popolari. Qui è il contrario.

FATTO La pagina della specifica non rivendica alcuna adesione da parte di un fornitore di IA, non menziona alcun processo di normazione (né IETF, né W3C, né WHATWG) e si descrive come aperta ai contributi della comunità tramite un repository GitHub. Dettaglio raramente rilevato: llms-full.txt non compare affatto nella specifica. È una convenzione nata dall'uso, che ognuno applica a modo suo.

Il nocciolo: qualcuno legge davvero questo file?

È l'unica domanda che conta, e ha risposte numeriche.

Cosa dicono i log dei server

FATTO Il 5 marzo 2026 Dries Buytaert — creatore di Drupal, CTO di Acquia — pubblica l'analisi di un mese di log Cloudflare. Il suo sito ha ricevuto 52 richieste su /llms.txt in un mese. Tutte provenivano da strumenti di audit SEO. Nessuna da un motore di risposta o da un crawler IA. Sull'intera infrastruttura di hosting di Acquia: circa 5 000 richieste su 400 milioni, cioè lo 0,001 %, quasi esclusivamente da strumenti SEO.

FATTO Un'analisi dei log di Ahrefs su 137 000 domini (giugno 2026, ripresa da PPC Land) conclude che il 97 % dei file llms.txt non ha ricevuto alcuna richiesta a maggio 2026. I robot di recupero IA rappresentavano l'1,1 % delle richieste osservate.

FATTO Infine, uno studio SE Ranking del 7 novembre 2025 su 300 000 domini non trova alcun effetto misurabile di llms.txt sulle citazioni da parte delle IA. Togliere la variabile dal modello predittivo ne migliorava persino la precisione.

Cosa dichiara Google

DICHIARAZIONE Google è l'unico grande attore a essersi espresso formalmente. La documentazione ufficiale sulle funzionalità IA della ricerca (developers.google.com, aggiornata il 10 dicembre 2025) lo scrive senza giri di parole:

DICHIARAZIONE Su Reddit, John Mueller ha paragonato llms.txt al tag meta keywords — abbandonato proprio perché è il sito stesso a compilarlo — e poi, riportato nel giugno 2026: «I don't think anyone knows – it's purely speculative for now (the file has existed for years, yet none of the AI systems use it — what does it mean?)». Aggiunge un criterio di decisione che trovo onesto: il giorno in cui una piattaforma IA che vi porta clienti chiederà il file, fatelo. Fino ad allora, no.

DICHIARAZIONE Gary Illyes, del team Search, ha indicato durante un Search Central Live nel luglio 2025 che Google non supporta llms.txt e non prevede di farlo — posizione riportata da Search Engine Roundtable.

Ciò che gli altri non dicono

NON VERIFICATO Per OpenAI, Anthropic, Perplexity e Mistral non ho trovato alcuna dichiarazione pubblica secondo cui i loro robot consumano il llms.txt di un sito terzo — né alcuna che lo escluda. Il silenzio non è prova di assenza, ma non è nemmeno un impegno. Pubblicare un file sulla propria documentazione non dice nulla su cosa faccia il proprio crawler a casa vostra: due squadre, due prodotti, due problemi.

La contraddizione di Google, documentata

È l'episodio più rivelatore, ed è verificabile.

RIPORTATO Il 3 dicembre 2025 un llms.txt compare su developers.google.com/search/docs/. Viene notato dalla consulente SEO Lidia Infante. Viene rimosso lo stesso giorno. Secondo i resoconti, il file non era una decisione del team Search: il sistema di gestione dei contenuti interno di Google, condiviso da diverse proprietà per sviluppatori, aveva iniziato a generarli automaticamente. Alcune squadre l'hanno rimosso, altre no.

FATTO — verificato il 4 agosto 2026 Lo stato attuale del campo conferma questa lettura. developers.google.com/search/docs/llms.txt, developer.chrome.com/llms.txt, web.dev/llms.txt, cloud.google.com/llms.txt, ai.google.dev/llms.txt: 404 ovunque. E firebase.google.com/docs/llms.txt: 200, 1,7 MB. Una squadra si è dimenticata di fare pulizia. Il «llms.txt di Google» citato ovunque come prova di adozione è il residuo di un rilascio automatico.

FATTO Eppure, nello stesso momento, un'altra parte di Google va nella direzione opposta. Lighthouse 13.3, lo strumento di audit integrato in Chrome, include una categoria sperimentale «Agentic Browsing» che contiene un controllo su llms.txt (documentazione aggiornata il 5 maggio 2026). Vi è descritto come «an emerging convention used to provide a machine-readable summary of a website's content, specifically designed for LLMs and AI agents», e il controllo osserva che senza il file gli agenti impiegano più tempo a esplorare il sito.

LA MIA INTERPRETAZIONE Non è ipocrisia, e non la presenterò come tale. È che «Google» non è un'entità unica e le due squadre non parlano dello stesso caso d'uso: Search parla di posizionamento e citazione in un motore di risposta, Chrome parla di efficienza di un agente che naviga. Le due posizioni sono difendibili separatamente. Sono semplicemente inconciliabili per il lettore che vuole capire se «Google» raccomandi o meno il file. E questa confusione nessuno la dissipa. Search Engine Journal l'ha riassunta bene: la raccomandazione di Google dipende dal prodotto a cui lo chiedete.

Allora perché lo pubblicano tutti?

Ecco l'ipotesi che sostengo, e sono i file stessi a supportarla: llms.txt non è mai stato un file SEO. È un file di documentazione per sviluppatori. Il lettore a cui si rivolge non è GPTBot che indicizza il web per un motore di risposta. È una sviluppatrice con Cursor, Claude Code o Copilot aperto, il cui agente deve caricare una documentazione API aggiornata invece di recitare una versione obsoleta appresa in addestramento.

FATTO Lo dicono i file stessi. Quello di Cohere contiene una sezione intitolata «Instructions for AI Agents» che raccomanda di aggiungere .md a qualsiasi URL per ottenere Markdown pulito, e di collegare un server MCP «for AI client integration (Claude Code, Cursor, etc.)». Quello di Cloudflare precisa che ogni prodotto ha il proprio llms.txt, «the recommended way to explore a specific product's content». Queste frasi non si rivolgono a un motore di ricerca.

FATTO I log di Buytaert vanno nella stessa direzione: gli agenti integrati negli IDE recuperano davvero queste risorse, a differenza dei crawler dei motori di risposta.

Se questa lettura è corretta, l'intero dibattito «llms.txt migliora la mia visibilità IA?» poggia su un errore di casting. Uno strumento di documentazione tecnica viene giudicato con i criteri del posizionamento. Fallisce, ovviamente. Non significa che non serva a nulla — significa che non serve a quello.

Ciò che funziona davvero, e che nessuno vende: il Markdown

FATTO È il dato più utile di tutta l'inchiesta, ed è passato quasi inosservato. Sempre dai log di Buytaert, quando una pagina è disponibile in Markdown a un URL prevedibile:

In altre parole: i crawler di OpenAI vanno a prendere il Markdown quando esiste a un URL indovinabile — tipicamente /mia-pagina.md. Un terzo dei recuperi, per GPTBot. È infinitamente più dello 0,001 % del llms.txt.

FATTO E il corollario è brutale: «No AI crawler uses content negotiation. Not one.» Nessun robot IA usa l'intestazione Accept per chiedere Markdown. La negoziazione del contenuto, il metodo pulito e normato da trent'anni, è ignorata da tutti. Ciò che funziona è il suffisso nell'URL, la soluzione più stupida.

È esattamente lo schema usato da Stripe, Cohere, Perplexity e Anthropic nei loro file: ogni voce punta a un gemello .md. Il llms.txt è l'elenco; i gemelli Markdown sono ciò che viene realmente consumato.

Il caso Stripe: quando l'indice diventa un ordine

FATTO Il llms.txt di Stripe non comincia con una descrizione. Comincia con imperativi rivolti alla macchina che lo legge. Estratto verificato, prime righe del file:

# Stripe Documentation

When installing Stripe packages, always check the npm registry for the latest
version rather than relying on memorized version numbers. Run `npm view stripe
version` [...] Never hardcode an old version number from training data — always
install with `@latest` or verify the current version first.

IPOTESI Questa deviazione d'uso solleva una questione di sicurezza che pongo senza poterla risolvere: se un file pubblico e non firmato può contenere istruzioni, e un agente lo carica nel proprio contesto senza distinguere «descrizione del sito» da «ordine da eseguire», siamo nel perimetro della prompt injection. Non ho trovato alcun incidente pubblico documentato che sfrutti un llms.txt. Il rischio è strutturale, non constatato. Ma oggi il formato non offre alcun modo di separare le due cose — e Stripe, in perfetta buona fede, ha appena dimostrato che la porta è aperta.

Otto proposte per riparare il formato

Criticare è facile. Ecco cosa, a mio avviso, trasformerebbe llms.txt da oggetto di fede a strumento utile. Ogni proposta si appoggia a un meccanismo che esiste già altrove.

1. Smettere di scriverlo a mano. Generarlo.

Un llms.txt scritto a mano marcisce in tre mesi: le pagine si spostano, il file no. Va prodotto al momento della build, dalla stessa fonte della sitemap o del CMS. Ironia della sorte: è esattamente ciò che faceva il sistema interno di Google — e l'incidente del dicembre 2025 nasce dal fatto che la generazione era automatica mentre la decisione non lo era. Automatizzate la generazione, non la decisione.

2. Servire i gemelli Markdown prima dell'indice.

È la proposta più redditizia, e ribalta l'ordine di priorità comunemente accettato. Poiché i crawler di OpenAI recuperano Markdown per circa un terzo delle loro richieste ma ignorano la negoziazione del contenuto, servite /mia-pagina.md accanto a /mia-pagina, a URL prevedibile, e dichiaratelo nell'HTML con <link rel="alternate" type="text/markdown" href="/mia-pagina.md">. Funziona oggi, in modo misurabile, a differenza di llms.txt. Se da questo articolo doveste portare via una sola cosa, portate via questa.

3. Traslocare in /.well-known/.

La RFC 8615 definisce dal 2019 uno spazio dei nomi standard proprio per file di questo tipo, con un registro IANA alle spalle. /.well-known/llms.txt risolverebbe in un colpo la questione della collocazione — quella che spiega perché tutti i file della tabella vivono su sottodomini di documentazione invece che alla radice — e aprirebbe l'unica via di normazione credibile.

4. Dichiararlo nel robots.txt.

Una riga, Llms: https://esempio.it/llms.txt, sul modello esatto della direttiva Sitemap: — anch'essa mai normata, e che tutti i motori rispettano comunque. Costo zero, scoperta garantita, e un meccanismo la cui adozione è già provata da vent'anni di pratica.

5. Datare ogni voce.

Un indice senza freschezza è inutilizzabile: di fronte a una pagina resa in diretta, un modello non ha alcun motivo di preferire una riga d'indice che potrebbe avere due anni. Una data per voce — - [Pagina](url) (2026-07-12): descrizione — e un Last-Modified onesto sul file stesso danno finalmente di che arbitrare.

6. Separare formalmente indice e corpus.

Il formato deve fissare un tetto rigido — diciamo 50 KB — per llms.txt, rinviando tutto il resto a un llms-full.txt esplicitamente definito nella specifica (dove tuttora non compare). L'1,7 MB di Firebase e l'1,3 MB di xAI non sono abusi: sono i sintomi di un formato che non ha mai detto dove fermarsi.

7. Firmare, o ammettere che non vale nulla.

L'obiezione di John Mueller — «è il sito a compilarlo, come meta keywords» — è inattaccabile finché non esiste una firma. Gli strumenti ci sono: firme dei messaggi HTTP (RFC 9421), chiave pubblicata in un record DNS TXT. Un file autodichiarato e non firmato avrà sempre esattamente il valore probatorio di un meta keywords del 2003.

8. Vietare l'imperativo — o recintarlo.

Finché nessun meccanismo distingue una descrizione da un'istruzione, il formato dovrebbe vietare gli ordini o imporre una sezione ## Agent instructions nettamente delimitata, che gli agenti trattino come dati non affidabili. Il caso Stripe non è un abuso isolato: è il primo sintomo.

E infine: misuratelo.

Nessuna di queste proposte vi dispensa dal gesto più semplice. Un accesso a /llms.txt è una riga nei vostri log di server. Filtrate sugli user-agent dei robot IA, confrontate con le vostre pagine HTML, e in una settimana saprete se quel file serve a qualcosa da voi. È l'unico dato che vi riguardi davvero. Tutti gli altri, compresi i miei, sono la media di qualcun altro.

Verdetto: conviene metterne uno nel 2026?

Non c'è una risposta. Ce ne sono quattro.

E una regola valida per tutti: non pagate nessuno per scrivere il vostro llms.txt. Sono venti minuti di lavoro, o zero se lo generate. L'unica cosa che merita un budget è verificare poi se i robot passano davvero — e questo lo dicono i vostri log, non un fornitore.

Per il resto la mia posizione non è cambiata dal nostro primo articolo sul tema: il file non fa danni, costa quasi nulla, e se un giorno l'uso decollerà sarete già pronti. Sono cambiati i dati. Ora sappiamo, numeri alla mano, che non è una leva di visibilità IA — e cominciamo a capire cos'è davvero: uno strumento per agenti di codice, mal chiamato e mal assegnato.

Nota di trasparenza: Snorklee pubblica il proprio llms.txt, alla radice, con un avvertimento scritto all'interno. Applichiamo quindi esattamente ciò che raccomandiamo: metterlo, non crederci, e misurarlo.