Vai al contenuto
Controllo in tempo reale · scarica il tuo URL lato server

Google Crawler Simulator

Visualizza l'HTML grezzo rispetto a quello che Googlebot indicizza dopo l'esecuzione di JS — affiancati.

Googlebot non vede la tua pagina nello stesso modo in cui la vede un browser. Recupera l'HTML, esegue JavaScript, attende il completamento delle richieste di rete, quindi indicizza l'output finale renderizzato—ma solo se il rendering finisce entro il budget di crawling. Questo simulatore di crawler Google recupera qualsiasi URL come Googlebot Desktop, Googlebot Mobile, Googlebot-Image, Bingbot, o GPTBot, mostra l'HTML grezzo e l'HTML renderizzato con JavaScript fianco a fianco, elenca le risorse bloccate, segnala avvisi di tempo di rendering, e visualizza il testo visibile che effettivamente viene indicizzato.

Cosa fa effettivamente un simulatore di crawler Google

Un simulatore di crawler invia una richiesta HTTP al tuo URL con una stringa user-agent che corrisponde al bot che selezioni, recupera la risposta, e registra il codice di stato, gli header, e l'HTML grezzo. Poi carica la pagina in un browser headless—Chrome con JavaScript abilitato—attende la stabilizzazione del DOM, cattura l'HTML renderizzato finale, e lo confronta con l'HTML iniziale per mostrare cosa JavaScript ha cambiato.

Estrae il testo visibile—quello che un bot vede dopo aver rimosso i tag HTML, CSS, e script—perché è il contenuto che Google indicizza. Segnala le risorse che non hanno caricato: immagini, font, file CSS, o bundle JavaScript bloccati da CORS, 404, o errori del server. Verifica i tag meta robots, gli header X-Robots-Tag, e i tag canonical che potrebbero impedire l'indicizzazione anche se la pagina ha caricato con successo.

Tre categorie di problemi appaiono in ogni test di crawl. La prima è il contenuto mancante dall'HTML grezzo che appare solo dopo l'esecuzione di JavaScript. Se il tuo headline hero o la descrizione del prodotto sono renderizzati lato client, Googlebot potrebbe non vederli durante il fetch iniziale. La seconda è il timeout di rendering. Se JavaScript impiega più di cinque secondi per finire, Googlebot potrebbe indicizzare la pagina incompleta. La terza è le risorse bloccate. Se i tuoi file CSS o JavaScript critici ritornano 403 o 404, la pagina si renderizza rotta, e Googlebot vede un layout rotto.

Come usare questo simulatore di crawler Google

  1. Incolla l'URL della pagina in Page URL. Usa la versione canonica—https, www se applicabile, nessun parametro UTM a meno che tu non stia testando come i parametri influenzano il rendering.
  2. Scegli un User-agent dal dropdown. Googlebot Desktop è l'impostazione predefinita. Googlebot Mobile simula l'indicizzazione mobile-first con un viewport mobile. Googlebot-Image testa il crawling specifico per immagini. Bingbot testa il crawler di Bing. GPTBot simula il crawler di training di OpenAI.
  3. Premi Simulate crawler. Ottieni quattro sezioni: HTML grezzo, HTML renderizzato, testo visibile, e un log delle risorse che mostra quali file hanno caricato o fallito.
  4. Confronta le schede Raw HTML e Rendered HTML. Se la versione renderizzata ha contenuto mancante dal grezzo, quel contenuto è iniettato da JavaScript. Se il tempo di rendering supera i cinque secondi, mostriamo un avviso.
  5. Controlla la lista Blocked resources. Qualsiasi risorsa che ha ritornato uno status non-200 viene segnalata. Se CSS o JavaScript critico è bloccato, la pagina probabilmente si renderizza in modo rotto per Googlebot.
  6. Scorri verso il basso a Visible text. Questo è quello che Google indicizza. Se la tua parola chiave target appare qui, Google può classificare la pagina per essa. Se non appare, la parola chiave è invisibile.

