Che cos'è Googlebot? Crawl, Render e Index spiegati

TL;DR. Googlebot non è un singolo bot ma una famiglia di crawler e, da quando l’indicizzazione mobile-first è diventata di default nel 2023, è praticamente Googlebot Smartphone a gestire quasi tutto. Il suo lavoro si svolge in tre fasi (crawl, render, index) che possono avvenire a ore o giorni di distanza, e la fase di render è quella in cui si concentra la maggior parte dei reclami «Googlebot non vede la mia pagina». Tra i ticket di supporto che abbiamo gestito in SEOJuice da metà 2024 a inizio 2026, circa 6 su 10 escalation di indicizzazione si sono rivelate problemi di render; solo 2 su 10 erano veri problemi di crawl (il resto erano tag noindex o configurazioni errate di robots.txt). Questa guida descrive la famiglia di bot, la pipeline a tre fasi, come verificare un vero hit di Googlebot, le domande su robots e crawl budget che tutti fanno e come Googlebot si confronta con Bingbot, GPTBot, PerplexityBot e ClaudeBot nel 2026.

Updated May 2026. Aggiornato con dati proprietari sul mix di ticket SEOJuice, un aneddoto nominativo su un outage dovuto a Cloudflare Bot Fight, e un richiamo nella sezione sui crawler AI che rimanda alle modalità di failure del rendering JS descritte in precedenza.

Ho scritto questo articolo perché invio lo stesso spiegone su Intercom tre o quattro volte alla settimana. Il cliente dice «Googlebot è bloccato sul mio sito». Apriamo Search Console. La fase di crawl è ok. Quella che è saltata una settimana fa è la fase di render, dopo che uno sviluppatore ha pubblicato un refactor di un tab-panel senza accorgersi che il corpo dell’articolo ora monta solo dopo un click. Volevo un’unica URL da incollare nel ticket invece di digitare sempre lo stesso paragrafo. Questa è quell’URL.

Che cosa è davvero Googlebot (in parole semplici)

Googlebot è il programma che Google utilizza per recuperare le pagine web così da poterle aggiungere all’indice di Google. Quando pubblichi un nuovo post sul blog e alla fine lo vedi nei risultati di ricerca, quel viaggio inizia con Googlebot che richiede l’URL, scarica l’HTML, esegue il JavaScript e passa il risultato al sistema di indicizzazione di Google. Senza Googlebot, le tue pagine non esistono per la ricerca di Google.

Due chiarimenti subito. «Googlebot» viene talvolta usato in modo generico per indicare «qualsiasi crawler di Google». In senso stretto, Googlebot è il crawler che recupera le pagine per l’indice di ricerca principale. Esistono altri crawler Google (AdsBot per i controlli di qualità delle landing page, Storebot per le schede Shopping, Google-Extended per l’opt-out dal training AI) con regole e schedulazioni diverse. Sii specifico su quale intendi quando fai debug.

Googlebot è anche distinto da uno scraper. Legge il tuo robots.txt prima di ogni crawl, rispetta i meta tag noindex, si autolimita quando il server rallenta e si identifica negli header della richiesta così che tu possa verificare che provenga davvero da Google. Se nei log vedi un «Googlebot» che martella l’origine senza back-off, quasi certamente non è il vero Googlebot. Verificalo prima di limitare la banda.

Googlebot è in realtà una famiglia di crawler

Il bot che devi considerare di più è Googlebot Smartphone, che dal completamento dell’indicizzazione mobile-first a metà 2023 esegue per default la scansione della versione mobile del tuo sito. Le scansioni desktop avvengono ancora, ma ora sono secondarie. Ecco l’albero genealogico con le stringhe user-agent esatte pubblicate da Google:

Il segnaposto W.X.Y.Z nelle user-agent Smartphone e Desktop non è letterale. Google sostituisce al momento della richiesta la versione reale di Chromium, che evolve per seguire la release stabile di Chrome. Al momento in cui scrivo, il motore di rendering di Googlebot dista poche settimane da quello che Chrome rilascia al pubblico. (Per anni ho detto ai clienti di trattare il renderer di Googlebot come se fosse Chrome 41, ed era effettivamente così fino all’aggiornamento evergreen del 2019. Non è più Chrome 41 da anni, e ho continuato a dare indicazioni superate fino al 2021, finché una talk di Martin Splitt a Search Off the Record non mi ha spinto a leggere i documenti attuali.) Se il tuo sito usa una feature JavaScript che richiede Chrome 130+, Googlebot probabilmente la supporta. Se richiede qualcosa non ancora rilasciato, Googlebot no.

