Monitoraggio uptime WordPress: strumenti, configurazione e cosa monitorare davvero

Monitoraggio uptime WordPress configurazione UptimeRobot

Setup minimo raccomandato: crea un account UptimeRobot gratuito, aggiungi un monitor HTTP(s) sulla homepage con intervallo 5 minuti, configura almeno due canali di alert (email + Telegram o Slack), aggiungi monitor su wp-login.php e una pagina interna con contenuto dinamico. Per WooCommerce aggiungi anche carrello e checkout. Attiva il monitoraggio SSL. Integra Google Search Console per gli errori di crawl. Ogni elemento è sviluppato in dettaglio qui sotto.

Il tuo sito è andato offline la notte scorsa per due ore. I visitatori hanno trovato una pagina di errore. Google ha tentato di crawlare cinque URL e ha ricevuto altrettanti errori 5xx. Tu lo hai scoperto la mattina dopo, per caso, aprendo il browser.

Questo accade quando non c’è nessun sistema di monitoraggio attivo. Configurarne uno richiede venti minuti con UptimeRobot gratuito; da quel momento ricevi un alert entro cinque minuti da qualsiasi downtime, prima che lo scoprano i tuoi visitatori.

Uptime al 100% non esiste: e non è questo il punto

Qualsiasi hosting promette il 99,9% di uptime. In numeri reali, significa circa 8,7 ore di downtime all’anno; il 99,99% sono 52 minuti. Nessun hosting arriva al 100% perché i server richiedono manutenzione, le reti hanno picchi e gli aggiornamenti di sistema portano con sé brevi interruzioni.

Le interruzioni brevi sono inevitabili. Quello su cui si può intervenire è la finestra tra quando il sito va offline e quando chi lo gestisce lo sa e interviene. Senza monitoraggio quella finestra dura ore. Con UptimeRobot dura cinque minuti.

Mantenere WordPress in salute nel tempo non è una strategia per i casi di emergenza, serve per prevenirli.

HTTP 200 non significa sito funzionante

HTTP 200 sito online ma rotto WordPress

Tutti gli strumenti di monitoraggio uptime funzionano allo stesso modo: inviano una richiesta HTTP al sito, controllano il codice di risposta, e se il server risponde 200 segnano tutto come online. Il problema è che un sito WordPress può restituire HTTP 200 ed essere completamente inutilizzabile per chi lo visita.

Ho visto questa situazione decine di volte: sempre una di queste tre.

  • Aggiornamento plugin rompe il checkout WooCommerce. La homepage carica normalmente, il monitor è felice. Chiunque provi ad acquistare trova un errore PHP. Il monitor non rileva nulla perché non controlla quella pagina.
  • Errore di memoria PHP su pagine con query complesse. Le pagine statiche rispondono perfettamente; le pagine dinamiche vanno in timeout. Il server dice 200, il sito è praticamente offline per metà dei visitatori.
  • Il tema si rompe su mobile dopo un aggiornamento. Il server risponde, la pagina carica. È illeggibile. Tecnicamente online, praticamente perso.

La soluzione: monitora sempre più URL, non solo la homepage. La homepage può rispondere 200 mentre il checkout è rotto, il database risponde a metà o il tema è esploso su mobile.

Cosa monitorare su un sito WordPress

Gli URL da aggiungere subito

  • wp-login.php — se questa pagina non risponde, nessun amministratore entra nella dashboard. È anche il primo segnale che qualcosa è andato storto con PHP.
  • Una pagina interna con contenuto dinamico — un articolo recente, una pagina con shortcode. Rileva problemi con il database che sulla homepage statica non si vedono.
  • Carrello e checkout (solo WooCommerce) — le pagine più soggette a rotture dopo aggiornamenti. Ogni minuto di downtime qui è un ordine perso.
  • Certificato SSL — UptimeRobot nel piano gratuito monitora la scadenza e avvisa 30 giorni prima. Utile anche con Let’s Encrypt: se il rinnovo automatico fallisce silenziosamente, lo scopri in tempo. Sul tema del certificato SSL su WordPress ho scritto una guida dedicata alla configurazione del certificato SSL su WordPress.

Le metriche che contano

  • Tempo di risposta. Un aumento progressivo da 300ms a 600ms nel giro di settimane è quasi sempre il segnale precoce di un problema: database sovraccarico, memory limit in esaurimento, un plugin che scala male. Intercettarlo qui evita problemi più gravi dopo.
  • Codice HTTP. 200 è normale; 301/302 sono redirect da verificare siano corretti; 404 indica pagine non trovate; 500 è errore del server. Configura il monitor per avvisarti su qualsiasi codice diverso da 200.
  • Percentuale uptime mensile. Il dato che serve quando parli con il tuo hosting provider di un problema ricorrente. Con i numeri in mano la conversazione è diversa.