Prova a simulare un'app a pagina singola creata con React o Vue. L'HTML grezzo spesso contiene un <div id="root"></div> vuoto e un tag script. L'HTML renderizzato mostra la pagina completa dopo l'esecuzione di JavaScript. Se il rendering impiega otto secondi a causa di chiamate API lente, avvertiamo che Googlebot potrebbe andare in timeout e indicizzare il guscio vuoto.

Perché l'HTML grezzo versus l'HTML renderizzato è importante

La pipeline di indicizzazione di Google ha due fasi. La prima è il fetch iniziale, dove Googlebot scarica l'HTML grezzo. La seconda è il rendering, dove Googlebot esegue JavaScript in un'istanza headless Chrome e cattura il DOM finale. Il rendering avviene ore o giorni dopo il fetch iniziale, e non ogni pagina viene renderizzata. Le pagine con tempi di caricamento veloci, link interni forti, e nessun errore JavaScript sono prioritarie.

Tre conseguenze pratiche.

Il contenuto nell'HTML grezzo si indicizza più velocemente. Se il tuo H1, meta description, e primo paragrafo sono nell'HTML iniziale, Googlebot può indicizzarli immediatamente. Se appaiono solo dopo l'esecuzione di JavaScript, l'indicizzazione attende la coda di rendering. Su un sito con 10.000 pagine, quel ritardo può essere di giorni o settimane.

Gli errori JavaScript bloccano l'indicizzazione. Se la tua pagina genera un errore di console durante il rendering, Googlebot potrebbe vedere una pagina bianca. Il nostro simulatore esegue la pagina e cattura i log della console. Un errore come "Uncaught TypeError: Cannot read property 'map' of undefined" può impedire a l'intera pagina di renderizzarsi.

Il budget di rendering è finito. Google alloca un budget di crawl e un budget di rendering per sito. Se il rendering della tua homepage impiega 10 secondi, Google potrebbe renderizzarla meno spesso rispetto ai competitor le cui pagine si renderizzano in due secondi. Riportiamo il tempo di rendering così sai se sei sopra budget.

Risorse bloccate e impatto sull'indicizzazione

Una risorsa bloccata è qualsiasi file—CSS, JavaScript, immagine, font—che la pagina ha provato a caricare ma ha ricevuto uno status code 4xx o 5xx, o che è stata bloccata da robots.txt o dalla politica CORS. Googlebot ignora il file e continua il rendering, ma il file mancante può rompere il layout o la funzionalità.

I file CSS critici controllano il layout. Se styles.css è bloccato da robots.txt, Googlebot renderizza la pagina senza stili, il che significa che il contenuto potrebbe essere nascosto da stati CSS predefiniti—accordion collassati, tab nascosti, modal fuori schermo. Il contenuto esiste nel DOM ma non è visibile, quindi Google potrebbe non indicizzarlo.

I file JavaScript critici controllano l'interattività e il fetching dei dati. Se app.js è bloccato, il routing lato client si rompe, e i link dentro l'app non funzionano. Se api-client.js è bloccato, la tua pagina di prodotto non può recuperare i dati di prodotto, quindi Googlebot vede uno spinner di caricamento invece dei dettagli del prodotto.

Le immagini e i font sono meno critici. Un'immagine mancante non rompe l'indicizzazione, ma potrebbe danneggiare i segnali di esperienza dell'utente se il layout della pagina si sposta o appaiono placeholder. Un font mancante cade indietro ai font di sistema, che va solitamente bene per l'indicizzazione.

Il nostro simulatore elenca ogni risorsa, il suo URL, il codice di stato, e il tipo. Se una risorsa ha fallito, mostriamo l'errore. Se è stata bloccata da robots.txt, la segnaliamo. Usa questa lista per correggere i blocchi a livello di server o nel tuo file robots.txt.

Indicizzazione mobile-first e viewport

