Due persone ci hanno fatto la stessa domanda durante il nostro evento live “Tutta la verità sul traffico bot”, e non siamo riusciti a rispondere a nessuna delle due in diretta: un file llms.txt impedisce davvero all’AI di bombardare il tuo sito?

Ci abbiamo riflettuto a lungo perché la risposta onesta non è un semplice sì o no. Il fatto è che llms.txt non è mai stato creato per svolgere nessuna delle due funzioni che la gente sperava potesse svolgere, e gran parte di ciò che è stato pubblicato quest’anno al riguardo ha silenziosamente indotto le persone a credere il contrario.

Questa confusione non è un caso isolato. Tra le domande che abbiamo ricevuto, si continuava a parlare di robots.txt, llms.txt, crawler AI e protezione dai bot come se fossero quattro impostazioni sullo stesso selettore, dove ruotarne una qualsiasi ti porta allo stesso risultato. Non è così. Si trovano in punti completamente diversi del percorso di richiesta, vengono applicati da meccanismi completamente diversi (o, in un caso, non vengono applicati affatto), e confonderli è esattamente il motivo per cui un proprietario di sito finisce per fare tutto “nel modo giusto” eppure viene comunque penalizzato.

E non è solo teoria. Nel nostro report sul traffico AI e bot, abbiamo scoperto che il traffico dei bot AI sui siti ospitati da Kinsta è passato da 1 visita su 200 un anno fa a 1 su 31 oggi. Un cartello sulla porta non serve a molto quando così tante persone provano a girare la maniglia.

TL;DR

  • Il file robots.txt è una richiesta, non un lucchetto. I crawler AI affidabili di OpenAI, Anthropic, Google e Perplexity in genere lo leggono e lo seguono. Altri, tra cui storicamente Bytespider di ByteDance, non lo fanno.
  • Il file llms.txt non controlla l’accesso. È un indice dei contenuti per gli strumenti di AI che scelgono di leggerlo, non un file di autorizzazioni. L’adozione si aggira intorno al 9–10% dei siti e, comunque, i principali crawler AI in gran parte non lo recuperano.
  • La protezione dai bot è l’unico strumento che impone davvero qualcosa. robots.txt e llms.txt funzionano chiedendo gentilmente. Protezione bot di Kinsta e AI Crawl Control di Cloudflare sono quelli che bloccano, contestano o limitano la frequenza di un crawler che ignora le tue preferenze.

Quattro livelli, quattro compiti, un unico punto di confusione

Livello Cosa fa effettivamente Può fermare un malintenzionato?
robots.txt Indica le tue preferenze a qualsiasi crawler che si prenda la briga di leggerlo No
llms.txt Fornisce agli strumenti di AI un indice pulito dei tuoi contenuti No
Crawler AI Sono i bot che effettuano le richieste N/A (questi sono quelli che gestisci, non un controllo)
Protezione dai bot (Kinsta / Cloudflare) Rileva, classifica e interviene sulle richieste a livello di infrastruttura Sì

Una volta che lo vedi presentato in questo modo, la maggior parte delle domande poste dai partecipanti trova risposta da sola. Quindi andiamo avanti passo dopo passo, partendo da quello che tutti hanno già più o meno capito.

robots.txt

Il file robots.txt, formalizzato come RFC 9309, indica ai crawler quali parti del tuo sito preferiresti che saltassero. Non ha alcun potere di imposizione tecnica, quindi funziona semplicemente perché i crawler che lo leggono hanno deciso, per politica aziendale, di rispettarlo.

La cosa rassicurante è che i crawler che ti interessano di più, come OpenAI, Anthropic, Google e Perplexity, pubblicano tutti user-agent documentati e rispettano le direttive standard.