Quanti URL monitorare: la tabella per tipologia di sito

Non esiste un numero universale di URL da monitorare, dipende dalla struttura del sito. Questa tabella riassume il setup minimo per ogni tipologia. Si può sempre aggiungere, ma questi sono i monitor senza i quali il sistema è cieco su qualcosa di critico.

Tipologia sitoURL da monitorarePerché
Sito vetrina (3 URL)Homepage · Pagina contatti · Certificato SSLLe tre pagine che un potenziale cliente visita prima di chiamare
Sito aziendale con blog (5 URL)Homepage · Pagina contatti · Un articolo recente · wp-login.php · Certificato SSLwp-login.php rileva problemi PHP che sulla homepage non si vedono
E-commerce WooCommerce (8 URL)Homepage · Pagina prodotto · Carrello · Checkout · Conferma ordine · Area account · wp-login.php · Certificato SSLOgni URL corrisponde a una fase del funnel di acquisto — se una si rompe, perdi vendite
Multisito WordPress (10+ URL)Homepage di ogni sottodominio o percorso + wp-login.php + Certificato SSL per dominioUn problema su un nodo può non propagarsi agli altri — monitorare separatamente

La regola generale: ogni URL che genera contatti o vendite va monitorato separatamente. La homepage è la pagina più stabile — paradossalmente è quella che si rompe meno. Le pagine dinamiche, i form, il checkout sono quelle che si rompono di più dopo un aggiornamento e quelle che nessun tool monitora automaticamente.

Quanto costa davvero un’ora di downtime

Uptime al 99,9% suona rassicurante. In numeri assoluti, per un e-commerce che fattura 200.000€ l’anno, significa circa 200€ di potenziale perdita ogni ora di downtime — calcolata sulla media, non sui picchi. Durante il Black Friday o una campagna attiva, quel numero moltiplica.

La formula per calcolare il costo del downtime sulla propria attività:

Fatturato annuo ÷ 8.760 ore = fatturato orario medio Fatturato orario × tasso di conversione dal sito = perdita potenziale per ora di downtime

Esempio concreto: e-commerce con 200.000€ di fatturato annuo, 30% generato dal sito (60.000€), tasso di conversione del 2%. Il fatturato orario dal sito è circa 6,85€. Sembra poco — ma in un’ora di downtime durante una campagna attiva con traffico 10x la media, diventano 68€ persi. In un weekend di Black Friday con traffico 20x, si arriva a 137€ all’ora.

Il punto non è il numero assoluto: è che questo calcolo cambia completamente la conversazione con il proprio hosting provider quando si negozia un piano, e la valutazione di quanto vale configurare un sistema di monitoraggio professionale invece di affidarsi solo all’email di downtime che arriva quando ormai è troppo tardi.

Per un sito di servizi che acquisisce lead — studio medico, commercialista, avvocato — il calcolo è diverso ma ugualmente utile: quante richieste di contatto perdi in un’ora di downtime? Se una richiesta vale mediamente 500€ di fatturato potenziale e il sito genera 3 richieste al giorno, ogni ora di downtime ha un costo atteso di circa 60€ in opportunità perse.

I segnali che precedono il downtime

Il downtime completo è quasi sempre preceduto da segnali deboli che UptimeRobot registra ma che in molti ignorano. Il tempo di risposta è il più utile: un sito che risponde normalmente in 200-300ms e inizia a rispondere in 600-800ms senza motivo apparente non sta andando male per caso.

Le cause più comuni di questo pattern: il database è cresciuto in modo disordinato e le query diventano più lente; un plugin ha un memory leak che si accumula nel tempo; l’hosting condiviso ha aggiunto altri siti e le risorse si sono ridotte. In tutti e tre i casi il problema è già presente e sta peggiorando.

Configurare UptimeRobot per ricevere alert anche quando il tempo di risposta supera una soglia — non solo quando il sito va offline — è l’unica configurazione che intercetta questi segnali prima che diventino un problema visibile ai visitatori.

UptimeRobot: configurazione completa con il piano gratuito

UptimeRobot e’ il punto di partenza per chiunque gestisca un sito WordPress. Il piano gratuito include fino a 50 monitor con controllo ogni 5 minuti, alert email illimitati e monitoraggio SSL. Per la grande maggioranza dei siti WordPress e’ piu’ che sufficiente. Registrati su uptimerobot.com.

Creare il primo monitor

  • Registra un account su uptimerobot.com
  • Dalla dashboard clicca su Add New Monitor.
  • Monitor Type: seleziona HTTP(s).
  • Friendly Name: un nome riconoscibile, es. Nome Sito — Homepage.
  • URL: inserisci l’indirizzo completo del sito con https://.
  • Monitoring Interval: seleziona 5 minutes.
  • Clicca Save. Il monitor e’ attivo.

