SERP e AI: la tua visibilità oggi passa due volte da Googlebot

Un ragnetto digitale che passa, legge il codice e se ne va. Per molto tempo Googlebot è stato raccontato così, come una presenza tecnica quasi invisibile che entrava in gioco solo quando una pagina spariva, tardava a comparire in SERP o smetteva di portare traffico. Bastava nominarlo per ridurre tutto a una formula semplice: il bot è passato, il bot non è passato, il bot ha letto male.

Oggi quella storia non tiene più. Googlebot continua a essere il crawler della Ricerca, ma lavora dentro un web che ha cambiato struttura, peso e ritmo. Siti mobile-first, frontend pesantissimi, rendering delicati, risorse distribuite su più domini, documenti che smettono di coincidere con un HTML lineare e sono un’orchestra di chiamate di rete. Anche la posta in gioco si è allargata. La scansione continua a servire per l’indice della SERP, ma oggi è la porta d’ingresso anche per AI Overview, AI Mode e le risposte generative, che nascono da quell’indice. Quando Googlebot legge male una pagina, il danno non si ferma ai dieci link blu. Sei più che invisibile.

Che cos’è Googlebot (e perché il nome inganna)

Googlebot è il crawler con cui Google Search scopre e recupera le pagine del web. È lo strumento attraverso cui miliardi di URL diventano materiale indicizzabile, è la prima mano che passa sui tuoi contenuti quando pubblichi qualcosa di nuovo, è il filtro tecnico che decide se il tuo lavoro entra nella conversazione della Ricerca o resta fuori. Tutto quello che chiamiamo SEO tecnica nasce dal tentativo di parlare la sua lingua.

Ma intorno al tema resta ancora una confusione che manda fuori asse molte analisi SEO, perché il suo nome finisce per coprire tutto: scansione, indicizzazione, ranking, pagine che non emergono, contenuti che non tengono. Il problema è proprio questo schiacciamento. Il crawler presidia il primo tratto della catena. L’indicizzazione arriva dopo. Il ranking arriva dopo ancora. Una pagina può essere raggiunta e recuperata senza guadagnare spazio nell’indice. Può entrare in indice e restare debole in SERP. Può anche succedere il contrario: il contenuto sembra valido al team, ma Google parte da una versione della pagina molto più povera di quella che avete davanti nel browser.

E c’è un altro aspetto, che è più di una semplice curiosità tassonomica. “Googlebot” è un misnomer storico. All’inizio degli anni Duemila Mountain View aveva un solo prodotto e un solo crawler, ma oggi Googlebot è solo uno degli utenti di quella che funziona come una piattaforma centralizzata di crawling: un’infrastruttura condivisa che scarica pagine per Search, Shopping, AdSense e decine di altri servizi, ciascuno con il proprio user agent, le proprie regole e i propri limiti. Quando vedi “Googlebot” nei log del tuo server, stai guardando Google Search. Quando vedi altri nomi, sono altri prodotti che passano dallo stesso sistema di tubi.

Questo passaggio cambia il modo in cui conviene leggere l’infrastruttura del sito. Il crawler della Ricerca resta il riferimento principale, ma non è più l’unico client Google che tocca le tue risorse. Entrano in gioco prodotti diversi, user agent diversi, limiti diversi, regole diverse. La scansione, da sola, non basta più come immagine sintetica del problema. Serve distinguere chi sta arrivando, perché sta arrivando e che cosa può davvero fare con ciò che trova.

Come si è evoluto Googlebot

Il mestiere di Googlebot è rimasto riconoscibile: scoprire risorse, raggiungerle, recuperarle. Il web su cui quel lavoro si appoggia, invece, è cambiato a fondo. Per molto tempo il crawler ha incontrato più spesso documenti compatti, con una distanza più corta tra codice disponibile e contenuto utile. Oggi attraversa pagine che distribuiscono l’informazione tra HTML iniziale, JavaScript, file esterni, componenti caricati in più fasi e passaggi di rendering che allungano la ricostruzione del documento. Google continua a documentare Googlebot come crawler della Search, ma dentro un quadro tecnico più articolato, con varianti distinte e limiti di recupero molto più espliciti di quanto accadesse anni fa.

Quando il contenuto utile si distribuisce su più livelli, il recupero diventa molto più esposto alla qualità tecnica con cui la risorsa viene servita. Un contenuto valido sul piano editoriale può perdere forza prima della SERP, semplicemente perché il documento lo consegna tardi, lo disperde oppure lo rende dipendente da passaggi che rendono la lettura meno stabile.

Non sprecare il tempo di Googlebot

Analizza il tuo sito con il SEO Spider di SEOZoom e verifica che il crawler trovi davvero quello che ti serve indicizzato

Attiva la tua prova gratis di SEOZoom

C’è poi uno spostamento che pesa in modo concreto sulla diagnosi tecnica. La vista principale è mobile. Googlebot Smartphone è la variante di riferimento per la maggior parte dei siti, in coerenza con il mobile-first indexing, mentre la lettura desktop resta disponibile ma senza occupare lo stesso ruolo. Qui cambia molto più dello user agent. Cambia la prospettiva con cui vanno giudicati ordine delle informazioni, struttura del documento, caricamento delle risorse e accessibilità del contenuto. Una pagina può sembrare solida in desktop e restituire molto meno nella forma con cui Google la incontra più spesso.

La vecchia metafora dello spider che descriveva il bot conserva una sua utilità introduttiva. Rende bene il gesto di base del crawling: una pagina porta a un’altra, i link aprono percorsi, la mappa delle risorse cresce passo dopo passo. Sul piano tecnico, però, oggi aiuta poco. Un documento contemporaneo può affidare parti centrali del contenuto a file esterni, richieste aggiuntive e fasi di rendering. Googlebot continua a fare il suo mestiere, ma incontra più attriti e dipende molto di più dalla qualità del documento che riceve.

I diversi Googlebot e gli altri crawler di Google

Chiamare tutto “Googlebot” semplifica troppo e, sul piano tecnico, fa perdere precisione proprio dove serve di più. Google usa più client per recuperare risorse sul web e li distingue in base al compito che svolgono. Nella documentazione ufficiale separa i common crawlers, usati per i prodotti di ricerca, dagli special-case crawlers, legati a prodotti specifici, e dai user-triggered fetchers, cioè i client avviati da un’azione diretta dell’utente. Googlebot appartiene al primo gruppo. È il crawler generico della Search, quello che entra in gioco quando Google scopre e recupera contenuti dal web per i propri sistemi di ricerca.

La distinzione pesa molto più nei fatti che nelle definizioni. Basta guardare i log per capirlo. Un accesso che arriva da Google non racconta sempre la stessa storia: può essere scansione ordinaria della Search, può essere un fetch legato a una funzione specifica, può essere una richiesta generata da un’azione dell’utente. Mettere tutto sotto il nome Googlebot confonde il significato tecnico delle visite e rende più debole anche la diagnosi.

Le tre famiglie di crawler di Google

La documentazione ufficiale classifica i crawler di Google in tre categorie, ed è utile tenerle presenti perché ciascuna si comporta in modo diverso con il tuo sito.

