llms, il file che presenta il tuo sito alle AI

Scrivi l’indirizzo del tuo sito, aggiungi /llms.txt e premi invio: può darsi che il server restituisca un file di cui ignoravi l’esistenza.

In testa trovi il nome del dominio e due righe di presentazione, sotto una lunga serie di link raggruppati per sezione. Se in azienda nessuno ricorda di averlo scritto, lo ha generato un plugin o il CMS all’attivazione di un’opzione, e da allora presenta il tuo brand con frasi che non hai mai approvato.

llms.txt ha la fama di indicare alle intelligenze artificiali quali contenuti citare quando qualcuno chiede di te. Con ogni probabilità nessuna di loro è ancora passata a leggerlo.

Che cos’è llms.txt

llms.txt è il file con cui indichi ai programmi costruiti sui modelli linguistici quali contenuti del tuo sito meritano la loro attenzione e in che ordine leggerli. È un testo in Markdown, la sintassi che segna titoli ed elenchi con pochi simboli e resta leggibile da una persona come da un software. In cima sta il nome del progetto, l’unica parte che la specifica richiede; sotto possono stare una sintesi di poche righe, utile a interpretare il resto, e gli indirizzi delle risorse raccolti per argomento. Ogni voce porta il titolo della risorsa, il suo indirizzo e, facoltativa, una nota su che cosa si trova in fondo al link.

I programmi a cui ti stai rivolgendo sono gli agenti AI, i software che aprono pagine e documentazione per portare a termine un incarico ricevuto da una persona. È un agente l’assistente di programmazione a cui uno sviluppatore chiede di collegare il tuo servizio al gestionale che sta scrivendo; lo è il chatbot che va a controllare le condizioni di un abbonamento prima di rispondere. Arrivano con un compito già definito, e il sito lo leggono in funzione di quello.

Il perimetro della dichiarazione lo fissa la cartella in cui pubblichi il file. Alla radice del dominio riguarda l’intero sito; dentro un percorso vale per i soli URL che stanno sotto, e un llms.txt in /docs/ descrive la documentazione mentre il resto del catalogo resta fuori dal suo campo. Dove più file si sovrappongono, per un agente vale il più specifico. Puoi quindi descrivere una sola sezione, anche quando la radice del dominio non la controlli.

llms.txt non è uno standard del W3C né una RFC dell’IETF, e nessun programma è tenuto a implementarlo. Jeremy Howard ha pubblicato la specifica il 3 settembre 2024 sul dominio llmstxt.org, a nome di Answer.AI e fast.ai, il laboratorio di ricerca e il progetto open source con cui lavora sui modelli linguistici, e il documento si presenta come una proposta aperta. La selezione dei contenuti non è definita dalla specifica, quindi due plugin possono generare file diversi pur rispettando lo stesso formato.

Il 10 agosto 2026 Howard ha pubblicato la versione 2, che formalizza il perimetro per percorso, introduce i collegamenti per trovare le copie Markdown e riduce «Optional» a una convenzione per i link secondari. Una guida non aggiornata dopo quella data va verificata contro la versione attuale.

Che cosa costa a un agente AI leggere il tuo sito

Un agente che arriva sul tuo sito non ha convenienza a esplorarlo indiscriminatamente. Il modello che lo governa ragiona dentro una finestra di contesto, la quantità di testo che riesce a tenere presente in una volta, e l’HTML delle tue pagine se ne prende una fetta in menu, script, banner e avvisi sui cookie prima di arrivare al contenuto. Ricavare da quel codice un testo pulito resta un’operazione imprecisa, e il token speso sul codice superfluo è tempo di calcolo che non torna.

Un llms.txt propone una soluzione più compatta: un documento abbastanza leggero da stare per intero nel contesto, che elenca le risorse invece di contenerle e lascia i dettagli dietro i link, recuperati quando servono. La specifica lascia a chi pubblica il file la scelta degli indirizzi e del loro ordine.

Che cosa lo distingue da robots.txt e dalla sitemap XML