Configurare gli alert: perché ne servono almeno due

Vai su My Settings → Alert Contacts e verifica che l’email sia confermata. Poi aggiungi un secondo canale: UptimeRobot supporta Slack, Telegram, webhook e notifiche push tramite app.

Il motivo per cui servono almeno due canali: se sei fuori casa senza accesso email e il sito va offline, il Telegram o lo Slack ti arriva comunque sul telefono. L’email sola è un punto di fallimento singolo che non ha senso accettare quando il secondo canale è gratuito e si configura in due minuti.

“Up & Down”: vuoi sapere sia quando il sito va offline sia quando torna online. Senza la notifica di ripristino non sai mai quanto è durato il downtime, e quella durata è l’informazione che serve quando parli con l’hosting o quando devi spiegare un’interruzione a un cliente.

Aggiungere i monitor per le pagine critiche

wp-login.php: UptimeRobot potrebbe segnalare un 302 se sei già loggato. In Advanced Settings → Custom HTTP Statuses aggiungi 302 come codice accettabile per quel monitor specifico.

Per WooCommerce aggiungi la pagina del carrello e del checkout come monitor separati. Sono le pagine che si rompono più spesso dopo aggiornamenti e le prime che i clienti abbandonano senza dirti nulla.

Jetpack: se vuoi il minimo senza configurazioni esterne

Chi gestisce un sito semplice e non vuole creare un account su un servizio esterno ha un’alternativa integrata: Jetpack include il monitoraggio downtime nel piano gratuito, con notifiche email immediate quando il sito va offline.

Il limite è chiaro: Jetpack monitora solo la homepage con un controllo meno frequente di UptimeRobot, e l’alert arriva solo via email. Non ha la gestione multicanale, non permette di aggiungere URL critici come il checkout, e non ha i grafici storici del tempo di risposta.

Va bene come punto di partenza per un sito vetrina senza traffico critico. Per qualsiasi sito che usa il web come strumento di acquisizione clienti o che ha funzioni e-commerce, UptimeRobot gratuito è la scelta corretta.

Uptime Kuma: se vuoi controllo totale e hai un VPS

Uptime Kuma è open source, self-hosted, senza limiti di monitor né di frequenza. Puoi controllare ogni 20 secondi invece di ogni 5 minuti; per un e-commerce WooCommerce dove ogni minuto di downtime si misura in Euro, questa differenza conta.

Il limite tecnico non va sottovalutato: richiede Docker o Node.js su un server separato da quello del sito. Se installi Uptime Kuma sullo stesso server che monitora, quando il server va offline vai giù insieme al monitor. Per chi gestisce solo il proprio sito, UptimeRobot gratuito è la scelta corretta. Uptime Kuma ha senso per chi gestisce siti di clienti e vuole un pannello centralizzato senza dipendere da servizi esterni.

StatusCake: quando ha senso passare al piano a pagamento

StatusCake nel piano gratuito non aggiunge molto rispetto a UptimeRobot. Il piano a pagamento, circa 20€ al mese, ha senso in tre casi concreti.

  • Monitoraggio da più location geografiche: verifica che il sito sia raggiungibile da Europa, Asia e USA contemporaneamente. Utile per traffico internazionale o per CDN che potrebbero avere problemi regionali mentre il server principale è online.
  • Monitoraggio dei Core Web Vitals nel tempo: misura LCP e CLS su base continuativa; puoi rilevare regressioni di performance prima che impattino il ranking.
  • Report mensili di uptime: per chi gestisce siti di clienti e deve rendicontare la disponibilità del servizio con dati verificabili.

Per un freelance che gestisce il proprio sito, UptimeRobot gratuito è sufficiente. StatusCake a pagamento ha senso quando la gestione di siti clienti diventa un servizio strutturato che richiede documentazione formale.

Google Search Console come secondo livello di monitoraggio

Search Console è la fonte più autorevole su come Google vede il sito; integrarla nel sistema di monitoraggio costa zero. Va controllata regolarmente, non solo quando c’è un problema.

Come leggere il report Copertura

Vai su Indicizzazione → Pagine. Quello che cerchi non è il numero assoluto di pagine indicizzate, ma le variazioni nel tempo. Un picco improvviso di errori 5xx nella colonna “Escluse” indica che Google ha tentato di crawlare il sito durante un periodo di downtime. Se quel picco coincide con una data in cui sai che il sito ha avuto problemi, conferma la correlazione. Se è inaspettato, hai un problema da investigare.