I crawler comuni sono quelli che usano l’indice di Search e gli altri servizi principali. Googlebot è il più noto, ma non è solo. Rispettano sempre le regole del robots.txt, e Google ne pubblica l’elenco degli intervalli IP in un file specifico (googlebot.json) che puoi usare per verificare l’identità di chi sta scansionando. Se vuoi controllare se una richiesta è davvero di Googlebot o è uno spoofing, questo è il tuo riferimento.

I crawler per casi speciali lavorano per prodotti specifici con accordi dedicati: AdSense e AdsBot controllano la qualità degli annunci, Googlebot-Image gestisce Google Immagini, Googlebot-Video i video, Googlebot-News le notizie. Alcuni rispettano il robots.txt, altri no, perché il loro comportamento è regolato da contratti d’uso del servizio associato. La loro lista IP è in un file separato (special-crawlers.json) che non coincide con quello dei crawler comuni.

I fetcher attivati dall’utente sono la terza categoria e la più sottovalutata. Sono gli strumenti che recuperano una pagina perché una persona lo chiede: Google Site Verifier quando un utente avvia una verifica, i sistemi che recuperano feed esterni su richiesta di applicazioni ospitate su Google Cloud, il Controllo URL di Search Console. Siccome il fetch è innescato da un utente, questi strumenti ignorano le regole del robots.txt. Non è una violazione, è la logica del servizio: l’utente ha chiesto di vedere quella risorsa, e il fetcher va a recuperarla per lui.

Googlebot desktop e mobile

Dentro Googlebot-per-Search convivono due facce: Googlebot Smartphone, che simula un utente con un dispositivo mobile, e Googlebot Desktop, che simula la navigazione da computer. La distinzione è tecnica e utile da conoscere per leggere i log, ma la partita è già chiusa: oggi la quasi totalità delle richieste di scansione passa dalla versione mobile. Il mobile-first non è più una transizione in corso, è lo stato di fatto della Ricerca.

Un dettaglio che vale la pena esplicitare: i due sottotipi condividono lo stesso token nel file robots.txt. Non puoi usare robots.txt per dire a Googlebot Mobile una cosa e a Googlebot Desktop un’altra. Se vuoi comportamenti diversi, l’unico modo è riconoscere l’user agent dall’intestazione HTTP e agire a livello applicativo. E lì la soglia che separa un comportamento lecito dal cloaking diventa molto più sottile.

Come funziona davvero Googlebot

Il lavoro di Googlebot si articola in passaggi distinti, e confonderli è uno degli errori più frequenti.

La scansione non è l’indicizzazione. L’indicizzazione non è il ranking. Il rendering non è la scansione. Ogni tappa ha regole proprie, e quando una pagina non compare nei risultati il primo esercizio è capire a quale di queste tappe è fermata.

Il crawling per scoprire e raggiungere

Il crawling è la fase di scoperta. Googlebot parte da un elenco di URL noti e lo espande continuamente incorporando nuove risorse che trova seguendo i link interni ed esterni, leggendo le sitemap XML che hai dichiarato in Search Console o inserito nel robots.txt, raccogliendo le segnalazioni esplicite dei proprietari dei siti. Non scansiona ogni angolo del web allo stesso modo: decide cosa visitare e quanto spesso in base a una combinazione di fattori che comprende autorevolezza del dominio, frequenza di aggiornamento, capacità del server di reggere il carico, qualità delle risorse già indicizzate.

Tre comportamenti valgono la pena conoscere bene. Il primo è che Googlebot rallenta automaticamente quando il tuo server fatica. Se le risposte diventano lente o si presentano errori, il crawler abbassa il ritmo per non peggiorare l’esperienza degli utenti. È un meccanismo di rispetto, non di punizione — ma l’effetto per te è che un server debole si traduce in una scansione meno profonda. Il secondo è che i siti aggiornati di frequente e autorevoli vengono rivisitati più spesso, mentre quelli statici scivolano in fondo alla coda. La freshness non è una metrica astratta, è un segnale concreto che alimenta la frequenza di crawling. Il terzo è che le pagine orfane, cioè quelle non linkate da nessun’altra del sito, tendono a non essere raggiunte. Se non appari nell’architettura interna, difficilmente entri nell’indice.

Il Web Rendering Service e la realtà dei siti moderni

Una volta che il crawler ha recuperato i bytes di una pagina, passa la palla a un altro componente: il Web Rendering Service, o WRS. È il modulo che esegue JavaScript, processa CSS, gestisce le chiamate XHR e ricostruisce lo stato finale della pagina in modo simile a un browser moderno. È la parte che permette a Google di vedere davvero quello che un utente vede, non solo l’HTML di partenza.

Qui entra una delle precisazioni più importanti che Google ha formalizzato di recente: il WRS opera in modalità stateless. Cancella local storage e session tra una richiesta e l’altra, non mantiene cookie tra i rendering, non conserva memoria di quello che è successo nella visita precedente. Se il tuo sito dipende da interazioni stateful per mostrare contenuti — accessi, preferenze salvate, stati di carrello, flussi multi-step — devi mettere in conto che il WRS lavora ogni volta da zero, come se fosse la prima volta che apre la pagina. I contenuti che compaiono solo dopo un’interazione utente, o che dipendono da stati memorizzati localmente, rischiano di restare invisibili al sistema che dovrebbe indicizzarli.

C’è un altro punto tecnico che pesa: il WRS può eseguire soltanto il codice che Googlebot è riuscito a scaricare. E qui il cerchio si chiude con il limite di cui parliamo tra un attimo. Se il tuo JavaScript critico sta oltre la soglia di fetch, non viene nemmeno eseguito. Non è un problema di rendering, è un problema a monte.

La relazione tra crawling, indicizzazione e ranking

C’è ancora grande confusione sulle tre fasi in cui si scompone la classica Ricerca Google.

Una pagina può essere scansionata e non indicizzata, e questo non è un bug ma una decisione del sistema. Googlebot recupera il contenuto, il sistema di indicizzazione lo analizza e può decidere di scartarlo per molte ragioni: duplicazione con un’altra pagina già nell’indice, qualità giudicata insufficiente, conflitto con segnali canonical, direttive noindex esplicite, intento non abbastanza differenziato rispetto ad altri contenuti del sito.

La conseguenza pratica è che “è stata scansionata” non equivale a “è nell’indice”, e “è nell’indice” non equivale a “viene mostrata agli utenti”. Tre soglie diverse, tre tipi di problemi possibili, tre tipi di diagnosi. Quando una pagina non porta traffico, la prima domanda non è “Googlebot è passato?” ma “a quale delle tre soglie si è fermata?”. Il Controllo URL di Search Console ti dà la risposta in pochi secondi, ed è il primo posto da guardare.

Il ranking è ancora un’altra cosa. Googlebot fornisce la materia prima su cui lavorano i sistemi di ranking, ma non assegna posizioni. I ranking systems di Google — quelli che decidono l’ordine dei risultati per una query — usano l’indice costruito a partire dal lavoro del crawler, ma operano in una fase successiva, con segnali e logiche proprie. Martin Splitt lo ha riassunto con un’immagine che rende bene il punto: Googlebot è il bibliotecario che cataloga i libri e ne scrive l’indice, il ranking è chi decide quale libro suggerire a chi chiede un consiglio.