Il robots.txt condivide con llms.txt la posizione e la desinenza del nome, e governa un’altra materia. Nel robots.txt dichiari quali percorsi un crawler può richiedere, e i programmi che applicano il protocollo leggono quelle regole prima di chiedere qualsiasi risorsa al tuo server. Un llms.txt entra in gioco dopo, quando un agente sta già cercando materiale per un compito. Una sezione in Disallow resta quindi fuori portata per chi rispetta la direttiva, anche se compare fra i collegamenti del sommario. ChatGPT-User e Perplexity-User fanno eccezione dichiarata: gli operatori scrivono che, quando il recupero nasce da una richiesta diretta dell’utente, quelle regole possono non essere applicate.

Il soprannome di «sitemap per le AI» circola fin dall’inizio. La sitemap XML però la consegni ai motori di ricerca perché scoprano gli URL che vuoi rendere disponibili alla scansione, e li elenca tutti. In un llms.txt indichi soltanto i documenti che contano per un certo perimetro, e puoi indicare anche risorse esterne quando aiutano a capire le tue. Howard aggiunge una ragione pratica: una sitemap copre di norma una quantità di documenti che nessuna finestra di contesto riesce a contenere.

Un URL elencato in llms.txt mantiene il canonical, le direttive robots e le condizioni di indicizzazione che aveva già: entra in Google se e quando ci sarebbe entrato comunque, e continua a essere fuori portata per i crawler che rispettano il Disallow.

Quanto serve llms.txt, e chi lo apre davvero

llms.txt ha un ruolo molto più circoscritto della fama che si è costruito. Offre effettivamente agli agenti una mappa sintetica delle risorse che vuoi rendere facili da individuare, con indicazioni sul loro contenuto e sulla loro funzione, ma non governa la scansione, che resta materia del robots.txt, né assegna priorità alle pagine nei sistemi di ricerca. Organizza una selezione e la rende leggibile a un programma che decide di consultarla.

Il valore sta quindi soprattutto nella chiarezza che aggiunge. Su documentazioni, API e raccolte ampie di risorse può ridurre il lavoro necessario per trovare il documento pertinente; su blog, ecommerce e siti aziendali il beneficio è meno evidente. Inoltre, ad oggi non abbiamo prove solide che la presenza di llms.txt aumenti la probabilità di essere scelti o citati nelle risposte generative. Pubblicarlo aggiunge un percorso possibile verso i tuoi contenuti, non un segnale di ranking o una garanzia di visibilità.

Questo non lo rende inutile. Se sitemap, accessibilità delle pagine, dati strutturati e robots.txt sono già in ordine, compilare llms.txt ti obbliga a esplicitare quali risorse hanno davvero una funzione per un agente e come vuoi descriverle. Se il file esiste già perché lo ha generato il CMS, il controllo è ancora più semplice: vale la pena verificare che quella selezione e quelle descrizioni corrispondano ancora al sito. Se invece devi costruirlo da zero, la priorità dipende dall’uso che puoi ragionevolmente aspettarti e, soprattutto, da quello che riesci a osservare.

Su quest’ultimo punto abbiamo qualche dato. Nel maggio 2026 Ahrefs ha analizzato le richieste a llms.txt su 137.210 domini collegati al proprio servizio di analytics (siti più tecnici e più attenti alla SEO della media del web, avvertivano già gli autori): pubblicavano un file valido 38.360 casi, e il 97% non ha ricevuto una sola richiesta nel mese. Una richiesta registrata, inoltre, documenta un fetch e non dimostra che il file sia stato letto o utilizzato: le percentuali descrivono quindi un limite superiore all’uso reale. Sui domini che non lo pubblicano, nessun sistema AI è andato a cercarlo.

Il 96% delle richieste arriva da bot, con cui l’AI addirittura ha poco a che fare: strumenti SEO, crawler generici, validatori, servizi che studiano proprio la diffusione del formato. I sistemi AI identificati valgono il 19,5% delle richieste, e fra le categorie principali gli agenti pesano il 10,5%, i crawler di addestramento il 5,3%, i bot che recuperano le fonti per le risposte generative – OAI-SearchBot e PerplexityBot – l’1,1%.

D’altra parte, anche nella sua guida all’ottimizzazione per le funzionalità di AI generativa Google dichiara che per comparire non servono file dedicati all’AI, markup aggiuntivo o versioni in Markdown, perché la Ricerca non li usa, una posizione che ha ripetuto più volte; tenere il file per altri servizi resta legittimo e non aiuta né danneggia la visibilità. AI Overview e AI Mode lavorano sull’indice che Googlebot costruisce visitando le tue pagine, e una pagina può essere considerata per quelle risposte quando è indicizzata e idonea allo snippet.