Ciò che spesso confonde le persone è pensare che ogni azienda utilizzi un unico “bot AI”. Non è così. La maggior parte di loro ora separa l’addestramento dalla ricerca, e questa separazione è la leva più utile di tutto questo articolo:

  • GPTBot (OpenAI) – addestra i modelli di base. Se lo blocchi, i tuoi contenuti smettono di alimentare i futuri cicli di addestramento.
  • OAI-SearchBot (OpenAI) – indicizza le pagine per la citazione nella ricerca di ChatGPT. Se lo blocchi, perdi quelle citazioni, ma l’addestramento non ne risente.
  • ClaudeBot (Anthropic) – addestramento.
  • Claude-SearchBot (Anthropic) – indicizzazione per la ricerca su Claude.
  • Google-Extended – regola l’uso nell’addestramento dell’AI e nelle panoramiche sull’AI in particolare. Bloccarlo non influisce sull’indicizzazione regolare di Googlebot né sui tuoi normali posizionamenti nei risultati di ricerca.
  • PerplexityBot: il crawler del motore di risposta di Perplexity.

Quindi la vera decisione non è mai stata “consentire l’accesso all’AI o bloccarla fuori”. Si tratta piuttosto di decidere se vuoi che i tuoi contenuti vengano utilizzati per addestrare un modello, vengano citati in una risposta dell’AI, entrambe le cose o nessuna delle due. Il file robots.txt ti permette già di rispondere a questa domanda con precisione. La maggior parte dei proprietari di siti semplicemente non se l’è mai posta in questi termini.

Ecco come si traduce questa precisione in un file robots.txt. Supponiamo che tu voglia escluderti completamente dall’addestramento, ma desideri comunque apparire quando qualcuno pone a ChatGPT o Claude una domanda a cui i tuoi contenuti potrebbero rispondere:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

Se invece preferisci escludere una sezione specifica da tutto, sia dall’addestramento che dalla ricerca, limita il disallow a un percorso specifico invece che all’intero sito:

User-agent: GPTBot
Disallow: /premium-reports/

User-agent: ClaudeBot
Disallow: /premium-reports/

Il problema è che il rispetto di queste regole è una cortesia, non un obbligo. È noto che alcuni crawler ignorino completamente le regole “disallow”. E c’è anche una novità: quando qualcuno chiede a ChatGPT o a un assistente simile di leggere una pagina specifica per suo conto in quel preciso momento, quel singolo recupero non si comporta sempre come una scansione, e la logica del file robots.txt non si applica in modo chiaro a questa situazione.

llms.txt

Molti contenuti del 2026 hanno descritto llms.txt come uno strumento di controllo degli accessi o un trucco SEO. La risposta onesta è più semplice e meno utile di quanto la maggior parte degli articoli abbia suggerito.

llms.txt è un semplice file Markdown nella tua directory principale che funziona come un indice per gli strumenti di AI, indirizzandoli verso le tue pagine più importanti in modo che un modello non debba analizzare un’intera pagina renderizzata per capire di cosa ti occupi. Questa è l’intera specifica. Non dice nulla su ciò che un crawler può o non può fare.

Ecco più o meno come si presenta:

# Acme Analytics

> Acme Analytics is a WordPress plugin for tracking site performance and uptime.

