User Agent e SEO

TL;DR — Un user agent è una piccola riga di testo che ogni browser e ogni bot invia con ogni richiesta per dire “ecco chi sono”. Il crawler di Google dice di essere Googlebot; quello di Bing dice bingbot. In robots.txt non scrivi l’intera riga — usi un nome breve (un “token”) come Googlebot. Ed ecco il punto: quella riga è solo testo, quindi chiunque può falsificarla. L’unico modo reale per sapere se un bot è chi dice di essere è controllare da dove proviene effettivamente la sua richiesta.

Cos’è un user agent

Ogni volta che il tuo browser carica una pagina, invia una breve etichetta di testo che dice cosa è — qualcosa come “Sono Chrome su un Mac”. Quell’etichetta è l’user agent, e viaggia in un header HTTP su ogni richiesta. I server possono leggerla e reagire a essa.

Importante avvertenza iniziale: il client compila quell’etichetta da solo. Niente la controlla. È una dichiarazione, non una credenziale — quindi un user agent che dice “Googlebot” non è la stessa cosa di una richiesta effettivamente verificata come Googlebot.

I crawler fanno la stessa cosa. Quando Googlebot recupera la tua pagina, invia un user agent che include Googlebot. Quando Bingbot la recupera, l’user agent include bingbot. È così che un bot si annuncia nei log del tuo server.

La stringa vs. il nome breve

Ci sono davvero due cose che le persone intendono con “user agent”, e confonderle causa molta confusione:

• La stringa user-agent è la riga completa nell’header della richiesta. Quella di Googlebot è lunga e assomiglia molto a un browser.
• Il token user-agent è il nome breve che usi in robots.txt per indirizzare un bot — come Googlebot o bingbot. Il token è solo un pezzo della stringa completa, non l’intera cosa.

Quindi quando scrivi una regola in robots.txt, usi il token breve:

User-agent: Googlebot
Disallow: /private/

Non incolli lì la gigantesca stringa che sembra un browser.

Non puoi fidarti della stringa

Questa è l’unica cosa da ricordare. La riga user-agent è testo semplice, quindi qualsiasi cosa può falsificarla. Qualsiasi script può affermare di essere Googlebot in una singola riga di codice — e molti lo fanno, per superare i blocchi. Google stesso dice che l’header Googlebot è “spesso spoofato.”

Ciò significa che non dovresti mai decidere chi ha accesso al tuo sito basandoti solo sull’user agent. Se hai davvero bisogno di confermare che un visitatore è il vero Googlebot (ad esempio, se stai leggendo i tuoi log), verifichi controllando da dove proviene la richiesta — non cosa dice di essere. La scheda Avanzate spiega esattamente come.

Alcuni intoppi

• I nomi user-agent in robots.txt sono case-insensitive — Googlebot e googlebot sono la stessa cosa.
• Bloccare tutto con User-agent: * non blocca tutti i bot di Google — i suoi crawler pubblicitari e il crawler di sicurezza ignorano il wildcard.
• Mostrare una versione di una pagina a un crawler e una diversa a persone reali è cloaking, e Google lo tratta come spam.

Vuoi il quadro completo — le tabelle dei token, ogni crawler di Google e Bing, i comandi esatti di verifica e le regole sul cloaking — passa alla scheda Avanzate.

TL;DR — Uno user agent è l’header della richiesta HTTP che qualsiasi client invia per identificarsi; è un metadato opzionale fornito dal client, non un’identità autenticata. Il suo valore è la stringa dello user agent. Distinta da questa è la token dello user agent (product token) usata in robots.txt — RFC 9309 dice che DOVREBBE essere una sottostringa della stringa, una convenzione forte con eccezioni documentate (Google-Extended non ha alcuna stringa di richiesta). Il matching è case-insensitive, i numeri di versione/wildcard nella riga del token vengono ignorati, vince il gruppo più specifico, e i gruppi con lo stesso token si uniscono ma non si uniscono mai con *. La stringa è banalmente falsificabile — Google chiama la propria “often spoofed” — quindi verifica tramite DNS inverso + diretto (dietro qualsiasi proxy/CDN, usa l’IP reale del client) contro googlebot.com/google.com/googleusercontent.com per Google o search.msn.com per Bing, oppure confronta gli intervalli IP pubblicati — e anche una richiesta verificata prova solo che una richiesta è arrivata, non che la pagina è stata indicizzata, recuperata o usata per l’addestramento dell’IA. AdsBot e Google-Safety ignorano User-agent: *. Chrome sta anche congelando i dettagli dalle stringhe UA del browser (User-Agent reduction); Client Hints sono il sostituto strutturato ma opt-in, e nessuno dei due sostituisce la verifica del crawler. L’adattamento dello user agent può essere legittimo, ma mostrare in modo ingannevole ai crawler contenuti materialmente diversi può essere cloaking.