La distinzione conta perché orienta le priorità. Se una pagina non è scansionata, il problema non è di ranking, è a monte. Se è scansionata ma non indicizzata, il problema è di qualità o coerenza, non di posizionamento. Se è indicizzata ma non si posiziona, allora è il momento di guardare i fattori di ranking. Saltare queste domande preliminari è il motivo per cui tante analisi SEO partono dal posto sbagliato.

Rendering, HTML iniziale e contenuto finale

Tra l’HTML iniziale e la pagina finale che vedi nel browser si è aperta da tempo una distanza che, in molti casi, pesa più del contenuto stesso. Googlebot recupera una prima versione della risorsa, poi il sistema di rendering affronta la parte che richiede elaborazione aggiuntiva. Più la pagina affida al rendering il compito di far emergere il contenuto importante, più cresce il rischio che la lettura del documento parta da una base povera, ritardata o dispersiva.

L’HTML iniziale continua quindi a contare molto. Quando struttura, segnali chiave e nucleo informativo sono leggibili presto, il recupero regge meglio. Quando il documento iniziale è carico di codice accessorio o rimanda troppo avanti l’informazione che conta, lo scarto si allarga. Questa è una delle ragioni per cui pagine apparentemente corrette possono restituire risultati deboli nella Search: il contenuto c’è, ma non arriva ai sistemi di Google nelle condizioni migliori.

Come Googlebot accede ai contenuti oggi

Ogni cliente della piattaforma di crawling di Google ha i suoi limiti operativi, e quelli di Googlebot-per-Search sono diventati materia pubblica. Il numero che devi tenere a mente è uno solo: 2MB per singolo URL HTML, inclusi gli header HTTP. Oltre questa soglia, il contenuto non viene rifiutato — e questa è la parte importante. Googlebot tronca il download esattamente al taglio e tratta i byte scaricati come se fossero il file completo. I byte che stanno oltre non vengono scaricati, non vengono renderizzati, non vengono indicizzati. Per Google, quei byte non esistono.

Una pagina può caricarsi senza problemi, apparire completa e continuare a portarsi dietro un limite tecnico serio. I segnali decisivi possono stare troppo in basso, una parte rilevante dell’informazione può arrivare tardi, il markup può gonfiarsi di materiale accessorio, la struttura del documento può costringere il crawler a attraversare molto rumore prima di arrivare al punto. In casi del genere Google parte da un materiale meno utile di quanto il team immagini. L’effetto non si presenta sempre come errore visibile. Più spesso riemerge dopo, con pagine che faticano a consolidare, contenuti che non spingono o segnali che sembrano non reggere.

Googlebot lavora quindi per recupero effettivo della risorsa, non per “idea” della pagina. Richiede l’URL, riceve la risposta del server, scarica la risorsa principale entro i limiti previsti, individua i riferimenti ai file esterni e li recupera a parte. Il resto del processo parte da lì.

Due precisazioni rapide prima di andare avanti. Il limite si applica ai dati non compressi: un bundle JavaScript che pesa 800KB in gzip può gonfiarsi oltre i 2,5MB una volta decompresso, e tu l’avevi già superato senza accorgertene. Per i PDF la soglia resta molto più alta, 64MB, a conferma che Google continua a considerare i documenti statici come fonti informative dense. Per tutti gli altri crawler di Google che non hanno un limite specifico dichiarato, il default è 15MB: un valore che molti articoli ancora citano come se fosse quello di Googlebot, ma non lo è più.

C’è poi una cosa che salva la giornata a tanti siti: le risorse esterne hanno un contatore separato. Ogni file CSS referenziato nell’HTML, ogni bundle JavaScript esterno, ogni risorsa che il WRS deve recuperare per completare il rendering, ha il proprio limite di 2MB indipendente. Non si sommano, non erodono il budget dell’HTML padre. Questa è la leva operativa più importante che ti lascia Google: spostare codice dall’inline all’esterno non è più solo una best practice di performance, è un modo concreto per stare dentro il perimetro della scansione.

Perché Google ha messo nero su bianco questo limite

Il limite di 2MB non è una novità tecnica improvvisa — era già in vigore, solo non dichiarato pubblicamente con questa nettezza. La vera novità è la chiarezza con cui Google l’ha formalizzata. E la formalizzazione nasce in un contesto preciso, che vale la pena capire perché condiziona le scelte che ti aspettano.

La lettura economica è la più immediata: Google sta scaricando sui publisher l’onere di contenere i costi infrastrutturali. Far girare AI Overview, AI Mode e i sistemi di risposta generativa costa molto più di una ricerca tradizionale, e ridurre dell’86,7% la capacità di download del crawler comprime sensibilmente la bolletta di Mountain View. È un trasferimento di costo: prima pagavi con il tuo server il carico delle scansioni, ora paghi con il tuo tempo di sviluppo per ripulire il codice. La posizione di totale dominio di Google permette di imporre la mossa senza conseguenze — i dati di Cloudflare dicono che Googlebot scansiona il web con una frequenza quasi 5 volte superiore a Bing e 3,2 volte superiore a OpenAI. Non puoi permetterti di non adeguarti.

Il limite è meno teorico di quanto sembri. Web Almanac 2025 mostra che la homepage mediana pesa 2,86 MB su desktop e 2,56 MB su mobile; sulla stessa homepage mediana si contano 80 richieste su desktop e 75 su mobile. In altre parole, il nuovo perimetro dei 2 MB non si misura contro pagine eccezionali, ma dentro un web in cui peso e frammentazione delle risorse sono ormai condizioni molto diffuse

C’è però una seconda lettura, più “provocatoria” e più “visionaria”: la “dieta” non serve solo a risparmiare. Serve ad alimentare i sistemi RAG con dati più puliti. I sistemi di retrieval-augmented generation, che sono il motore dietro AI Overview e AI Mode, hanno bisogno di precisione e rapidità per citare le fonti senza allucinare. Una pagina satura di commenti sviluppatori, JavaScript inline, CSS duplicato, markup ridondante è rumore che rende più costoso per l’AI estrarre un’informazione verificabile. Tagliare il fetch a 2MB costringe i publisher a rendere il proprio codice più leggibile per la macchina che deve sintetizzarlo. È un indirizzo strategico sul web che verrà, non solo una manovra di budget.

Cosa significa in pratica per il tuo sito

La stragrande maggioranza dei siti non si avvicinerà mai alla soglia. La mediana di una pagina HTML non compressa è intorno ai 20KB, e anche pagine ricche di contenuto restano ampiamente sotto il limite. Ma se gestisci un ecommerce con mega-menu che elencano migliaia di link, un news site con template complessi, un’applicazione web che accumula JavaScript inline, un blog dove il tema grafico ha deciso di mettere tutto nello stesso file, è il momento di misurare.

Le azioni che contano sono poche e specifiche.