La sezione “Pagine con reindirizzamento” è utile per verificare che i redirect 301 configurati siano corretti dopo migrazioni o riorganizzazioni della struttura del sito. Un redirect che punta al posto sbagliato passa inosservato finché Google non lo segnala.

Impressioni e clic: il segnale più lento ma più significativo

Un calo verticale del traffico organico senza modifiche al sito è quasi sempre un problema tecnico: downtime prolungato non rilevato, penalizzazione o un aggiornamento che ha rotto qualcosa di strutturale. Il calo nel grafico impressioni/clic arriva con un ritardo di 2-7 giorni rispetto all’evento che lo ha causato; questa latenza significa che quando lo vedi è già successo da un po’.

Per questo il monitoraggio uptime in tempo reale e Search Console non sono alternativi; sono complementari. UptimeRobot ti dice quando è successo qualcosa. Search Console ti dice quanto ha impattato su Google.

Problemi di sicurezza: controllo settimanale senza eccezioni

Controlla Sicurezza e azioni manuali ogni settimana senza eccezioni. Google rileva malware spesso prima che tu te ne accorga; trovarlo qui significa che la compromissione è già visibile a Google e potenzialmente ai visitatori. Intervieni entro poche ore: ogni ora in più peggiora l’impatto sul ranking e sulla fiducia degli utenti.

Ricevere un alert è una cosa. Sapere cosa fare nei dieci minuti successivi è un’altra. Se gestisci un sito che conta per la tua attività, manutenzione sito web WordPress — intervengo io quando scatta.

In sintesi

UptimeRobot gratuito è il punto di partenza: 50 monitor, controllo ogni 5 minuti, alert email. Si configura in venti minuti e copre le esigenze della grande maggioranza dei siti WordPress.

L’errore più comune è monitorare solo la homepage. La homepage può rispondere 200 mentre il checkout è rotto, il database risponde a metà o il tema è esploso su mobile. Aggiungi wp-login.php, una pagina con contenuto dinamico e per WooCommerce carrello e checkout.

Il tempo di risposta dice più del codice HTTP. Un trend in aumento nel corso di settimane è quasi sempre il segnale precoce di qualcosa che sta peggiorando: database in crescita disordinata, plugin che scala male, memory limit vicino al limite. Intercettarlo prima del downtime completo è l’unico modo per evitarlo.

Uptime Kuma se hai un VPS e vuoi controllo totale senza dipendere da servizi esterni. StatusCake a pagamento se gestisci siti di clienti e hai bisogno di monitoraggio da più location e report mensili. Jetpack se vuoi il minimo senza configurazioni esterne per un sito semplice. Per tutto il resto, UptimeRobot gratuito fa il lavoro.

Domande frequenti (FAQ)

Con UptimeRobot gratuito il controllo è ogni 5 minuti; sufficiente per la maggior parte dei siti. Per e-commerce WooCommerce con transazioni continue, considera il piano a pagamento di UptimeRobot (controllo ogni 60 secondi) o Uptime Kuma self-hosted che arriva a 20 secondi. La frequenza di controllo determina quanto velocemente ricevi l’alert e quanto tempo il sito rimane offline senza che tu lo sappia.

Non direttamente: Google non legge i dati di UptimeRobot. L’impatto indiretto è reale: downtime frequenti o prolungati aumentano gli errori di crawl in Search Console, riducono le impressioni organiche e nei casi peggiori portano a una penalizzazione temporanea del ranking. Monitorare serve a intervenire velocemente; è l’unica cosa che riduce l’impatto SEO del downtime.

Tre possibilità. Il downtime era temporaneo e si è risolto in pochi secondi prima che tu apressi il browser; UptimeRobot lo registra comunque perché ha rilevato quell’istante. Il problema riguardava solo la posizione geografica del server di monitoraggio; alcune CDN o configurazioni di firewall bloccano le richieste da certi IP. Il problema è intermittente e si manifesta sotto carico; il browser aperto a mano non replica le condizioni del picco.

Sì. Il piano gratuito supporta monitor HTTP(s), ping, porte TCP/UDP e keyword monitoring. Per il DNS aggiungi un monitor di tipo Port sulla porta 53. Per le email un monitor sulla porta 25 o 587. Il keyword monitor è utile per verificare che una parola chiave specifica sia presente nella risposta del sito; si può usare per rilevare defacement o contenuti iniettati da malware.

UptimeRobot Pro permette di configurare maintenance windows: periodi in cui il monitor viene messo in pausa automaticamente. Nel piano gratuito devi farlo manualmente dalla dashboard prima di iniziare una manutenzione programmata. La buona prassi è mettere il monitor in pausa prima di qualsiasi aggiornamento importante e riattivarlo subito dopo per verificare che tutto sia tornato online correttamente.