Nel 2026, Google usa l'indicizzazione mobile-first per tutti i siti. Questo significa che Googlebot Mobile è il crawler primario, e la versione mobile della tua pagina determina le classifiche anche per le ricerche desktop. Se la tua pagina mobile nasconde il contenuto dietro un toggle "Leggi di più" o rimuove i widget della barra laterale, Googlebot non vede quel contenuto, e non conta verso le classifiche.

Testare con Googlebot Mobile come user-agent mostra quello che il crawler mobile vede. Renderizziamo la pagina con un viewport 375px—larghezza iPhone SE—così vedi il layout mobile. Se il tuo CSS nasconde elementi con larghezza mobile, mancano dall'HTML renderizzato. Se il tuo JavaScript carica pigrizia le immagini o il testo mentre l'utente scorre, e Googlebot non scorre, quel contenuto è invisibile.

Due fix sono comuni. Il primo è il rendering lato server o la generazione di sito statico, dove il contenuto completo è nell'HTML grezzo indipendentemente dal viewport. Il secondo è assicurare che il CSS mobile non imposti display: none su contenuto importante. Usa opacity: 0 o position: absolute; left: -9999px per l'accessibilità, ma anche quelli possono danneggiare l'indicizzazione se usati eccessivamente.

Tag meta robots e header X-Robots-Tag

Anche se una pagina carica con successo, un tag <meta name="robots" content="noindex"> o un header HTTP X-Robots-Tag: noindex dice a Googlebot di non indicizzarla. Il nostro simulatore verifica entrambi e li riporta nel riepilogo.

I valori comuni sono noindex (non aggiungere ai risultati di ricerca), nofollow (non seguire i link su questa pagina), noarchive (non memorizzare in cache), nosnippet (non mostrare uno snippet nei risultati), e none (equivalente a noindex, nofollow). Se il tuo sito di staging accidentalmente va live con i tag noindex ancora presenti, perdi tutto il traffico di ricerca. Verificare prima del lancio cattura questo.

L'header HTTP ha precedenza sul tag HTML se entrambi sono presenti e differiscono. Una pagina con <meta name="robots" content="index"> ma X-Robots-Tag: noindex non sarà indicizzata. Il nostro simulatore mostra entrambi così puoi individuare i conflitti.

Errori comuni

  • Renderizzare l'intera pagina lato client. Se l'HTML grezzo è vuoto e tutto appare dopo JavaScript, l'indicizzazione è lenta e fragile. Sposta il contenuto critico nell'HTML iniziale via rendering lato server o pre-rendering.
  • Bloccare JavaScript o CSS in robots.txt. Google ha bisogno di questi file per renderizzare la pagina. Disallow: *.js o Disallow: *.css rompe il rendering. Blocca questi solo se hai un buon motivo, e verifica di nuovo con il simulatore dopo.
  • Ignorare errori di console. Una singola eccezione non catturata può arrestare il rendering. Controlla il log della console nell'output del simulatore e correggi gli errori prima di fare il deploy.
  • Testare solo con un browser, non con Googlebot. I browser sono più indulgenti di Googlebot. Una pagina che funziona in Chrome potrebbe fallire in headless Chrome a causa di polyfill mancanti o controlli user-agent. Simula Googlebot per vedere l'esperienza reale.
  • Assumere che Googlebot scorri. Non lo fa. Il contenuto caricato pigrizia attivato da eventi scroll è invisibile a meno che tu non implementi Intersection Observer o carichi tutto sul rendering iniziale.
  • Non testare dopo gli aggiornamenti del framework. Un aggiornamento di versione di Next.js o Gatsby può cambiare il modo in cui la generazione statica funziona. Verificare di nuovo il rendering dopo gli aggiornamenti per confermare che il contenuto è ancora nell'HTML grezzo.

