llms.txt e Pagine di Manifesto per Agenti: Un Indice del Sito Manutenuto per Macchine

Una pagina llms.txt e manifesto per agenti è un indice rivolto alle macchine che dice ai sistemi IA cosa rappresenta un sito, quali pagine pubbliche sono autorevoli e — quando l’azienda supporta azioni degli agenti — quali capacità e policy verificate si applicano. È una mappa verso fonti mantenute, non un sostituto di tali fonti e non una promessa che un particolare crawler la utilizzerà.

Il suo contratto è identità → ambito → destinazioni autorevoli → capacità opzionali → vincoli → freschezza. Il file ha successo quando una macchina può recuperarlo, interpretarlo senza fare supposizioni, seguire URL canonici funzionanti e arrivare a fatti che corrispondono ancora alla realtà produttiva.

Domande a cui risponde

La domanda principale è: “Quali parti di questo sito dovrebbe usare un sistema IA per comprendere l’organizzazione, i suoi contenuti e le sue azioni supportate?” Le domande di supporto includono:

• Qual è il nome canonico del sito, il dominio, lo scopo e il pubblico?
• Quali pagine di prodotto, servizio, documentazione, prezzi, policy e supporto sono autorevoli?
• Quali pagine dovrebbero essere preferite rispetto ad archivi, pagine campagna, parametri o versioni regionali duplicate?
• Il sito espone una capacità effettiva per agenti, o solo informazioni leggibili da umani?
• Dove sono documentati autenticazione, limiti di frequenza, gestione dei dati, termini commerciali e supporto?
• Quali affermazioni sono indicazioni descrittive piuttosto che regole di controllo accesso?
• Chi possiede il file, quale evento attiva un aggiornamento e come viene rilevato il decadimento?

Quando usare questo tipo di post

Usa questo tipo quando il sito ha abbastanza contenuto pubblico e durevole da trarre beneficio da un indice curato orientato alle macchine e qualcuno può occuparsi della sua manutenzione. La ragione per pubblicarlo è ridurre l’ambiguità per i sistemi di recupero informazioni, non creare un URL aggiuntivo fine a sé stesso.

Non confondere indicazioni con controllo. robots.txt esprime preferenze di accesso per crawler; una sitemap XML aiuta i crawler a scoprire URL; autenticazione e autorizzazione determinano se un’azione può avvenire. llms.txt fornisce contesto curato. Una frase in llms.txt non può concedere accesso, revocare accesso, proteggere un segreto o sovrascrivere i termini di una pagina di destinazione.

Ideale per questi tipi di business

1. SaaS . La migliore corrispondenza perché un’azienda di software di solito ha fonti distinte per prodotto, funzionalità, prezzi, integrazioni, API, sicurezza, stato e documentazione. L’indice può risolvere quale pagina possiede ciascun fatto, mentre un manifesto delle capacità separato può descrivere solo le azioni che il prodotto supporta realmente.
2. Ecommerce . Adatto quando prodotti, spedizioni, resi, disponibilità e policy del servizio clienti sono pubblici e canonici. Mantieni i dati volatili degli articoli in feed o API; usa l’indice per puntare a quelle fonti mantenute piuttosto che copiare un catalogo in Markdown.
3. Marketplace . Utile quando le policy di acquirenti, venditori, fornitori e piattaforma differiscono. Etichetta ogni pubblico e giurisdizione in modo che un agente non applichi le regole dei venditori a un acquirente o deduca l’inventario della piattaforma da un singolo annuncio.
4. Servizi B2B . Utile per chiarire capacità, settori, confini dei servizi, evidenze, materiale per appalti e canali di contatto. Non convertire un ambito negoziato o una promessa specifica per un cliente in un’affermazione universale rivolta alle macchine.
5. Agenzie . Utile quando l’azienda mantiene molte pagine di servizi, metodologie, case study e competenze. I portali clienti, le credenziali, i report privati e i playbook interni restano fuori dal file pubblico.
6. Aziende manifatturiere e industriali . Utile per indirizzare i sistemi a famiglie di prodotti, specifiche, certificazioni, manuali, distributori e documenti di sicurezza. L’indice non deve mai parafrasare istruzioni critiche per la sicurezza quando il documento controllato è l’autorità.

