llms.txt: cos'è e come si scrive

Cosa dice davvero la proposta

Il problema per cui è nato llms.txt è il contesto, non la scansione. Quando un modello o un agente deve rispondere a una domanda usando il tuo sito, ha una finestra di contesto limitata e un input ostile: pagine HTML piene di menu, cookie banner, sidebar, pubblicità e contenuti generati in JavaScript. Convertire un sito ampio in qualcosa su cui un modello possa ragionare è un processo costoso e con perdita di informazione.

La specifica llms.txt propone due rimedi complementari. Primo: un singolo file Markdown in /llms.txt che funge da indice curato — ecco cos'è questo progetto, ecco le pagine che contano, in ordine di priorità. Secondo: pubblicare versioni Markdown pulite delle singole pagine a URL prevedibili (una pagina in /docs/setup disponibile anche in /docs/setup.md), così che una volta scelto un link dall'indice l'agente possa recuperare testo invece di un template.

Nota bene cosa non è. Non contiene direttive, non ha regole allow o disallow, non concede permessi. È una lista di letture che proponi, e chi la consuma è libero di ignorarla. La specifica usa deliberatamente Markdown invece di JSON o XML proprio perché il destinatario previsto è un modello linguistico, e perché le persone devono poterlo mantenere a mano.

• Dove siamo davvero con l'adozione
• paragraphs
• bullets

Dove siamo davvero con l'adozione

Diffida di chi sostiene che llms.txt sia ormai un fattore di ranking. John Mueller di Google lo ha paragonato pubblicamente al vecchio meta tag keywords e ha dichiarato che Google non lo usa per la Ricerca; la copertura della vicenda si trova su Search Engine Roundtable. La documentazione di Google su scansione e indicizzazione non menziona il file; il file che Google documenta per il controllo dei crawler è robots.txt.

Sul lato di chi consuma il file, la posizione onesta è questa: nessun grande fornitore di assistenti ha pubblicato documentazione in cui afferma che il proprio crawler o il proprio livello di retrieval usa /llms.txt per decidere cosa recuperare o citare. Dove il file viene usato in modo dimostrabile è nella direzione opposta: gli sviluppatori incollano l'URL di un llms.txt in una chat oppure lo passano a un coding agent, e l'agente segue i link. Questo è un flusso di lavoro reale, ed è il flusso per cui la specifica è stata scritta.

L'adozione da parte degli editori è più visibile nella documentazione per sviluppatori, in parte perché piattaforme di documentazione come Mintlify generano il file automaticamente per i siti che ospitano. È un buon motivo per averlo se pubblichi documentazione — e un cattivo motivo per dare per scontato che l'ecosistema si sia standardizzato. Una convenzione che costa quasi nulla adottare dice poco su quanto qualcuno la stia effettivamente consumando.

Come si scrive llms.txt: il formato esatto

La specifica definisce un ordine preciso degli elementi, e l'ordine è tutto il punto: chi consuma il file deve poterlo interpretare con un semplice parser Markdown, non con delle euristiche.

L'unico elemento obbligatorio è un H1 che contiene il nome del sito o del progetto. Tutto il resto è facoltativo ma vincolato nella posizione: un blockquote facoltativo subito dopo l'H1 con un breve riepilogo contenente le informazioni chiave per capire il resto; poi zero o più sezioni Markdown di testo o elenchi con dettagli aggiuntivi, senza intestazioni; infine zero o più sezioni H2, ognuna con un elenco di link.

Le righe dei link hanno la forma di un elemento di elenco Markdown con un collegamento e una descrizione facoltativa dopo i due punti: il nome, l'URL, poi una frase che spiega quando leggerla. Quelle descrizioni fanno un lavoro concreto: sono il modo in cui un modello decide su quali due dei tuoi quindici link spendere contesto, quindi scrivile come istruzioni di instradamento, non come testo promozionale.

Un H2 ha un significato speciale: la sezione intitolata Optional. I link inseriti al suo interno possono essere saltati quando serve un contesto più breve. Usala per changelog, materiale di riferimento approfondito e tutto ciò a cui un lettore potrebbe ragionevolmente rispondere anche senza. Una convenzione a parte, llms-full.txt, che contiene l'intero testo della documentazione concatenato, è diffusa fra le piattaforme di docs ma non fa parte della specifica di base: trattala come un extra e pubblicala solo se i tuoi contenuti stanno davvero in una finestra di contesto moderna.