L’header, la stringa e il token

Tre cose, e tenerle distinte è la maggior parte di questo argomento.

• L’header. User-Agent è un header HTTP di richiesta. Ogni client lo invia: il tuo browser, curl, un crawler, un bot. Secondo RFC 9110 (lo standard di base della semantica HTTP), è un campo opzionale che il client compila — metadati descrittivi forniti dal client, non un’identità autenticata verificata dal server.
• La stringa. Il valore dell’header — una riga libera che descrive il software, la versione, il motore di rendering e talvolta il sistema operativo.
• Il token. L’identificatore breve usato nelle righe User-agent: di robots.txt per indirizzare un crawler — Googlebot, bingbot, Google-Extended.

La relazione è la parte che confonde le persone. RFC 9309 (lo standard formale del Robots Exclusion Protocol) dice che il token “SHOULD be a substring of the identification string that the crawler sends… in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” Questo è un SHOULD, non un MUST — una convenzione forte che lo standard raccomanda, non un requisito rigido a cui ogni crawler è meccanicamente vincolato. Google-Extended (sotto) è l’esempio più chiaro di un’ eccesione documentata a questa regola. Non leggere la regola della sottostringa come universale solo perché Google la segue per la maggior parte dei suoi token. Il token è parte di la stringa quando un provider ne fornisce uno; indirizzi il token in robots.txt e leggi la stringa nei tuoi log.

La stessa formulazione di Google su come i suoi bot si identificano è utile qui: “Google’s crawlers identify themselves through three things: the HTTP user-agent request header, the source IP address of the request, and the reverse DNS hostname of the source IP.” Nota che lo user agent è solo uno dei tre — gli altri due sono come lo verifichi effettivamente.

Google-Extended: un token senza stringa

L’illustrazione più chiara di token ≠ stringa è Google-Extended. Controlla se Google può usare i tuoi contenuti per l’addestramento e il grounding di Gemini — e non ha nessuna stringa user-agent di richiesta HTTP dedicata. La scansione stessa viene eseguita con le stringhe Googlebot esistenti; Google-Extended esiste solo come token di controllo robots.txt. Non vedrai mai “Google-Extended” in un header di richiesta nei tuoi log.

La conseguenza pratica: bloccare Google-Extended influisce solo sull’uso del tuo contenuto per l’addestramento dell’IA — non impedisce a Googlebot di eseguire la scansione e l’indicizzazione per la Ricerca. Sono decisioni separate controllate da token separati. (Per un quadro più ampio dei bot che leggono il tuo sito, vedi AI crawler e crawler.)

Stringhe user-agent di Googlebot

Googlebot è “evergreen” — gira su una versione recente di Chrome e la versione di Chrome nella sua stringa viene aggiornata periodicamente (dal dicembre 2019). Ecco perché la versione appare come segnaposto W.X.Y.Z:

Googlebot Smartphone (mobile):

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

Googlebot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36

Due cose da interiorizzare. Primo, non hardcodare la versione — W.X.Y.Z cambia e fare matching su di essa si romperà. Abbina invece il token stabile Googlebot. Secondo, non puoi separare mobile e desktop in robots.txt. Entrambe le varianti condividono l’unico token Googlebot, quindi una regola robots.txt si applica a entrambe.

Token dei crawler di Google

Google gestisce un’intera famiglia di crawler e fetcher, ognuno con il proprio token. Quelli che incontrerai più spesso:

E quelli che infrangono le regole usuali — i crawler speciali che ignorano User-agent: *:

• AdsBot (AdsBot-Google) e AdsBot Mobile (AdsBot-Google-Mobile) — non obbediscono al wildcard. Per bloccarli devi nominarli esplicitamente.
• AdSense (Mediapartners-Google) — stesso discorso; ignora il * globale.
• Google-Safety — usato per il rilevamento di malware/abusi; ignora robots.txt completamente.

L’implicazione è quella che la gente si perde: User-agent: * non blocca AdsBot o Google-Safety. Se “blocchi tutti i bot” con un wildcard e presumi che AdsBot sia sparito, non lo è. (Questo è esattamente il tipo di sorpresa che porta una pagina in territorio indicizzata ma bloccata da robots.txt — vedi robots.txt per la storia completa del controllo.)

Stringhe user-agent di Bingbot

Bing ha ricostruito la stringa di Bingbot nel 2022 per riflettere che esegue il rendering con Microsoft Edge. Le stringhe attuali:

Bingbot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/W.X.Y.Z Safari/537.36

Bingbot Mobile:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

Il token robots.txt è semplicemente bingbot. La cosa da osservare: dopo il 2022, la stringa di Bingbot sembra quasi esattamente un vero browser Chrome/Edge — l’unico indizio è il frammento bingbot/2.0 al suo interno. Se hai qualsiasi logica che filtra o rileva bot in base allo UA, quel cambiamento conta.