Suggerimenti avanzati

  • Testa lo stesso URL con Googlebot Desktop e Googlebot Mobile. Se il contenuto differisce, l'indicizzazione mobile-first potrebbe classificare la pagina diversamente da quanto ti aspetti.
  • Confronta il tempo di rendering su più pagine. Se la tua homepage si renderizza in 2 secondi ma le pagine di prodotto impiegano 8 secondi, identifica la chiamata API lenta o lo script pesante e ottimizzalo.
  • Controlla la sezione Visible text per la presenza di parole chiave. Se la tua parola chiave target è nella fonte HTML ma non nel testo visibile, potrebbe essere nascosta da CSS o JavaScript, il che significa che non conta verso le classifiche.
  • Usa il simulatore dopo aver deployato una nuova feature. Un flusso di checkout, widget di live chat, o script di analytics può rompere il rendering se genera errori. Catturarlo post-deploy previene cali di indicizzazione.
  • Se sono trovate risorse bloccate, fai un controllo incrociato con il robots.txt checker per confermare se robots.txt è la causa. Se no, controlla i log del server per errori 403 o CORS.
  • Combina questo strumento con il website metadata checker per confermare che title, meta, e schema sono presenti nell'HTML renderizzato, non solo nella fonte grezza.

Dopo la simulazione, se scopri che JavaScript è richiesto per il contenuto critico, considera il passaggio al rendering lato server o alla generazione statica. Se le risorse bloccate sono il problema, aggiorna il tuo robots.txt con il robots.txt file generator. Se vuoi vedere come tutti i fattori SEO on-page—rendering, metadata, canonical, link interni—si sommano, usa il SEO checklist per un audit di 20 punti.

Domande frequenti

Cos'è Googlebot?

Googlebot è il crawler web che Google usa per scoprire, recuperare, renderizzare, e indicizzare le pagine su internet. Viene in due tipi principali: Googlebot Desktop (simula un browser desktop) e Googlebot Smartphone (simula un browser mobile, che Google usa per l'indicizzazione mobile-first). Quando Googlebot effettua il crawl del tuo sito, segue i link, legge il tuo file robots.txt per vedere cosa è consentito, recupera l'HTML, esegue JavaScript se necessario, e estrae testo e metadata. Googlebot non vede il tuo sito nel modo in cui lo vede un umano. Non può interagire con i form, fare clic su pulsanti che richiedono input dell'utente, o aggirare paywall. Rispetta il budget di crawl (il numero di pagine che farà il crawl per sessione, basato sull'autorità del tuo sito), quindi i siti grandi potrebbero non avere il crawl di ogni pagina. Googlebot si identifica con una stringa user-agent che include "Googlebot". Puoi verificare le richieste di Googlebot mediante lookup DNS inversa. Il nostro simulatore ti consente di vedere cosa vede Googlebot, incluso testo visibile, risorse bloccate, e avvisi di tempo di rendering.

Come simulo un crawl di Google?