Lighthouse cerca invece /llms.txt alla radice del dominio, dentro Agentic Browsing, la categoria sperimentale dedicata alla navigazione degli agenti: esito positivo se il server lo restituisce, «non applicabile» se risponde con un 404, perché pubblicarlo resta facoltativo, problema segnalato se la richiesta finisce in un errore del server. Il controllo verifica che il file esista, non che cosa contenga.

Che cosa si vede nei log, e fin dove arriva

Le richieste a /llms.txt compaiono nel log del server, il registro in cui ogni accesso porta indirizzo IP, data, risorsa richiesta e user agent, la stringa con cui un programma dichiara chi è. Settimane senza una sola riga dicono che in quel periodo, sul tuo dominio, nessun programma ha chiesto il file.

Sullo user agent, da solo, non puoi contare. Si falsifica in un momento, e nel registro uno scraper che prende il nome di un bot noto appare identico all’originale. Gli operatori pubblicano per questo gli intervalli IP delle proprie infrastrutture: OpenAI per GPTBot, OAI-SearchBot e ChatGPT-User, Perplexity per PerplexityBot e Perplexity-User. Il confronto fra indirizzo di provenienza e intervallo dichiarato separa il traffico legittimo da quello che ne prende il nome.

Accessi da strumenti SEO e da validatori raccontano di qualcuno che controlla se il file esiste e se rispetta il formato. Una visita di GPTBot documenta il passaggio di un crawler destinato all’addestramento, e il peso di quel download sul modo in cui un modello parlerà del tuo brand sfugge a qualunque registro. ChatGPT-User e Perplexity-User possono richiedere pagine in risposta a un’azione dell’utente e, quando lo fanno, compaiono nel log con il proprio user agent.

Un indizio più solido compare quando la richiesta al file è seguita a breve, dalla stessa infrastruttura, dalle richieste agli URL che il file elenca. Resta un indizio, perché il ragionamento del sistema non è osservabile: il recupero dimostra che qualcuno ha scaricato il documento, non che abbia seguito le indicazioni contenute dentro.

Che cosa succede dopo che un agente ha aperto il file

Quando un agente scarica il tuo llms.txt, la proposta prevede che cerchi nel documento le informazioni utili e segua i collegamenti pertinenti. La scelta di usare o citare una di quelle risorse avviene dopo, e dipende da criteri che llms.txt non controlla.

Una risposta generativa può nascere dalla conoscenza che il modello ha assimilato durante l’addestramento, ferma fino all’aggiornamento successivo, oppure da informazioni recuperate sul momento – è la differenza tra GEO e AEO. Il tuo llms.txt può essere scaricato dai crawler che alimentano l’addestramento, e che cosa ne facciano dopo non è osservabile da fuori. Nella ricerca dal vivo entra soltanto se qualcuno va a chiederlo.

Per AI Overview e AI Mode, Google descrive il query fan-out, la scomposizione della domanda in più interrogazioni collegate, e dichiara che le pagine di supporto vengono individuate attraverso i sistemi della Ricerca. Le esperienze generative poggiano sui sistemi di ranking e qualità e recuperano pagine dall’indice, quindi essere indicizzata e idonea allo snippet è la condizione minima perché una tua pagina possa entrare in quel bacino. Il percorso completo di una risposta ha altri snodi, e llms.txt non compare fra quelli che Google indica. Altri assistenti usano infrastrutture, indici e agenti differenti, quindi una regola universale costruita su un solo prodotto non tiene.

Una pagina deve comunque essere raggiungibile, chiara su che cosa tratta, aggiornata e pertinente alla richiesta. Il title link e lo snippet sono ancora la rappresentazione della tua pagina nei risultati di ricerca; i dati strutturati continuano a descrivere entità e proprietà nei contesti in cui sono supportati, e Google avverte che non esiste un markup dedicato alla visibilità nelle risposte generative. Una mappa porta un sistema fino a una risorsa; sceglierla come fonte è un’operazione successiva, e con altri criteri.

Dove un agente ha davvero un compito da svolgere