La pipeline a tre fasi: Crawl, Render, Index

Il lavoro di Googlebot è suddiviso in tre fasi distinte. Non avvengono contemporaneamente e un ritardo o un errore in una qualunque di esse può tenere la tua pagina fuori dai risultati di ricerca. La documentazione di Google lo riassume bene: «Google elabora le web app JavaScript in tre fasi principali: 1. Crawling 2. Rendering 3. Indexing.» Se non sai in quale fase si colloca un problema, stai solo indovinando la soluzione. Questa è la distinzione portante che giustifica l’esistenza di questo articolo.

Fase 1: Crawling

Googlebot sceglie un URL dalla sua coda, invia una richiesta HTTP e riceve la risposta HTML grezza. Fine della fase. Nessun JavaScript viene eseguito. Nessun contenuto renderizzato viene analizzato. Il crawler legge il codice di stato, gli header di risposta (inclusi caching, X-Robots-Tag ed eventuali redirect) e il corpo HTML grezzo. Gli URL provengono da sitemap XML, link interni da pagine indicizzate, link esterni da altri siti e invii diretti dallo strumento di ispezione URL in Search Console.

Se la risposta HTML grezza contiene già tutto ciò che deve essere indicizzato (classico caso SSR), Googlebot può procedere. Se invece l’HTML è quasi vuoto e il contenuto viene iniettato via JavaScript, la pagina passa alla fase di rendering. È anche qui che Googlebot legge robots.txt prima di ogni crawl. Se un URL è disallow, Googlebot non lo recupera nemmeno.

Fase 2: Rendering

Se il contenuto richiede l’esecuzione di JavaScript, Googlebot passa l’URL al Web Rendering Service (WRS). Il WRS è un Chromium headless che carica la pagina in un ambiente simile a un browser, esegue gli script e produce l’HTML renderizzato finale. La documentazione di Google è chiara: «Quando le risorse di Google lo consentono, un Chromium headless renderizza la pagina ed esegue il JavaScript.»

La frase «quando le risorse di Google lo consentono» fa parecchio lavoro. Il rendering è costoso (avviare un browser completo, eseguire JS, attendere richieste di rete), quindi Google lo batcha e lo mette in coda. Le pagine possono restare in coda di render per secondi, ore o, nei casi peggiori, giorni. (Ho uno screenshot del 2024 con 96 ore di gap tra crawl e render su un e-commerce Next.js; lo tengo pinnato in Slack per vincere la stessa discussione ogni pochi mesi su cosa significhi davvero «Googlebot ha scansionato la mia pagina».) La guida ufficiale resta vaga: «La pagina può rimanere in questa coda per pochi secondi, ma può volerci più tempo.» Non è chiaro come la coda prioritizzi un URL rispetto a un altro: ho visto siti quasi identici ottenere il render in cinque minuti o in trentasei ore senza capirne il perché.

Questo ritardo di rendering è il problema pratico ricorrente nei siti che dipendono da JavaScript: il tuo post può essere scansionato pochi minuti dopo la pubblicazione ma non renderizzato per altre 24 ore, quindi non appare nei risultati finché Google non completa il render. Le pagine SSR saltano del tutto questa coda.

Fase 3: Indexing

Una volta che Googlebot ha l’HTML finale (dal crawl o dal WRS), il sistema di indicizzazione analizza il documento, estrae il testo, classifica il contenuto, valuta i segnali di ranking e archivia tutto nell’indice di Google. Da qui la pagina diventa idonea a comparire nei risultati. Anche l’indicizzazione non è istantanea e può richiedere minuti o ore dopo il rendering, ma a questo punto il lavoro di Googlebot su quell’URL è finito; il resto dipende dagli algoritmi di ranking.

Cosa rompe il rendering JavaScript (e come intercettarlo)