1. Sposta gli elementi critici in alto nel documento: tag title, meta, canonical, dati strutturati JSON-LD, heading principali, contenuto testuale primario. Se Googlebot si ferma al taglio, questi sono i segnali che non puoi permetterti di perdere. Una buona regola operativa è concentrarli entro i primi 500KB di codice non compresso.
2. Atomizza JavaScript e CSS: distribuisci le funzionalità su file esterni più piccoli invece di un singolo bundle gigante che rischia il troncamento. Ogni file esterno ha il proprio budget di 2MB.
3. Elimina il rumore inline: commenti degli sviluppatori, metadati ridondanti, script di tracciamento duplicati, dati URI pesanti (come immagini in base64 incorporate nell’HTML — contribuiscono eccome al peso del file).
4. Verifica le dimensioni reali: Chrome DevTools nella scheda Network ti mostra il peso del documento principale, Screaming Frog ordina le pagine per size, Google PageSpeed Insights segnala le risorse con payload eccessivi.

Che cosa Googlebot riesce a leggere bene, leggere male o non leggere affatto

Googlebot non lavora sulla qualità potenziale della pagina, ma sul materiale che riesce davvero a recuperare. Per questo una risorsa può sembrare forte al team editoriale, coerente sul piano SEO on page e perfettamente leggibile in browser, poi indebolirsi nel passaggio tecnico. Le criticità che pesano di più si concentrano in tre aree.

• I problemi che nascono dalla struttura della pagina

Una pagina lunga non è automaticamente difficile da leggere per Googlebot. Lo diventa quando il documento diluisce troppo ciò che conta. Markup ridondante, componenti ripetuti, blocchi secondari che precedono il nucleo informativo, codice accessorio e segnali decisivi collocati troppo in basso allargano la distanza tra la pagina che hai costruito e la parte che Google riesce a usare con più continuità. Qui rientrano anche errori che spesso passano inosservati perché la pagina “funziona”: dati strutturati inseriti tardi, canonical che si perdono dentro un file gonfio, blocchi centrali della risposta spinti dopo aperture troppo lunghe, template che pesano più del contenuto.

• I problemi che nascono dal server

Prima del contenuto, Googlebot incontra la qualità della risposta tecnica. Status code incoerenti, redirect chain, tempi di risposta instabili, errori intermittenti, risorse che si caricano in modo discontinuo o server che faticano a reggere le richieste alterano il recupero già alla base. In questi casi la pagina può avere un buon contenuto e una struttura sensata, poi arrivare al crawler in condizioni peggiori di quelle immaginate dal team. Il difetto nasce nel trasporto del contenuto: risposta lenta, risorsa instabile, file esterni consegnati male, redirect inutili che consumano passaggi.

• I problemi che nascono da un frontend troppo opaco

Il frontend moderno apre molte possibilità, ma può diventare un ostacolo quando il contenuto utile dipende da passaggi troppo fragili. Script che reggono quasi tutta la resa, componenti caricati tardi, parti decisive del testo che emergono solo dopo più richieste, interfacce che privilegiano l’effetto rispetto alla leggibilità del documento rendono il recupero meno affidabile. Google chiarisce che CSS e JavaScript vengono richiesti separatamente e che il rendering introduce un ulteriore livello di complessità nella ricostruzione della pagina. Quando il frontend diventa troppo opaco, l’HTML iniziale parte più povero, il rendering pesa di più e la qualità del recupero dipende da una catena tecnica più lunga. Nei casi migliori questo rallenta. Nei casi peggiori riduce davvero il materiale utile che arriva ai sistemi successivi della Search.

Googlebot e l’universo AI: perché la scansione oggi vale doppio

Per anni il rapporto tra Googlebot e la tua visibilità si è misurato su una sola dimensione: essere nell’indice della Ricerca. Oggi ce n’è una seconda, e molti non l’hanno ancora inquadrata bene.

Le superfici AI di Google — AI Overview nella SERP, AI Mode come modalità di ricerca conversazionale — non sono un canale parallelo, sono costruite sopra l’indice di Search, quello che Googlebot alimenta con il suo lavoro di scansione. Google lo dice nella documentazione senza ambiguità: “AI is built into Search and integral to how Search functions, which is why robots.txt directives for Googlebot is the control for site owners to manage access to how their sites are crawled for Search”. Tradotto: il controllo che hai sulle tue apparizioni nelle esperienze AI di Google passa dal governo del rapporto con Googlebot, non da un canale separato.

La conseguenza è pesante. Se blocchi Googlebot — via robots.txt, via infrastruttura, via errori tecnici che impediscono la scansione — non esci solo dai dieci link blu. Esci anche dalle risposte generate. I contenuti del tuo sito non vengono più usati come fonte per le sintesi, il tuo brand sparisce dai riferimenti citati, la tua entità non viene presa in considerazione quando l’utente chiede qualcosa sul tuo ambito. Sei più che invisibile: sei fuori dal materiale con cui la macchina costruisce la verità che l’utente vede.

Google-Extended: cosa controlla davvero (e cosa no)

Qui nasce una confusione che vale la pena pulire. Una cosa è l’addestramento dei modelli. Un’altra è il recupero delle informazioni fresche dentro le esperienze AI della Ricerca

Già nel 2023 Google ha introdotto un token separato chiamato Google-Extended, aggiornato poi quando Bard è diventato Gemini, che permette di dichiarare nel robots.txt il consenso all’uso dei propri contenuti per allenare i modelli di intelligenza artificiale di Google — Gemini Apps e le API generative di Vertex AI. È un controllo sull’opt-out dal training, non un controllo sulla scansione operativa.

Bloccare Google-Extended ha un effetto preciso e limitato: i tuoi contenuti non entrano nei dataset di addestramento dei modelli AI Google. Non tocca il ranking, non tocca la scansione per Search, non tocca l’inclusione nelle funzionalità generative come AI Overview. Quelle passano tutte da Googlebot. Chi pensa di governare la propria visibilità AI bloccando Google-Extended si sta fermando al pedaggio sbagliato: sta solo dicendo a Google di non usare i suoi testi per l’addestramento futuro, mentre continua a essere scansionato, indicizzato e citabile dalle risposte generative.

La separazione è netta e ha una sua logica. Training e grounding sono processi diversi: il primo è l’addestramento del modello con dati storici, il secondo è il recupero di informazioni fresche dall’indice per costruire una risposta in tempo reale. Google-Extended governa il primo, Googlebot il secondo. Se vuoi restare fuori dall’addestramento ma presente nelle risposte AI, blocchi Google-Extended e lasci lavorare Googlebot. Se vuoi uscire da tutto, blocchi entrambi — e rinunci alla visibilità sulla Search e su ogni superficie AI che passa dall’indice.

Il caso llms.txt: una proposta che non gira

In parallelo al tema Google-Extended, negli ultimi anni è circolata una proposta di standard chiamata llms.txt, un file markdown da posizionare nella root del sito per presentare ai modelli linguistici una versione pulita dei contenuti principali, senza pubblicità, navigazione, rumore. L’idea è attraente sulla carta. Il problema è che nessun motore AI di peso la sta usando.

Google è stato esplicito. John Mueller ha dichiarato pubblicamente che nessun sistema AI utilizza llms.txt al momento. Anche Gary Illyes ha chiuso ulteriormente la porta confermando che Google non supporta lo standard e non ha in programma di supportarlo. Mueller lo ha paragonato al meta tag keywords — una di quelle convenzioni che sulla carta sembravano utili e che i motori hanno abbandonato perché troppo facili da abusare con tecniche di cloaking e troppo ridondanti rispetto all’analisi del contenuto vero. A dicembre 2025 qualcuno ha notato che llms.txt compariva sui dev docs di Google stessi, sollevando perplessità, ma l’origine era un artefatto del CMS usato per pubblicare quella sezione, non un endorsement di Search.

