Bloccare i crawler AI del sito web: quando farlo davvero e come non perdere visibilita

Introduzione

Negli ultimi mesi sempre piu aziende si stanno facendo la stessa domanda: "posso impedire a ChatGPT, Claude o ad altri sistemi AI di leggere il mio sito?".

La domanda e comprensibile, ma spesso porta a una risposta troppo semplice: bloccare tutto.

Il problema e che non tutti i crawler AI fanno la stessa cosa. Alcuni servono per training, altri per indicizzare contenuti nei risultati di ricerca AI, altri ancora recuperano una pagina su richiesta diretta dell'utente.

Tra fine aprile e maggio 2026, la documentazione ufficiale di OpenAI, Anthropic, Google e Cloudflare ha reso questo punto molto piu chiaro. OpenAI distingue tra GPTBot e OAI-SearchBot. Anthropic separa ClaudeBot, Claude-User e Claude-SearchBot. Google continua a ricordare che noindex, nosnippet e affini funzionano solo se la pagina resta leggibile al crawler. Cloudflare, intanto, ha trasformato il tema in un problema operativo concreto con strumenti dedicati per monitorare accessi, violazioni di robots.txt e blocchi piu forti.

Per un sito web, quindi, la domanda giusta non e "blocchiamo l'AI?" ma "quale uso vogliamo consentire, a quali pagine e con quale impatto su visibilita, contenuti sensibili e manutenzione?".

Perche il problema non e tecnico soltanto

Gestire i crawler AI non significa solo scrivere due righe in robots.txt.

Significa prendere decisioni che toccano almeno quattro aree:

• visibilita dei contenuti nei motori e negli assistenti AI
• protezione di materiali sensibili, preview e aree non pronte
• coerenza tra contenuto pubblico e contenuto che gli assistenti possono leggere
• manutenzione futura del sito e dei suoi ambienti

Molte aziende oggi hanno online non solo pagine pubbliche pulite, ma anche:

• staging o preview temporanee
• documenti scaricabili
• aree riservate
• pagine di test
• contenuti vecchi ancora raggiungibili

Se non distingui questi casi, rischi uno dei due estremi peggiori:

• lasciare esposto a crawler AI materiale che non dovrebbe circolare
• bloccare in massa pagine utili e perdere visibilita proprio dove il sito dovrebbe farsi trovare

I crawler AI non fanno tutti la stessa cosa

Questo e il punto che cambia davvero il modo di decidere.

OpenAI spiega che OAI-SearchBot serve a far emergere contenuti in ChatGPT search, mentre GPTBot riguarda l'esclusione da possibili usi di training. Anthropic fa un passo ancora piu esplicito e divide il traffico in tre famiglie:

• ClaudeBot per la raccolta di contenuti destinati allo sviluppo dei modelli
• Claude-SearchBot per migliorare la qualita dei risultati di ricerca
• Claude-User per recuperare pagine quando un utente chiede a Claude di leggere contenuti sul web

Dal punto di vista business, questa distinzione conta moltissimo.

Bloccare un bot di training non e la stessa cosa che bloccare un bot di search. Bloccare un bot di search non e la stessa cosa che impedire il fetch di una pagina chiesta da un utente. Fare tutto con una regola generica significa spesso non sapere davvero cosa stai rinunciando a ottenere.

Cosa cambia tra training, search e fetch su richiesta

Vale la pena tradurre queste categorie in effetti pratici.

Training

Qui l'obiettivo e limitare l'uso dei tuoi contenuti per addestramento futuro. E una scelta di governance del contenuto e del brand.

Search

Qui il tema e la discoverability. Se blocchi i bot che alimentano la ricerca AI, riduci la probabilita che i tuoi contenuti vengano trovati, citati o collegati in ambienti come ChatGPT search o strumenti equivalenti.

Fetch su richiesta utente

Qui non stai dicendo "questa pagina puo stare in un indice", ma "questa pagina puo essere letta quando un utente chiede esplicitamente all'assistente di aprirla o interpretarla".

Per molte PMI e per molti siti di servizio, il valore vero non sta nel training. Sta nel capire se vuoi essere leggibile in contesti di ricerca e assistenza AI senza esporre tutto il resto.

Robots.txt, noindex e blocco tecnico fanno lavori diversi

Uno degli errori piu comuni e usare lo strumento giusto per il problema sbagliato.

robots.txt

Serve a dare istruzioni di crawling. E utile per esprimere preferenze e segmentare accessi, ma non e un blocco tecnico garantito. Cloudflare lo dice in modo esplicito: molti crawler seri lo rispettano, ma non puoi considerarlo da solo una barriera definitiva.

noindex

Serve a dire che una pagina non deve comparire nei risultati dei motori che supportano quella direttiva. Google continua a ribadire un punto chiave: per vedere il noindex, il crawler deve poter leggere la pagina. Se la blocchi prima via robots.txt, il segnale rischia di non essere visto.

OpenAI aggiunge una sfumatura utile: una pagina disallowata puo comunque comparire come semplice link e title se l'URL arriva da altre fonti e viene giudicato rilevante. Se vuoi evitarlo, la strada indicata e usare noindex, lasciando al crawler la possibilita di leggere il tag.

nosnippet, data-nosnippet e limiti allo snippet

Google documenta che queste direttive influenzano non solo la ricerca classica, ma anche AI Overviews e AI Mode. Questo le rende utili quando vuoi limitare quanto testo puo essere riusato o mostrato, senza necessariamente eliminare del tutto la pagina.

Blocco tecnico

Quando il contenuto non deve proprio essere letto, servono controlli veri:

• autenticazione
• protezione lato server
• WAF o regole edge
• rimozione dell'URL pubblico