È qui che si rompono le cose. La fase di crawl quasi sempre riesce; la pagina semplicemente non si renderizza come previsto. Le sei modalità di errore qui sotto sono quelle che vedo più spesso sui siti dei clienti SEOJuice, in ordine decrescente di frequenza: i punti 1 e 2 coprono da soli oltre metà delle escalation di render che gestiamo, secondo il campione di ticket citato nel TL;DR.

1. Contenuto che richiede interazione utente per caricarsi

Se l’unico modo per rivelare una sezione è cliccare «Mostra altro», Googlebot non la vedrà. Il WRS esegue il JavaScript ma non clicca né scrolla. Qualsiasi cosa importante va nel DOM al load, anche se nascosta via CSS che l’utente può attivare. È la causa più comune di failure di rendering, di solito in librerie che montano pigramente tab, accordion o feed «load more».

2. Lazy-loading senza segnali corretti

Immagini e blocchi di contenuto lazy-loaded richiedono l’attributo nativo loading="lazy" o un Intersection Observer che il WRS possa risolvere. Le librerie personalizzate che aspettano eventi di scroll falliscono spesso perché il WRS non scrolla. Usa loading="lazy" per le immagini; per i componenti, assicurati che vengano renderizzati server-side o tramite un framework con SSR/hydration corretti.

3. Errori JavaScript durante l’esecuzione

Se uno script top-of-page lancia un’eccezione non gestita, gli script a valle potrebbero non eseguire, lasciando il resto della pagina vuota. Il WRS vedrà ciò che era renderizzato prima dell’eccezione. Usa «Visualizza pagina testata» nello strumento di ispezione URL per vedere esattamente ciò che Googlebot ha visto, inclusi HTML renderizzato e screenshot.

4. Regole WAF e protezione bot

CAPTCHA, Cloudflare Bot Fight Mode troppo aggressivo e blocchi geografici ingenui possono restituire un 403 o una challenge agli IP di Googlebot. (Il Bot Fight Mode di default di Cloudflare ha colpito più siti nostri di qualunque altra impostazione: un SaaS B2B ha perso due terzi delle pagine indicizzate in un weekend a fine 2024 dopo che uno stagista security l’ha attivato, e il recupero ha richiesto tre settimane di reinvii.) Whitelista sempre gli IP Google verificati (lista googlebot.json nel sito developer) prima di attivare «block bots». Verifica con l’ispezione URL dopo ogni modifica WAF.

5. Risorse bloccate in robots.txt

Se robots.txt disallow /static/ o /assets/, il WRS non può recuperare i bundle JS/CSS e la pagina verrà renderizzata senza stili o con JS rotto. Consenti a Googlebot di scansionare le risorse statiche anche se blocchi altri percorsi.

6. Contenuto dietro autenticazione o cookie

Googlebot non effettua login, non gestisce cookie in modo significativo e non mantiene sessione. Qualsiasi cosa dietro login non sarà indicizzata. Usa l’Indexing API o i dati strutturati per i contenuti paywall se devono essere scopribili e specifica chiaramente cosa è gated.

La community SEO ha discusso dal 2017 al 2020 se il renderer di Googlebot avrebbe mai raggiunto Chrome moderno. Il dibattito è finito: ci è arrivato con lo switch evergreen 2019 e da allora segue Chrome stabile. Molti consigli ancora in circolazione però sono precedenti, ed è per questo che i punti 1 e 2 continuano a comparire.

Come verificare che una richiesta sia davvero di Googlebot

La stringa user-agent di Googlebot è facile da spoofare. Chiunque può inviare una richiesta che dichiara di provenire da Googlebot. Le vere richieste arrivano da intervalli IP Google pubblicati. Il metodo affidabile è: reverse DNS, poi forward DNS. Procedura pratica:

1. Prendi l’IP dai log.
2. Reverse DNS: l’hostname deve terminare con .googlebot.com o .google.com.
3. Forward DNS su quell’hostname: deve risolvere allo stesso IP.
4. Se entrambi i passaggi passano, è il vero Googlebot; altrimenti è spoof.

Da CLI: host 66.249.66.1 poi host crawl-66-249-66-1.googlebot.com. Su siti a traffico alto automatizza il controllo; spesso un «picco Googlebot» è in realtà uno scraper con UA falsata. Ahrefs ha un buon walkthrough con esempi curl se preferisci quel formato.