Come robots.txt abbina effettivamente un token

Alcune regole governano quale gruppo di regole un crawler obbedisce (secondo la specifica robots.txt di Google e RFC 9309):

• Vince la corrispondenza più specifica. Google “determina il gruppo corretto di regole trovando… il gruppo con lo user agent più specifico che corrisponde allo user agent del crawler.” Un gruppo Googlebot batte un gruppo * per Googlebot.
• I gruppi con lo stesso token si fondono — ma mai con *. Più gruppi che nominano lo stesso agente vengono combinati in uno. Un gruppo con agente specifico e il gruppo * non vengono fusi; * è solo il fallback quando nulla di specifico corrisponde.
• Case-insensitive. Sia il nome del campo che il valore — Googlebot, googlebot, GOOGLEBOT sono equivalenti.
• I numeri di versione e i wildcard nella riga del token vengono ignorati. Secondo Google, “sia googlebot/1.2 che googlebot* sono equivalenti a googlebot.” Non puoi scrivere User-agent: Googlebot* per corrispondere a una famiglia — il * lì non fa nulla.

Quindi una riga User-agent: accetta un token e lo confronta come una sottostringa semplice (senza distinzione tra maiuscole e minuscole) dell’identità del crawler — nessun blocco di versione, nessun carattere jolly al suo interno.

Perché non puoi fidarti della stringa — e come verificarla

La stringa user-agent è testo libero. Qualsiasi cosa può impostarla. Una riga di curl può dichiarare di essere Googlebot, e molti strumenti e bot malevoli fanno esattamente questo per superare i blocchi. Google lo dice nella propria documentazione su Googlebot: “l’header della richiesta HTTP user-agent usato da Googlebot è spesso falsificato da altri crawler.” Come ho scritto nella mia guida a Googlebot, “Molti strumenti SEO e alcuni bot malevoli fingono di essere Googlebot. Questo può permettere loro di accedere a siti web che cercano di bloccarli.”

Quindi non prendere mai una decisione di accesso o di contenuto basandoti solo sulla stringa. Verifica invece.

Un prerequisito prima di entrambi i metodi: ottieni il vero IP di origine. Se il tuo sito è dietro un proxy inverso, un bilanciatore di carico o una CDN, l’indirizzo nel tuo log di accesso predefinito potrebbe essere l’IP del proxy, non quello del crawler — hai bisogno dell’IP client originale (di solito inoltrato in un header come X-Forwarded-For, configurato correttamente sul tuo proxy) altrimenti nessuno dei due metodi di verifica ha senso.

Metodo 1 — DNS inverso + diretto (ideale per controlli a campione). I due passaggi di Google:

1. “Esegui una ricerca DNS inversa sull’indirizzo IP di accesso dai tuoi log, usando il comando host. Verifica che il nome di dominio sia googlebot.com, google.com o googleusercontent.com.”
2. “Esegui una ricerca DNS diretta sul nome di dominio recuperato al passaggio 1… Verifica che sia lo stesso indirizzo IP di accesso originale dai tuoi log.”

Per Bingbot, la stessa danza in due passaggi, ma il nome host deve terminare con search.msn.com (non un dominio con marchio Bing — una sorpresa comune). I comandi sono nella scheda Script.

Metodo 2 — intervalli IP pubblicati (ideale su larga scala). Google non pubblica una lista bianca statica per l’hardcoding (“questi intervalli di indirizzi IP possono cambiare”), ma pubblica file JSON CIDR leggibili da macchina che puoi confrontare (common-crawlers.json e i file dei crawler più ampi). Bing ora pubblica anche i suoi intervalli. Ho creato uno strumento di verifica IP di Googlebot proprio per questo — incolla gli IP e li classifica. Bing Webmaster Tools ha anche uno strumento integrato “Verifica Bingbot”.

Il DNS è migliore per un controllo una tantum dei log; il confronto degli intervalli IP è migliore per la verifica su larga scala. Usa quello che preferisci — ma usane uno. E tratta sia i nomi host attesi che i file di intervalli come attuali da oggi, non permanenti — Google e Bing hanno cambiato questi percorsi in passato (i file JSON degli intervalli IP sono stati spostati e rinominati da quando questo articolo è stato scritto), quindi ricontrolla il documento di verifica live se una ricerca che funzionava smette di corrispondere.

Una corrispondenza UA non è una prova dei risultati a valle

Anche una richiesta completamente verificata — IP reale di Googlebot, DNS inverso confermato in avanti, tutto torna — prova solo una cosa: quella richiesta è arrivata al tuo server. È tentatore trasformarla in un’affermazione molto più grande, ma ciascuna di queste è un fatto separato che richiede prove separate:

