Il 20 marzo 2026 Google ha aggiornato la documentazione sul crawling introducendo Google-Agent, un nuovo user agent destinato agli agenti ospitati sull’infrastruttura Google che navigano il web ed eseguono azioni su richiesta dell’utente. Non è un dettaglio da addetti ai lavori fissati con i changelog. È uno di quei segnali che, se letti bene, spiegano dove sta andando il web e perché chi fa SEO tecnica oggi non può più limitarsi a ragionare solo in termini di Googlebot.

La prima cosa da chiarire è semplice: Google-Agent non è il nuovo Googlebot. Non stiamo parlando del crawler classico della Search che visita i siti per scoperta, scansione e indicizzazione. Google continua a distinguere i common crawlers dai sistemi user-triggered, cioè quelli attivati da una richiesta dell’utente. Google-Agent rientra in questo secondo scenario ed è documentato come sistema usato da agenti Google per navigare il web e compiere azioni su richiesta.

Questa differenza, secondo me, è il punto più importante di tutta la vicenda. Molti si fermeranno al nome del nuovo user agent. Il vero tema, invece, è che Google sta formalizzando una cosa molto più grande: il traffico verso i siti non serve più soltanto a leggere pagine e indicizzarle, ma anche a interagire con il web in modo operativo.

Il punto non è il bot. Il punto è il cambio di modello

Per anni la SEO tecnica ha lavorato su una domanda dominante:
Google riesce a vedere bene questa pagina?

Domanda corretta, ancora oggi fondamentale. Ma non basta più.

Con Google-Agent compare con più chiarezza un’altra domanda:
un sistema Google riesce a usare correttamente questo percorso web per conto dell’utente?

Qui cambia proprio il modello mentale.

Una pagina informativa classica può essere perfetta per Googlebot: HTML pulito, stato 200, rendering corretto, canonical coerente, link interni solidi, niente blocchi inutili. Ma lo stesso sito può essere pessimo per un agente che deve fare qualcosa di più del semplice fetch di contenuto.

Può trovarsi davanti a modali che bloccano il flusso, componenti che compaiono solo dopo eventi strani, filtri AJAX fragili, form multi-step poco robusti, selettori che cambiano stato senza feedback chiaro, percorsi che per un utente umano sono tollerabili ma per un sistema automatizzato diventano disordinati.

Ed è qui che la novità diventa interessante.
Non perché cambi l’algoritmo della Search da un giorno all’altro, ma perché allarga il perimetro del lavoro tecnico.

Perché per un SEO esperto questa notizia vale più di tanti update “rumorosi”

Lo dico in modo netto: questo tipo di aggiornamento, per chi lavora davvero sui siti, conta spesso più di tanti presunti update che generano rumore su LinkedIn per due giorni e poi spariscono.

Perché qui non siamo nel territorio delle ipotesi da forum. Siamo davanti a un cambiamento documentato che tocca tre aree molto concrete: lettura dei log, gestione del traffico automatizzato e progettazione tecnica dei flussi web.

Chi fa SEO “da dashboard” forse non percepisce subito la portata della cosa.
Chi invece lavora con log file, crawling reale, WAF, CDN, rendering e architetture, capisce subito che questa introduzione sposta il discorso su un livello più maturo.

Google, in sostanza, sta dicendo: non esiste un solo modo in cui i nostri sistemi entrano nei siti. E se non distingui questi modi, inizi a leggere male i dati.

Dove si vede davvero il cambiamento

La prima area in cui questa novità conta è la log analysis. Per troppo tempo molti team hanno usato classificazioni rozze: Googlebot, altri bot, utenti. O al massimo: Google, Bing, bot vari. Questa impostazione oggi è troppo povera. Google documenta ormai categorie diverse di requesters e Google-Agent va letto dentro questa evoluzione.

Se nei log compare traffico Google-Agent e tu lo butti nel calderone “Googlebot”, stai facendo un errore di interpretazione. Rischi di attribuire al crawling classico comportamenti che magari appartengono a richieste attivate da utenti o da sistemi agentici.

Esempio pratico: grande e-commerce con filtri e comparatori

Immagina un e-commerce con categorie complesse, filtri dinamici, selettori di taglia, comparazione prodotti, configuratori e disponibilità gestite in JavaScript.

Se un team vede accessi Google su:

• URL filtrate
• step intermedi di comparazione
• componenti client-side
• percorsi che non sono il classico contenuto editoriale

potrebbe cadere nell’errore di dire:
“Googlebot sta andando più a fondo, forse è cambiato qualcosa nel crawling.”

Non è necessariamente così.