robots.txt e Crawl Budget: le domande tattiche più comuni

Quanto crawlerà Googlebot il mio sito?

Google lo chiama crawl budget. Sotto ~10 000 URL quasi mai è un problema: Googlebot scansiona tutto l’essenziale in tempi ragionevoli. Diventa critico su siti con milioni di URL, e-commerce a faccette o quando Googlebot spreca crawl su URL duplicati/poco utili. I due fattori dichiarati da Google sono crawl rate (quanto il server regge senza errori) e crawl demand (popolarità e frequenza di aggiornamento di un URL). L’analisi Semrush spiega bene i segnali di crawl rate se vuoi approfondire.

Dovrei bloccare Googlebot dagli URL di poco valore?

Sì, se quegli URL consumano crawl budget su un sito grande. Schema tipico: blocca URL di ricerca a faccette, risultati di ricerca interna, pagine archivio oltre pagina 5, varianti con ID sessione e endpoint admin. Usa robots.txt per bloccare al crawl e noindex per bloccare all’indicizzazione. Funzioni diverse: robots impedisce il crawl, noindex consente il crawl ma blocca l’indice.

Come accelero l’indicizzazione di una nuova pagina?

Inviala con lo strumento di ispezione URL in Search Console. Avvia un crawl fuori banda (Google-InspectionTool) più rapido della coda normale. Collega poi la nuova pagina da un URL autorevole già indicizzato così venga scoperta nel prossimo crawl regolare.

Perché Googlebot scansiona il mio ambiente di sviluppo?

Perché un URL di staging/dev è finito nel web pubblico (link accidentale, risultato di ricerca, issue tracker aperto) e Googlebot segue il grafo dei link. Blocca l’intero dominio di staging in robots.txt con Disallow: / e aggiungi basic auth se il contenuto è sensibile.

Debugging dei problemi «Googlebot non vede questa pagina»

Il debug sistematico prevede quattro check in ordine finché uno non dà risposta chiara.

Check 1, Ispezione URL in Search Console. Incolla l’URL. Lo strumento mostra se Google lo ha scansionato/indicizzato, quando, e «Visualizza pagina testata» per HTML renderizzato e screenshot. Se manca il contenuto nell’HTML renderizzato, problema di render. Se status ≠ 200, problema di crawl. Circa due terzi dei ticket si chiudono qui.

Check 2, curl con UA Googlebot. curl -A "Mozilla/5.0 ... Googlebot/2.1 ..." https://yoursite.com/path. Se il server serve contenuto diverso a Googlebot rispetto a un browser, lo vedi. Cloaking (voluto o no) spiega molti problemi di indicizzazione.

Check 3, audit robots.txt e meta tag. Vai su https://yoursite.com/robots.txt. Controlla che non blocchi l’URL. Poi nel sorgente cerca noindex. Sorprende quante volte un noindex di staging rimane in produzione.

Check 4, analisi log server. Filtra gli access log per richieste Googlebot verificate degli ultimi 30 giorni. Se l’URL non appare mai, problema di discoverability: aggiungilo a sitemap e link interni. Se appare ma restituisce 4xx/5xx, risolvi l’errore e riprova. SEOJuice esegue questa analisi e ti avvisa quando un URL chiave sparisce dal traffico Googlebot reale.

Googlebot vs Bingbot vs i crawler AI

Una volta Googlebot era l’unico crawler di cui preoccuparsi; ora non più. Ecco il confronto 2026:

Nota come le failure 1, 2 e 5 del rendering JS — gating con interazione utente, segnali di lazy-load e asset bloccati — colpiscano i crawler AI più di Googlebot, perché i loro renderer sono più deboli. Lo stesso checklist risolve un problema di citazioni in Perplexity; gli impatti in AI Search per ora sono minori rispetto a Google Search. (Per troppo tempo ho dato per scontato che PerplexityBot fosse simile a Googlebot. L’ho scoperto errato solo dopo che un sito SSR ha superato di 4× il concorrente CSR nelle citazioni Perplexity.)