• Richiesta ricevuta — una richiesta con quel user agent ha raggiunto il tuo server. (Ciò che la verifica dei log dimostra realmente.)
• Identità confermata — la richiesta proviene realmente dal crawler che dichiara di essere. (Ciò che il reverse DNS / il controllo degli intervalli IP aggiunge.)
• Contenuto recuperato e renderizzato — il crawler ha renderizzato correttamente la pagina (nessun errore, nessuna risorsa bloccata). Non è garantito solo perché una richiesta è arrivata.
• Indicizzato — l’URL è entrato nell’indice di ricerca. Un recupero riuscito non garantisce l’indicizzazione.
• Usato per il recupero, la citazione o l’addestramento — soprattutto per i crawler AI (Google-Extended, GPTBot e altri), una scansione non è la prova che i tuoi contenuti siano stati recuperati per una risposta specifica, citati o usati nell’addestramento del modello. Questi sono passaggi separati, per lo più non osservabili, a valle della scansione.

Un hit verificato di Googlebot nei tuoi log è un segnale reale — semplicemente non spingerlo oltre ciò che mostra realmente.

Web Bot Auth: dove sta andando la verifica

Nel 2026 Google ha iniziato a sperimentare Web Bot Auth — “un protocollo crittografico sperimentale usato per autenticare le richieste inviate dai bot.” L’idea è di “andare oltre gli header facilmente falsificabili verso un’identità verificata e disaccoppiare l’identità dell’agente dagli indirizzi IP.” I bot firmano crittograficamente le loro richieste; i siti verificano la firma rispetto alle chiavi pubbliche pubblicate da Google, e le richieste firmate portano un header Signature-Agent. L’avvertenza di Google conta: “Non firmiamo ogni richiesta di un particolare agente. Assicurati di ricorrere ai metodi consolidati di verifica dei bot.” Quindi è additivo, non una sostituzione — il reverse DNS e gli intervalli IP rimangono la tua base oggi.

Anche i browser stanno diventando più difficili da analizzare dalla stringa UA

Tutto quanto sopra riguarda i crawler, ma la stessa lezione “non fidarti troppo della stringa” si applica ai browser, e sta diventando più forte. Chrome ha implementato gradualmente la User-Agent reduction: congelare o rendere meno precise parti della sua stringa UA (versione completa del browser, versione del sistema operativo, modello del dispositivo) invece di riportarle esattamente, così la stringa non può essere usata per identificare un utente specifico. La stessa formulazione di Google: “La granularità e l’abbondanza di dettagli possono portare all’identificazione dell’utente. La disponibilità predefinita di queste informazioni può portare a un tracciamento occulto.” In pratica, ciò significa che l’analisi della stringa UA per la versione esatta di browser/OS/dispositivo — analisi, rilevamento del dispositivo, triage dei bug — è sempre più inaffidabile e lo sarà sempre di più.

La sostituzione che Chrome raccomanda è User-Agent Client Hints (UA-CH): dati strutturati che il browser invia solo quando un server lo richiede esplicitamente. Gli hint a bassa entropia (marchio del browser, versione principale, flag mobile) vengono inviati per impostazione predefinita; gli hint ad alta entropia (versione esatta, versione della piattaforma, modello del dispositivo) richiedono che il server accetti tramite un header di risposta Accept-CH prima — una negoziazione esplicita, non una trasmissione. Due avvertenze prima di affidartici: è un meccanismo della famiglia Chrome/Chromium, non qualcosa che ogni browser invia, e anche dove è supportato, “il valore può essere vuoto, non restituito o popolato con un valore variabile.” I Client Hints risolvono il problema della stringa del browser; non sono un meccanismo di verifica dei crawler — Google e Bing verificano ancora i propri crawler tramite DNS e intervalli IP, non tramite Client Hints.

Targeting e cloaking basati sullo user agent

La mossa allettante — “rileva Googlebot dal suo UA e servigli qualcosa di speciale” — è sia tecnicamente fragile che una violazione delle policy.

Fragile, perché Google non esegue la scansione con un solo UA. Dovresti gestire correttamente Googlebot (mobile e desktop), Google-InspectionTool, AdsBot, GoogleOther e altri, da IP rotanti — praticamente impossibile da inserire in una whitelist in modo pulito.

Una violazione delle policy, perché servire contenuti diversi a un crawler rispetto agli utenti è cloaking: “presentare contenuti diversi a utenti e motori di ricerca con l’intento di manipolare il posizionamento nei risultati di ricerca e ingannare gli utenti.” La penalità va da una retrocessione algoritmica alla completa deindicizzazione. Nota la riga: l’adattamento legittimo (layout responsive, negoziazione dei contenuti) è accettabile — è lo scambio del contenuto stesso tra bot e utenti che sfocia nel cloaking.

Per capire dove si colloca lo user agent nel flusso più ampio, vedi crawling (l’hub) e crawler. Per controllare cosa quei bot possono recuperare, vedi robots.txt.