Se il problema e "non voglio che questa pagina venga letta", robots.txt da solo non basta.

Bloccare tutto puo costare piu del previsto

La tentazione di bloccare tutto nasce spesso da prudenza. Ma per un sito web il costo puo essere concreto.

Se impedisci la lettura a bot di search o fetch utili, rischi di perdere:

• visibilita su contenuti di servizio e supporto
• citazioni o link da esperienze di ricerca AI
• traffico referral misurabile
• comprensione corretta delle tue pagine pubbliche da parte di nuovi canali

OpenAI, per esempio, indica che i referral da ChatGPT search possono essere tracciati con utm_source=chatgpt.com. Questo significa che per alcuni siti il tema non e teorico: esiste gia un canale che puo essere osservato, misurato e valutato.

Bloccare tutto senza misurare equivale a rinunciare a un canale prima ancora di capire se ti stava portando visite utili.

Dove un blocco forte ha davvero senso

Ci sono scenari in cui la scelta corretta e molto piu netta.

Per esempio:

• ambienti staging e preview
• documenti riservati o materiali commerciali non pubblici
• pagine di test, sandbox o contenuti incompleti
• aree con dati sensibili o informazioni cliente-specifiche
• file scaricabili che non devono diventare punti di ingresso pubblici

Un caso raccontato da Cloudflare e particolarmente utile: sui propri siti preview di documentazione, l'azienda ha osservato che una quota enorme dei crawl AI stava andando verso versioni temporanee e non definitive. Prima robots.txt ha ridotto il problema, poi una regola di sicurezza ha portato i crawl su quelle preview a zero.

La lezione pratica e semplice: se il contenuto non e pronto o non deve circolare, meglio un blocco reale che una speranza affidata solo alle convenzioni.

Dove conviene lasciare accesso controllato

Non tutte le pagine pubbliche meritano un blocco.

In molti siti conviene rendere leggibili, con criterio, contenuti come:

• pagine servizio ben mantenute
• FAQ pubbliche
• documentazione di supporto
• pagine contatti e informazioni operative
• contenuti evergreen che rappresentano bene il brand

Qui il beneficio non e "far usare tutto all'AI", ma aumentare la probabilita che un contenuto pubblico corretto venga compreso e richiamato in modo coerente.

Questo vale soprattutto se il sito ha pagine che rispondono bene a domande pratiche. Se un assistente AI deve capire chi sei, cosa fai, come contattarti o come funziona un servizio, e meglio che legga la pagina giusta e aggiornata, non una preview dimenticata o una pagina secondaria ambigua.

Un framework decisionale semplice per PMI e siti di servizio

Per non trasformare il tema in una discussione astratta, puo aiutare una griglia minima.

Scenario 1: pagina pubblica e commerciale

Se la pagina rappresenta bene il tuo servizio, e aggiornata e non contiene dati delicati, ha senso valutare apertura ai bot di search e fetch utili.

Scenario 2: contenuto pubblico ma non da riusare liberamente

Qui puoi ragionare su segnali piu granulari, come noindex o limiti allo snippet, invece di un blocco cieco dell'intero sito.

Scenario 3: contenuto non pronto o temporaneo

Qui la scelta migliore e quasi sempre il blocco tecnico vero, non la sola direttiva di crawling.

Scenario 4: contenuto privato o sensibile

Qui la discussione sui crawler arriva dopo. Prima viene l'architettura di accesso: autenticazione, permessi, scadenze, controlli server-side.

In pratica, non esiste una policy unica buona per tutto il dominio. Esiste una governance diversa per classi di contenuto diverse.

Cosa controllare dopo aver cambiato le regole

Una modifica a robots.txt, noindex o WAF non andrebbe mai trattata come intervento da fare e dimenticare.

Conviene osservare almeno:

• log o analytics sui bot effettivamente presenti
• eventuali violazioni di robots.txt
• presenza di traffico referral da strumenti AI quando i contenuti pubblici restano accessibili
• pagine preview o staging ancora richieste da crawler
• coerenza tra le pagine che vuoi promuovere e quelle che stanno davvero ricevendo richieste

Se il tuo CDN o layer edge offre telemetria specifica sui bot AI, questa parte diventa molto piu concreta. Il vero salto di qualita non e scrivere piu regole, ma vedere se stanno producendo l'effetto voluto.

Checklist pratica prima di toccare robots.txt o WAF

Prima di aggiornare le regole, conviene verificare:

• quali pagine vuoi rendere trovabili in search o assistenza AI
• quali URL non dovrebbero essere letti in nessun caso
• se stai confondendo opt-out dal training con blocco della discoverability
• se una pagina deve essere esclusa dai risultati o solo limitata nello snippet
• se il noindex restera leggibile al crawler che deve vederlo
• se staging, preview e documenti temporanei sono protetti davvero
• se esiste un modo per misurare traffico e richieste prima e dopo la modifica
• chi manterra queste regole quando il sito cambiera struttura o stack

Se mancano queste risposte, il rischio e creare una policy apparente che sembra prudente ma in realta lascia zone scoperte o taglia canali utili.

Conclusione

Bloccare i crawler AI puo essere una scelta corretta, ma solo quando e chiaro cosa vuoi bloccare e perche.

Se tratti nello stesso modo training, search, fetch su richiesta e contenuti sensibili, rischi di prendere decisioni troppo larghe e poco difendibili. Se invece distingui usi, pagine e livelli di protezione, puoi costruire una governance molto piu pulita: visibilita dove serve, blocco vero dove conta, meno sorprese operative nel tempo.

Se vuoi, posso aiutarti a rivedere robots.txt, regole edge, noindex e struttura dei contenuti del tuo sito per capire quali pagine ha senso lasciare leggibili e quali invece dovrebbero essere isolate davvero.