llms.txt: serve davvero per i motori AI?

No, per la visibilità sui motori AI llms.txt non serve. Nessun motore dichiara di leggerlo, Google scrive nella sua documentazione che lo ignora, e in uno studio su 137.210 domini il 97% dei file pubblicati non ha ricevuto una singola richiesta in un mese.

Il file però è vivo e funziona benissimo. Solo che il pubblico è un altro: gli assistenti di coding che devono ingoiare documentazione tecnica. Il secondo user-agent AI che va a prenderlo nei log si chiama Claude-Code, e come indizio dovrebbe bastare.

Qui sotto: com’è fatto un llms-txt, cosa dice Google (e perché Lighthouse sembra dire il contrario), i numeri di chi lo richiede davvero, tre controlli per verificare il tuo, e il criterio per decidere se ti conviene.

Cos’è il file llms.txt

llms.txt è un file di testo scritto in markdown che pubblichi sul sito e che dà a un modello linguistico un indice curato dei tuoi contenuti: un titolo, una riga di sintesi, una lista di link con la descrizione di cosa c’è dietro ciascuno. L’ha proposto Jeremy Howard di Answer.AI nel settembre 2024 e oggi la specifica è alla versione 2. Lo trovi scritto anche llms-txt col trattino: stessa cosa, cambia la grafia.

Due chiarimenti prima di andare avanti, perché in giro si legge di tutto.

Non è uno standard. È una proposta pubblica che qualcuno ha adottato: nessun ente la ratifica, nessun motore la richiede, e il numero di siti che ce l’hanno non la rende più obbligatoria del tuo font preferito.

Non blocca niente. Chi vuole dire a un crawler cosa può prendersi e cosa no continua a farlo con robots.txt, l’unico strumento indicato dalle pagine ufficiali di OpenAI, Anthropic e Perplexity. Il file llms txt sta dall’altra parte del banco: non toglie accesso, lo offre.

Il modo più onesto di descriverlo è il bigliettino sul frigo. Scrivi a chi entra dove sta il caffè e quale anta non si apre, e gli risparmi mezz’ora di rumore. Poi dipende da chi entra. Se quello il bigliettino non lo guarda, il bigliettino resta lì.

Come è fatto: la struttura minima

La spec prevede cinque parti e una sola è obbligatoria: l’H1 col nome del progetto. Il resto è convenzione, ed è la convenzione a renderlo leggibile.

1. H1: il nome del sito o del progetto, uno solo, in cima.
2. Blockquote: una riga di sintesi con > davanti. Cosa fa, a chi serve.
3. Prosa libera: qualche riga senza heading, per i dettagli che dai link non si deducono.
4. Sezioni H2: liste di link markdown, raggruppate per tema.
5. Sezione Optional: quello che si può saltare quando il contesto è stretto.

La forma è questa:

# Nome del progetto

> Una riga: cosa fa, a chi serve, in che contesto si usa.

Due righe di prosa per i dettagli che i link non raccontano da soli.

## Documentazione