Riepilogo AI

Una sintesi della versione Advanced:

• Tre cose da tenere distinte: l’header della richiesta User-Agent — opzionale, metadati compilati dal client secondo RFC 9110, non identità autenticata; il suo valore, la stringa user-agent; e il token usato in robots.txt. Secondo RFC 9309 il token DOVREBBE essere una sottostringa della stringa — una convenzione forte, non una regola universale.
• Alcuni token non hanno una stringa. Google-Extended è l’eccezione documentata: esiste solo come controllo robots.txt (addestramento Gemini); il crawling usa le normali stringhe Googlebot. Bloccarlo non influisce sull’indicizzazione nella Ricerca.
• Le stringhe Googlebot/Bingbot sono sempreverdi — la versione di Chrome appare come W.X.Y.Z e cambia; abbina il token stabile (Googlebot, bingbot), mai la versione. Googlebot mobile e desktop condividono un unico token. Il Bingbot post-2022 sembra un browser reale tranne per il frammento bingbot/2.0.
• Corrispondenza robots.txt: vince il gruppo più specifico; i gruppi con lo stesso token si fondono ma mai con *; la corrispondenza non fa distinzione tra maiuscole e minuscole; i numeri di versione e i caratteri jolly nella riga User-agent: vengono ignorati (Googlebot* = Googlebot).
• AdsBot e Google-Safety ignorano User-agent: * — bloccali per nome o per niente.
• La stringa è banalmente falsificabile (Google la definisce “spesso falsificata”). Ottieni prima il vero IP del client (proxy/CDN possono mascherarlo nei tuoi log), poi verifica tramite DNS inverso + diretto (googlebot.com/google.com/googleusercontent.com; Bing → search.msn.com) o gli intervalli IP pubblicati — file che Google ha rinominato/spostato in passato, quindi ricontrolla il documento live se una ricerca smette di corrispondere. Non fidarti mai della stringa per il controllo degli accessi.
• Una richiesta verificata non è comunque una prova di tutto ciò che segue. Richiesta ricevuta, identità confermata, contenuto renderizzato, pagina indicizzata e contenuto recuperato/citato/addestrato sono affermazioni separate che richiedono prove separate — un hit nei log dimostra la prima, nient’altro automaticamente.
• Web Bot Auth (2026, sperimentale) firma le richieste crittograficamente — additivo, con DNS/IP ancora come fallback.
• Anche le stringhe UA dei browser stanno diventando più difficili da analizzare: la riduzione dello User-Agent di Chrome congela i dettagli esatti di versione/OS/dispositivo fuori dalla stringa; Client Hints sono il sostituto strutturato e opt-in — ma sono specifici di Chrome e non sostituiscono la verifica dei crawler.
• Servire contenuti diversi in base allo UA è cloaking — una violazione delle policy anti-spam, e fragile perché Google esegue il crawling con molti UA.

Documentazione ufficiale

Documentazione di fonte primaria dai motori di ricerca e dallo standard.

Google

• Panoramica dei crawler e dei fetcher di Google (user agent) — i tre segnali di identificazione e l’elenco completo dei crawler.
• Crawler comuni di Google — la tabella token + stringa user-agent.
• Crawler per casi speciali di Google — AdsBot, Mediapartners-Google, Google-Safety e le eccezioni *.
• Verifica delle richieste dai crawler e fetcher di Google — il metodo DNS in due passaggi e i file degli intervalli IP.
• Cos’è Googlebot — le stringhe di Googlebot e la nota “often spoofed”.
• Come Google interpreta la specifica robots.txt — corrispondenza dei token, insensibilità alle maiuscole, wildcard ignorate.
• Autenticazione delle richieste con Web Bot Auth (sperimentale) — il protocollo di firma crittografica.
• Aggiornamento dello user agent di Googlebot (2019) — perché la stringa mostra W.X.Y.Z.
• Politiche anti-spam — Cloaking — la definizione e la penalità.

Bing / Microsoft

• Annuncio del cambio di user-agent per Bingbot (apr 2022) — le attuali stringhe desktop + mobile (Fabrice Canel).
• Come verificare che Bingbot sia Bingbot (ago 2012) — il metodo reverse-DNS *.search.msn.com.
• Bing Webmaster Tools — Verifica Bingbot — lo strumento di verifica integrato.

Lo standard

• RFC 9110 — HTTP Semantics, §10.1.5 User-Agent — la specifica HTTP di base: User-Agent è un campo opzionale fornito dal client, non un’identità autenticata.
• RFC 9309: Robots Exclusion Protocol — la definizione formale a livello SHOULD del token di prodotto come sottostringa della stringa user-agent.
• MDN — Intestazione User-Agent — la sintassi HTTP dell’intestazione stessa.

Stringhe UA del browser