La documentazione software è il caso in cui la proposta dichiara l’uso più intenso. Un agente di programmazione deve recuperare la firma di una funzione, controllare un parametro, leggere la procedura di autenticazione, capire come una libreria gestisce un comportamento specifico; in una documentazione ampia un llms.txt può ridurre i recuperi inutili. Fra gli esempi di adozione la proposta cita le documentazioni per sviluppatori di OpenAI, Anthropic e Gemini, e diverse piattaforme di documentazione generano il file per ogni progetto che ospitano.

Fuori dal software la proposta porta esempi distanti fra loro, tenuti insieme da un agente che deve recuperare informazioni con uno scopo riconoscibile: un’azienda che espone struttura e policy, una scuola che organizza le informazioni sui corsi, un sito personale da cui ricostruire un curriculum.

Su un blog, un ecommerce o un sito aziendale non abbiamo prove solide di un vantaggio diretto sulla visibilità nelle risposte AI. Compilare il file significa comunque scegliere quali risorse rendere più facili da individuare per un agente e descrivere la funzione di ciascuna, e su un sito già in ordine – sitemap valida, contenuti accessibili, pagine pulite, dati strutturati coerenti – è la ragione più solida che abbiamo per pubblicarlo.

Anche un file generato dal CMS contiene una selezione, definita dalle regole del generatore. La specifica elenca fra le integrazioni Mintlify e GitBook per la documentazione, Yoast SEO e AIOSEO per WordPress, Wix per i siti costruiti sulla sua piattaforma, e il Web Almanac 2025 conta llms.txt sul 2,1% dei siti, con il 39,6% di quelle occorrenze generato automaticamente da un plugin.

Un generatore mette in fila la tassonomia del CMS, e chi non ha mai aperto il file ci trova dentro cose che non avrebbe scelto. Le pagine compaiono con il titolo che hanno nel backend, quindi una home può presentarsi con il proprio title SEO o con il nome di lavorazione che nessuno ha più cambiato. Accanto ai contenuti su cui hai costruito la tua competenza finiscono le landing di promozioni scadute, le pagine fatte per un singolo canale o per un codice sconto, le flash news, le categorie, le voci di glossario, tutte allo stesso livello. Se il plugin ha compilato anche la riga di presentazione, l’ha presa dalla descrizione del sito, nella lingua in cui è impostata. La somma di quelle voci è il ritratto del brand che consegni a chi il file lo legge, e non l’ha scritto nessuno.

Se il file esiste già, aprilo e verifica che cosa dichiara al posto tuo. Se non esiste, scriverlo ha senso soprattutto quando hai un uso agentico riconoscibile – documentazione, API, procedure che gli assistenti di programmazione consultano – oppure quando nei log vedi richieste che arrivano davvero. Su un sito editoriale senza quelle evidenze, llms.txt è un’attività secondaria rispetto alle pagine che dovresti dichiararci dentro.

Quali pagine metti nel file

La regola di base per compilare il file llms.txt è “inserisci una risorsa quando puoi dire quale compito aiuta un agente a svolgere“. «Questa pagina è buona» e «questa pagina è recente» non sono compiti. Più indirizzi sullo stesso tema hanno senso quando svolgono funzioni diverse: documentazione e riferimento delle API, procedura e pagina dei limiti, guida e changelog possono convivere nello stesso file. Si sovrappongono quando rispondono alla stessa richiesta con contenuti equivalenti, e lì la voce doppia trasferisce all’agente un’ambiguità che è tua. Conviene poi che ogni pagina sia comprensibile anche fuori dal percorso di navigazione costruito per le persone.

Su un tema presidiato da anni le pagine raramente sono una sola. C’è la guida, c’è l’aggiornamento che l’ha seguita, c’è la categoria che nel frattempo si è irrobustita, c’è la landing commerciale che affronta lo stesso argomento da un’altra angolazione. Elencarle tutte senza chiederti che compito svolge ciascuna evita la decisione. Distinguere le voci che convivono da quelle che si contendono la stessa richiesta ti chiede di guardare il sito dall’esterno, con dati che a occhio non hai – ed è il momento in cui ti aiuta SEOZoom.

Quando più tue pagine si contendono la stessa richiesta

