Controllo dello stato del server

Inserisci fino a 100 URL (ogni URL deve essere su una riga separata)

Server Status Checker – Controlla lo stato e la velocità di risposta del server

Il Server Status Checker ti permette di verificare in un'unica operazione lo stato e il tempo di risposta del server di un gran numero di siti web, fino a un massimo di 100 URL per ogni scansione. Inserisci gli indirizzi che vuoi analizzare e lo strumento restituisce per ciascuno il codice di stato HTTP e la velocità di risposta del server, dandoti una panoramica immediata dell'accessibilità e delle prestazioni di ogni sito. È uno strumento indispensabile per monitorare i propri progetti, verificare lo stato dei competitor e diagnosticare problemi di raggiungibilità prima che si trasformino in danni al posizionamento.

Tempo di risposta del server e TTFB: cosa significano

Quando parliamo di tempo di risposta del server ci riferiamo a quello che in ambito tecnico viene chiamato TTFB (Time to First Byte): il tempo che intercorre tra la richiesta inviata dal browser e il momento in cui il browser riceve il primo byte della risposta dal server. È la misura più diretta di quanto velocemente l'infrastruttura che ospita un sito è in grado di elaborare una richiesta e iniziare a restituire i dati. Il TTFB include il tempo di risoluzione DNS, la connessione TCP, l'eventuale handshake TLS per HTTPS, e il tempo di elaborazione lato server prima che la risposta inizi a viaggiare verso l'utente.

Le soglie di riferimento stabilite da Google nella documentazione ufficiale di web.dev, aggiornata a novembre 2025 e misurate al 75° percentile delle visite reali, sono chiare: un TTFB inferiore a 800 millisecondi è considerato buono, tra 800 ms e 1.800 ms necessita di miglioramento, oltre 1.800 ms è classificato come scarso. Nella pratica, tuttavia, gli 800 millisecondi vanno intesi come una soglia minima di sicurezza, non come un obiettivo: per un posizionamento competitivo, i professionisti puntano a un TTFB inferiore a 200 millisecondi sulle pagine cached, un valore che lascia ampio margine per raggiungere la soglia "buona" di 2,5 secondi sul Largest Contentful Paint, la metrica Core Web Vitals più direttamente influenzata dalla velocità del server.

Perché il tempo di risposta è cruciale per la SEO

Il TTFB non è formalmente uno dei tre Core Web Vitals (che sono LCP, INP e CLS), ma è il fondamento su cui tutti e tre si appoggiano. Il Largest Contentful Paint — la metrica che misura quanto velocemente l'elemento visivo principale della pagina diventa visibile — non può mai essere più veloce del TTFB, perché il browser non può renderizzare ciò che non ha ancora ricevuto. Secondo i dati del Web Almanac 2025, i siti con un LCP scarso spendono in media 2,27 secondi solo di TTFB, esaurendo quasi interamente il budget di 2,5 secondi previsto dalla soglia "buona" di Google prima ancora che il browser abbia iniziato a costruire la pagina. Correggere il TTFB è quindi spesso l'intervento più efficace per migliorare complessivamente i Core Web Vitals.

I numeri confermano la correlazione tra velocità del server e posizionamento. Un'analisi condotta su 10 milioni di risultati di ricerca alla fine del 2025 ha rilevato che i siti nelle posizioni 1-3 presentano un TTFB mediano di 180 millisecondi, mentre quelli nelle posizioni 7-10 raggiungono i 420 millisecondi. La correlazione non equivale a una relazione causale diretta, ma il pattern è consistente attraverso settori diversi e suggerisce con chiarezza che un server lento rappresenta un handicap significativo nella competizione per le prime posizioni.

C'è poi un impatto diretto sul crawl budget. La documentazione di Google aggiornata a dicembre 2025 afferma esplicitamente che quando un sito risponde velocemente, Google aumenta il limite di scansione, e quando rallenta o restituisce errori, lo riduce. Per siti con migliaia di pagine, un server lento può significare che Google impiega settimane anziché giorni per scoprire e indicizzare contenuti nuovi o aggiornati, creando un ritardo competitivo rispetto ai siti più rapidi nella stessa nicchia.

Il tempo di risposta e l'esperienza utente