• Chrome Privacy Sandbox — Riduzione dello User-Agent — cosa viene congelato/ingrossato nella stringa UA di Chrome e perché.
• Chrome for Developers — User-Agent Client Hints — hint a bassa vs. alta entropia e l’opt-in Accept-CH.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google, Bing e della RFC. Ogni link è un deep link che salta al passaggio citato nella pagina di origine.

Google — come i crawler si identificano

• “Google’s crawlers identify themselves through three things: the HTTP user-agent request header, the source IP address of the request, and the reverse DNS hostname of the source IP.” (traduzione) «I crawler di Google si identificano tramite tre elementi: l’intestazione della richiesta HTTP user-agent, l’indirizzo IP di origine della richiesta e il nome host DNS inverso dell’IP di origine.» — Documentazione di Google Search Central. Vai alla citazione

Google — la stringa è spoofata

• “The HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” (traduzione) «L’intestazione della richiesta HTTP user-agent utilizzata da Googlebot è spesso spoofata da altri crawler.» — Documentazione di Google Search Central. Vai alla citazione

Google — verifica tramite DNS

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (traduzione) «Esegui una ricerca DNS inversa sull’indirizzo IP di accesso dai tuoi log, usando il comando host. Verifica che il nome di dominio sia googlebot.com, google.com o googleusercontent.com.» Vai alla citazione
• “Google doesn’t post a public list of IP addresses for website owners to allowlist because these IP address ranges can change.” (traduzione) «Google non pubblica un elenco pubblico di indirizzi IP da consentire per i proprietari di siti web perché questi intervalli di indirizzi IP possono cambiare.» Vai alla citazione

Google — corrispondenza dei token in robots.txt

• “All non-matching text is ignored (for example, both googlebot/1.2 and googlebot* are equivalent to googlebot).” (traduzione) «Tutto il testo non corrispondente viene ignorato (ad esempio, sia googlebot/1.2 che googlebot* sono equivalenti a googlebot).» — Specifica robots.txt di Google. Vai alla citazione

Google — Web Bot Auth

• “An experimental cryptographic protocol used to authenticate requests sent by bots.” (traduzione) «Un protocollo crittografico sperimentale utilizzato per autenticare le richieste inviate dai bot.» Vai alla citazione
• “We don’t sign every request of a particular agent. Be sure that you fall back to the established methods of bot verification.” (traduzione) «Non firmiamo ogni richiesta di un particolare agente. Assicurati di ricorrere ai metodi consolidati di verifica dei bot.» Vai alla citazione

Google — cloaking

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (traduzione) «Il cloaking si riferisce alla pratica di presentare contenuti diversi agli utenti e ai motori di ricerca con l’intento di manipolare i ranking di ricerca e ingannare gli utenti.» — Google Search Essentials, Spam Policies. Vai alla citazione

RFC 9309 — il token è una sottostringa della stringa

• “The product token SHOULD be a substring of the identification string that the crawler sends to the service. For example, in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” (traduzione) «Il token di prodotto DOVREBBE essere una sottostringa della stringa di identificazione che il crawler invia al servizio. Ad esempio, nel caso di HTTP, il token di prodotto DOVREBBE essere una sottostringa nell’header User-Agent.» Vai alla citazione

Patrick Stox — sullo spoofing

• “Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.” (traduzione) «Molti strumenti SEO e alcuni bot dannosi fingono di essere Googlebot. Questo può consentire loro di accedere a siti web che cercano di bloccarli.» — dal mio articolo su Googlebot su Ahrefs. Leggilo

Crawler → token → stringa → verifica

La tabella di riferimento. Il token è ciò che inserisci in robots.txt; l’hostname di verifica è ciò a cui una richiesta autentica risolve inversamente.

Regole di corrispondenza di robots.txt a colpo d’occhio

Fatti rapidi

• Il token è una sottostringa della stringa UA (RFC 9309). Non l’intera stringa.
• Googlebot mobile e desktop condividono un token — non puoi separarli in robots.txt.
• La versione Chrome nella stringa è W.X.Y.Z — cambia; non codificarla mai.
• La stringa UA è banalmente falsificabile — verifica tramite DNS o IP, non fidarti mai della stringa.

Verifica un bot tramite DNS inverso e diretto

La stringa user-agent può essere falsificata in una riga di curl. Conferma che un bot sia genuino controllando l’IP da cui proviene effettivamente. Il pattern è lo stesso per Google e Bing — solo il nome host atteso differisce.

Ottieni prima l’IP corretto: se le richieste passano attraverso un proxy inverso, un load balancer o una CDN prima di raggiungere il tuo server, i tuoi log predefiniti potrebbero mostrare l’indirizzo del proxy, non quello del crawler. Usa il vero IP del client (da un header di forwarding configurato correttamente) prima di eseguire uno dei due controlli seguenti.

macOS / Linux