Incolla il tuo Page URL nel nostro strumento, seleziona Googlebot Desktop o Googlebot Mobile dal dropdown User-agent, e premi run. Recuperiamo la pagina usando la stessa stringa user-agent che Googlebot usa, eseguiamo JavaScript per renderizzare la pagina, ed estraiamo il testo visibile, metadata, risorse caricate, risorse bloccate, e direttive robots. L'output mostra esattamente quello che Googlebot vede: l'HTML renderizzato dopo l'esecuzione di JavaScript, il contenuto di testo che Google indicizza, qualsiasi risorsa bloccata da robots.txt, e avvisi se il tempo di rendering supera i cinque secondi. Vedi anche i tag canonical, meta robots, e dichiarazioni hreflang. Questo è critico per i siti pesanti su JavaScript (React, Next.js, Vue) dove l'HTML iniziale è un guscio e il contenuto reale si renderizza lato client. Confronta la vista HTML grezzo (quello che il tuo server invia) con la vista renderizzata (quello che Googlebot vede dopo l'esecuzione di JavaScript) per individuare i problemi di rendering. Se il contenuto manca dalla vista renderizzata, Google non può indicizzarlo. Usa questo strumento prima di lanciare le nuove pagine o dopo i cambiamenti di JavaScript.

Cos'è un web crawler?

Un web crawler (anche chiamato spider o bot) è un programma che effettua sistematicamente il browse del web seguendo i link, recuperando le pagine, ed estraendo dati. I motori di ricerca usano i crawler per scoprire e indicizzare il contenuto: Googlebot per Google, Bingbot per Bing, Yandex Bot per Yandex. I crawler iniziano con un elenco seed di URL (da sitemap o link precedentemente sottoposti a crawl), recuperano ogni pagina, analizzano l'HTML per estrarre i link, aggiungono nuovi link alla coda di crawl, e ripetono. I crawler rispettano robots.txt (un file che dichiara quali percorsi sono disconsentiti), seguono i tag canonical, e obbediscono ai limiti di velocità di crawl. Non tutti i crawler sono motori di ricerca. Alcuni sono data scraper, bot di ricerca, o strumenti di monitoraggio. Alcuni crawler sono malevoli (raccogliendo indirizzi email, scrapendo contenuto senza permesso). Puoi identificare i crawler dalla loro stringa user-agent nei log del server e bloccare quelli indesiderati via robots.txt. Per SEO, i crawler più importanti sono Googlebot, Googlebot-Image, Bingbot, e i crawler AI emergenti come GPTBot, ClaudeBot, e PerplexityBot. Il nostro strumento simula Googlebot e altri crawler importanti.

Perché Googlebot non effettua il crawl del mio sito?

Cinque cause comuni: robots.txt sta bloccando Googlebot, il tuo sito non ha link interni o esterni che lo puntano, la tua sitemap è mancante o rotta, le tue pagine ritornano errori del server, o hai accidentalmente impostato un tag meta robots noindex. Innanzitutto, controlla robots.txt e conferma che non hai una regola Disallow: /. Se l'hai, quella blocca tutti i crawler. Secondo, conferma che hai inviato una sitemap a Google Search Console. Se la tua sitemap è mancante, Googlebot si affida alla scoperta di link, che può impiegare settimane. Terzo, controlla i log del server o il report Crawl Stats di Search Console per vedere se Googlebot sta ricevendo errori o timeout. Se il tuo server è instabile, Googlebot riduce la frequenza di crawl. Quarto, ispeziona il tuo source della pagina per un tag meta robots con noindex. Questo dice a Googlebot di saltare l'indicizzazione. Quinto, conferma che il tuo sito ha link interni dalla homepage. Le pagine orfane si affidano interamente alle sitemap. Usa il nostro strumento per simulare un crawl di Googlebot e conferma che la pagina è accessibile, si renderizza correttamente, e non ha blocchi.

Come verifico se Googlebot può effettuare il crawl della mia pagina?

Incolla il tuo Page URL nel nostro strumento, seleziona Googlebot Desktop o Googlebot Mobile, ed esegui la simulazione. Recuperiamo la pagina usando l'user-agent di Googlebot, eseguiamo JavaScript per renderizzarla, e mostriamo esattamente quello che Googlebot vede: testo visibile, metadata, risorse bloccate, tag canonical, e avvisi di tempo di rendering. Se la pagina carica e si renderizza con successo, Googlebot può effettuare il crawl. Se otteniamo un 404, 403, 500, o timeout, Googlebot otterrebbe lo stesso errore. Se i file CSS o JavaScript sono bloccati da robots.txt, li segnaliamo. Se la pagina impiega più di cinque secondi per renderizzarsi, avvertiamo che questo potrebbe danneggiare il budget di crawl. Puoi anche usare lo strumento URL Inspection di Google Search Console: incolla il tuo URL, e Google lo recupera live, lo renderizza, e mostra la versione indicizzata. Il vantaggio del nostro strumento è la velocità (nessun login richiesto, risultati istantanei) e la modalità di confronto. Usa questo prima di lanciare le nuove pagine, dopo i cambiamenti di JavaScript, o quando diagnostichi i problemi di indicizzazione.

Qual è la differenza tra HTML grezzo e HTML renderizzato?

L'HTML grezzo è quello che il tuo server invia quando un browser o un crawler richiede per la prima volta una pagina, prima che qualsiasi JavaScript venga eseguito. L'HTML renderizzato è quello che la pagina sembra dopo che JavaScript è eseguito e modifica il DOM. Per i siti statici o i siti renderizzati dal server, l'HTML grezzo e quello renderizzato sono quasi identici. Per i siti renderizzati dal client (React, Vue, Angular), l'HTML grezzo è spesso un guscio minimo e tutto il contenuto si renderizza lato client dopo l'esecuzione di JavaScript. Googlebot recupera l'HTML grezzo per primo, poi attende l'esecuzione di JavaScript e renderizza la pagina in un browser headless Chrome. Se il tuo contenuto esiste solo nell'HTML renderizzato, ci vuole più tempo per Google per indicizzarlo perché il rendering è un'operazione di secondo passaggio. Il nostro strumento mostra entrambe le viste fianco a fianco: HTML grezzo (quello che il tuo server invia) e HTML renderizzato (quello che Googlebot vede dopo l'esecuzione di JavaScript). Se il contenuto critico manca dall'HTML grezzo e appare solo nella vista renderizzata, considera il rendering lato server per migliorare la velocità di indicizzazione.