Il segnale operativo è chiaro: llms.txt oggi non serve a niente per Google. Se vuoi presidiare la visibilità nelle risposte AI della Ricerca, il lavoro vero è assicurarti che Googlebot possa scansionare bene il tuo sito, che i contenuti critici stiano entro il limite di 2MB, che il tuo brand sia leggibile come entità coerente nel tempo. Non c’è una scorciatoia tecnica che bypassi la qualità della scansione.

Googlebot e crawl budget: cosa conta davvero, e per chi conta

Googlebot non lavora su un calendario fisso: non passa “ogni tot ore” e non torna sulle pagine con una regolarità che puoi dare per scontata. Da tempo nella community si è diffuso il concetto di crawl budget, che indica proprio è il quantitativo di risorse che Googlebot dedica alla scansione del tuo sito in una finestra di tempo.

Tecnicamente nasce dall’intersezione di due fattori: il crawl rate, che è la velocità massima con cui il tuo server può sostenere le richieste senza degradare, e il crawl demand, che è la frequenza con cui Google vuole tornare sulle tue pagine in base ad autorevolezza, freschezza dei contenuti e valore percepito. La combinazione dei due determina intensità e profondità della scansione.

Una precisazione importante arriva direttamente da Gary Illyes, che da qualche anno ripete a ogni occasione utile lo stesso messaggio: per la maggior parte dei siti, il crawl budget non è un problema. Se hai qualche centinaio o qualche migliaio di pagine e pubblichi con regolarità, Google arriva dove deve arrivare. La faccenda diventa rilevante quando entri in territorio di siti grandi: decine di migliaia di URL, ecommerce con filtri e combinazioni, news site con flusso continuo, portali editoriali ricchi di contenuti storici. Lì il budget smette di essere astratto e diventa una risorsa scarsa da allocare.

Quando il budget conta, il nemico numero uno sono le pagine che consumano scansioni senza restituire valore. URL parametrizzati che generano duplicati, catene di redirect infinite, pagine di filtro di un catalogo che moltiplicano le combinazioni all’infinito, archivi tag autogenerati che non intercettano alcuna query, pagine di ricerca interna indicizzabili, sessioni con ID in query string. Ognuno di questi casi sottrae attenzione alle risorse che la meritano davvero: Googlebot spende tempo su pagine che non meritano la visita, e intanto le pagine che dovrebbero essere scansionate più spesso ricevono meno attenzione.

Il lavoro di ottimizzazione del crawl budget è quindi togliere, non aggiungere. Bloccare via robots.txt le sezioni tecniche che non aggiungono valore, applicare noindex alle pagine che non dovrebbero comparire in SERP ma che Google scansiona comunque, consolidare i duplicati con canonical, pulire i redirect chain, risolvere gli errori 404 ricorrenti. Ogni pagina che liberi dal carico è tempo che Googlebot può spendere su quello che conta.

Perché è importante la frequenza di scansione

La frequenza di scansione è quindi il ritmo con cui Googlebot torna a richiedere risorse del tuo sito. Non riguarda solo quante visite compaiono nei log file, ma anche come quelle visite si distribuiscono nel tempo, su quali sezioni si concentrano e con quale intensità Google decide di tornare sulle pagine già note. Una home, una sezione editoriale aggiornata spesso, un archivio statico, una pagina prodotto stagionale e un PDF non vengono trattati nello stesso modo.

La parte più pratica del problema si vede quando il sito restituisce segnali tecnici deboli. Se il server comincia a rispondere lentamente, se aumentano gli errori, se alcune risorse diventano instabili o se il crawler trova troppi attriti nel recupero, la frequenza può cambiare. Google documenta in modo esplicito che risposte come 500, 503 e 429 possono essere usate per chiedere una riduzione temporanea del crawl rate, perché il sito smette di essere una destinazione affidabile dal punto di vista tecnico.

Questa riduzione non va letta come una punizione morale del sito. È una misura di adattamento. Googlebot cerca di non stressare ulteriormente un’infrastruttura che mostra segnali di sofferenza. Il problema è che, se questa situazione si prolunga, rallenta anche la capacità della Search di recuperare aggiornamenti, rivedere contenuti importanti e mantenere una lettura viva delle aree che contano.

Che cosa influenza davvero il ritorno del crawler

Il ritorno del crawler dipende anche da quanto il sito riesce a dare a Google motivi concreti per tornare. Un progetto con architettura leggibile, linking interno solido, risorse importanti ben collegate e contenuti che si aggiornano in modo chiaro tende a offrire una mappa più utile al crawling. Un sito dispersivo, pieno di URL secondari, pagine deboli, catene inutili o sezioni poco leggibili tende invece a rendere più opaco anche il ritmo con cui Google torna sulle risorse che contano.

Conta anche la distribuzione del valore interno. Non tutte le pagine meritano lo stesso refresh. Quelle che intercettano meglio la domanda, che vengono aggiornate davvero, che si trovano in aree centrali della struttura e che mostrano segnali di utilità più forti hanno più possibilità di rientrare in un ciclo di scansione più vivo. Il contrario succede alle risorse marginali, duplicate, poco utili o isolate. La frequenza di scansione, letta bene, diventa quindi anche una forma indiretta di lettura del sito: ti mostra dove Google torna più volentieri e dove, invece, il progetto smette di offrire abbastanza ragioni per insistere.

Se vuoi capire come Googlebot scansiona il sito e con quale frequenza, i due punti di osservazione più utili restano i log server e le statistiche di scansione in Search Console. I log ti mostrano il comportamento reale, URL per URL, richiesta per richiesta. Search Console ti aiuta a vedere volume delle richieste, tempi di risposta e distribuzione dell’attività del crawler. Nessuno dei due basta da solo. Insieme, però, ti permettono di capire se il crawler mantiene un rapporto stabile con il sito oppure se qualcosa si è inclinato.

La lettura utile nasce dai pattern: aree che ricevono attenzione costante, sezioni che si raffreddano, cambiamenti dopo update tecnici, rallentamenti che coincidono con errori server o con peggioramenti nella risposta delle risorse. È qui che la frequenza di scansione ti dice se il sito regge il rapporto con Googlebot e se le parti che contano vengono davvero lette con il ritmo che meriterebbero.

Come facilitare la scansione da parte di Googlebot

Il crawling migliora quando il documento diventa più leggibile, il recupero più lineare e il percorso verso le risorse importanti meno dispersivo. Googlebot lavora in modo efficace su siti che gli consegnano presto ciò che conta, senza costringerlo a passare attraverso troppo rumore tecnico. Questo riguarda l’ordine dei segnali nel documento, il peso del markup, la stabilità delle risorse esterne, la qualità della risposta del server e la chiarezza con cui il sito distribuisce il proprio valore interno.

Le indicazioni ufficiali Google spingono tutte nella stessa direzione: meno attrito tra la risorsa e il suo recupero reale.

Le leve operative sono poche e molto concrete.

1. Portare in alto i segnali che contano

