Crawler AI e visibilità: come rendere il sito accessibile

Quale crawler serve alla ricerca e quale all’addestramento?

Prima di modificare robots.txt, decidi se vuoi consentire la ricerca, l’addestramento o entrambi. Per le funzioni AI della Ricerca Google, comprese AI Overviews e AI Mode, il riferimento è Googlebot. Google-Extended controlla invece l’uso dei contenuti per addestrare Gemini e per fornire fonti alle risposte in alcuni altri prodotti Google: quest’ultimo uso è chiamato grounding. È un nome da usare nelle regole di robots.txt, non uno user-agent distinto da cercare nei log, e non influisce sull’inclusione o sul posizionamento nella Ricerca Google.

Le visite richieste da un utente seguono regole diverse dalla scansione automatica. OpenAI avverte che robots.txt può non applicarsi a ChatGPT-User; Perplexity dichiara che Perplexity-User generalmente lo ignora. I contenuti riservati vanno quindi protetti con autenticazione. Per verificare nomi e funzioni aggiornati consulta la documentazione di OpenAI, Perplexity e l’elenco Google, soprattutto dopo modifiche del provider.

Come scrivere e controllare robots.txt

Apri il file pubblico all’indirizzo /robots.txt dello stesso host, protocollo e porta delle pagine da controllare: per https://example.com/servizi/ sarà https://example.com/robots.txt. Le regole di questo file non si applicano a https://www.example.com. Prima di intervenire, conserva la versione in uso; dopo il rilascio riapri il file pubblico per verificare che il CMS o la procedura di pubblicazione non abbiano sovrascritto le modifiche.

Supponiamo che l’azienda voglia consentire a ChatGPT di cercare le pagine pubbliche ed escludere la raccolta di GPTBot per l’addestramento. Nel file seguente /area-riservata/ è un percorso di esempio, che richiede comunque un login per proteggere i dati. Il divieto compare anche nel gruppo di OAI-SearchBot perché a un gruppo specifico non si sommano automaticamente le regole del gruppo con *. Se il file contiene più gruppi per lo stesso crawler o percorsi sovrapposti, verifica quali regole si applicano secondo il Robots Exclusion Protocol.

Adatta l’esempio al file esistente, conservando gli altri divieti necessari e gli indirizzi delle sitemap. Non occorre aggiungere Allow: / per consentire un percorso che non è vietato. Prima di chiudere l’intervento, confronta il file pubblico con quello approvato.

User-agent: *
Disallow: /area-riservata/

User-agent: OAI-SearchBot
Disallow: /area-riservata/

User-agent: GPTBot
Disallow: /

Sitemap: https://example.com/sitemap.xml

Quali direttive controllare nella pagina e negli header

Perché una pagina possa comparire come fonte collegata in AI Overviews o AI Mode, Google richiede che sia indicizzata e idonea a mostrare uno snippet, cioè un estratto nei risultati. Controlla sia il meta robots nell’HTML sia X-Robots-Tag negli header, le intestazioni della risposta HTTP finale. Per esempio, la CDN che distribuisce le pagine potrebbe aggiungere noindex anche se il codice HTML non lo contiene. Le direttive di Google sugli snippet comprendono nosnippet, max-snippet e data-nosnippet; non attribuire automaticamente gli stessi effetti a ogni piattaforma.

Se robots.txt blocca il recupero della pagina, il motore non può leggere il suo noindex. Per far elaborare questa direttiva devi consentire il recupero. In Ispezione URL di Search Console controlla l’HTML ricevuto da Google: il tag presente nel repository, da solo, non dimostra che sia arrivato al motore.

OpenAI distingue inoltre le risposte di ricerca dai link di navigazione: un sito escluso da OAI-SearchBot può ancora comparire come link di navigazione. Il blocco della scansione non equivale alla cancellazione di ogni riferimento al dominio.

Un piano iniziale: 32 tentativi su quattro URL

Scegli quattro pagine pubbliche diverse che possiedi o sei autorizzato a verificare. Nel registro chiameremo U1 la pagina di servizio, U2 la guida, U3 la pagina aggiornata di recente e U4 quella con contenuto che dipende da JavaScript. Se quest’ultima non esiste, scegli una pagina con una struttura diversa dalle altre tre. Se due criteri coincidono nello stesso URL, cerca comunque una quarta pagina distinta. Questo campione serve a una prima diagnosi; un sito con molti tipi di pagina richiederà controlli ulteriori. Usa URL che vuoi rendere accessibili: un’esclusione intenzionale va annotata, senza rimuoverla per ottenere un esito positivo.

