Come scrivere un robots.txt che blocchi davvero gli scraper AI

La scomoda verità su robots.txt

Un file robots.txt non è una serratura. È un cartello sulla porta.

Questa distinzione conta quando i team chiedono se possono “bloccare gli scraper AI” con un piccolo file di testo. Per i crawler affidabili che seguono il Robots Exclusion Protocol, sì: un robots.txt scritto correttamente può dire loro di non eseguire la scansione delle tue pagine. Per scraper sconosciuti, imitatori, automazioni del browser e bot a cui semplicemente non importa, da solo non farà nulla.

Quindi l’obiettivo pratico non è “rendere impossibile lo scraping”. È:

• Dire ai crawler AI conformi di non usare il tuo sito.
• Evitare di bloccare accidentalmente motori di ricerca o servizi utili.
• Aggiungere controlli lato server più forti contro gli abusi.
• Mantenere la policy gestibile man mano che cambiano i nomi dei crawler.

Questa è la versione noiosa. È anche la versione che funziona.

Cosa può e non può fare robots.txt

Un file robots.txt si trova alla radice di un sito:

https://example.com/robots.txt

I crawler lo richiedono prima di eseguire la scansione. Il file contiene gruppi di regole. Ogni gruppo inizia con una o più righe User-agent, seguite da direttive Allow o Disallow.

Un semplice blocco dell’intero sito appare così:

User-agent: GPTBot
Disallow: /

Significa: se sei GPTBot, non eseguire la scansione di nulla su questo sito.

Ma robots.txt ha limiti rigidi:

1. È volontario. Gli attori malevoli possono ignorarlo.
2. Non impedisce che un URL venga richiesto da un normale browser o script.
3. Non rimuove contenuti già raccolti altrove.
4. Non definisce da solo copyright, licenze o diritti di addestramento.
5. Può essere configurato male in modi che bloccano i bot sbagliati.

Se ti serve un vero controllo degli accessi, usa autenticazione, autorizzazione, rate limiting, controlli basati su IP, bot management o strumenti legali. Robots.txt è comunque utile, ma appartiene a una strategia più ampia di protezione dei contenuti.

È simile ad altri problemi di governance del web: il controllo visibile raramente è l’intero controllo. Se la tua organizzazione ha già un uso non gestito dell’AI al proprio interno, vale lo stesso principio; un rapido audit della shadow AI è spesso più utile che fingere che un singolo documento di policy risolva il problema.

Parti dalla decisione di policy

Prima di modificare il file, decidi che cosa stai effettivamente cercando di bloccare.

Ci sono almeno quattro cose diverse che le persone intendono con “scraper AI”:

• Crawler usati per raccogliere dati di addestramento.
• Crawler per ricerca AI o answer engine.
• Fetcher attivati dall’utente, per esempio quando qualcuno chiede a un prodotto AI di riassumere un URL.
• Scraper generici che fingono di essere normali browser.

Potresti volerli bloccare tutti. Oppure potresti volere la scoperta tramite ricerca, ma escluderti dall’addestramento dei modelli. Non sono la stessa policy.

Per esempio, OpenAI documenta user agent separati per scopi diversi, inclusi GPTBot, ChatGPT-User e OAI-SearchBot. Google usa Google-Extended come token di controllo per alcuni casi d’uso di Gemini e Vertex AI, mentre la normale scansione di Google Search è gestita da altri user agent di Googlebot.

Questa separazione è importante. Se blocchi user agent ampi senza attenzione, puoi danneggiare la normale visibilità nella ricerca mentre cerchi di bloccare l’addestramento AI.

Un modello ragionevole di robots.txt per bloccare l’AI

Ecco un punto di partenza prudente per bloccare diversi crawler comunemente documentati e legati all’AI, lasciando indisturbati i crawler di ricerca generali:

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

Non è una lista universale e magica. È un pattern mantenibile.

Qualche nota:

• Disallow: / significa “non eseguire la scansione di alcun percorso”.
• User-agent: * si applica ai crawler che non corrispondono a un gruppo più specifico.
• Allow: / non è strettamente necessario per il gruppo predefinito, ma rende chiara la tua intenzione.
• Mantieni brevi i commenti. Alcuni parser sono tolleranti, ma robots.txt dovrebbe restare noioso.
• Non includere URL privati in robots.txt. Il file è pubblico, e indicare percorsi sensibili può pubblicizzarli.