Se una parte di quel traffico è invece riconducibile a Google-Agent, cambia completamente la lettura. Non stai osservando solo scansione per l’indice, ma interazioni attivate in un altro contesto. Questo significa che la risposta tecnica non è “ottimizziamo il crawl budget”, ma magari “miglioriamo la robustezza del percorso” oppure “separiamo meglio ciò che deve essere accessibile da ciò che genera rumore o stati inutili”.

Ed è un’enorme differenza.

La seconda area critica è la verifica del traffico

Su questo bisogna essere molto chiari: la user agent string da sola non basta.

Google continua a ricordare che le stringhe user agent possono essere falsificate e che il traffico va verificato con metodi più affidabili, come reverse DNS / forward DNS o controllo degli IP ranges ufficiali. Nella documentazione di verifica Google include anche gli elenchi per i sistemi user-triggered, compreso user-triggered-agents.json.

Questo passaggio è fondamentale perché vedo ancora troppi contesti in cui si ragiona così:
“C’è scritto Google, quindi è Google.”

No. Non funziona così.

Esempio pratico: sito editoriale con bot protection aggressiva

Pensa a un publisher con paywall leggero, overlay pubblicitari, protezioni anti-scraping e WAF abbastanza severo.

Se il team sicurezza riconosce bene Googlebot ma non ha ancora aggiornato le regole per distinguere Google-Agent, può succedere una cosa molto comune: richieste legittime vengono trattate come sospette. Scattano challenge, blocchi, limitazioni di sessione, falsi positivi.

A quel punto il SEO vede traffico strano, il sistemista vede anomalie, il publisher vede comportamenti non lineari e nessuno capisce bene dove sia il problema.

La verità è che il problema non è nel bot. È nella classificazione sbagliata del bot.

Su questo ho un’opinione molto semplice: nel 2026 chi gestisce siti strutturati non può più basarsi quasi solo sulla user agent string per prendere decisioni operative serie.

Robots.txt resta importante, ma non basta più come chiave di lettura generale

Un altro aspetto che secondo me molti sottovaluteranno è questo: la cultura SEO si è formata per anni attorno al binomio crawler + robots.txt.

Quel modello non sparisce, ma oggi non è più sufficiente per spiegare tutta la relazione tra sito e sistemi Google.

Google distingue chiaramente il crawling automatico dai fetcher e dai sistemi user-triggered. In più, nella documentazione generale, spiega che i user-triggered fetchers spesso non si comportano come il crawling classico rispetto a robots.txt, proprio perché la richiesta nasce da un’azione dell’utente.

Questo non significa che robots.txt improvvisamente non conti più. Significa una cosa diversa e più importante: non puoi più usare solo robots.txt per interpretare tutti gli accessi Google al sito.

Esempio pratico: comparatore assicurativo

Un comparatore assicurativo può avere:

• pagine editoriali perfette per la Search
• strumenti di preventivazione
• form multi-step
• risultati generati in modo dinamico
• schermate di riepilogo
• sezioni che dipendono da interazioni utente

Se ti limiti a pensare in termini di robots.txt, stai guardando solo una fetta della questione.
Il problema vero può essere altrove: flussi fragili, chiamate asincrone poco stabili, gestione stato poco chiara, componenti che non restituiscono segnali robusti, regole anti-bot troppo aggressive, rendering che si rompe in alcuni passaggi.

Questa è la ragione per cui continuo a dire che Google-Agent non è una notizia da “SEO news”, ma una notizia da SEO tecnico che lavora insieme a sviluppo e infrastruttura.

Il collegamento con Project Mariner chiarisce il contesto

Google cita come esempio Project Mariner, e questo basta già a far capire il quadro. Mariner è stato presentato da Google DeepMind come progetto orientato ad agenti in grado di osservare il browser, pianificare passaggi e aiutare a completare task sul web.

Per me questo è il punto che spiega meglio la direzione.

Non siamo più soltanto nel modello “motore che trova una risposta”.
Siamo anche nel modello “sistema che deve muoversi nel web per ottenere un risultato”.

E quando il valore passa dal contenuto statico all’esecuzione di un flusso, cambiano anche le priorità tecniche.

Un sito può essere ottimo da leggere e pessimo da usare.
Per un utente umano, magari, quel pessimo si compensa con pazienza, esperienza e capacità di adattamento. Per un agente, no.

La parte più interessante: non solo accesso, ma fiducia

Dentro la documentazione su Google-Agent c’è anche una nota che secondo me anticipa un passaggio ancora più importante: Google dice di star sperimentando il protocollo web-bot-auth, usando l’identità https://agent.bot.goog.