Una pagina non pesa solo per quanto è lunga. Pesa per come distribuisce le informazioni nel documento. Se canonical, meta, dati strutturati, titolo reale della pagina e blocchi centrali del contenuto arrivano presto, il recupero parte da una base più solida. Quando invece il documento accumula apertura ridondante, markup dispersivo, componenti ripetuti o lunghi blocchi secondari prima di arrivare al punto, la distanza cresce.

Qui la lettura utile non riguarda soltanto i “meta tag”. Riguarda la gerarchia complessiva della pagina. Un contenuto forte, ben ordinato, con i passaggi decisivi esposti presto, aiuta sia la comprensione editoriale sia il recupero tecnico. La stessa pagina, se appesantita da troppo codice accessorio o da una struttura che rimanda in basso il cuore del contenuto, parte peggio anche quando il testo in sé è valido.

2. Ridurre peso e dispersione del documento

Markup superfluo, componenti inutili, frammenti ripetuti, DOM profondi, codice che si accumula senza aggiungere valore: tutto questo non “rompe” per forza una pagina, ma peggiora la qualità con cui la risorsa viene recuperata. Google non ragiona sulla bellezza del codice. Ragiona su ciò che riesce a scaricare e ricostruire in condizioni reali. Più il documento si riempie di materiale accessorio, più aumenta il rischio che il contenuto utile perda spazio relativo o arrivi in una zona più fragile del processo.

Vale anche per pagine editoriali che, senza apparente motivo, si trascinano dietro troppo markup, script non essenziali, blocchi ridondanti o template che pesano più del contenuto stesso. Quando il documento si alleggerisce senza perdere struttura, Googlebot parte da una risorsa più leggibile e il recupero diventa più pulito.

3. Tenere vicino HTML iniziale e contenuto utile

Più il contenuto importante è ben rappresentato già nell’HTML iniziale, più il recupero regge. Quando invece il documento iniziale porta poco e rimanda troppo a passaggi successivi, la lettura diventa più fragile. Google chiarisce che CSS e JavaScript vengono richiesti separatamente e che il rendering aggiunge un ulteriore livello di complessità. Non significa che una pagina basata su script sia destinata a fallire. Significa che la solidità del recupero dipende sempre di più da quanto il documento iniziale resta leggibile e utile già prima dei passaggi successivi.

Questo si vede bene nelle pagine che funzionano “visivamente” ma consegnano poco nei primi livelli del documento. L’utente apre il browser e trova tutto. Google parte da un materiale più povero, più ritardato o più frammentato. Se il contenuto chiave, la struttura della risposta e i segnali principali restano leggibili già presto, il rapporto tra ciò che metti online e ciò che Google recupera si accorcia molto.

4. Dare al sito una struttura che accompagni il crawler

Googlebot non incontra le pagine in isolamento. Le incontra dentro una struttura fatta di collegamenti, profondità, sezioni più o meno centrali, URL che ricevono più o meno supporto dal resto del sito. Un linking interno pulito, una gerarchia leggibile, una sitemap coerente e la riduzione delle aree dispersive aiutano il crawler a concentrare meglio l’attenzione sulle risorse che contano. Google continua a trattare linking e accessibilità delle risorse come elementi centrali del crawling.

Questo aspetto pesa molto anche quando il problema non è tecnico in senso stretto. Un sito con troppe pagine secondarie, archivi ridondanti, URL deboli o sezioni che consumano richieste senza aggiungere valore rende più opaco il rapporto tra Googlebot e contenuti importanti. Quando la struttura accompagna davvero il crawler, la scansione diventa meno casuale e più utile. E questo, nel tempo, incide anche sulla capacità del sito di far tornare Google dove serve davvero.

5. Rendere stabile la risposta tecnica

C’è poi una parte che il contenuto, da solo, non può compensare: la stabilità della risorsa. Tempi di risposta irregolari, errori intermittenti, file esterni che non vengono consegnati bene, redirect inutili o catene troppo lunghe peggiorano il recupero anche quando la pagina è ben costruita. Google documenta la relazione diretta tra salute tecnica del server e comportamento del crawler, fino al punto da consigliare risposte come 500, 503 o 429 quando serve chiedere una riduzione temporanea del crawl rate. Un sito che risponde in modo stabile non costringe Googlebot a lavorare su un terreno incerto. E quando il terreno smette di oscillare, diventa più facile distinguere i problemi veri di contenuto e struttura da quelli che nascono semplicemente da un recupero tecnico poco affidabile.

Una parte del lavoro riguarda anche il trasporto delle risorse. Supporto a HTTP/2 e compressione tramite gzip, deflate o Brotli riducono il carico e rendono più efficiente il dialogo tecnico con il crawler, senza trasformarsi per questo in un vantaggio diretto di ranking.

Come gestire la scansione: bloccare, controllare, rallentare

Governare il rapporto con Googlebot è una questione di strumenti precisi usati per gli scopi giusti.

Semplificando, hai la possibilità di bloccare l’accesso alle risorse, bloccare la presenza in Search e rallentare la frequenza. Ma devi intervenire solo quando sai con precisione che cosa vuoi ottenere, perché ogni azione ha una conseguenza specifica, e scambiarle tra loro è l’errore che genera più problemi alla visibilità del tuo sito.

Il file robots.txt è il tuo primo strumento di comunicazione con i crawler, e lavora sul piano della scansione. Posizionato nella root del sito, dichiara quali sezioni Googlebot (e altri crawler che rispettano lo standard) non devono visitare. È utile per tenere fuori aree tecniche, backend, pagine di login, contenuti generati che non aggiungono valore, risorse infrastrutturali che consumano budget inutilmente.

La trappola più frequente è confondere “bloccato da robots.txt” con “non compare in SERP”. Non è la stessa cosa. Se una pagina bloccata nel robots.txt riceve link esterni, Google può decidere di indicizzare comunque l’URL (senza contenuto scansionato) e mostrarla nei risultati con una descrizione minimale. Per tenere davvero una pagina fuori dall’indice serve il tag noindex, e il noindex richiede che Googlebot possa leggere la pagina per vederlo — quindi robots.txt e noindex sulla stessa pagina si cancellano a vicenda, perché il primo impedisce al secondo di essere letto.

Un’altra trappola riguarda le risorse. Se blocchi CSS o JavaScript nel robots.txt, impedisci al WRS di renderizzare correttamente le tue pagine. Il risultato è un sito che al Controllo URL appare incompleto, con layout spezzati, contenuti invisibili perché non eseguiti. Le risorse che servono al rendering devono restare accessibili.

Noindex controlla l’indicizzazione, non la scansione

Il tag noindex (in meta tag o come header HTTP X-Robots-Tag) funziona all’opposto: lascia Googlebot libero di scansionare la pagina ma gli dice di non includerla nell’indice. È la soluzione corretta per pagine che devono restare raggiungibili, che potrebbero cambiare nel tempo, ma che non dovrebbero apparire nei risultati di ricerca — risultati di ricerca interna, carrelli, pagine di ringraziamento post-conversione, filtri di prodotto che non hanno valore autonomo.

Usare noindex ha un costo in termini di crawl budget, perché Googlebot continua a visitare la pagina per verificare che la direttiva sia ancora attiva. Per siti grandi con molte pagine non-indicizzabili, la combinazione giusta è quasi sempre noindex iniziale per far uscire la pagina dall’indice, seguito dal blocco robots.txt una volta consolidata l’uscita, per risparmiare il budget successivo.