I piccoli siti brochure con cinque pagine stabili potrebbero trarre poco beneficio da un ulteriore artefatto da mantenere. I siti senza un chiaro proprietario dei contenuti dovrebbero prima risolvere canonicalizzazione, navigazione e qualità delle fonti prima di pubblicare un file che decadrà immediatamente.

Intento di ricerca

L’intento di ricerca è il risultato atteso da una query. Questo tipo ha due pubblici con intenti diversi. Una macchina recupera un percorso radice prevedibile e si aspetta Markdown conciso, intestazioni stabili, collegamenti canonici e nessun rumore decorativo. Un ricercatore umano di solito vuole indicazioni implementative: “esempio llms.txt”, “cosa inserire in llms.txt” o “formato manifesto per agenti”. La pagina esplicativa pubblica può rispondere a queste domande, mentre il file /llms.txt distribuito rimane ottimizzato per il recupero da parte delle macchine.

Il file in sé non è una pagina di atterraggio per parole chiave. Non aggiungere definizioni generiche, termini di categoria ripetuti o centinaia di collegamenti a blog per farlo “posizionare”. Ogni riga extra consuma attenzione e crea un ulteriore obbligo di manutenzione. Preferisci dieci collegamenti ponderati con descrizioni chiare piuttosto che un dump di diecimila URL.

Poiché convenzioni e supporto dei consumatori possono cambiare, indica su cosa si basa la tua implementazione ed evita di rivendicare un’adozione universale. Un recupero riuscito dimostra solo che il file è accessibile e analizzabile; non dimostra che un particolare prodotto IA lo utilizzi per posizionamento, recupero, addestramento o citazione.

Struttura della pagina

Le fasce di parole sono vincoli di editing, non obiettivi. Il file distribuito dovrebbe rimanere abbastanza conciso da poter essere verificato riga per riga. La nota implementativa per umani può essere più lunga, ma non deve essere copiata nel file per macchine.

Un file curato tipico è di circa 200–700 parole. La lunghezza non è un segnale di qualità: la dimensione giusta è l’indice più piccolo che stabilisce l’identità e indirizza un consumatore verso fonti mantenute senza nascondere distinzioni chiave.

Elementi obbligatori

L’indice deve essere noioso nel senso migliore: prevedibile, esplicito e facile da confrontare. Metti le interpretazioni critiche prima dei collegamenti opzionali in modo che una lettura parziale non produca una conclusione falsa.

Frontmatter

Segui la specifica del frontmatter . In questa specifica di tipo di post, usa entity = "post-type-llms-txt-page" e schemaType = "Article". Su una pagina implementativa per umani per un’organizzazione specifica, usa un’identità stabile come acme-ai-access-index, non una frase di campagna o una data.

Usa Article perché la pagina web spiega l’implementazione. Lo schema markup descrive il contenuto visibile; non trasforma il file di testo raw in un protocollo per agenti riconosciuto. Non contrassegnare la pagina come SoftwareApplication, Dataset o HowTo a meno che il suo contenuto visibile e il template non soddisfino i requisiti pertinenti in modo indipendente.

Il file raw /llms.txt normalmente non ha frontmatter perché il frontmatter non deve trapelare nell’output pubblicato. Archivia i suoi metadati operativi nel CMS, nella configurazione del generatore o nel record del repository: dominio canonico, ambito locale, proprietario, raccolta sorgente, modalità di generazione, ultima data di verifica, regola di revisione successiva, risultato del validatore e destinazione degli avvisi. Se esistono file localizzati, documenta la regola di selezione e mantieni una risposta canonica radice inequivocabile.

Esempio completo