# --- Googlebot ---
# 1) Reverse DNS the IP from your logs — must end in googlebot.com, google.com, or googleusercontent.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

# --- Bingbot ---
# Reverse DNS must end in search.msn.com, then forward-confirm back to the IP
host 157.55.39.1
host <the-hostname-it-returned>

Windows

:: Googlebot
nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

:: Bingbot
nslookup 157.55.39.1
nslookup <the-hostname-it-returned>

Se la ricerca inversa non termina con il dominio atteso — googlebot.com / google.com / googleusercontent.com per Google, search.msn.com per Bing — o la ricerca diretta non corrisponde all’IP originale, non è il vero bot, qualunque cosa dica la stringa user-agent.

Confronta con gli intervalli IP pubblicati (su larga scala)

Per verificare molte richieste, salta il DNS per richiesta e confronta l’IP con gli intervalli CIDR pubblicati dal motore. Google pubblica JSON leggibile da macchina:

https://developers.google.com/static/crawling/ipranges/common-crawlers.json
https://developers.google.com/static/crawling/ipranges/special-crawlers.json
https://developers.google.com/static/crawling/ipranges/user-triggered-fetchers.json

Scarica il file, costruisci il set CIDR e testa ogni IP registrato per l’appartenenza. (Ho creato un strumento di verifica IP per Googlebot che fa questo per te.) Bing pubblica anche i suoi intervalli, e Bing Webmaster Tools ha un controllo integrato “Verify Bingbot”.

Checklist di sanità della user-agent

Prima di scrivere regole UA o agire su un bot nei tuoi log:

• Stai prendendo di mira il token in robots.txt (es. Googlebot), non incollando l’intera stringa UA.
• Nessun numero di versione o * nella riga User-agent: — vengono ignorati (Googlebot* non fa nulla).
• Non hai assunto che User-agent: * blocchi AdsBot o Google-Safety — non lo fa; nominali esplicitamente se necessario.
• Se hai bloccato Google-Extended, capisci che influisce solo sull’uso per l’addestramento AI — Googlebot continua a eseguire la scansione e l’indicizzazione per la Ricerca.
• Non stai basando il controllo degli accessi o i contenuti sulla stringa UA grezza — è falsificabile.
• Qualsiasi controllo “è davvero Googlebot?” passa attraverso DNS inverso + diretto (googlebot.com / google.com / googleusercontent.com) o gli intervalli IP pubblicati — Bing tramite search.msn.com.
• Nessuna corrispondenza UA con versione fissa da nessuna parte — la parte Chrome W.X.Y.Z cambia.
• Non stai servendo contenuti diversi a un UA bot rispetto agli utenti (questo è cloaking).

Strumenti per lavorare con gli user agent

Tre dei miei strumenti gratuiti coprono i tre compiti per cui le persone arrivano a questo argomento: confermare che un bot dichiarato sia reale, vedere quali user agent stanno realmente colpendo il tuo sito e verificare cosa possono fare i crawler AI.

Googlebot Verifier — lo strumento per il problema esatto a cui questo articolo torna continuamente: la stringa user-agent è solo testo, quindi non puoi fidarti da sola. Incolla un indirizzo IP dai tuoi log, scegli quale crawler sostiene di essere (Googlebot, Bingbot e altri), ed esegue il controllo DNS inverso + diretto e la corrispondenza con gli intervalli IP pubblicati per te, quindi restituisce un verdetto a livelli — DNS inverso confermato, negli intervalli pubblicati, falsificato, non verificabile o non un crawler noto. Hai un’intera giornata di hit da controllare invece di un singolo IP? Incolla fino a 500 IP o righe di log grezze nella casella batch.

Log File Analyzer — per la domanda “quali user agent stanno realmente eseguendo la scansione del mio sito?” Carica un log di accesso del server (nginx, Apache, IIS/W3C o JSON) e lo analizza interamente nel tuo browser, suddividendo l’attività di scansione per bot e per sezione, segnalando lo spreco di codici di stato, separando i crawler AI dai crawler di ricerca e — la parte che conta di più per questo argomento — eseguendo un report sui falsificatori che nomina le richieste che sostengono di essere il token user-agent di un crawler noto senza l’IP a supporto.

AI-Crawler Access Checker — per la famiglia più recente di token che non si comportano come Googlebot o bingbot. Inserisci un URL e controlla il tuo robots.txt contro ogni token user-agent dei principali crawler AI (GPTBot, ClaudeBot, PerplexityBot, Google-Extended e altri), mostra la regola esatta che vince per ciascuno e segnala se esiste un llms.txt. Utile per confermare che un token come Google-Extended stia facendo ciò che pensi stia facendo — poiché, come spiegato sopra, non ha una propria stringa di richiesta da individuare nei tuoi log.

Prompt per attività con user agent