Per ciascun URL esegui quattro richieste GET, una con ogni profilo, poi ripetile in un secondo momento. Il primo passaggio si chiama R1, il secondo R2: 4 URL × 4 profili × 2 passaggi danno 32 tentativi. Le sigle del registro sono CTRL per AuditCrawler/1.0, GOOG per Googlebot/2.1 (+http://www.google.com/bot.html), OAI per OAI-SearchBot/1.4 e PPLX per PerplexityBot/1.0. Queste stringhe di user-agent servono solo a confrontare le risposte; i bot autentici possono usare stringhe complete e versioni diverse. Esegui una richiesta alla volta e registra l’orario di ciascuna. Eventuali redirect aggiungono richieste di rete ai 32 tentativi previsti.

Il comando seguente usa GET e salva header e corpo della risposta. Una richiesta HEAD, che recupera solo le intestazioni, non permette di riconoscere una pagina di verifica restituita con stato 200. In PowerShell usa curl.exe per evitare l’alias presente in alcune versioni; su macOS e Linux usa curl. Esegui il comando in una cartella dedicata, dopo aver sostituito il dominio di esempio. Il limite di 30 secondi serve a interrompere una prova che non termina; non è una soglia SEO.

curl -sS -L --max-redirs 5 --connect-timeout 10 --max-time 30 -A "AuditCrawler/1.0" -D U1-CTRL-R1-header.txt -o U1-CTRL-R1.html -w "HTTP=%{http_code} URL=%{url_effective} BYTE=%{size_download}\n" "https://example.com/servizi/"

Come verificare l’identità del bot e un blocco WAF

Le prove con curl partono dal tuo indirizzo IP, anche quando dichiari lo user-agent di un crawler. Possono rivelare un filtro sul nome, ma non riproducono tutte le caratteristiche di una richiesta autentica. Perciò un 403 con il nome OAI-SearchBot non basta a dimostrare che il sito blocchi OpenAI. Per saperlo servono le richieste reali e la verifica della loro provenienza.

Il WAF è il firewall che filtra le richieste web. Se è collocato davanti al server, può rifiutare una visita prima che questa raggiunga il sito. Cerca quindi le richieste agli URL del campione nei log del WAF o della CDN, non soltanto nei registri del server di origine. Per ciascuna conserva data, ora e fuso, IP del visitatore, user-agent, URL, stato HTTP, byte restituiti e l’eventuale regola applicata. Se un identificativo della richiesta compare in entrambi i registri, usalo per collegarli; altrimenti confronta URL, orario e IP, annotando i limiti del riscontro. Se c’è un proxy, chiedi al gestore quale campo del log riporti l’IP del visitatore verificato dall’infrastruttura: un header che il visitatore può compilare liberamente non è una prova affidabile.

Per Google usa la verifica ufficiale delle richieste: confronta l’IP con l’elenco pertinente pubblicato da Google. In alternativa, con una ricerca DNS inversa ricava il nome associato all’IP; controlla che appartenga al dominio previsto per quel crawler, poi esegui la ricerca diretta sul nome ottenuto. Il risultato deve includere l’IP di partenza. Un nome che contiene soltanto la parola “google” non basta.

Per OpenAI e Perplexity verifica se l’IP appartiene agli intervalli pubblicati nei file JSON collegati nelle rispettive documentazioni. Conserva una copia dell’elenco e la data del controllo, perché gli intervalli possono cambiare. Perplexity raccomanda di usare insieme IP e user-agent nelle regole del firewall. Se non riesci a verificare la provenienza, registra “identità non verificata”: il solo nome del bot non giustifica un’eccezione al WAF.

Se il WAF blocca un crawler verificato che vuoi consentire, chi gestisce il firewall deve correggere la regola per quel traffico e per le pagine pubbliche interessate. Le protezioni delle funzioni sensibili e l’autenticazione devono restare attive. Prima della modifica, salva la regola precedente e indica chi può ripristinarla; dopo, ripeti le prove sugli URL coinvolti.

Se arriva un 200, il contenuto è davvero disponibile?

Apri il file HTML salvato e confrontalo con la pagina nel browser senza login. Un 200 può contenere il testo “verifica di essere umano”, un modulo di accesso o una pagina d’errore. La frase essenziale scelta prima del test permette di distinguere la pagina attesa da queste risposte, senza affidarsi al solo codice HTTP.

Se la frase manca nell’HTML salvato ma compare nel browser dopo il caricamento, controlla il contenuto aggiunto da JavaScript e gli eventuali errori degli script. Google può elaborare JavaScript, ma questo non dimostra che gli altri sistemi AI eseguano gli stessi script. Per Google verifica l’HTML acquisito in Ispezione URL; per gli altri provider confronta le capacità documentate con le prove disponibili. Se un’informazione pubblica essenziale compare solo dopo un clic o l’accettazione dei cookie, chiedi a chi sviluppa il sito di renderla disponibile anche senza queste interazioni. I contenuti riservati devono invece restare protetti dal login.

Controlla anche che i link verso le pagine importanti abbiano un indirizzo href, che le tabelle abbiano intestazioni comprensibili e che le immagini informative abbiano un testo alternativo adeguato. Google deve poter recuperare i file CSS e JavaScript necessari a ricostruire la pagina. Se il problema riguarda più tipi di pagina, usa la guida all’audit SEO tecnico.

Come registrare e interpretare i risultati

Per ogni identificativo del piano, come U1-CTRL-R1, registra OK se hai ricevuto il contenuto atteso, KO se hai trovato un blocco o una pagina diversa, NV se la prova manca o non permette una conclusione. Annota anche il codice HTTP e conserva i file della risposta. La verifica dell’identità va riportata a parte: l’esito OK di una tua richiesta di prova non certifica l’accesso di un bot autentico.

Dopo la correzione ripeti le quattro combinazioni fallite e verifica che la modifica non abbia cambiato l’accesso per gli altri profili. Salva i nuovi file in una cartella con la data del controllo, conservando quelli precedenti per il confronto. Se poi osservi un crawler con identità verificata che riceve la pagina, hai confermato il suo accesso in quel momento. L’indicizzazione e la citazione come fonte restano da verificare separatamente.

Accesso risolto: come verificare la scoperta

Collega le pagine importanti da altre pagine pertinenti del sito e inserisci nella sitemap gli URL canonici che vuoi far indicizzare. Verifica che la sitemap pubblica sia raggiungibile e che lastmod, la data dell’ultima modifica, cambi quando aggiorni sostanzialmente il contenuto. Link e sitemap aiutano il crawler a scoprire gli URL, ma non garantiscono una visita o una citazione.

In Ispezione URL di Search Console leggi la data dell’ultima scansione e controlla se l’URL canonico scelto da Google corrisponde a quello previsto. Se la scansione precede la correzione, l’HTML acquisito può ancora mostrare la vecchia versione. La prova dal vivo serve invece a verificare il recupero attuale: non aggiorna da sola lo stato di indicizzazione. Registra quindi sia la data della modifica sia quella del controllo, per capire a quale versione si riferisce ciascun risultato.

Per le funzioni AI di Google non servono file AI o markup Schema.org speciali: valgono i requisiti tecnici della Ricerca. Non usare la presenza di llms.txt come prova di accesso o di idoneità. Se l’accesso è confermato ma il sito non viene citato, passa alla misurazione della visibilità nella ricerca AI per documentare risposte e fonti nel tempo.

Registro tecnico da scaricare e consegna al team

Il PDF stampabile contiene la configurazione iniziale, una scheda con otto prove per un URL e un riepilogo per la diagnosi e le correzioni. Stampa una copia della prima e della terza pagina e quattro copie della seconda: avrai 32 righe, una per ciascun tentativo. Il registro si compila a mano; conserva i file di header, HTML e log in una cartella, usando gli identificativi riportati sulla scheda.

Quando consegni il registro a chi gestisce il sito, allega le regole pubbliche e le decisioni su ricerca e addestramento. Indica quali pagine e profili hai provato, quali controlli mancano e quali identità hai verificato. Per ogni correzione devono risultare il problema, il responsabile e la data della nuova prova. Se non puoi consultare i log del WAF o della CDN, segna NV per la verifica dell’identità e chiedi al gestore dell’hosting le richieste corrispondenti agli URL e agli orari annotati.

Scarica il registro tecnico crawler AI (PDF, 3 pagine)