Due implicazioni pratiche: i crawler AI renderizzano JavaScript peggio di Googlebot. Se il tuo contenuto dipende dal client-side, potresti posizionarti bene in Google ma essere invisibile a ChatGPT, Perplexity e Claude. Soluzione: render server-side o pre-render. Il nostro AI visibility checker gratuito mostra in meno di un minuto quali engine vedono davvero il tuo contenuto. Inoltre, ogni crawler AI ha le proprie direttive robots.txt: User-agent: GPTBot blocca il training OpenAI, User-agent: Google-Extended blocca Gemini, mentre User-agent: Googlebot resta indipendente. Vuoi apparire in Google ma non nell’AI? Imposta regole separate.

«La cosa che la gente dimentica più spesso è che crawling e rendering non sono la stessa fase. Un URL può essere scansionato e non avere ancora una versione renderizzata per ore.» — Martin Splitt, Google Search Relations, parafrasato da Search Off the Record

Domande frequenti

Che cos’è Googlebot?

Googlebot è il crawler che Google usa per scoprire e scaricare pagine web da indicizzare e mostrare nei risultati. È una famiglia di crawler (Smartphone, Desktop, Image, Video, News) con UA e scopi diversi, ma «Googlebot» di solito indica Googlebot Smartphone, crawler primario dal completamento del mobile-first indexing nel 2023.

Googlebot esegue JavaScript?

Sì. Il Web Rendering Service (WRS) è un Chromium headless che esegue JS sulle pagine che lo richiedono. La versione segue da vicino Chrome stabile, quindi le feature moderne funzionano. Il problema è la coda di rendering: può avvenire secondi, ore o giorni dopo il crawl. Le pagine SSR saltano la coda.

Come verifico se una richiesta viene davvero da Googlebot?

Reverse DNS sull’IP: deve risolvere in .googlebot.com o .google.com. Poi forward DNS sull’hostname: deve tornare allo stesso IP. Se uno dei due fallisce, è spoof. La UA da sola non basta; chiunque può inviare qualsiasi stringa.

Posso bloccare Googlebot?

Sì. In robots.txt metti User-agent: Googlebot e Disallow: /. Bloccando il crawl, la pagina non verrà indicizzata né mostrata. Per controllo più granulare usa noindex (consente il crawl ma blocca l’indice) o blocca percorsi specifici in robots.txt. Non bloccare però i bundle CSS/JS: il renderer ne ha bisogno.

Googlebot è uguale a GPTBot o PerplexityBot?

No. Sono crawler separati di aziende diverse: Googlebot indicizza per Google Search; GPTBot raccoglie dati per ChatGPT; PerplexityBot per il motore Perplexity. Ognuno ha UA e direttive robots.txt proprie. Puoi permettere Googlebot e bloccare GPTBot, o viceversa, con regole separate.

Perché Googlebot non ha ancora indicizzato la mia nuova pagina?

Cause più comuni: la pagina non è linkata da URL indicizzati, restituisce status ≠ 200, ha noindex, è bloccata in robots.txt, o dipende da JS client-side che il renderer non ha ancora processato. Usa l’ispezione URL: «Visualizza pagina testata» mostra cosa ha visto Googlebot. Nuove pagine richiedono da ore a giorni per l’indice, più a lungo su siti a bassa frequenza di crawl.

Cosa significa davvero per il tuo sito

Implicazione pratica: se il tuo contenuto dipende da JavaScript e controlli solo il ranking in Google, stai ottimizzando per il renderer più forte e ignorando il resto. I crawler AI sono più deboli e la loro quota di referral cresce ogni trimestre. Il server-side rendering non è più un’ottimizzazione Google; è un prerequisito per la visibilità AI. Ricordalo.

Per un check rapido su quali crawler vedono il tuo sito, il nostro AI visibility checker gratuito renderizza la tua URL con le stesse limitazioni di Googlebot, GPTBot, PerplexityBot e ClaudeBot e ti mostra dove compare una pagina vuota. La maggior parte dei siti che auditiamo trova almeno un template critico (prodotto o blog) che Google vede ma Perplexity no.

Quello che devo ancora capire: la logica di priorità della coda di render. I documenti parlano di risorse, ma la varianza tra siti quasi identici suggerisce altro. Se hai un dataset pulito prima/dopo, mandamelo.

Letture correlate:

• SEO per Single Page Application
• Answer Engine Optimization (AEO)
• Strumento di audit SEO gratuito
• AI Visibility Checker gratuito