Quali tue pagine si sovrappongono su un tema lo leggi nella Cannibalizzazione del progetto. Ogni riga porta traffico, numero di keyword, menzioni AI e il conteggio degli altri URL coinvolti; aprendola vedi quali sono, con quante keyword condivise e con quante menzioni ciascuno. L’elenco non stabilisce quale voce va nel file, mostra gli URL che condividono keyword e ti lascia individuare i casi da verificare prima di compilarlo. La colonna delle menzioni aggiunge quale di quelle pagine i sistemi generativi già nominano.

Con le Keyword Monitorate controlli quale URL del dominio compare nella SERP rilevata. Scelta una voce nell’elenco, il pannello di destra la mostra accanto ai punteggi di autorità della pagina e del dominio. Se è diverso dall’indirizzo che stavi per mettere nel file, hai una decisione davanti: allinearti all’URL che in quella SERP si sta posizionando, oppure tenere il tuo e sapere perché. Quando due tue pagine si contendono la stessa richiesta, distinguerle o accorparle è il lavoro che rende sensata la voce.

Cannibalizzazione e Keyword Monitorate sono utili soprattutto quando le risorse che dichiari presidiano query organiche: siti editoriali, ecommerce, corporate. Su una documentazione tecnica il criterio resta il compito, e una API reference entra perché risolve un problema preciso a un agente, non perché si posiziona.

Se la destinazione regge il ruolo che le stai dando

La tenuta tecnica della destinazione la verifichi con il SEO Spider, che per ogni URL restituisce codice di risposta, canonical, direttive robots, title, description e intestazioni. Il report mette in evidenza le destinazioni da correggere o da verificare. Un indirizzo che risponde con un errore non restituisce la risorsa prevista; per uno che risponde con un redirect conviene indicare direttamente la destinazione finale. Un URL in noindex, o con canonical verso un altro indirizzo, resta invece perfettamente utilizzabile da un agente – una documentazione che non vuoi nell’indice è il caso tipico – e ti chiede soltanto di verificare che sia una scelta e non un residuo. La scansione parte da un indirizzo e segue i link interni, quindi una risorsa isolata dal linking interno non compare nel report e va controllata a parte.

Una migrazione può rendere obsoleto un llms.txt formalmente valido. Una pagina cambia indirizzo, una categoria viene chiusa, due contenuti vengono accorpati, una landing viene sostituita, e il CMS continua a esportare la tassonomia di prima: il file rimane al suo posto e consegna all’agente una mappa corretta verso risorse che nel frattempo hanno cambiato ruolo.

La sintassi del file, e le note che lo fanno funzionare

La specifica fissa la struttura. In cima un titolo H1 con il nome del progetto o del sito, l’unica parte obbligatoria. Può seguire una sintesi in blockquote, la citazione che in Markdown si apre con il simbolo >, con le informazioni necessarie a capire il resto, e poi eventuali paragrafi o elenchi senza titoli, dove spieghi come interpretare le risorse, e infine le sezioni introdotte da un titolo H2, ciascuna con un elenco di link in cui ogni voce porta il nome della risorsa, l’URL e, dopo i due punti, una nota.

# Nome del progetto
 
> Che cosa fa il progetto e per chi, in una o due frasi.
 
Indicazioni su come usare le risorse elencate.
 
## Documentazione
 