- [Guida introduttiva](https://esempio.dev/guida.md): come si parte da zero
- [Riferimento API](https://esempio.dev/api.md): endpoint, parametri, esempi

## Optional

- [Changelog](https://esempio.dev/changelog.md): storico delle versioni

Qui casca metà delle guide in circolazione: la descrizione va dopo il link, sulla stessa riga, dopo i due punti. Non prima, non a capo, non in corsivo sotto. Se la sposti, chi legge non ha più modo di capire quale descrizione appartiene a quale URL, e il file diventa una lista di link come tante.

Quanto deve essere grosso? Quello di llmstxt.org pesa 637 byte. Seicentotrentasette. Il file che descrive la specifica sta in meno di un messaggio vocale di trenta secondi trascritto, e questo dice parecchio su quanto dovrebbe essere lungo il tuo.

llms.txt e llms-full.txt: due file diversi

Sono due file con due mestieri diversi. llms.txt è l’indice, llms-full.txt è il libro intero incollato dentro un file solo.

Il primo elenca gli URL con una descrizione a fianco e lascia che sia il modello a decidere cosa aprire. Il secondo concatena il testo di tutte le pagine in markdown, così chi legge ha già tutto in mano senza una richiesta in più.

Sulla carta il secondo sembra la versione migliore. Poi vai a vedere quanto pesa uno vero: il file llms-full.txt di modelcontextprotocol.io sta a circa 2,4 MB (2.377.742 byte al controllo del 26 agosto 2026, e il file cambia a ogni release). Anche la finestra di contesto più larga in circolazione resta stretta per un sito intero, come ammette la specifica stessa, e ogni token sprecato costa tempo e denaro: 2,4 MB di markdown sono fuori scala per quasi qualunque assistente in circolazione. Glielo passi tutto e lui ne guarda una fetta, scegliendo lui quale.

llms-full.txt ha senso sulla documentazione tecnica, dove il testo è denso e strutturato, e va rigenerato a ogni release: altrimenti stai distribuendo la fotocopia di com’era il prodotto tre versioni fa. Su un blog è peso morto.

Cosa dice Google su llms.txt

Google Search ignora llms.txt, e non è una deduzione: sta scritto nella documentazione ufficiale.

La guida all’ottimizzazione per le funzionalità generative, aggiornata il 10 luglio 2026, dice che per apparire nella Ricerca, incluse le funzioni generative, non serve creare nuovi file leggibili dalle macchine, AI text file, markup o Markdown, perché Google Search non li usa. E aggiunge il pezzo che conta: mantenere un llms.txt per altri sistemi non aiuta né danneggia visibilità e ranking, perché Google Search lo ignora. Nell’elenco delle tattiche da lasciar perdere, llms.txt è nominato per nome.

La pagina su AI Overviews e AI Mode, aggiornata il 10 dicembre 2025, ribadisce: nessun requisito aggiuntivo, nessun file leggibile dalle macchine, e nemmeno uno structured data schema.org dedicato alle funzioni AI.

Da più di un anno gira una dichiarazione di John Mueller dell’aprile 2025, ricitata in mezza SERP italiana senza uno straccio di URL. Bella, ma ormai inutile: la documentazione ufficiale è pubblica, datata e linkabile, e dice la stessa cosa con parecchia più autorità di uno screenshot di terza mano.

Occhio a non capovolgere la frase, però. Google non dice che llms.txt fa male: dice che non lo guarda. Effetto zero, in entrambe le direzioni. Se ti serve il quadro completo di come funziona la visibilità sui sistemi generativi, sta nella guida alla SEO per l’AI.

Il paradosso Lighthouse: Google lo controlla ma non lo usa

Sì, Chrome ha messo un audit llms.txt dentro Lighthouse, nella categoria sperimentale Agentic Browsing (documentazione aggiornata il 5 maggio 2026). L’audit controlla se il server restituisce un errore nel recupero del file; se il file non c’è e risponde 404, l’esito è Not Applicable, perché fornirlo è al momento opzionale.

Non è una smentita di Search Central. Prodotti diversi, squadre diverse, domande diverse: Lighthouse misura se una pagina è pronta per un agente che ci naviga sopra, Search Central parla di cosa entra nell’indice e di cosa muove il ranking. La categoria che lo contiene, poi, non ha un punteggio come le altre: niente media pesata da 0 a 100 come per performance o accessibilità, solo la frazione di controlli superati, serve Chrome 150 o successivo, e insieme a llms.txt ci trovi gli audit su WebMCP, accessibility tree e CLS. È un banco di prova, non una pagella.

Ecco perché in giro leggi tutto e il contrario di tutto. Uno apre PageSpeed Insights, vede la voce llms.txt segnalata e conclude che Google lo pretende. Un altro legge Search Central e conclude che Google lo disprezza. Hanno letto due pagine diverse della stessa azienda, scritte per rispondere a due domande che fra loro non si parlano.

Chi lo supporta davvero

Chi pubblica un llms.txt non è chi lo legge. È l’equivoco su cui poggia metà degli articoli sul tema: si vede il file sul dominio di OpenAI e si conclude che ChatGPT legge il tuo.

Tre piani, da tenere separati perché raccontano cose opposte. I motori AI, che il file lo pubblicano per la propria documentazione e non dichiarano da nessuna parte di andarlo a leggere sui siti altrui. I tool SEO, che lo generano e ci mettono sopra promesse molto diverse fra loro. I dev-tools, dove il file viene letto per davvero.

I lab AI lo pubblicano, i loro crawler non dichiarano di leggerlo

I lab pubblicano, i loro crawler tacciono. Tutti e quattro i grandi hanno un llms.txt online per la propria documentazione, e nessuna delle loro pagine ufficiali sui bot dice che quei bot vadano a prendere il tuo.

I file esistono, verificati con curl il 26 agosto 2026: developers.openai.com/llms.txt risponde 200 e pesa circa 5,9 KB, docs.anthropic.com/llms.txt circa 64 KB, ai.google.dev/gemini-api/docs/llms.txt circa 28,5 KB. Anche Perplexity lo pubblica per la propria documentazione.

Poi apri le pagine sui crawler e cambia l’aria.

OpenAI documenta quattro user-agent: OAI-SearchBot per i risultati di ricerca di ChatGPT, OAI-AdsBot, GPTBot per il training e ChatGPT-User per le azioni che avvii tu. Lo strumento di controllo indicato è robots.txt, e puoi consentire OAI-SearchBot bloccando GPTBot separatamente. In quella pagina llms.txt compare solo come indice della documentazione OpenAI.

Anthropic documenta ClaudeBot, Claude-User e Claude-SearchBot, e indica robots.txt con Disallow e Crawl-delay. La parola llms.txt in quella pagina non compare mai.

Perplexity documenta PerplexityBot e Perplexity-User, con i range IP pubblicati su perplexity.com/perplexitybot.json e perplexity.com/perplexity-user.json. Anche qui llms.txt è soltanto l’indice dei loro documenti.

Una precisazione di metodo, che mi tengo stretta: assenza di dichiarazione non è dimostrazione di assenza. Nessuno dei quattro ha scritto “non leggiamo llms.txt”. Però quando quattro aziende documentano nel dettaglio i propri user-agent, il proprio metodo di controllo e perfino i propri range IP, e in nessuna riga nominano quel file come input, l’onere della prova si sposta su chi sostiene il contrario.

I tool SEO lo generano, e ci mettono sopra promesse diverse

I tool lo generano quasi tutti, ma la promessa che ci scrivono sopra cambia parecchio. Due esempi, con le parole loro.

Yoast SEO ha un interruttore in Yoast SEO > Impostazioni > Funzioni del sito > Strumenti AI > LLMS.txt. Il linguaggio della documentazione è prudente: la funzione permette di offrire ai modelli un’anteprima del sito, evidenziando i contenuti più importanti e aggiornati. Nessuna promessa di ranking, nessuna citazione garantita.

AIOSEO genera llms.txt e llms-full.txt e li presenta con tutt’altro tono: “AI Rankings & Citations”, “AI Search Visibility”, e in pagina uno “Stop letting AI search engines decide what to show from your site”. Nessun disclaimer sull’efficacia reale. La versione Lite si ferma a llms.txt; llms-full.txt e l’output markdown stanno nella Pro.

Adesso rimettici accanto la frase di Google, quella della guida ufficiale aggiornata a luglio 2026: mantenere un llms.txt non aiuta né danneggia visibilità e ranking, perché Google Search lo ignora.

Le due frasi possono stare in due schede del browser aperte insieme e dicono cose incompatibili. Non aggiungo commenti, tanto il confronto si legge da solo. Serve solo tenere a mente una cosa quando un plugin ti mette un interruttore accanto alla scritta “AI Search Visibility”: quella scritta è copy di prodotto, non documentazione di un motore.

Il bacino vero: assistenti di coding e documentazione tecnica

Il formato serve agli assistenti di coding sulla documentazione tecnica. È lì che viene letto, ed è lì che risolve un problema vero.

Nella ripartizione dei richiedenti dello studio Ahrefs su 137.210 domini i primi user-agent AI che vanno a prendere il file sono GPTBot e Claude-Code, davanti a ogni singolo bot di AI search e di assistenza.

Claude-Code. Un agente che gira nel terminale di uno sviluppatore e che, quando gli chiedi di integrare una libreria, ha bisogno della documentazione di quella libreria in una forma che non lo faccia annegare.

Guarda chi lo pubblica sul serio e il cerchio si chiude da sé. Cursor pubblica l’indice della propria documentazione come llms.txt (HTTP 200, circa 19 KB). Model Context Protocol pubblica un llms-full.txt da 2,4 MB. E le query correlate che la gente digita sono “llms txt cursor” e “langgraph llms txt”: chi cerca vuole l’indice della documentazione di un framework, non vuole posizionarsi.

Ha senso, se ci pensi trenta secondi. Un agente di coding non deve scegliere quale sito citare in una risposta: deve caricare la documentazione giusta prima di scrivere codice che altrimenti si inventa parametri mai esistiti. llms.txt risolve quello, l’ingestione di documentazione tecnica, e lo risolve bene. Non risolve un problema di visibilità, perché non è mai stato costruito per quello.

Qui sta la riga che nessuno tira: se il tuo sito non è roba che qualcuno incolla dentro un IDE, sei fuori dal bacino di chi quel file lo legge davvero.

Serve davvero per la visibilità sui motori AI? I numeri

No, e i numeri sono brutali. Lo studio Ahrefs pubblicato il 15 giugno 2026 ha guardato 137.210 domini con traffico a maggio 2026: il 28% (38.360 domini) pubblica un llms.txt valido, e il 97% di quei file non ha ricevuto nessuna richiesta nel mese. Trentottomila file scritti, aggiornati, caricati online, e per novantasette su cento non è passato nessuno a leggerli.

Resta un 3% che qualche richiesta la riceve. E chi la fa?

La ripartizione dei richiedenti censita dallo studio, con l’unica riga non-bot in fondo:

La riga “Esseri umani” sta in nota nello studio, non nella tabella: le dodici categorie di bot valgono il 96% delle richieste, il resto sono persone. La somma fa 99,7% per arrotondamento.

Rileggila al contrario. La fetta più grossa sono tool di audit SEO, cioè plugin e crawler che vanno a controllare se il file esiste perché glielo hai chiesto tu o qualcuno come te: il file più visitato del web viene visitato dai controllori del file. Con un dettaglio che Ahrefs mette in nota e che vale la pena tirare fuori: 2.334 di quelle 4.776 richieste sono i crawler di Ahrefs stessa, il 10,6% del totale. Tolti quelli, i tool di audit terzi valgono l’11,1% e scivolano al quarto posto, dietro bot non identificati, crawler generici e tool di profiling. Il primo lettore di llms.txt, in questo campione, è il crawler di chi ha fatto lo studio. I bot di retrieval AI, quelli che vanno a prendere un contenuto per costruire una risposta, stanno all’1,1%. Un punto e uno.

Un avvertimento sul dato, che preferisco darti io. È uno studio di parte: lo firma Ahrefs, che in quell’area ha un prodotto, e il campione sono domini dentro la loro rete di monitoraggio, quindi siti già seguiti da qualcuno che fa SEO di mestiere. Non è un campione casuale del web. Resta l’unica misurazione pubblica su questa scala, e nessuna delle pagine italiane che ti dice “mettilo, non si sa mai” ha una singola metrica da opporgli.

Il dettaglio che in Italia non cita nessuno: i bot non lo vanno nemmeno a cercare

Sui domini che un llms.txt non ce l’hanno, i bot AI non vanno nemmeno a bussare: nello stesso studio le richieste da bot AI a quel path sono zero. Il path però qualche visita la riceve lo stesso, e per il 98% arriva da esseri umani, che secondo Ahrefs sono con ogni probabilità SEO che controllano a mano se il concorrente ce l’ha. I sistemi AI non sondano il percorso per vedere se nel frattempo è comparso.

È il dettaglio che ribalta tutto il consiglio operativo, e in italiano non l’ho visto ripreso da nessuno: Ahrefs ci dedica un capitolo, le guide che citano lo studio si fermano al 97%. Se i bot provassero il path a tappeto, pubblicare il file sarebbe una scommessa a costo quasi zero: prima o poi passano, prima o poi lo trovano. Solo che non passano.

Il file viene letto quando qualcuno glielo mette davanti: un link, un incollaggio in chat, un tool configurato per andarselo a prendere. Pubblicarlo e sperare non è una strategia. È un file in più nella root.

Come verificare il tuo file llms.txt (tre controlli)

Tre controlli, dieci minuti, e sai esattamente a che punto sei. Li puoi rifare su qualunque dominio, anche non tuo.

Uno: risponde, e con quale Content-Type.

curl -sI https://tuosito.it/llms.txt

Vuoi vedere un HTTP/2 200 e un Content-Type che parli di testo (text/plain o text/markdown). Se torna 404, il file non c’è e stai leggendo la sezione sbagliata dell’articolo. Se torna text/html, il server ti sta servendo una pagina d’errore travestita da file, oppure una route del CMS che intercetta il path: su WordPress con permalink aggressivi succede più spesso di quanto immagini.

Due: è conforme alla spec. Controlli a occhio, che è già meglio di un llms txt validator online: un validator ufficiale non esiste e la specifica non ne prevede uno, quindi quelli che trovi in giro applicano le regole che ha deciso chi li ha scritti. Guarda tre cose. Un solo H1 in cima. Le descrizioni dopo il link, sulla stessa riga, dopo i due punti. Gli URL assoluti e vivi. Poi apri due o tre link a caso: se uno è un 404, il tuo file sta descrivendo un sito che non esiste più.

Tre: chi te lo chiede davvero. Qui sta la risposta vera, ed è nei tuoi log, non in un articolo.

grep '/llms.txt' access.log | grep -Ei 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|Claude-Code|PerplexityBot|Perplexity-User|Google-Extended'

Sono i nomi documentati dalle pagine ufficiali di OpenAI, Anthropic, Perplexity e Google. Se la lista torna vuota, hai la tua risposta, e non te l’ha data un blog: te l’ha data il tuo server.

Il test è riproducibile e non costa niente. Se lo fai, scrivimi cosa ti esce: sto raccogliendo risultati su siti diversi per tipologia, e i numeri di un blog italiano di nicchia mi interessano quanto quelli di un sito di documentazione.

Quando ha senso metterlo e quando no

Ha senso dove il contenuto viene letto da un agente, non da una persona arrivata da una ricerca. La riga di taglio è questa, e non passa per il settore: passa per chi consuma il testo.

Il criterio in una frase: se il tuo contenuto finisce incollato dentro un IDE o dentro il contesto di un agente, l’indice serve; se finisce letto da un essere umano che ci arriva da Google o da una risposta generata, l’indice non fa niente che sitemap e markup non facciano già.

E c’è un costo che nessuno mette a bilancio: il file va mantenuto. Un llms-txt scritto una volta e dimenticato per otto mesi descrive un sito che non esiste più, e un indice sbagliato è messo peggio di un indice assente, perché chi lo legge ci crede.

Come si crea e si mette online

Si scrive a mano in mezz’ora, si salva come llms.txt e si carica nella root del dominio, così che risponda su https://tuosito.it/llms.txt. Tre strade, in ordine di quanto mi fido del risultato.

A mano. La consigliata, e non per snobismo artigianale: il valore del file sta nella selezione dei link, e la selezione la sai fare solo tu. Venti link scelti battono duecento generati. Apri un editor di testo, H1 col nome del sito, blockquote di una riga, due o tre sezioni H2 con i link che vuoi davvero far leggere, ciascuno con la sua descrizione dopo i due punti.

Con un plugin WordPress. Yoast SEO ha l’interruttore in Yoast SEO > Impostazioni > Funzioni del sito > Strumenti AI > LLMS.txt: lo accendi e il file compare. AIOSEO fa lo stesso, con una differenza da conoscere prima di installarlo: la versione Lite genera solo llms.txt, mentre llms-full.txt e l’output markdown stanno nella Pro. In entrambi i casi vai a leggere cosa hanno prodotto prima di lasciarlo online: un file generato dal CMS tende a includere tutto ciò che il CMS considera contenuto, categorie e archivi paginati compresi.

Con un generator automatico. Firecrawl ne ha uno pubblico: gli dai il dominio, scansiona e sputa fuori il file. In cima alla pagina però c’è l’avviso: l’endpoint è deprecato e Firecrawl non lo mantiene più dal 30 giugno 2025, e rimanda allo script create-llmstxt-py. Va ancora bene per la prima bozza su un sito grosso, sapendo che dietro non c’è più nessuno che lo aggiorna.

Cosa non metterci dentro: URL che non hai linkato da nessuna parte nel sito (il file diventa la mappa di quello che volevi tenere defilato), pagine scadute, e l’intero archivio paginato. Nessun bisogno di dichiararlo in robots.txt o nella sitemap: la specifica non lo prevede e nessun motore lo va a cercare lì.

Cosa cambia con la spec v2

La v2 cambia quattro cose e nessuna pagina italiana le racconta. Stanno tutte sulla pagina delle modifiche di llmstxt.org.

Il file può stare su qualsiasi subpath. Non più solo in root: puoi averne uno in /docs/llms.txt e uno in /docs/api/llms.txt, e vale il più specifico rispetto al percorso che si sta leggendo. Comodo sui siti grandi, dove due sezioni non c’entrano niente l’una con l’altra.

La discovery passa dai link. Puoi dichiarare la versione markdown di una pagina con rel="alternate" e type="text/markdown", e puntare al file di descrizione con rel="describedby", sia come tag <link> nell’HTML sia come header HTTP Link. Chi non può toccare il markup ha finalmente una strada.

Gli URL markdown ammettono due forme, entrambe valide: l’estensione .md appesa all’URL completo, estensione inclusa (/guida.html diventa /guida.html.md), oppure l’estensione sostituita (/guida.html diventa /guida.md). Prima valeva solo la prima, e chi pubblica con tool che sostituiscono l’estensione doveva scegliere fra la spec e le proprie route.

La sezione Optional cambia significato. Nella v1 aveva una semantica meccanica legata ai tool di espansione del contesto, che lì dentro decidevano cosa scartare quando lo spazio finiva. Nella v2 torna a essere quello che sembra: materiale secondario, senza una regola automatica che ci lavori sopra.

Rischi, costi e falsi positivi

Il costo vero è la manutenzione, il rischio vero è crederci troppo.

Il drift. Il sito cambia, il file no. Dopo qualche mese il file racconta una struttura che non esiste più, con link a pagine spostate e sezioni sparite. Chi lo legge non ha modo di accorgersene: si fida dell’indice, e l’indice mente con la faccia seria.

Gli URL che non volevi in vetrina. Un generator automatico pesca dalla sitemap o dal crawl, e ci finisce dentro roba che dal sito non è linkata da nessuna parte: landing vecchie, pagine di test, archivi lasciati morire in pace. Rileggilo riga per riga prima di pubblicarlo.

Il falso senso di controllo. È il costo più caro e non si vede da nessuna parte: metti il file, spunti la casella, e ti convinci di aver fatto qualcosa per la visibilità sui sistemi AI. In quella direzione non hai fatto niente, e nel frattempo non hai fatto le cose che invece contano.

Poi ci sono i falsi positivi degli strumenti, che a giugno 2026 hanno colpito perfino l’audit di Chrome. Nella issue 17082 di Lighthouse, aperta il 18 giugno 2026 e poi chiusa con una PR, l’audit segnalava “Fetch of llms.txt failed” su file perfettamente conformi alla specifica, mentre i log del CDN mostravano fetch riusciti (HTTP 200, Content-Type text/plain), su Chrome 146 dentro PageSpeed Insights.

Morale operativa: prima di riscrivere il file perché un tool lo boccia, apri i tuoi log e verifica se il tool ha ragione.

In sintesi

Il verdetto in due righe. llms.txt non ti porta visibilità sui motori AI, perché Google dichiara di ignorarlo e gli altri non dichiarano di leggerlo. Ti serve se pubblichi documentazione che finisce dentro un assistente di coding, e in quel caso serve sul serio. In mezzo non c’è granché.

Se ce l’hai online, fatti un favore: apri i log, filtra per gli user-agent della lista qui sopra e guarda chi te lo chiede in un mese. Poi scrivimi il numero. Sto mettendo insieme i risultati su tipologie di sito diverse e mi interessa soprattutto il caso italiano, dove finora non l’ha misurato nessuno.

Da leggere accanto a questo: la guida alla SEO per l’AI, e se stai lavorando su come i sistemi generativi riconoscono la tua entità, il knowledge graph e il knowledge panel di Google.

Domande frequenti