L'impatto della velocità del server non si limita ai motori di ricerca: si traduce direttamente nel comportamento degli utenti e nei risultati di business. Le ricerche sul tema convergono su dati inequivocabili: le pagine che si caricano in meno di 2 secondi mostrano una frequenza di rimbalzo intorno al 9%, mentre quelle che superano i 5 secondi vedono la frequenza di rimbalzo esplodere fino al 38%. Ogni secondo di ritardo oltre la soglia di 2,5 secondi di LCP comporta un aumento del 32% dei rimbalzi, e un singolo secondo aggiuntivo di tempo di caricamento può ridurre le conversioni del 7%. Per un e-commerce che genera 10.000 euro al mese, quel secondo vale 700 euro di mancato fatturato ogni mese.

Il meccanismo è semplice e brutale: l'utente arriva, la pagina non si carica abbastanza velocemente, l'utente torna ai risultati di ricerca e clicca su un altro sito. Non si tratta di un fastidio temporaneo: nella maggior parte dei casi quell'utente non tornerà mai. Il tempo di risposta del server è il primo anello di questa catena, e se è lento, nessuna ottimizzazione del front-end potrà compensare completamente il ritardo accumulato prima ancora che il browser abbia ricevuto il primo byte della pagina.

I tre fattori che determinano la velocità di risposta

La velocità con cui un server risponde dipende dall'interazione di tre elementi, ciascuno dei quali rappresenta un potenziale collo di bottiglia che questo strumento ti aiuta a individuare.

Il primo è la distanza fisica tra il server e l'utente. I dati viaggiano attraverso cavi in fibra ottica alla velocità di circa 200.000 km/s, il che significa che la distanza introduce una latenza ineliminabile. Un server a Francoforte serve un utente a Milano con una latenza di pochi millisecondi, mentre un server a New York aggiunge 100-150 millisecondi di ritardo di rete prima ancora che il server inizi a elaborare la richiesta. Dati di monitoraggio reale mostrano che utenti europei vicini al server registrano TTFB sotto i 170 millisecondi, mentre utenti dall'India sperimentano un TTFB tre volte superiore. Se il tuo pubblico è in Italia e il tuo server è dall'altra parte dell'oceano, stai accumulando un debito di latenza che nessuna ottimizzazione software può eliminare.

Il secondo fattore è la qualità del servizio di hosting. La differenza tra un hosting condiviso economico e un hosting gestito con risorse garantite non è solo una questione di prezzo: è una differenza che si riflette direttamente nel TTFB e, a cascata, nel posizionamento. Un hosting condiviso sovraccarico — in cui decine o centinaia di siti competono per le stesse risorse CPU, RAM e disco — produce un TTFB instabile che può oscillare tra 150 e 1.500 millisecondi a seconda del carico. Questa variabilità è particolarmente insidiosa perché il TTFB medio potrebbe sembrare accettabile, ma Google misura i Core Web Vitals al 75° percentile: significa che basta un 25% di richieste lente per far scivolare l'intero sito nella zona "scarsa". Hosting con server LiteSpeed, dischi NVMe SSD, caching server-side integrato e risorse non condivise producono un TTFB costantemente basso che, moltiplicato per ogni visita e ogni pagina nell'arco dei 28 giorni di raccolta dati CrUX, spinge le metriche solidamente nella zona "buona".

Il terzo fattore è l'ottimizzazione della pagina stessa. Anche con un server eccellente e geograficamente vicino, una pagina che genera query di database inefficienti, carica plugin non necessari, non utilizza caching o serve immagini non compresse avrà un tempo di risposta più alto del necessario. Il peso complessivo della pagina, la complessità del codice server-side, la presenza di redirect interni e il numero di risorse esterne da caricare contribuiscono tutti al tempo totale percepito dall'utente. Strumenti come il Page Size Checker ti aiutano a valutare questo aspetto e a identificare le pagine che necessitano di ottimizzazione.

Il ruolo delle CDN nella velocità di risposta

Una Content Delivery Network (CDN) come Cloudflare, Fastly o Akamai distribuisce copie cached delle risorse statiche del sito — immagini, CSS, JavaScript, font — su decine di server edge distribuiti nel mondo, servendo ogni utente dal nodo geograficamente più vicino. L'effetto sul TTFB degli asset statici è immediato e misurabile: la latenza si riduce al minimo perché la distanza fisica viene quasi azzerata.

Tuttavia, è fondamentale capire cosa una CDN può e cosa non può risolvere. Una CDN ottimizza la consegna dei contenuti statici e, nelle configurazioni più avanzate, può anche cacheare l'intera pagina HTML all'edge. Ma per i contenuti dinamici — pagine generate dal CMS a ogni richiesta, operazioni di carrello e checkout, risultati di ricerca interna — la richiesta deve comunque raggiungere il server di origine. Se quel server impiega 2 secondi per generare la pagina, la CDN non può comprimere quel tempo. Per questo motivo, una CDN complementa un buon hosting ma non lo sostituisce: il server di origine deve essere veloce di suo, e la CDN si occupa di distribuire efficacemente ciò che quel server produce.