## Docs
- [Getting Started](https://example.com/docs/getting-started): Install and configure the plugin
- [API Reference](https://example.com/docs/api): Full REST API documentation

## Pricing
- [Plans](https://example.com/pricing): Current plans and feature comparison

Nota che non c’è nessun Allow, nessun Disallow, nessun targeting per user-agent, niente che indichi a un crawler cosa può o non può fare.

Ecco cosa dicono i dati attuali:

  • L’adozione è scarsa. Circa il 9–10% dei siti ne ha uno, anche tra i domini più grandi del web, nonostante sia ormai passato ben più di un anno da quando ci si raccomanda a vicenda di aggiungerlo.
  • I bot che contano di più, per lo più, non lo leggono. L’analisi del traffico su centinaia di milioni di richieste AI mostra che GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot e Google-Extended ignorano in modo schiacciante il file e passano direttamente alla scansione dell’HTML.
  • Google ha detto di no, ufficialmente. Gli stessi esperti di ricerca di Google hanno affermato senza mezzi termini che llms.txt non viene usato come segnale di ranking o di scansione, e l’hanno paragonato, in modo sfavorevole, al meta tag delle parole chiave, ormai fuori uso da tempo.
  • Nessun grande laboratorio di AI si è impegnato a trattarlo come un segnale di accesso, né per l’addestramento né per la ricerca.

Dove invece si rivela davvero utile è come mappa per gli agenti di codifica e gli strumenti di sviluppo, come Claude Code o Cursor, che traggono vantaggio da un indice pulito e strutturato di un sito di documentazione.

Quindi, llms.txt non impedirà che il tuo sito venga sottoposto a scraping ripetutamente. È un aiuto alla scoperta, non un limitatore di frequenza e non un filtro.

Crawler AI

Il termine “crawler AI” viene usato come termine generico per indicare almeno tre comportamenti distinti, e confonderli è proprio il punto da cui partono molte decisioni sbagliate:

  1. Crawler di addestramento che raccolgono periodicamente contenuti per il set di addestramento di un modello: GPTBot, ClaudeBot, Google-Extended, Bytespider, CCBot.
  2. Crawler di ricerca e risposta che creano l’indice da cui un motore di risposta AI attinge effettivamente: OAI-SearchBot, Claude-SearchBot, PerplexityBot.
  3. Richieste in tempo reale da parte di un agente, in cui una persona chiede a un assistente di andare a leggere una pagina specifica proprio in quel momento, e lui lo fa, all’istante.

I primi due si comportano come i classici crawler e in genere si identificano con un user-agent documentato, che è proprio ciò che rende possibile, in primo luogo, il controllo basato su robots.txt. Il terzo assomiglia molto di più a una persona che clicca su un link che a una scansione, ed è in parte per questo che alcuni strumenti di navigazione basati sull’AI ora compaiono nei log del server indistinguibili dai visitatori normali, ed è anche il motivo per cui un blocco dei bot troppo rigido a volte finisce per intercettare attività legittime, dirette da esseri umani, nella stessa rete.

Questo è anche il senso di quanto ha sottolineato Daniel Pataki durante il webinar: la maggior parte del traffico dei crawler AI oggi non è dannoso, è semplicemente inarrestabile. Segue ogni link che trova, comprese tutte le varianti ridondanti di URL che una pagina dinamica di WordPress o WooCommerce può generare, e finisce per entrare in un loop che sembra un attacco ma in realtà è solo un bot che non sa di aver già visto quella pagina novemila volte.

Approfondiamo il motivo per cui questo danneggia in modo specifico l’infrastruttura di WooCommerce e perché i siti WooCommerce sono particolarmente vulnerabili al traffico dei bot.

Il livello che fa davvero la differenza: la protezione dai bot

Una volta accettato che il file robots.txt è facoltativo e che llms.txt non è affatto un controllo, rimane solo un livello in grado di intervenire su un crawler che si rifiuta di collaborare: la protezione dai bot, che si tratti di Protezione bot Kinsta, degli strumenti di Cloudflare o di qualcos’altro ancora.

Da parte di Cloudflare le cose si sono evolute rapidamente, ma noi di Kinsta adottiamo un approccio più mirato, specifico per WordPress per affrontare lo stesso problema: un pulsante dedicato Blocca crawler AI che blocca i crawler basati sull’intelligenza artificiale, compresi quelli verificati, senza intaccare Googlebot o Bing, oltre a una classificazione dei crawler AI con frequenza eccessiva che individua un bot tecnicamente verificato ma che sta martellando un sito molto più di quanto farebbe mai una normale scansione.

Kinsta bot protection tool
Lo strumento Protezione bot di Kinsta

Laszlo Farkas, il nostro Direttore Tecnico, ha spiegato così il compromesso di fondo quando gli abbiamo chiesto di confrontare uno strumento gestito con la creazione di regole personalizzate da zero:

Se hai le competenze e il tempo per mettere a punto tutto da solo, probabilmente è la scelta migliore per te. Se invece non li hai, penso sia meglio usare quello di Kinsta, perché è gestito, ottimizzato per WordPress e mantenuto per te.

Per un confronto più completo su dove si collocano rispettivamente lo strumento di Kinsta e quello di Cloudflare, dai un’occhiata alla nostra guida su Protezione bot di Kinsta vs. Cloudflare.

Le domande che ci sono state poste, con le risposte dirette

“Vogliamo accogliere i crawler LLM ma evitare gli abusi. C’è un modo affidabile per farlo?” Sì, si tratta della distinzione tra “addestramento” e “ricerca”, applicata in modo mirato. Consenti l’accesso ai crawler di ricerca e risposta se che il sito sia reperibile e citato. Usa il file robots.txt per escludere specificatamente i crawler di addestramento, se è quella la parte che ti crea problemi. Poi lascia che la protezione dai bot intercetti gli abusi basati sul volume provenienti da qualsiasi fonte, verificata o meno, che esegua il crawling in modo più intenso del dovuto.

“Non vogliamo bloccare il traffico perché vogliamo che l’AI metta in evidenza la nostra azienda. Cosa facciamo in pratica?” Stessa risposta, diversa formulazione. Essere reperibili nelle risposte dell’AI e controllare il carico sulle risorse non sono in contrasto, perché ci sono bot diversi che si occupano di ciascun compito. Verifica o blocca i crawler di addestramento e quelli ad alto volume se è questa la tua preoccupazione, e lascia esplicitamente liberi i crawler di ricerca e risposta.

“I paywall dei contenuti impediscono ai bot AI di estrarre quei contenuti?” In parte, e solo contro i crawler che si comportano come tali. Un paywall blocca un bot che rispetta la normale struttura della pagina e non ha credenziali valide, proprio come blocca qualsiasi utente umano anonimo. Non ha alcun effetto sugli strumenti di AI che navigano più come un vero utente non connesso, o che raggiungono gli stessi contenuti tramite una copia nella cache, un feed RSS o qualche altra “porta secondaria” che non entra affatto in contatto con la logica del paywall. È utile, aggiuntivo, ma non sostituisce la protezione dai bot.

“Possiamo impedire ai crawler basati sull’AI di scorrere all’infinito i filtri del nostro negozio WooCommerce?” Questo è un problema di cache e struttura degli URL mascherato da protezione contro i bot. I crawler seguono ogni link che incontrano, e i parametri dinamici di filtro e ordinamento generano un numero quasi infinito di URL distinti per quella che, per un essere umano, è la stessa pagina. Bloccare quei modelli di parametri nel file robots.txt è una prima mossa sensata:

User-agent: *
Disallow: /*?*filter_
Disallow: /*?*orderby=

Se un crawler lo ignora comunque, come alcuni fanno, sono le regole basate sulla frequenza nella protezione dai bot a interrompere davvero il ciclo.

A che punto sei

Smetti di pensare a queste quattro opzioni come alternative in competizione tra loro e inizia a considerarle come uno stack, da applicare in ordine:

  1. il file robots.txt dichiara le tue intenzioni, separando i crawler di addestramento da quelli di ricerca e risposta in base a ciò che vuoi effettivamente da ciascuno.
  2. Il file llms.txt, se ti prendi la briga di crearlo, è un gesto di cortesia verso gli strumenti che lo leggono, non una leva per ridurre o controllare il volume di scansione.
  3. I crawler AI comprendono i bot di addestramento, i bot di ricerca e i recuperi degli agenti in tempo reale, e ciascuno di essi potrebbe meritare una risposta diversa.
  4. La protezione dai bot è dove si concentra effettivamente l’applicazione delle regole, perché è l’unico livello qui in grado di intervenire su una richiesta che ignora tutto ciò che hai chiesto.

Se la domanda che ti stai ponendo non è tanto “come faccio a controllare tutto questo”, quanto piuttosto “come faccio a farmi trovare da questo sistema”, le nostre guide su AEO per WordPress e GEO vs. AEO vs. SEO riprendono da dove ci siamo fermati. Per approfondire i controlli trattati qui, dai un’occhiata allo strumento Protezione bot di Kinsta.

Joel Olawanle Kinsta

Joel è uno Frontend developer che lavora in Kinsta come redattore tecnico. È un insegnante appassionato che ama l'open source e ha scritto oltre 200 articoli tecnici principalmente su JavaScript e i suoi framework.