- [Guida introduttiva](https://example.com/docs/guida.md): requisiti e primi passi
- [Riferimento tecnico](https://example.com/docs/riferimento.md): parametri e risposte
 
## Optional
 
- [Storico delle versioni](https://example.com/docs/versioni.md)

Titolo e indirizzo dicono poco di che cosa aspettarsi; la nota permette di capire a che cosa serve quella risorsa prima di aprirla. Una descrizione come «tutte le informazioni sul nostro prodotto» non aiuta a scegliere; una nota che delimita il contenuto, specifica la funzione della risorsa o segnala una condizione particolare fa il lavoro per cui esiste. Le indicazioni dell’autore chiedono parole chiare e nessun gergo lasciato senza spiegazione.

La sintesi in testa al file va confrontata con la home, con la pagina chi siamo e con i dati strutturati Organization. Una descrizione del brand disallineata da quelle mette in circolo una seconda versione della stessa identità, e quella versione la leggono i programmi.

Prima di pubblicare, l’autore della proposta suggerisce un collaudo: dai a un agente AI il tuo llms.txt come unico punto di partenza e chiedigli di rispondere a qualche domanda sui contenuti del sito. L’agente deve poter seguire i collegamenti e arrivare alle risorse giuste. Se non ci arriva, o se sceglie la pagina sbagliata, hai qualcosa da isolare: la selezione e le note sono i primi posti dove guardare, ma il punto può stare anche nella pagina, nei link interni o nel modo in cui hai formulato la richiesta.

Le versioni Markdown e i collegamenti che le rendono trovabili

La specifica raccomanda di puntare a contenuti già leggibili dai modelli e propone di affiancare a ogni documento utile una copia in Markdown allo stesso indirizzo, con .md aggiunto in fondo (pagina.html.md) oppure al posto dell’estensione (pagina.md). Un agente che apre quella copia riceve il testo senza il codice che avvolge la versione HTML, e le due forme di indirizzo convivono perché le implementazioni reali avevano già preso entrambe le strade.

Perché quelle copie siano raggiungibili anche da un agente arrivato senza passare dal sommario, la versione 2 indica i collegamenti che le dichiarano. Nella pagina originale un elemento link con rel="alternate" e type="text/markdown" indica dove sta la copia Markdown, uno con rel="describedby" quale llms.txt descrive quella pagina. Gli stessi collegamenti viaggiano nell’intestazione HTTP Link della risposta, soluzione che funziona anche per risorse senza una pagina HTML da modificare, e che imposti sul server o sulla CDN senza toccare il codice del sito.

Quanto valga la pena costruirle dipende da chi passa davvero sul tuo dominio, e il conto va fatto insieme al resto del lavoro di accessibilità tecnica dei contenuti: su una documentazione consultata dagli agenti di programmazione l’utilità è molto più evidente che su un blog editoriale, dove ogni copia è un contenuto in più da tenere allineato.

Le pagine che dichiari e le fonti che compaiono nelle risposte AI

Con llms.txt hai indicato agli agenti quali risorse consideri utili per determinati compiti. Il passaggio successivo è osservare che cosa succede sulle stesse aree tematiche quando entrano in gioco le risposte generative: quale URL del tuo sito compare, se ne emerge uno diverso da quello che avevi scelto e quali fonti esterne partecipano alla risposta.

Sono due piani distinti. Nel file organizzi e descrivi le risorse che vuoi rendere più facili da individuare; nelle risposte AI osservi invece le fonti effettivamente comparse nelle rilevazioni. Il confronto ti aiuta a capire se la pagina che hai selezionato coincide con quella utilizzata dal sistema oppure se emerge un’altra configurazione.

In SEOZoom puoi seguire questo confronto con AI Prompt Tracker. Monitori i prompt che rappresentano le domande e gli intenti rilevanti per il tuo brand e, nella colonna Pagine web, vedi quali URL del dominio compaiono nelle risposte. Aprendo il dettaglio trovi anche le Fonti utilizzate, con indirizzo e passaggio ripreso dal sistema.

Se compare proprio la pagina che avevi selezionato, i due segnali coincidono. Se emerge un altro URL del tuo sito, puoi verificare se risponde meglio a quella domanda, copre un intento diverso o rende opportuno rivedere la selezione. Quando compare una fonte esterna, puoi aprirla e capire quale informazione sta fornendo e quale spazio occupa nella risposta.

La coincidenza fra la pagina indicata nel file e quella citata da un assistente non dimostra però che una abbia causato l’altra, attenzione: il sistema può aver raggiunto quella risorsa dalla Ricerca, da un proprio indice, dal linking interno o da un’altra fonte, e quel percorso non è osservabile. Hai misurato un accordo fra la tua selezione e ciò che compare nella risposta. Non hai misurato un effetto.

Se il file esiste già sul tuo sito, controlla quindi quali risorse indica, come le descrive e se gli URL sono ancora quelli che vuoi rendere disponibili agli agenti. Se devi crearlo da zero, la priorità cambia con il contesto: documentazione, API e procedure consultate dagli agenti gli danno una funzione concreta; su un blog, un ecommerce o un sito aziendale senza segnali di utilizzo viene dopo il lavoro sulle pagine, sulla loro accessibilità e sulla qualità delle informazioni che contengono. llms.txt può rendere più semplice trovare una risorsa. Il valore resta nella risorsa che l’agente trova.