Come faccio a attivare un crawl di Google?

Non puoi forzare Google a effettuare un crawl su richiesta, ma puoi richiedere l'indicizzazione e rendere il tuo sito più crawl-friendly così Google lo prioritizza. Innanzitutto, invia la tua sitemap a Google Search Console. Questo dice a Google dove sono tutte le tue pagine e quando sono state aggiornate l'ultima volta. Secondo, usa lo strumento URL Inspection in Search Console, incolla il tuo URL, e fai clic Request Indexing. Questo spinge l'URL in cima alla coda di crawl di Google. Terzo, aggiungi link interni alla nuova pagina da pagine ad alta autorità sul tuo sito perché Googlebot segue i link e prioritizza le pagine ben collegate. Quarto, aggiorna la data lastmod nella tua sitemap.xml ogni volta che pubblichi una pagina perché Google usa questo segnale per prioritizzare il contenuto fresco. Quinto, evita lo spreco di budget di crawl bloccando le pagine a basso valore in robots.txt e usando i tag canonical. Puoi anche fare ping a Google manualmente visitando google.com/ping?sitemap=yoursitemapurl dopo aver pubblicato il contenuto nuovo. Se la tua pagina ancora non sta facendo il crawl dopo 48 ore, usa il nostro strumento per simulare un fetch di Googlebot.

Googlebot può renderizzare JavaScript?

Sì, Googlebot può renderizzare JavaScript usando un browser headless Chrome, ma avviene in un secondo passaggio dopo il fetch HTML iniziale, il che introduce un ritardo. Googlebot per primo recupera l'HTML grezzo e scansiona i link, i tag canonical, e le direttive meta robots. Se la pagina è consentita, Google l'aggiunge alla coda di rendering. Un paio di ore a alcuni giorni dopo, Googlebot recupera di nuovo la pagina, esegue JavaScript, attende la stabilizzazione del DOM (fino a cinque secondi), e indicizza l'output renderizzato. Questo sistema di due passaggi significa che i siti pesanti su JavaScript sono più lenti da indicizzare rispetto ai siti renderizzati dal server. Le pagine che si affidano interamente al rendering lato client potrebbero impiegare settimane per indicizzarsi completamente. Se il tuo JavaScript non riesce a eseguirsi, Google indicizza il guscio vuoto e perde tutto il tuo contenuto. Il nostro strumento simula questo processo recuperando HTML grezzo, eseguendo JavaScript, e mostrando l'output renderizzato. Se il contenuto critico appare solo dopo l'esecuzione di JavaScript, considera il passaggio al rendering lato server o alla generazione statica per migliorare la velocità di indicizzazione.