Questo tema va seguito molto da vicino. Perché finora il web ha gestito i bot con strumenti spesso abbastanza grezzi: stringhe user agent, IP, reverse DNS, challenge, CAPTCHA, regole euristiche.

Quel mondo funziona ancora, ma sempre peggio, man mano che cresce il numero di soggetti automatizzati che hanno un motivo legittimo per entrare nei siti.

Secondo me il passaggio vero dei prossimi mesi sarà questo: non limitarsi a capire se una richiesta è automatizzata, ma capire chi è davvero il soggetto automatizzato e quale livello di fiducia merita.

Per i siti enterprise è enorme.

Vuol dire che la governance del traffico non sarà più solo “blocca o lascia passare”.
Sarà sempre più qualcosa di simile a: riconosci, verifica, attribuisci fiducia, concedi accesso in base al contesto.

Questa, a mio avviso, è una trasformazione molto più grossa del singolo user agent.

Dove vedo i primi impatti reali nei progetti

Nei grandi e-commerce vedo impatti soprattutto su varianti, filtri, comparazioni, configuratori, motori interni e moduli che oggi vengono progettati pensando quasi solo all’utente umano e solo in seconda battuta alla robustezza tecnica del percorso.

Nel travel vedo un problema ancora più chiaro. Molti motori di prenotazione funzionano, ma tecnicamente sono un groviglio di script, stati lato client, refresh parziali, blocchi temporanei e dipendenze che rendono difficile l’attraversamento del flusso. Un agente che deve cercare una soluzione o seguire un task potrebbe mettere in evidenza tutti questi limiti.

Nel finance e nell’insurance il tema è fortissimo. Precompilazioni, preventivi, wizard, form annidati, percorsi che cambiano a seconda degli input: tutto questo oggi è spesso ottimizzato male anche per gli umani, figuriamoci per sistemi automatizzati che devono agire in modo affidabile.

Nell’editoria premium il problema sarà leggere correttamente il traffico e capire dove finisce la normale interazione dei sistemi Google e dove iniziano le aree che il publisher vuole proteggere in modo diverso.

La mia opinione personale, senza girarci intorno

La mia lettura è questa: molti minimizzeranno Google-Agent perché non vedono un impatto diretto e immediato sulle SERP. Secondo me è un errore.

Non perché domani cambierà il ranking, ma perché questa novità dice una cosa molto concreta: la SEO tecnica non può più vivere chiusa nel recinto dell’indicizzazione.

Chi continua a ragionare solo in termini di crawl budget, robots.txt e pagine indicizzabili farà sempre più fatica a leggere il mondo reale. Sono temi ancora fondamentali, ma non bastano più da soli a descrivere la complessità del traffico e delle interazioni moderne.

Questa è una novità che interessa soprattutto i SEO tecnici veri, quelli che leggono log, parlano con i sistemisti, capiscono il rendering, discutono con il team sicurezza e non si accontentano di guardare Search Console.

Se devo dirla in modo ancora più diretto:Google-Agent non cambia il mestiere di chi fa SEO superficiale. Cambia il mestiere di chi la SEO tecnica la fa sul serio.

Cosa farei subito, in modo pragmatico

La prima cosa che farei è rivedere la classificazione dei log. Non tra un mese: subito. Google-Agent va separato da Googlebot e dal resto del traffico Google, altrimenti i dati restano ambigui.

Poi parlerei con chi gestisce sicurezza, CDN, WAF e bot protection. Perché se il sito è protetto in modo serio, questo tema non è “solo SEO”. È un punto di contatto tra SEO tecnico e infrastruttura.

Poi testerei i percorsi realmente sensibili del sito:

schede prodotto con varianti, configuratori, motori interni, form multi-step, sezioni caricate in JS, componenti con overlay, interfacce che cambiano stato senza una logica solida.

Infine cambierei proprio la domanda guida del lavoro tecnico.

Non solo “questa pagina è leggibile e indicizzabile?”, ma anche “questo percorso è robusto, chiaro e attraversabile per soggetti legittimi che non stanno semplicemente leggendo HTML?”

Questa, secondo me, è la domanda giusta da portarsi avanti da ora in poi.

Approfondimenti

Google Search Central – Changelog documentazione crawling, update del 20 marzo 2026 su Google-Agent. 

Google Search Central – Google user-triggered fetchers, scheda ufficiale di Google-Agent e nota su agent.bot.goog.

Google Search Central – Overview of Google crawlers and fetchers.

Google Search Central – Verify Google crawler and fetcher requests.

Google DeepMind – Project Mariner.