Codici di stato HTTP: cosa significano i risultati

Oltre al tempo di risposta, il Server Status Checker restituisce il codice di stato HTTP di ogni URL analizzato. Questi codici sono il linguaggio con cui il server comunica al browser e ai crawler cosa sta succedendo con la pagina richiesta, e saperli leggere è fondamentale per la diagnostica SEO.

Un codice 200 indica che tutto funziona correttamente: il server ha ricevuto la richiesta, l'ha elaborata e sta restituendo il contenuto della pagina. È lo stato normale e desiderato per ogni URL del tuo sito. I codici della famiglia 3xx (301, 302, 307, 308) indicano un reindirizzamento, permanente o temporaneo, verso un altro URL: sono normali quando intenzionali, ma la loro presenza su pagine che dovrebbero rispondere direttamente può segnalare un problema di configurazione. I codici 4xx indicano errori lato client, il più comune dei quali è il 404 (pagina non trovata): se compare su un URL che dovrebbe essere attivo, significa che il contenuto è stato rimosso o spostato senza un redirect, con conseguenze immediate su indicizzazione e traffico. I codici 5xx indicano errori lato server — il server non è riuscito a completare la richiesta. Un 500 (Internal Server Error) o un 503 (Service Unavailable) segnalano problemi nell'infrastruttura che impediscono al sito di funzionare. Se questi errori si verificano con frequenza, Google può ridurre il crawl rate e, nei casi più gravi, rimuovere temporaneamente le pagine dall'indice.

Lo stato attuale della velocità sul web

I dati globali del Web Almanac 2025, basati sulle misurazioni reali del Chrome User Experience Report, offrono una fotografia importante: solo il 44% dei siti mobile raggiunge un TTFB classificato come "buono", una percentuale che è rimasta sostanzialmente invariata rispetto al 41% del 2021, rendendo il TTFB la metrica prestazionale più stagnante dell'intero web. In altre parole, più della metà dei siti web ha un problema di velocità del server che non ha ancora risolto. Complessivamente, solo il 48% delle pagine mobile supera tutte e tre le soglie dei Core Web Vitals, il che significa che oltre la metà del web mobile sta fallendo gli standard minimi di performance fissati da Google.

Questi numeri rappresentano un'opportunità per chi investe nella velocità: in un panorama in cui la maggioranza dei siti ha un TTFB mediocre, un server che risponde costantemente sotto i 200 millisecondi offre un vantaggio competitivo concreto, misurabile e cumulativo su ogni singola pagina, ogni singolo visitatore e ogni ciclo di valutazione da parte dei ranking systems di Google.

Come usare i risultati del Server Status Checker

Dopo aver inserito gli URL da analizzare, osserva per ciascuno il tempo di risposta restituito. Se il tuo sito mostra un tempo superiore a 800 millisecondi, hai un problema che sta influenzando i Core Web Vitals e probabilmente il posizionamento. Se supera 1,8 secondi, il problema è grave e richiede un intervento urgente sull'infrastruttura. Confronta il tempo di risposta del tuo sito con quello dei competitor diretti: se i loro server rispondono in 150 millisecondi e il tuo in 900, stai partendo con uno svantaggio strutturale che nessun contenuto, per quanto eccellente, potrà compensare completamente.

Presta attenzione anche alla coerenza dei risultati. Se esegui il test più volte e il tempo di risposta del tuo sito oscilla significativamente tra una misurazione e l'altra, è un segnale tipico di hosting sovraccarico con risorse condivise. La stabilità del TTFB è importante almeno quanto il suo valore assoluto, perché Google misura le prestazioni al 75° percentile: anche pochi picchi di lentezza possono trascinare l'intero punteggio nella zona critica.

Lo strumento è pensato anche per il monitoraggio periodico. Le prestazioni di un server non sono statiche: cambiano con il traffico, con le modifiche al sito, con gli aggiornamenti del CMS e con le attività degli altri siti sullo stesso server condiviso. Eseguire un controllo regolare con il Server Status Checker, insieme all'analisi dei Core Web Vitals in Google Search Console, ti permette di individuare tempestivamente un degrado delle prestazioni prima che si traduca in una perdita di posizionamento.