Quali user-agent dovrei testare?

Testa Googlebot Desktop e Googlebot Mobile come minimo, perché Google usa l'indicizzazione mobile-first. Se il tuo sito ha layout o contenuto diversi per mobile versus desktop, testa entrambi per confermare la parità. Se servi contenuto diverso agli utenti mobile, Google potrebbe indicizzare la versione mobile e ignorare il contenuto solo desktop. Testa anche Googlebot-Image se le immagini sono critiche al tuo contenuto (e-commerce, portfolio, gallerie). Testa Bingbot se il traffico di Bing è importante per il tuo business (è il secondo motore di ricerca più grande negli USA). Testa GPTBot se vuoi controllare come OpenAI effettua il crawl del tuo contenuto per il training di ChatGPT. Puoi bloccarlo via robots.txt se non vuoi che il tuo contenuto sia usato. Testa altri crawler AI (ClaudeBot, PerplexityBot, CCBot) se ti importa dei dati di training AI o dei motori di risposta. Il nostro strumento supporta tutti i crawler importanti, così puoi testare ognuno e confermare che i tuoi blocchi di robots.txt funzionano. Per la maggior parte dei siti, Googlebot Mobile e Googlebot Desktop sono sufficienti.

Cos'è il budget di tempo di rendering?

Il budget di tempo di rendering è l'importo di tempo che Googlebot alloca per eseguire JavaScript e renderizzare la tua pagina prima di indicizzare quello che ha. Il testing del settore suggerisce che Googlebot attende fino a cinque secondi per l'esecuzione di JavaScript da finire e per il DOM da stabilizzarsi. Se la tua pagina impiega più tempo a causa di script di terze parti lenti o rendering pesante, Googlebot potrebbe indicizzare una versione incompleta della pagina o saltare il rendering del tutto. Questo è particolarmente problematico per le app a pagina singola dove l'HTML grezzo è un guscio vuoto. Per stare entro il budget, riduci la dimensione del bundle JavaScript (code-split, tree-shake il codice non usato), rinvia o carica pigrizia gli script non critici, renderizza lato server o genera staticamente il contenuto chiave, e evita di bloccare il thread principale con script di lunga durata. Il nostro strumento misura il tempo di rendering e segnala le pagine che impiegano più di cinque secondi. Se la tua pagina si renderizza in meno di due secondi, sei al sicuro entro il budget. Se supera i cinque secondi, il contenuto critico potrebbe non essere indicizzato.

Strumenti gratuiti correlati

Tutti gli strumenti →
Più popolare
Verificatore di Backlink Gratuito

Verifica qualsiasi dominio. Authority Score, domini di riferimento, anchor text. Nessuna registrazione.
Controllo dal vivo
Robots.txt Checker

Analizza, testa per user-agent (inclusi GPTBot/ClaudeBot), rileva conflitti di regole.
Controllo dal vivo
Website Metadata Checker

Visualizza la tua pagina come la vedono Google, Twitter, LinkedIn e Slack — affiancati.
Istantaneo
Checklist SEO

Inserisci un URL — audituiamo 20 controlli on-page in meno di 5 secondi.
Controllo dal vivo
HTTP Status Checker

Controlla fino a 50 URL contemporaneamente — visualizza codici di stato, redirect e tempi di risposta in pochi secondi.
Controllo dal vivo
Page Size Checker

Vedi il peso reale di qualsiasi pagina — byte del doc HTML, dimensione wire in gzip, tempo di risposta e le richieste di asset che il browser avrà comunque bisogno.
Controllo dal vivo
Robots.txt Generator

Preset per il tuo CMS + controlli espliciti per i crawler AI rilevanti nel 2026.