L’ultimo punto vale la pena ripeterlo. Robots.txt non è un meccanismo di segretezza. Se /client-contracts/ non deve essere pubblico, proteggilo con autenticazione. Non limitarti a disallow.

Fai attenzione a Google-Extended

Google-Extended è spesso frainteso. Non equivale a bloccare Google Search.

Secondo la documentazione di Google, Google-Extended è un token di prodotto autonomo che gli editori possono usare per gestire se i contenuti del sito possano contribuire a migliorare alcune funzionalità di Gemini e Vertex AI. Bloccarlo non dovrebbe, di per sé, impedire a Googlebot di eseguire la scansione per Search.

Detto questo, non sostituire tutte le direttive Google con un blocco ampio come questo, a meno che tu non lo voglia davvero:

User-agent: Googlebot
Disallow: /

Direbbe al crawler principale di Google Search di non eseguire la scansione del tuo sito. Per la maggior parte dei siti web pubblici, non è ciò che desideri.

La stessa distinzione vale altrove. Alcuni fornitori separano i crawler di addestramento dalla navigazione attivata dall’utente o dai crawler di ricerca AI. Altri no. Devi leggere la documentazione dei bot che ti interessano e trattare il tuo robots.txt come un file vivo, non come una casella da spuntare una volta sola.

Testa il file come codice di produzione

Robots.txt sembra semplice, ed è per questo che è facile romperlo.

Gli errori comuni includono:

• Caricarlo nel posto sbagliato, per esempio /assets/robots.txt invece di /robots.txt.
• Usare virgolette tipografiche copiate da un editor di documenti.
• Bloccare tutti i crawler con User-agent: * e Disallow: / per errore.
• Dare per scontato che il file di un dominio si applichi a un altro sottodominio.
• Dimenticare che host http://, https://, www e non-www possono essere gestiti in modo diverso a seconda della configurazione.

Per i siti multi-dominio, controlla ogni host canonico. Un file robots su https://www.example.com/robots.txt non governa automaticamente https://app.example.com/robots.txt.

Durante il debug, ispeziona la risposta HTTP effettiva, non solo ciò che mostra l’anteprima del tuo CMS. Vuoi una risposta 200 OK, un content type text/plain se possibile, e il file esatto che ti aspetti. Se sono coinvolti redirect, caching o regole CDN, l’ispezione grezza degli header aiuta. Il workflow in debug di redirect e header HTTP in produzione si applica direttamente anche qui.

Aggiungi controlli lato server per i bot che ignorano le regole

Se il crawler è conforme, robots.txt è il segnale più pulito. Se il crawler è abusivo, ti serve enforcement.

I controlli pratici includono:

Rate limiting

Imposta soglie per pattern di richieste insoliti: troppe pagine al minuto, attraversamento profondo della paginazione, 404 ripetuti o alto volume di richieste da un piccolo insieme di IP. I limiti di frequenza dovrebbero essere abbastanza generosi da non penalizzare gli utenti reali e abbastanza rigidi da rendere costosa l’estrazione di massa.

Filtro per user agent

Puoi bloccare user agent documentati di crawler AI a livello di web server, reverse proxy, CDN o applicazione. È più forte di robots.txt perché restituisce una vera risposta di negazione.

Per esempio, Nginx può bloccare un pattern di user agent, anche se le regole di produzione andrebbero testate con attenzione:

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

Non è infallibile. Le stringhe user-agent sono facili da falsificare. Ma ferma il traffico onesto o pigro e riduce il carico.

Controlli su IP e ASN

Alcuni operatori pubblicano intervalli IP, ma molti ecosistemi di scraper no. Il blocco basato su IP può funzionare per abusi evidenti, soprattutto da intervalli di hosting cloud senza traffico utente normale, ma può anche creare falsi positivi. Usa i log prima delle regole.

Autenticazione e paywall

Se il contenuto non deve essere copiato su larga scala, non mettere il contenuto completo su un URL pubblico. Robots.txt non è adatto a materiale riservato, database con licenza, community private o archivi a pagamento.

Minimizzazione dei contenuti