Quando serve la protezione password

L’unico metodo davvero affidabile per tenere contenuti fuori da Google è la protezione tramite password o autenticazione. Quando una risorsa deve essere proprio sottratta all’accesso pubblico perché il contenuto è sensibile o non deve essere accessibile a nessuno che non sia autorizzato, il login è l’unica barriera tecnica che funziona davvero. Qualsiasi altra soluzione — robots.txt, noindex, X-Robots — ha punti di fragilità, soprattutto quando i contenuti ricevono link esterni o vengono nominati da terze parti.

Canonical per consolidare, non bloccare

Il tag canonical non controlla scansione o indicizzazione, ma risolve un problema diverso: quando esistono più URL con contenuto sostanzialmente identico, indica a Google quale considerare la versione preferita. I segnali di ranking, i backlink, l’autorità raccolta dalle varianti vengono consolidati sull’URL canonico. È lo strumento giusto per parametri di tracciamento, varianti di prodotto equivalenti, versioni HTTPS e HTTP, URL con e senza trailing slash.

È uno strumento delicato perché è un suggerimento, non una direttiva vincolante. Google può decidere di scegliere un canonico diverso da quello dichiarato se i segnali che legge vanno in un’altra direzione. Se il canonico dichiarato contraddice struttura dei link interni, sitemap, hreflang o altri indicatori, Google prende la sua decisione basandosi sull’insieme. Per questo il canonical deve essere coerente con il resto della comunicazione del sito: non sostituisce noindex, non sostituisce robots.txt, non sostituisce una struttura interna coerente.

Sitemap XML: la guida, non il sostituto

La sitemap XML è la mappa che fornisci a Google delle pagine del tuo sito che consideri importanti. Aiuta nella scoperta, specialmente per contenuti nuovi, per sezioni poco linkate internamente, per siti grandi dove il crawler può perdersi. Non è una garanzia di scansione e non è un sostituto di una buona architettura di link interni — una pagina orfana in sitemap difficilmente verrà trattata con priorità.

La sitemap funziona bene quando accompagna un sito leggibile. Funziona male quando viene usata per compensare problemi strutturali che restano intatti. Tienila pulita: includi solo URL che vuoi davvero in SERP, senza duplicati, senza redirect, senza 404, con tag lastmod aggiornati in modo onesto. Una sitemap piena di rumore è un segnale negativo che Google registra.

Quando ha senso limitare il crawl

C’è un livello più operativo che riguarda il carico del sito. In alcune fasi ha senso chiedere a Google di rallentare. Server sotto stress, errori ripetuti, infrastruttura in sofferenza, picchi che compromettono la stabilità: in questi casi Google documenta segnali molto chiari, come le risposte 500, 503 e 429, per ottenere una riduzione temporanea del crawl rate. È una leva tecnica da attivare quando il sito non regge bene il rapporto con il crawler e hai bisogno di proteggere la stabilità dell’infrastruttura.

Ridurre il crawl non è una best practice generale. Ha senso in condizioni specifiche, quasi sempre legate alla tenuta tecnica del sito. Se il server mostra segnali di sofferenza, se le richieste di Googlebot peggiorano una fase già critica o se alcuni picchi mettono a rischio la stabilità complessiva, ha senso intervenire in modo temporaneo.

La parola chiave, però, resta “temporaneo”. Limitare il crawl non risolve il problema di fondo. Ti compra spazio operativo mentre sistemi server, risorse, errori o condizioni che hanno reso il recupero meno stabile. Se trasformi questa misura in una strategia permanente, stai solo spostando in avanti un difetto che prima o poi riemergerà. La gestione di Googlebot funziona bene quando nasce da una diagnosi precisa: che cosa vuoi bloccare, perché vuoi bloccarlo e quale effetto ti aspetti davvero da quell’intervento.

Come monitorare il passaggio di Googlebot

Googlebot lascia tracce, ma non tutte valgono allo stesso modo. Una richiesta nei log non basta a dire che la pagina sia stata recuperata bene. Uno user-agent che contiene il nome del crawler non basta a provare che la visita arrivi davvero da Google. Una scansione isolata non dice quasi nulla sul destino di una risorsa nella Search. Il dato utile nasce solo quando metti insieme autenticità della richiesta, contesto tecnico, risposta del server e distribuzione della scansione nel tempo.

Tenere sotto controllo il comportamento di Googlebot è la condizione per capire se i segnali che invii stanno arrivando, se il crawl budget viene speso bene, se ci sono sezioni ignorate che dovrebbero essere scansionate.

Gli strumenti da usare davvero

Il Rapporto Statistiche di Scansione in Search Console è la fonte ufficiale aggregata: ti mostra quante richieste Googlebot ha fatto nelle ultime settimane, come si distribuiscono tra desktop e mobile, quali status code hanno restituito, quanto ci ha messo il server a rispondere, come si ripartiscono tra HTML, CSS, JavaScript, immagini. Non è un dato granulare per singolo URL, ma è la fotografia di insieme che ti fa capire se qualcosa è cambiato nel ritmo di scansione e se il server sta reggendo.

Il Controllo URL lavora invece sul singolo URL: ti dice se quella pagina è stata scansionata, quando, che contenuto ha letto Googlebot, se l’ha indicizzata, se ci sono problemi di rendering, se il canonico dichiarato coincide con quello scelto dal sistema. È il primo strumento da aprire quando una pagina non compare come ti aspetti.

I file di log del server sono il livello più granulare, e per siti medio-grandi diventano indispensabili. Ogni richiesta di Googlebot lascia una traccia con IP, user agent, URL, status code, timestamp. Analizzarli ti permette di vedere esattamente cosa il crawler sta visitando, con che frequenza, su quali sezioni sta concentrando l’attenzione, dove sta sprecando tempo.

Verificare che sia davvero Googlebot

Lo user agent di Googlebot viene spoofato regolarmente da bot malevoli che vogliono accedere ai contenuti facendo finta di essere il crawler di Google.

Se il blocco di un’attività sospetta ti preoccupa perché temi di stare bloccando il crawler vero, il metodo corretto per verificare è duplice:

1. Una ricerca DNS inversa sull’IP di origine, che deve risolvere in un host di dominio googlebot.com, google.com o googleusercontent.com
2. Il confronto diretto con gli intervalli IP ufficiali che Google pubblica nei file JSON dedicati (googlebot.json, special-crawlers.json, user-triggered-fetchers.json), recentemente riorganizzati sotto il percorso /crawling/ipranges/.

Se l’IP non è in quelle liste, non è Googlebot — indipendentemente da cosa dice l’header user-agent.

Come SEOZoom ti aiuta a monitorare e ottimizzare la scansione

Gli strumenti di Search Console sono il punto di partenza, ma per un lavoro strutturale serve un’analisi più profonda e continua. Devi simulare il comportamento del crawler, leggere la struttura effettiva del sito, isolare i punti in cui la scansione si disperde o si sporca. E gli strumenti di SEOZoom dedicati all’analisi tecnica diventano i tuoi alleato.

Il lavoro non finisce con la scansione