Questo file fittizio dimostra un indice conciso per una piattaforma SaaS. I suoi URL, prodotto e capacità sono esempi; il modello è la specifica.

# Northstar Analytics

> Northstar Analytics è una piattaforma di reporting per team operativi. Questo indice punta alle pagine pubbliche che definiscono il prodotto, i piani, la documentazione, le policy e la capacità supportata per agenti.

I permessi di accesso sono controllati da robots.txt, autenticazione e dalle policy collegate di seguito. Questo file non concede accesso o permesso di riutilizzare i contenuti.

## Prodotto

- [Panoramica del prodotto](https://www.northstar.example/product): Ambito attuale del prodotto e flussi di lavoro di reporting supportati.
- [Piani e prezzi](https://www.northstar.example/pricing): Piani pubblici attuali, funzionalità incluse e termini di fatturazione.
- [Integrazioni](https://www.northstar.example/integrations): Fonti dati e sistemi di destinazione supportati.

## Documentazione

- [Home della documentazione](https://docs.northstar.example/): Documentazione attuale per utenti e amministratori.
- [Riferimento API](https://docs.northstar.example/api/): Endpoint pubblici, schemi, autenticazione, errori e limiti di frequenza.
- [Note di rilascio](https://docs.northstar.example/releases/): Modifiche datate al prodotto e al comportamento dell'API.

## Fiducia e supporto

- [Sicurezza](https://www.northstar.example/security): Programma di sicurezza e documenti di garanzia attuali.
- [Informativa sulla privacy](https://www.northstar.example/privacy): Elaborazione dati, conservazione e diritti degli utenti.
- [Supporto](https://www.northstar.example/support): Canali di contatto supportati e collegamento allo stato del servizio.

## Capacità per agenti

- [Azione di esportazione report](https://docs.northstar.example/agents/export-report): Contratto d'azione autenticato, input accettati, formato di output, limiti di frequenza e gestione degli errori. La disponibilità dipende dal piano e dal ruolo dell'utente.

## Opzionale

- [Biblioteca di ricerche](https://www.northstar.example/research): Report di benchmark originali con metodi e date di pubblicazione.

Verificato il 2026-08-27 dal team Documentazione Operativa. Generato dal registro canonico delle risorse pubbliche; convalidare dopo modifiche a prodotto, piani, policy, API o URL.

L’esempio dichiara una sola capacità perché esiste un contratto d’azione reale e documentato. Se il prodotto non ha alcuna azione per agenti supportata, ometti quella sezione. Non dedurre mai una capacità transazionale dalla presenza di un campo di ricerca, modulo o endpoint non documentato.

Per un manifesto per agenti archiviato separatamente da /llms.txt, mantieni la stessa disciplina. Specifica un formato versionato, identificatore canonico, endpoint di produzione, metodo di autenticazione, operazioni consentite, schema di input e output, limiti di frequenza, confini di consenso, stati di errore e URL delle policy. Validalo rispetto al sistema live. Una dichiarazione sintatticamente valida che pubblicizza un’azione disabilitata è comunque errata.

Galleria di design

Il file raw ha poco design visivo per scelta. Le varianti della galleria dovrebbero testare l’architettura dell’informazione, l’ordine di scansione, la leggibilità su mobile della pagina implementativa per umani e l’evidenza operativa — non la decorazione.

Checklist di qualità

Pubblica solo quando ogni affermazione applicabile è vera:

• Il file è raggiungibile all’URL radice previsto senza autenticazione, loop di reindirizzamento, muri di consenso o un’applicazione renderizzata.
• La risposta è testo semplice leggibile o Markdown, usa UTF-8 e non dipende da JavaScript per rivelare il suo contenuto.
• L’H1 fornisce il nome canonico dell’organizzazione o del sito, e la descrizione indica scopo, pubblico e ambito senza slogan.
• Ogni URL collegato è canonico, pubblico, indicizzabile per policy, raggiungibile e di proprietà dell’organizzazione o chiaramente etichettato come esterno.
• Le descrizioni dei collegamenti dicono quale autorità possiede la destinazione; non ripetono testo di ancoraggio generico come “scopri di più”.
• Le fonti principali di prodotto, prezzi, documentazione, policy e supporto sono in accordo con l’indice.
• Pagine archivio, risultati di ricerca, parametri di tracciamento, lingue duplicate, pagine campagna e pagine tag di scarso valore sono escluse.
• Le dichiarazioni di capacità corrispondono a un contratto live, supportato e autenticato, e includono i vincoli pertinenti.
• Nessun segreto, token, endpoint privato, dato personale, documento del cliente, elemento di roadmap non pubblicato o dettaglio implementativo sensibile alla sicurezza appare.
• Il linguaggio su accesso, permessi, licenze e policy punta a fonti di controllo e non è contraddetto dall’indice.
• Il file non rivendica posizionamento garantito, citazione, esclusione dall’addestramento o supporto universale da parte dei consumatori.
• L’ambito locale e regionale sono espliciti ovunque prezzi, policy, disponibilità o documentazione differiscano.
• Il proprietario, il registro delle fonti, il processo di generazione e il metodo di convalida sono registrati all’esterno o alla fine del file.
• I controlli per link rotti, reindirizzamenti imprevisti, stato della risposta, hash del contenuto e sezioni obbligatorie vengono eseguiti dopo le distribuzioni pertinenti.
• La data di verifica cambia solo dopo che destinazioni, descrizioni, capacità e policy sono state controllate sostanzialmente.

Errori comuni

Trattare il file come una sitemap. Un inventario completo di URL distrugge la priorizzazione ed è difficile da revisionare. Mantieni le sitemap XML per la scoperta; cura llms.txt intorno a fonti autorevoli e gruppi significativi.

Trattarlo come controllo accessi. Una richiesta in Markdown non è un livello di enforcement. Esprimi le regole di crawling in robots.txt, proteggi le risorse private con autenticazione e posiziona i requisiti vincolanti nelle policy pertinenti e nei controlli di sistema.

Copiare il contenuto di destinazione nell’indice. Prezzi, specifiche di prodotto e policy riportati divergono. Riassumi solo quanto basta per identificare l’autorità, poi collega alla fonte mantenuta.

Pubblicare capacità speculative. Un modulo o endpoint API non documentato non rende un sito pronto per agenti. Dichiara solo azioni supportate in produzione con autenticazione, schemi, vincoli, errori e un proprietario.

Includere tutto “per sicurezza”. Più collegamenti creano più ambiguità e più punti di errore. I contenuti opzionali dovrebbero guadagnarsi l’inclusione rispondendo a un probabile bisogno di recupero che le sezioni primarie non coprono.

Esporre materiale privato. I file pubblici leggibili da macchina sono pubblici. Non elencare mai host di staging, API interne, credenziali, export di clienti, documenti non pubblicati o dettagli di sicurezza che non siano stati intenzionalmente approvati per la pubblicazione.

Generare senza governance. L’automazione può riprodurre dati sorgente errati rapidamente. Un generatore necessita di un registro delle fonti approvato, regole di esclusione, ordinamento deterministico, convalida, proprietà della revisione e avvisi di distribuzione.

Modificare a mano un file generato. La generazione successiva sovrascrive la correzione. Correggi il record sorgente o il generatore, rigenera e registra la modifica sostanziale.

Rivendicare risultati non supportati. “Questo garantisce citazioni dall’IA” trasforma una convenzione implementativa incerta in una promessa fuorviante. Riporta l’accessibilità e le evidenze di recupero separatamente dai risultati di visibilità e citazione.

Aggiornare la data senza verificare la realtà. Un nuovo timestamp non può riparare un URL di documentazione morto, un piano rinominato o un’azione disabilitata. Verifica significa confrontare ogni dichiarazione importante con la sua fonte di produzione.

Collegamenti interni

Collega la pagina implementativa per umani verso l’alto a Tipi di post SEO quando un autore deve distinguere l’indice per macchine da una directory, pagina di documentazione o policy. Collega da ogni dichiarazione operativa alla sua fonte di controllo: ambito del prodotto alla pagina prodotto, prezzi correnti alla pagina prezzi, comportamento alla documentazione, permessi ai controlli di accesso e obblighi alla policy.

Il file raw dovrebbe usare URL canonici assoluti perché potrebbe essere recuperato al di fuori della normale navigazione del sito. Preferisci una destinazione autorevole per fatto. Se due pagine si sovrappongono, risolvi la proprietà prima di elencarle entrambe; l’indice dovrebbe esporre la gerarchia delle fonti, non cristallizzare un disaccordo interno.

Usa nomi di sezione brevi e stabili come Prodotto, Documentazione, Policy e Capacità per agenti. Mantieni le varianti linguistiche in gruppi chiaramente etichettati solo quando differiscono sostanzialmente. Non collegare ogni post del blog; seleziona ricerche o guide durevoli solo quando aiutano un sistema a comprendere l’argomento e le evidenze del sito.

Anche i collegamenti in entrata contano operativamente. La documentazione, i portali per sviluppatori e le guide di accessibilità IA dovrebbero indirizzare i manutentori al record implementativo, mentre il record punta al file live e al validatore. Questo crea un percorso di revisione per umani senza ingombrare l’indice per macchine.

Come misurare i risultati

Misura il file come infrastruttura prima, e come input per la visibilità dopo. Un aumento delle citazioni non può essere attribuito a llms.txt solo perché entrambi sono avvenuti dopo la pubblicazione.

Monitora quattro livelli:

• Disponibilità: stato della risposta all’URL radice, comportamento di reindirizzamento, tipo di contenuto, codifica, latenza, indipendenza dal rendering e uptime.
• Integrità: successo dell’analisi, sezioni obbligatorie, URL duplicati, link rotti, destinazioni di reindirizzamento, discrepanze canoniche, domini non autorizzati, segreti esposti e modifiche all’hash del contenuto.
• Freschezza: giorni dalla verifica sostanziale, modifiche alle destinazioni dalla verifica, copertura del registro delle fonti, conferma del proprietario e tempo per riparare il decadimento.
• Risultati: recuperi dai log del server da parte di agenti identificabili dove legalmente e tecnicamente appropriato, visite alle destinazioni indicizzate, citazioni IA delle pagine canoniche preferite e accuratezza delle risposte per domande tracciate su marchio o prodotto.

Stabilisci una baseline prima della distribuzione: quali URL sono citati, quali fatti sono dichiarati in modo errato, se il file radice esiste e quali crawler lo richiedono. Annota la pubblicazione e ogni aggiornamento sostanziale. Confronta finestre di osservazione sufficientemente lunghe da evitare di interpretare un singolo recupero o citazione come un trend, e mantieni la distinzione tra correlazione e causalità.

Testa direttamente le modalità di fallimento. Rinomina una copia di staging di un URL elencato e conferma che il validatore rilevi la rottura. Cambia una mappatura canonica e conferma che il generatore aggiorni l’indice. Disabilita una capacità in un ambiente di test controllato e conferma che il controllo del manifesto fallisca. Questi test provano il sistema di manutenzione, non l’adozione esterna.

Usa come misuriamo i risultati per separare disponibilità tecnica, rappresentazione macchina, scoperta, citazione, coinvolgimento e risultati di business. In AmICited, rivedi il file live sotto Agent Accessibility e usa il report Cockpit per osservare URL citati e visibilità IA insieme alle annotazioni di distribuzione. L’affermazione di successo credibile è “il file è valido, aggiornato e indirizza i sistemi alle fonti previste”; qualsiasi cambiamento di visibilità a valle richiede evidenze separate.

FAQ

Domande frequenti