A volte la migliore protezione è architetturale. Non esporre API non necessarie, payload JSON grandi, metadati nascosti, endpoint di bozza o archivi completi se la pagina pubblica richiede solo un piccolo sottoinsieme. Anche i siti molto basati su immagini dovrebbero riflettere sui metadati che pubblicano; la logica di privacy in rimuovere i metadati EXIF prima di condividere foto online si applica anche alle operazioni sui contenuti.

Usa i meta tag robots per regole a livello di pagina

Robots.txt controlla la scansione. I meta tag robots e gli header X-Robots-Tag controllano l’indicizzazione e il comportamento degli snippet per motori di ricerca e crawler conformi.

Per esempio:

<meta name="robots" content="noindex, noarchive">

Oppure come header HTTP:

X-Robots-Tag: noindex, noarchive

Non sono scudi specifici contro l’AI. Sono utili quando vuoi che una pagina sia accessibile ma non indicizzata. Tuttavia, se blocchi un crawler dal recuperare una pagina in robots.txt, potrebbe non vedere mai il meta tag a livello di pagina. Non fare affidamento su un tag noindex su un URL che al crawler è vietato scansionare.

La regola approssimativa:

• Usa robots.txt per ridurre o prevenire la scansione.
• Usa meta robots o X-Robots-Tag per controllare il comportamento di indicizzazione.
• Usa controlli lato server per far rispettare l’accesso.

Monitora i log dopo la pubblicazione

Pubblicare il file è solo il primo passo. Dopo, controlla i log.

Cerca:

• Richieste a /robots.txt dagli user agent che hai nominato.
• Scansione continuata dopo che sono state servite regole di disallow.
• User agent sospetti con alto volume.
• User agent simili a browser che richiedono migliaia di pagine in sequenza.
• Accessi ripetuti a feed, sitemap, pagine di ricerca e paginazione.

Se un bot richiede robots.txt, vede un disallow completo e poi si ferma, robots.txt ha fatto il suo lavoro. Se continua, sposta quel bot nell’enforcement: rate limit, blocchi o autenticazione.

Rivedi anche l’esposizione della sitemap. Le sitemap sono utili per i motori di ricerca, ma sono anche mappe comode per gli scraper. Questo non significa che dovresti rimuoverle dai siti ordinari. Significa che non dovresti includere URL che non vuoi far scoprire ai sistemi pubblici.

Mantieni il file piccolo e revisionato

Robots.txt tende a degradarsi. Un team marketing aggiunge un microsito di campagna. Uno sviluppatore aggiunge un percorso di staging. Un fornitore cambia il nome del proprio crawler. Due anni dopo nessuno sa perché esista metà delle regole.

Trattalo come configurazione:

• Archivialo nel controllo versione quando possibile.
• Aggiungi un breve commento per ogni gruppo di crawler AI.
• Rivedilo trimestralmente.
• Controlla la documentazione del fornitore prima di aggiungere regole ampie.
• Testa dopo cambiamenti a CDN, CMS o hosting.

Se il tuo sito pubblica contenuti assistiti dall’AI, separa anche la policy sui crawler dalla trasparenza editoriale. Bloccare gli scraper AI riguarda l’accesso e il riutilizzo. La disclosure riguarda la fiducia del lettore. Si sovrappongono sul piano etico, ma non sono lo stesso controllo. Un approccio pratico alla disclosure è trattato in come appare una disclosure AI onesta su un piccolo sito web.

<!-- tool-cta:start -->

💡 Prova questo: Dopo aver aggiunto regole per i crawler IA, verifica la sintassi con Robots.txt Tester così da non bloccare accidentalmente anche bot legittimi.

<!-- tool-cta:end -->

In sintesi

Un buon file robots.txt bloccherà i crawler AI conformi. Non fermerà lo scraping determinato, le stringhe user-agent copiate, i browser compromessi o le persone che incollano manualmente i tuoi contenuti nei sistemi AI.

Questo non lo rende inutile. Lo rende uno strato.

Scrivi regole esplicite per i crawler AI documentati. Evita blocchi ampi che danneggiano la visibilità nella ricerca. Testa il file servito, non la bozza. Osserva i log. Fai enforcement con controlli lato server quando il comportamento passa da indesiderato ad abusivo.

Il web ha sempre funzionato su un mix di protocollo, norme ed enforcement. Robots.txt è lo strato delle norme. Usalo, ma non confonderlo con un muro.