Verifica che il tuo brand non sia solo indicizzato ma anche citato dalle risposte AI con AI Visibility, GEO Audit e AEO Audit di SEOZoom

Attiva la tua prova gratis di SEOZoom

Il cuore operativo è il SEO Spider. Esegue una scansione completa del sito seguendo i link interni e restituisce, per ogni URL, status code, direttive robots, meta tag, heading, immagini, link interni ed esterni e conformità dei dati strutturati. I risultati si leggono in due viste principali, Errori e Warning, così distingui subito ciò che ostacola direttamente indicizzazione e scansione da ciò che abbassa la qualità complessiva del sito. La mappa ad albero (Crawl Tree) ricostruisce la gerarchia interna come la vede il crawler. Nei piani Business e Corporate puoi attivare anche il rendering JavaScript, utile per verificare come una pagina costruita con framework moderni viene letta dopo l’esecuzione degli script. Il SEO Audit trasforma la scansione in un report strutturato con sintesi dei problemi e priorità di intervento, utile anche nella condivisione con team e stakeholder.

Sul fronte dell’efficienza della scansione, il riferimento sta in Rendimento pagine, dentro i Progetti. La metrica Crawl budget sprecato aiuta a leggere la quota di pagine a rendimento molto basso che stanno consumando risorse di Googlebot senza restituire traffico. Non è una sentenza automatica. È un indicatore che orienta la lettura manuale successiva e segnala dove conviene guardare per primo.

Per leggere l’evoluzione del sito nel tempo, Time Machine ti permette di confrontare lo stato del dominio tra due date diverse e di vedere quali keyword e pagine hanno guadagnato o perso visibilità nel periodo. Qui lo strumento serve soprattutto a separare un problema strutturale già in corso dagli effetti di un update, di una migrazione o di un refactoring importante. Trend negativo raccoglie le pagine che hanno registrato cali di visibilità nell’ultimo periodo e le keyword che hanno perso posizioni: è un sistema di allerta che ti permette di intervenire prima che un problema si approfondisca. Cannibalizzazione ti mostra quando più pagine del sito competono per le stesse query con una percentuale di sovrapposizione, situazione che confonde Googlebot nella scelta della versione da privilegiare.

C’è poi il set di strumenti più recenti, racchiusi nella sezione SEO for AI. AI Visibility, GEO Audit e AEO Audit ti permettono di leggere come il tuo brand si comporta nelle risposte dei motori generativi — AI Overview, AI Mode, ChatGPT, Perplexity, Gemini. Non sono strumenti che misurano direttamente il comportamento di Googlebot, ma ti dicono se il lavoro di crawling sta producendo l’effetto finale che ti interessa: essere citato, essere scelto, essere riusato nelle risposte. Leggere i dati di scansione insieme a quelli di visibilità AI ti dà il quadro completo, dal primo fetch fino alla sintesi che l’utente legge.

Ottimizzare davvero per Googlebot oggi

Arrivati fin qui, le leve operative che contano sono poche, precise e interconnesse. Conviene raccoglierle insieme.

1. HTML snello e scritto bene. I contenuti e i segnali SEO critici entro i primi KB del documento. JavaScript e CSS esterni, non inline. Rumore, commenti, metadati ridondanti via. ma non riguarda solo casi estremi. Il Web Almanac 2025 mostra che la homepage mediana pesa 2,86 MB su desktop e 2,56 MB su mobile, con 80 richieste su desktop e 75 su mobile. In un web così carico, alleggerire il file iniziale e distribuire meglio le risorse non è una finezza: è una condizione di leggibilità tecnica.
2. Server veloce e stabile. Se il tuo server risponde lento o produce errori intermittenti, Googlebot riduce la frequenza di scansione. Il Time To First Byte sotto i 200 millisecondi è il target tecnico di riferimento; gli 800ms sono la soglia oltre la quale Core Web Vitals ti classifica come “server response time scadente”. Un server che fatica è un ostacolo che lavora contro di te in modo invisibile, perché riduce la superficie che Google riesce a esplorare nel tempo a disposizione.
3. Architettura di link interni curata. Le pagine orfane non vengono scansionate, e nemmeno una buona sitemap risolve interamente il problema. Se una risorsa è importante, deve essere raggiungibile con link interni da altre pagine importanti. La distanza dalla homepage conta, la profondità di navigazione conta, la coerenza dei percorsi tematici conta. L’architettura dei link non è un dettaglio di UX, è la mappa che Googlebot usa per capire cosa ha valore nel tuo sito.
4. Rendering-aware nel design del sito. Se dipendi pesantemente da JavaScript per mostrare i contenuti, considera che il WRS opera stateless e che le sue capacità, pur essendo evergreen e allineate all’ultima versione di Chromium, hanno limiti pratici. I contenuti critici dovrebbero essere visibili nel primo rendering, senza dipendere da interazioni utente o stati memorizzati. Il Web Almanac misura un payload JavaScript mediano di 613 KB su desktop e 558 KB su mobile, mentre il Web Almanac 2025 registra 22 richieste JavaScript sulla homepage mediana. Affidare troppo del contenuto rilevante a una catena di script significa rendere il recupero più fragile.
5. Coerenza tra mobile e desktop. Se ancora mantieni due versioni separate (pattern sempre più raro ma non estinto), considera che la mobile è quella che conta per l’indicizzazione. Contenuti presenti solo su desktop rischiano di non entrare nell’indice, o di non pesare quanto dovrebbero.

Oltre Googlebot: la visibilità che si gioca sui motori AI

Per anni la SEO tecnica ha misurato la propria efficacia sulla domanda: Googlebot arriva, legge, indicizza? Oggi è una base necessaria ma non più sufficiente. Essere scansionati, essere nell’indice, posizionarsi bene nei risultati organici — tutto questo resta il terreno di base. Ma sopra si è aggiunto un altro livello, quello in cui il contenuto non compete per essere cliccato, compete per essere riusato.

Quando AI Overview costruisce una risposta, non mostra una lista di link da scegliere: seleziona frammenti di contenuto da più fonti, li isola, li rielabora, li presenta come sintesi. Il contenuto che viene scelto è quello più facile da estrarre, più coerente con il cluster tematico, più citabile. Un brand forte, riconoscibile, con un’entità leggibile nei sistemi di Google, parte da una posizione più forte.

Questo cambia l’inquadramento della scansione. Il livello tecnico — far passare Googlebot, farsi scansionare bene, farsi indicizzare — è il biglietto di ingresso. Senza non sei nemmeno nella partita. Ma una volta dentro, la visibilità si sposta su un terreno più ampio: chiarezza dell’identità editoriale, coerenza tra brand e temi, qualità dei segnali esterni che corroborano ciò che il sito dice di essere, leggibilità dell’entità per sistemi che sintetizzano e selezionano. Il lavoro tecnico apre la porta. Il resto dipende da come il brand si è costruito come soggetto informativo riconoscibile.

Il ragnetto digitale che passava e se ne andava non basta più come immagine di Googlebot. Oggi è il primo passaggio di una catena lunga che arriva fino alle risposte generate dall’AI, e ogni passaggio di quella catena conta. Non lavorare per Googlebot, lavora con Googlebot. La differenza, tra qualche anno, sarà visibile nei risultati.