La maggior parte dei Googlebot è falsa: come riconoscerli

Un server riceve una richiesta con lo user agent Googlebot. Nei report di traffico compare quindi il crawler di Google, magari impegnato a visitare centinaia o migliaia di URL. Sembra tutto normale, ma spesso non lo è: lo user agent non prova l’identità di chi effettua la connessione e qualunque client HTTP può presentarsi come Googlebot modificando una semplice intestazione.

Esaminando i log di un server web, soprattutto in presenza di traffico anomalo, si arriva spesso a una conclusione netta: gran parte delle richieste che dichiarano di provenire da Googlebot non supera i controlli necessari per attribuirle davvero a Google. Crawler diversi da quelli usati dall’azienda di Mountain View, meccanismi di scraping e sistemi automatici sfruttano da anni nomi familiari per aggirare filtri poco rigorosi, ottenere un trattamento privilegiato o confondersi con il traffico indispensabile per l’indicizzazione.

Il protocollo HTTP ha sempre lasciato al client la possibilità di dichiarare liberamente il proprio user agent. Una richiesta può identificarsi come browser, applicazione mobile, scanner di sicurezza o motore di ricerca senza fornire alcuna prova crittografica.

Google stessa ha avviato con Chrome un progressivo ridimensionamento dello user agent, un’intestazione considerata troppo ricca di dettagli, favorevole al fingerprinting e poco affidabile come fonte di informazioni sul client. I Client Hints sono intestazioni HTTP controllate dal software che apre la connessione e non dimostrano che dietro una richiesta ci sia davvero Chrome, Googlebot o un altro prodotto Google.

Perché tanti bot fingono di essere Googlebot

Googlebot gode di un trattamento particolare su molti siti. Gli amministratori evitano comprensibilmente di bloccarlo, perché un errore potrebbe rallentare la scansione delle pagine, compromettere l’aggiornamento dell’indice o rendere invisibili contenuti importanti nei risultati di ricerca. Alcune configurazioni gli concedono inoltre limiti di frequenza più generosi, accesso a URL normalmente protetti dai “filtri antiautomazione” o l’esclusione da determinate regole del Web Application Firewall.

Per uno scraper la convenienza è evidente: copiare un user agent non costa nulla e può ridurre la probabilità di ricevere un errore 403, una pagina CAPTCHA o una risposta HTTP 429. Altri software usano il nome Googlebot per raccogliere prezzi, testi, indirizzi email, dati sui prodotti oppure per mappare applicazioni e percorsi nascosti.

Un’intestazione plausibile può assomigliare a quella usata dal crawler per smartphone, oggi centrale per la scansione delle pagine dopo il passaggio di Google al mobile-first indexing. Copiarla è banale:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/... Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

La presenza di Googlebot/2.1 non dimostra nulla. Anche il collegamento alla pagina informativa di Google è soltanto testo inviato dal client; non stabilisce alcun rapporto tra l’indirizzo IP sorgente e l’infrastruttura del motore di ricerca.

Il controllo corretto parte dall’indirizzo IP

Google descrive due metodi per verificare i suoi crawler. Il primo usa gli intervalli IP pubblicati dall’azienda sotto forma di file JSON; il secondo applica una verifica DNS in due passaggi. Entrambi risultano molto più affidabili del confronto sullo user agent, anche se richiedono una gestione accurata e qualche cautela.

Google pubblica elenchi distinti per i crawler comuni, per quelli speciali e per i fetcher attivati dagli utenti. I file contengono prefissi IPv4 e IPv6 in notazione CIDR, per esempio reti della forma 66.249.64.0/19. Un’applicazione può scaricare periodicamente questi dati, convertirli in strutture adatte alla ricerca e controllare se l’IP rilevato nel sistema di analytics in tempo reale o nei log appartiene a uno degli intervalli autorizzati.

I crawler comuni comprendono Googlebot e altri agenti usati per la ricerca; gli special-case crawler seguono regole specifiche e possono utilizzare host differenti. I fetcher avviati da un utente, invece, entrano in funzione quando un prodotto Google recupera una risorsa su richiesta diretta, come può accadere con alcuni strumenti di verifica.

Reverse DNS e forward DNS: servono entrambi

Il controllo DNS consigliato da Google segue una sequenza precisa. Prima si esegue una ricerca PTR sull’indirizzo IP sorgente, ottenendo il nome host associato. Per un Googlebot autentico il risultato deve terminare con domini autorizzati come googlebot.com o google.com, a seconda del tipo di crawler.

Su Linux, macOS o altri sistemi che includono il comando host, la ricerca inversa si avvia così: host <indirizzo_ip>

In alternativa si può interrogare direttamente il record PTR con dig: dig -x <indirizzo_ip> +short

Su Windows si può usare il comando seguente: nslookup <indirizzo_ip>

È opportuno anche effettuare la verifica opposta: risolvere il nome ottenuto tramite record A e AAAA e controllare che tra gli indirizzi restituiti compaia esattamente l’IP iniziale.

Cosa rivelano i log quando la verifica è fatta bene

Nei log grezzi, le richieste con user agent Googlebot possono apparire numerose e distribuite su molte reti. Dopo il controllo dell’origine, una parte consistente perde quell’identità: gli indirizzi non appartengono alle reti pubblicate da Google oppure falliscono la verifica DNS.

Un picco di traffico attribuito a Google potrebbe dipendere in realtà da scraper aggressivi; un elevato consumo di banda apparentemente legato all’indicizzazione potrebbe nascere da sistemi esterni che copiano contenuti; URL visitati di continuo da un presunto crawler potrebbero indicare attività tese a verificare tutte le risorse web indicate.

Il file robots.txt comunica ai crawler cooperativi quali percorsi possono visitare. Non autentica il client, non impedisce tecnicamente l’accesso e non protegge dati riservati. Un bot ostile può ignorarlo del tutto; anzi, le direttive possono perfino rivelargli percorsi interessanti.

Nemmeno il meta tag noindex costituisce un controllo di accesso: indica ai motori conformi di non inserire la pagina nell’indice, ma il server deve comunque consegnare il documento affinché il crawler possa leggere la direttiva.