Due prompt costruiti attorno alle trappole specifiche che questo argomento presenta — falsificazione e sintassi dei token robots.txt — non generico riempitivo “controlla il mio SEO”. Incolla i tuoi dati nei segnaposto.

Prompt 1 — triage di un batch di stringhe user-agent dai tuoi log per segni di falsificazione

Incolla una colonna di stringhe user-agent grezze estratte dal tuo log di accesso (non IP — questo prompt non può verificare l’identità, solo individuare incongruenze nella stringa stessa):

Here is a list of raw User-Agent strings from my server access log, one per
line. For each one:
1. Say which crawler token it claims to be (e.g. Googlebot, bingbot,
   GPTBot), or "no recognizable token" if none.
2. Flag anything internally inconsistent for that claimed crawler — e.g. a
   claimed Googlebot string missing "compatible; Googlebot" or the
   "+http://www.google.com/bot.html" URL, a claimed bingbot string missing
   "bingbot/2.0", or a Chrome version that looks hand-typed rather than a
   real evergreen build.
3. Remind me that this is a text-pattern check only — it cannot confirm
   identity. Real verification requires reverse+forward DNS or matching
   against the crawler's published IP ranges.

[paste user-agent strings here]

Prompt 2 — controlla un robots.txt per errori di corrispondenza dei token

Incolla il tuo file robots.txt completo:

Review this robots.txt file for user-agent token mistakes:
1. Flag any User-agent line that includes a version number or a wildcard
   inside the token (e.g. "Googlebot/1.2" or "Googlebot*") — these are
   ignored, not matched as a family.
2. Check whether User-agent: * is being relied on to block AdsBot-Google,
   AdsBot-Google-Mobile, Mediapartners-Google, or Google-Safety — these
   ignore the wildcard and need their own named group if I want them
   blocked.
3. Note any duplicate groups for the same token that could be merged, and
   confirm token matching here is case-insensitive so I don't need
   near-duplicate groups for casing variants.
4. List which named groups exist and which of Google's/Bing's common
   crawler tokens (Googlebot, Googlebot-Image, Google-Extended, bingbot)
   have no explicit group at all, so I know they're falling through to *.

[paste robots.txt here]

Mettiti alla prova: user agent

Cinque domande rapide sull’header, la stringa, il token e come verificare che un bot sia reale. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

I miei articoli correlati

• Cos’è Googlebot e come funziona? — le stringhe complete dello user agent di Googlebot, i metodi di verifica e il mio strumento di verifica IP.
• Indicizzato, ma bloccato da robots.txt — dove si scontrano il blocco basato sullo user agent e il blocco tramite robots.txt.
• Robots.txt e SEO: tutto quello che devi sapere — come funzionano realmente i gruppi di user agent e le regole.
• Incontra i nuovi crawler web: i bot AI si stanno avvicinando ai bot dei motori di ricerca — il cast in evoluzione degli user agent nei tuoi log.

Ufficiali / standard

• RFC 9110 — HTTP Semantics, §10.1.5 User-Agent — la definizione di base: metadati opzionali forniti dal client.
• RFC 9309: Robots Exclusion Protocol — la definizione formale a livello SHOULD del token di prodotto come sottostringa.
• La Panoramica di crawler e fetcher di Google e Verifica dei crawler Google.
• Chrome Privacy Sandbox — Riduzione dello user agent e User-Agent Client Hints — perché le stringhe dello user agent dei browser stanno diventando più difficili da analizzare e cosa le sostituisce.

Da altri

• John Mueller — Bot che impersonano Googlebot — sullo spoofing e perché il reverse DNS è la risposta.
• MDN — Intestazione User-Agent — la visione dell’intestazione secondo la specifica HTTP.
• r/TechSEO — la community per il debug di crawl e log.
• Web Bot Auth: il nuovo metodo sperimentale di Google per validare i bot autentici (Search Engine Land, Barry Schwartz, maggio 2026) — il miglior riepilogo giornalistico di come funziona la firma crittografica dei bot e cosa significa nella pratica.
• Lo user agent Google-Agent identifica il traffico degli agenti AI nei log del server (Search Engine Land) — copre il nuovo fetcher attivato dall’utente che ignora robots.txt e utilizza Web Bot Auth.
• Google sta testando un nuovo standard di autorizzazione per i bot (Search Engine Journal) — contesto industriale più ampio sullo standard IETF e su quali aziende (Amazon, Cloudflare, Akamai, OpenAI) lo sostengono.
• Annuncio dei futuri user agent per Bingbot (Bing Webmaster Blog, Fabrice Canel, dicembre 2019) — l’annuncio originale del passaggio di Bingbot al rendering basato su Edge prima del lancio del 2022.
• Rilasciata la lista Microsoft degli indirizzi IP di Bingbot (Search Engine Land) — copertura della decisione di Bing di pubblicare gli intervalli IP per la verifica dei bot su larga scala.

Cronologia modifiche