LLMS.txt è un file di testo pubblico, posizionato di norma alla radice del dominio (/llms.txt), pensato per offrire agli strumenti di Large Language Models (LLM) una guida esplicita su come leggere e interpretare i tuoi contenuti in fase di consultazione e risposta. Non sostituisce robots.txt, né impone regole di accesso: agisce come un canale dichiarativo che segnala che cosa è utile ai modelli e come va interpretato.
Mentre robots.txt nasce per governare la crawling policy (chi può accedere e dove) secondo il Robots Exclusion Protocol (RFC 9309), il file LLMS.txt si propone come una “guida d’uso” per i sistemi che consumano i contenuti durante l’inferenza, indicando quali URL sono più adatti per estrarre risposte attendibili, quale è il contesto, come si possono citare le fonti e quali limiti semantici andrebbero rispettati.
La spinta a usare LLMS.txt è aumentata in parallelo all’adozione di crawlers legati ad AI e a user-agent specifici (ad esempio GPTBot, Google-Extended, CCBot di Common Crawl), controllabili via robots.txt. Tuttavia la funzione di LLMS.txt è diversa: non blocca, ma chiarisce che cosa vale la pena leggere, in che ordine, con quali istruzioni di interpretazione, e come gestire citazioni e limiti d’uso.
Un’azienda che vuole governare presenza organica, traffico da motori e riuso da parte di AI deve distinguere tre piani:
1) robots.txt gestisce l’accesso dei crawler. È normato da una specifica tecnica e accettato dalla maggioranza dei motori. Consente di permettere o negare la scansione per uno o più user-agent, e può includere regole dedicate a bot per AI come GPTBot o Google-Extended. Se l’obiettivo è escludere certe aree dal training, robots.txt resta la sede adeguata.
2) Meta direttive e intestazioni su singola pagina (ad esempio approcci emergenti per dichiarare preferenze “no AI” o simili) mirano a esprimere la volontà dell’editore a livello di documento. Il supporto varia tra operatori e non esiste un’uniformità definitiva; per questo conviene trattarle come indicazioni aggiuntive.
3) LLMS.txt non governa l’accesso ma la comprensione e l’utilizzo dei contenuti in fase di risposta: può elencare sezioni prioritarie, dataset verificati, glossari, policy di citazione, contesti temporali e versioning. È un file descrittivo, pensato per migliorare qualità delle risposte, affidabilità delle citazioni e riduzione delle allucinazioni.
Creare un LLMS.txt ben scritto porta benefici misurabili. Le aziende lo usano per orientare chatbot, motori con risposta generativa e agent che costruiscono snippet direttamente dai siti.
Maggiore coerenza: i modelli ricevono una mappa chiara delle pagine affidabili, con priorità e aggiornamenti, riducendo interpretazioni errate su contenuti obsoleti.
Migliore citabilità: si possono dichiarare regole di citazione e crediti, favorendo l’inserimento di link di origine nelle risposte.
Riduzione del rischio: suggerendo dataset certificati e pagine ufficiali si limita l’uso di fonti non controllate.
Supporto all’aggiornamento: il file diventa un indice vivo di ciò che cambia nel sito, con date e changelog sintetici.
Allineamento legale: puoi chiarire condizioni d’uso, licenze, preferenze di citazione, contesti di esclusione e di fair use, integrando il tutto con la policy sul trattamento dei dati.
Non esiste un’unica specifica vincolante, ma il panorama si è orientato verso una struttura leggibile in chiaro, con blocchi identificati e campi fissi. Il formato più usato prevede sezioni con titolo e coppie chiave: valore, e una o più righe per quantità variabili (come liste di URL). Qui sotto trovi un modello che usiamo spesso nei progetti.
Comprende nome del sito, data, versione del file, lingua principale e contatti del team. Serve ai modelli per capire freschezza e punto di verità.
Descrive in poche righe perché il file esiste, quali tipologie di risposte intende abilitare, come trattare i contenuti in termini di contesto, licenza e diritti.
Elenco di categorie, hub, pillar page e documentazione con tag “priority” e annotazioni su quando conviene citarle. È utile indicare l’ordine preferito e eventuali alternative.
Link a dataset pubblici o pagine di specifica interna, glossari e definizioni terminologiche. I modelli apprezzano una terminologia coerente.
Istruzioni su come attribuire i contenuti: preferire titolo pagina e anchor specifica, includere anno o data ultima modifica, usare URL canonico.
Dichiara aree dove è meglio non estrarre passaggi (es. pagine non aggiornate, contenuti promozionali, sezioni in bozza), o dove è necessaria una nota di contesto.
Indica frequenza di revisione, dove trovare il changelog e chi contattare per integrazioni. Questo aumenta la fiducia dei sistemi che consumano il file.
Di seguito un esempio semplificato che puoi adottare e adattare. Ogni riga è pensata per essere comprensibile a sistemi automatici e a persone.
Un file LLMS.txt porta valore quando è sostenuto da un flusso chiaro. Questo è il percorso che consigliamo nei progetti: audit, modellazione informativa, stesura, QA tecnico, pubblicazione, monitoraggio.
Si censiscono pagine e documenti che rappresentano il punto di verità: guide, documentazione, Q&A, schede prodotto, white paper, policy. Ogni contenuto riceve metadati minimi: data, proprietà, stato di aggiornamento, qualità editoriale.
Si selezionano le sezioni prioritarie che il modello dovrebbe consultare. Il tag “priority” non è solo un elenco: conviene indicare quali pagine usare per definizioni, quali per esempi applicativi e quali per normative o tariffe.
Si lavora in un editor di testo, controllando l’encoding (UTF-8) e la conformità ai separatori. Preferiamo campi in minuscolo, chiave univoca e valori chiari. Dove possibile si normalizzano i nomi (es. priority_sections) per garantire prevedibilità.
Se vuoi impedire che certi bot di AI usino il tuo sito per training, robots.txt è il luogo adeguato. Esempi frequenti riguardano GPTBot, il crawler di OpenAI, Google-Extended e CCBot di Common Crawl. Le regole di esclusione del training vanno mantenute coerenti con ciò che dichiari nel LLMS.txt, per evitare messaggi incoerenti.
Si pubblica il file in /llms.txt. È utile registrare la pagina nel monitoring, aggiungere test periodici e versionare il testo. In alcuni casi conviene conservare un “llms-full.txt” con dettagli aggiuntivi, non necessariamente esposti.
Si programma una revisione mensile o trimestrale, legandola al ciclo di aggiornamento della documentazione. Ogni modifica rilevante merita una voce di changelog. Così i sistemi che leggono il file capiscono che il contenuto è vivo.
L’ottimizzazione non si esaurisce nel posizionamento classico. Le risposte generate da motori e chatbot citano fonti, estraggono definizioni e sintetizzano passaggi in autonomia. Un LLMS.txt fatto bene aiuta a indirizzare questo comportamento verso pagine solide, coerenti, aggiornate, riducendo estrazioni da contenuti meno affidabili.
Tre riflessi che osserviamo spesso: più link alle pagine hub, maggiore coerenza tra snippet AI e testi originali, migliore adesione delle citazioni alle URL canoniche. Non si tratta di automatismi, ma di probabilità: se guidi i sistemi, aumenti le chance che rispondano citando le tue migliori fonti.
Misurare l’impatto di LLMS.txt richiede un mix di analisi qualitative e quantitative. Questi i segnali che consigliamo di tracciare.
Traccia il traffico verso le URL prioritizzate nel file. Se gli agent seguono l’indirizzo della tua mappa, col tempo vedrai un incremento di visite machine-driven sulle sezioni di riferimento.
Raccogli esempi di risposte in cui la tua fonte viene citata. Alcuni operatori di AI espongono link; altri mostrano riferimenti testuali. Valuta qualità e coerenza con la richiesta.
Controlla che i passaggi citati dalle AI corrispondano al contenuto aggiornato. Se emergono discrepanze, chiariscile nel LLMS.txt aggiungendo note di contesto e correggendo le priorità.
Il file LLMS.txt è leggero, ma il suo valore dipende da pagine di destinazione veloci, accessibili e ben strutturate. Cura typography, contrasto, spaziatura, leggibilità su schermo piccolo. Riduci le dipendenze, minimizza script non indispensabili, usa immagini ottimizzate con lazy loading sulle pagine linkate come prioritarie.
Mantieni URL stabili e canonici, organizza breadcrumb e markup coerente. Se cambi struttura di navigazione, aggiorna il LLMS.txt e il sitemap per riflettere i nuovi hub.
Chi aggiorna il file? Quando? Con quale processo di approvazione? Definisci una mini content policy che indichi responsabilità, tempi, strumenti di QA, integrazione con compliance e privacy. Assegna un owner e una back-up chain, in modo che il file non resti indietro rispetto all’evoluzione del prodotto.
Se desideri escludere il training dei modelli, usa robots.txt con le regole per gli user-agent rilevanti. Alcuni esempi: User-agent: GPTBot, User-agent: Google-Extended, User-agent: CCBot. L’efficacia dipende dall’aderenza del singolo operatore: per questo conviene combinare scelte tecniche con accordi contrattuali dove possibile.
LLMS.txt rimane il luogo in cui dichiari come vorresti che i contenuti fossero usati durante la risposta. Puoi anche inserire un paragrafo che spiega che eventuali restrizioni in robots.txt hanno priorità rispetto alle indicazioni del LLMS.txt.
Una volta pubblicato il file, serve un controllo periodico. Qui trovi una checklist sintetica che puoi riusare nel tuo team.
/llms.txt, status 200, cache controllata.robots.txt e meta direttive locali.Tre errori ricorrenti: usare LLMS.txt come se fosse un blocco di accesso, elencare centinaia di URL senza priorità, confondere pagine promozionali con risorse di riferimento. Più il file è chiaro e conciso, più è utile.
Un altro errore è non allineare il file alle modifiche del sito. Se sposti le guide o rinomini le categorie, aggiorna LLMS.txt. Infine, evitare linguaggi ambigui: frasi brevi e assertive aiutano i sistemi a capire.
Se la tua strategia prevede restrizioni, usa robots.txt per gli user-agent specifici. Ecco alcuni casi d’uso reali: GPTBot (OpenAI), crawler Google e CCBot di Common Crawl. Per Google esiste anche lo user-agent Google-Extended, utilizzabile in regole dedicate, a seconda della tua preferenza d’uso dei dati.
Ricorda che robots.txt non è una misura di sicurezza. Gli operatori rispettosi lo seguono, altri possono ignorarlo. Per questo va abbinato a scelte editoriali, contrattuali e, quando serve, a soluzioni tecniche lato server.
Scegli un numero finito di hub con contenuto sempreverde: guide, documentazione, pagina about, policy e condizioni. Evita di indicare pagine stagionali o promozionali. Se hai più lingue, crea un LLMS.txt per ciascun sottodominio o percorso, oppure indica nel file la lingua prevalente e le alternative con tag dedicato.
Includi un paragrafo di contesto: descrivi come interpretare unità di misura, sigle, riferimenti normativi, versioni software o cataloghi.
Per scalare, conviene dotarsi di un piccolo generatore che prenda dati da CMS e knowledge base, producendo il file LLMS.txt aggiornato. In parallelo, prevedi test automatici su URL non raggiungibili, link non canonici e sezioni duplicate. Il monitoraggio deve segnalare se il file non risponde correttamente o se la data è troppo vecchia rispetto alla policy interna.
Per chi desidera studiare protocolli e bot AI, ecco riferimenti tecnici utili: RFC 9309: Robots Exclusion Protocol, OpenAI GPTBot, Google-Extended, Common Crawl CCBot. Per il quadro di proposta relativo a /llms.txt vedi llmstxt.org.
No. robots.txt resta lo strumento per indicare chi può includere o escludere sezioni del sito dalla scansione. LLMS.txt è un file descrittivo che suggerisce ai modelli quali pagine usare come riferimento e come citarle. Funzionano insieme, con scopi diversi.
Va pubblicato alla radice del dominio, raggiungibile su /llms.txt, servito con status 200 e codifica UTF-8. Mantieni il file sotto i 100 KB per semplicità di lettura e cache.
Seleziona hub e guide che rappresentano il punto di verità: documentazione, termini, pagine tutorial, studi di caso. Evita pagine promozionali o articoli datati. Aggiorna l’elenco quando sposti categorie o modifichi la navigazione.
Puoi esprimere preferenze (es. citare titolo, URL canonico e data). Non è una garanzia universale, ma molte piattaforme tendono a rispettare indicazioni chiare. Per tutela legale servono condizioni d’uso e accordi specifici.
Sì, in contesti complessi. Puoi mantenere un file pubblico conciso e un “llms-full.txt” più ricco, linkato solo quando necessario. L’importante è allineare le due versioni e aggiornare il changelog.
Usa robots.txt con regole per gli user-agent rilevanti (ad esempio GPTBot, Google-Extended, CCBot). Ricorda che è un meccanismo di buona condotta, non un blocco tecnico assoluto. Per una tutela maggiore valuta accordi contrattuali.
Analizza l’accesso alle pagine prioritarie, osserva citazioni e backlink generati da risposte AI, raccogli esempi e confrontali con le preferenze espresse nel file. Se emergono fraintendimenti, aggiorna istruzioni e priorità.
Non direttamente come segnale di ranking. Incide però sulla qualità delle risposte generative che possono citarti e indirizzare traffico qualificato verso le tue pagine hub. È un investimento sull’ecosistema di scoperta.
Abbina LLMS.txt al tuo ciclo editoriale: una revisione mensile va bene per molti siti. Se cambiano spesso doc e API, anche settimanale. Ogni modifica importante merita un aggiornamento di versione e una nota nel changelog.
Indica esplicitamente cosa evitare: vecchi articoli non più validi, promozioni scadute, bozze, contenuti con contesto locale o temporale che può generare fraintendimenti. Specifica anche dove trovare la fonte aggiornata.
Impostazioni privacy
Questo sito utilizza i cookie per migliorare la tua esperienza di navigazione su questo sito.