• Servilo nella radice del dominio come /llms.txt, con content type text/plain o text/markdown, in HTTPS.
• Tienilo corto. Da dieci a trenta link curati valgono più di uno scarico della sitemap; se ti servissero tutti gli URL, hai già una sitemap XML.
• Scrivi descrizioni che disambiguano: «piani tariffari e limiti», non «scopri di più su Growli».
• Collega solo pagine pubblicamente accessibili e stabili. In un indice curato, i link rotti sono peggio dell'assenza di indice.
• Rigeneralo nella build, non a mano, se la tua documentazione cambia ogni settimana.

Un esempio concreto: il file di Growli

Il nostro è volutamente piccolo. Growli misura come gli assistenti AI menzionano e raccomandano le aziende, quindi le pagine che servono a un agente sono: cosa fa il prodotto, come funziona la misurazione, i prezzi e i contenuti di ricerca che definiscono i nostri termini. Nient'altro si merita un posto.

Letto come file, è un H1, un riepilogo in un blockquote, poi due sezioni H2 — la seconda è Optional. Ogni riga qui sotto è una riga di quel file:

• # Growli
• > Growli monitora come gli assistenti AI — ChatGPT, Gemini, Claude, Perplexity, Copilot e Grok — menzionano, confrontano e raccomandano le aziende, e trasforma i divari in azioni prioritizzate.
• ## Core
• How it works: il metodo di misurazione — set di prompt, frequenza delle rilevazioni e come vengono valutate menzioni e raccomandazioni.
• AI visibility: definizione della metrica, cosa la muove e cosa no.
• ## Optional
• Blog: contenuti di ricerca sul comportamento degli assistenti, sui pattern di citazione e sulla metodologia di misurazione.

Come si colloca rispetto a robots.txt e ai dati strutturati

Questi tre file rispondono a tre domande diverse, e confonderli è l'errore più comune che vediamo negli audit.

robots.txt risponde alla domanda «puoi recuperare questa risorsa?»: è un file di controllo degli accessi per i crawler, con un comportamento di parsing consolidato e documentato, ed è lì che consenti o blocchi crawler AI specifici. Se vuoi limitare l'addestramento o la scansione, lo fai lì e nei tuoi termini di servizio, mai in llms.txt. I dati strutturati rispondono alla domanda «che cos'è questo?»: il vocabolario Schema.org in JSON-LD ti permette di dichiarare senza ambiguità che sei un'Organization con questo nome, questi prodotti, questo prezzo e queste recensioni — il tipo di fatto leggibile dalle macchine che sopravvive alla sintesi. llms.txt risponde solo alla domanda «cosa dovrei leggere prima?», per chi ha già deciso di leggerti.

In termini di ritorno sull'impegno, l'ordine è poco affascinante ma coerente: prima sistema scansionabilità e rendering lato server, poi i dati strutturati a livello di entità, poi llms.txt. Un file che elenca link a pagine che senza JavaScript restano bianche non aiuta nessuno.

Quindi conviene pubblicarlo?

Sì, se hai documentazione, un'API, un prodotto per sviluppatori o una knowledge base: il costo è di pochi minuti, il file è leggibile anche dalle persone e il flusso in cui qualcuno passa a un agente l'URL del tuo llms.txt è già diffuso. Pubblicalo, tienilo aggiornato e vai avanti.

Probabilmente non è una priorità se sei un'attività di servizi locale, un catalogo e-commerce o un sito vetrina da dodici pagine. Non esistono prove che cambi la probabilità che un assistente ti raccomandi, e l'impegno rende di più altrove: sulle cose che gli assistenti dimostrabilmente leggono, cioè pagine che si renderizzano senza JavaScript, contenuti espliciti di confronto e di prezzo, fatti coerenti sull'entità fra il tuo sito e le schede di terze parti, e presenza nei siti di recensioni e nelle classifiche a cui i modelli si appoggiano quando rispondono a «migliore X per Y».

Il test onesto è la misurazione. Monitora quanto spesso gli assistenti ti nominano, su quali prompt e quali fonti citano quando lo fanno: è esattamente ciò per cui è nato il nostro monitoraggio della AI visibility, e how it works spiega il metodo. Se pubblicare llms.txt muove quei numeri per il tuo sito, lo vedrai. Se non li muove, avrai speso venti minuti e imparato qualcosa di vero.

FAQ