Un sito WordPress può sembrare perfettamente funzionante e nascondere comunque configurazioni superate, operazioni pianificate che non partono o comunicazioni interne che falliscono. All’opposto, può mostrare un avviso tecnico senza che esista un guasto immediato. Per questo Site Health WordPress, chiamato Salute del sito nell’interfaccia italiana, è un buon punto di partenza per una diagnosi ragionata. Non sostituisce i backup, il monitoraggio delle prestazioni o l’analisi dei log, ma raccoglie controlli utili in un unico posto. In questa guida vediamo dove trovarlo, come leggere i risultati e quali interventi effettuare senza trasformare una segnalazione innocua in un problema vero.
Che cos’è Site Health e cosa controlla davvero
Site Health è una funzionalità inclusa nel core di WordPress. Esegue una serie di test relativi alla configurazione del sito e del server, agli aggiornamenti, ai servizi necessari per il funzionamento di WordPress e ad alcune buone pratiche. I controlli possono cambiare tra versioni di WordPress, ambienti di hosting e plugin installati: per questo due siti apparentemente identici possono mostrare risultati differenti. La schermata non è una certificazione di sicurezza, non garantisce che il sito sia veloce e non dimostra che ogni plugin sia compatibile con gli altri. È soprattutto uno strumento di diagnostica preventiva. Il suo valore sta nel collegare un messaggio tecnico a una verifica concreta, non nel cercare di ottenere a ogni costo un indicatore perfetto.
Dove trovare Salute del sito nella bacheca WordPress
Accedi alla bacheca con un account che disponga dei permessi necessari e apri Strumenti → Salute del sito. La pagina presenta normalmente due schede principali: Stato e Informazioni. Nella prima compaiono i controlli e le raccomandazioni; nella seconda trovi un riepilogo tecnico dell’installazione. Alcune installazioni possono mostrare un collegamento alla salute del sito anche nella dashboard. Se la voce non è visibile, verifica i permessi dell’utente e l’eventuale presenza di personalizzazioni amministrative. Non serve installare un plugin soltanto per accedere a questa funzione: fa già parte di WordPress.
Come leggere la scheda Stato senza farsi ingannare dai colori
I risultati sono generalmente organizzati tra problemi critici, miglioramenti raccomandati e test superati. La parola “critico” indica che il controllo considera la situazione importante, non che il sito sia necessariamente offline. Un avviso sulle comunicazioni interne, per esempio, può incidere sull’editor o su funzioni specifiche anche se le pagine pubbliche continuano ad aprirsi. Un miglioramento raccomandato segnala invece una condizione da valutare: può riguardare prestazioni, manutenzione o impostazioni non ideali. Apri ogni voce e leggi la spiegazione prima di intervenire. Annota il testo esatto del messaggio, quando è comparso e se coincide con modifiche recenti. Un messaggio isolato, privo di sintomi, merita una verifica diversa da un errore accompagnato da checkout bloccato o pagine irraggiungibili.
La priorità giusta: rischio reale, impatto e reversibilità
Un modo efficace per lavorare è distinguere tre domande. Il problema ha conseguenze concrete? Per esempio, gli aggiornamenti non vengono installati, l’editor non salva o un servizio esterno non riceve le richieste. Quanto è esteso? Riguarda tutti gli utenti, solo l’amministrazione o una singola funzionalità? Quanto è rischioso correggerlo? Aggiornare una versione PHP senza verificare la compatibilità di temi e plugin può essere più pericoloso dell’avviso che si voleva eliminare. Dai priorità ai malfunzionamenti riproducibili, ai componenti non aggiornati con vulnerabilità note e ai servizi essenziali. Le ottimizzazioni facoltative vengono dopo. Prima di cambiare configurazioni importanti, prepara un backup WordPress completo e, se possibile, prova le modifiche in staging.
Versione PHP: quando l’avviso richiede attenzione
PHP è il linguaggio sul quale si basa WordPress. Una versione obsoleta può comportare problemi di sicurezza, compatibilità e prestazioni. Se Site Health segnala che PHP deve essere aggiornato, non limitarti a cercare il numero più alto disponibile nel pannello hosting. Controlla prima i requisiti della versione di WordPress in uso, le indicazioni dei produttori dei plugin più importanti e la compatibilità del tema. Esegui un backup, verifica la disponibilità di uno staging e annota la versione corrente. Dopo il cambio controlla homepage, pagine prodotto, carrello, checkout, accesso utente, editor e log degli errori. Se qualcosa smette di funzionare, ripristina temporaneamente la configurazione precedente e identifica il componente incompatibile. Un aggiornamento PHP è una manutenzione necessaria, ma va pianificata come una modifica tecnica, non come un semplice clic per far sparire un colore giallo.
Aggiornamenti di WordPress, temi e plugin
Site Health può evidenziare componenti non aggiornati o configurazioni legate agli aggiornamenti automatici. Il punto non è installare ogni novità senza controllo: è mantenere il sito su versioni supportate e sapere quando un aggiornamento è in attesa. Prima di procedere leggi il changelog, verifica la compatibilità dichiarata e assicurati che il backup sia recente. Sui siti ecommerce è utile testare soprattutto pagamenti, email transazionali e account cliente. Dopo un aggiornamento, ripeti i controlli di Salute del sito e verifica le funzioni principali. Se WordPress non funziona dopo un aggiornamento, consulta la nostra guida su come affrontare i problemi successivi agli aggiornamenti. Non confondere un aggiornamento disponibile con una prova automatica di vulnerabilità: il rischio effettivo dipende dal componente e dalla versione.
REST API: perché un errore può bloccare l’editor
La REST API permette a WordPress e a molte applicazioni di scambiare dati tramite richieste HTTP. È importante, tra le altre cose, per diverse operazioni dell’editor a blocchi e per integrazioni che comunicano con il sito. Se Site Health segnala un problema REST API, prova prima a riprodurre il sintomo: salva una bozza, modifica una pagina e verifica eventuali errori nell’editor. Le cause possibili includono regole di sicurezza troppo restrittive, autenticazione, configurazioni del server, problemi di permalink o interferenze di plugin. Non disattivare indiscriminatamente firewall e protezioni: confronta i log e prova le modifiche in modo controllato. Se il problema compare dopo un aggiornamento o una nuova regola, quello è il primo elemento da indagare. La REST API non deve essere resa pubblicamente accessibile senza restrizioni per tutte le operazioni: i permessi continuano a contare.
Richieste loopback: cosa significa se falliscono
Una richiesta loopback avviene quando il sito tenta di contattare se stesso tramite HTTP. WordPress usa meccanismi di questo tipo per alcune attività interne e programmate. Un test fallito può dipendere da timeout, DNS, certificati, regole firewall, autenticazione HTTP, limiti del server o restrizioni dell’hosting. Non significa automaticamente che il sito sia stato violato. Prima di modificare qualcosa verifica se le attività pianificate funzionano e se il problema è intermittente. Registra l’errore completo e chiedi al provider di hosting se le connessioni del server verso il proprio dominio sono consentite. Evita di inserire eccezioni di sicurezza generiche: la soluzione deve essere mirata alla causa verificata.
WP-Cron e attività programmate: i sintomi da osservare
WordPress gestisce numerose attività pianificate attraverso il sistema WP-Cron. La loro esecuzione può dipendere dalle visite e dalla configurazione del sito; in alcuni ambienti viene sostituita o affiancata da un cron di sistema. Se Site Health segnala un problema alle attività pianificate, controlla se gli articoli programmati vengono pubblicati, se le email previste partono e se i processi in background terminano. Per un ecommerce possono essere coinvolte anche operazioni periodiche gestite da plugin. Un’attività in ritardo non dimostra da sola che WP-Cron sia disabilitato: potrebbe esserci un errore specifico, un traffico ridotto o un blocco temporaneo. Chiedi all’hosting come viene eseguito il cron e verifica i log prima di introdurre configurazioni personalizzate.
Cache e prestazioni: cosa misura e cosa non misura Site Health
Alcune versioni di WordPress includono controlli relativi alla cache delle pagine e alla risposta del server. Sono indizi utili, ma non equivalgono a un test completo dell’esperienza utente. Una pagina servita rapidamente dalla cache può convivere con immagini troppo pesanti, JavaScript invasivo o un checkout lento. Inoltre le pagine personalizzate per utenti registrati, carrello e checkout non dovrebbero essere trattate come una homepage statica. Se ricevi un avviso sulla cache, verifica prima come è configurata nell’hosting, nell’eventuale CDN e nei plugin di ottimizzazione. Non installare più sistemi di cache sovrapposti senza conoscerne l’interazione. Per le prestazioni reali affianca Site Health a misurazioni delle pagine più importanti e a test eseguiti in condizioni ripetibili.
HTTPS, certificati e comunicazioni sicure
La presenza di HTTPS è fondamentale per proteggere le comunicazioni tra browser e sito. Se compare una segnalazione relativa al protocollo o al certificato, controlla che il dominio si apra correttamente con HTTPS, che il certificato sia valido e che non ci siano risorse caricate in modo non sicuro. Verifica anche gli indirizzi configurati in Impostazioni → Generali, ma non modificarli alla cieca: un URL sbagliato può rendere difficile l’accesso alla bacheca. Per i siti con proxy o CDN, la terminazione HTTPS può avvenire su più livelli e richiedere impostazioni coerenti. Se non sei sicuro della configurazione, raccogli il messaggio esatto e coinvolgi l’hosting. Un lucchetto nel browser è importante, ma non sostituisce aggiornamenti, backup e controlli sugli accessi.
Moduli PHP, database e configurazione del server
Tra i controlli possibili ci sono anche estensioni PHP, versione del database e caratteristiche dell’ambiente. WordPress può raccomandare moduli che migliorano compatibilità o funzionalità, ma la disponibilità dipende dal provider. Prima di chiedere un intervento identifica quale estensione viene segnalata e se manca una funzione concreta. Non tutte le impostazioni del server sono modificabili dalla bacheca e non è opportuno copiare parametri trovati in rete senza verificarne l’effetto. Per le modifiche infrastrutturali prepara un elenco con versione PHP, tipo di server, database, messaggio di Site Health e sintomi osservati. È molto più utile per l’assistenza tecnica di una richiesta generica come “il sito non è sano”.
Come usare la scheda Informazioni per una diagnosi
La scheda Informazioni è spesso sottovalutata. Raccoglie dati sull’installazione WordPress, sul server, sul database, sulle directory, sul tema attivo e su altre componenti, a seconda dell’ambiente. Le sezioni sono espandibili e aiutano a verificare informazioni che altrimenti andrebbero cercate in pannelli diversi. Per esempio puoi controllare la versione PHP effettivamente utilizzata dal sito, confrontarla con quella impostata nell’hosting e identificare il tema attivo. Questa scheda è utile anche quando chiedi supporto: fornisce un contesto tecnico ordinato, evitando decine di messaggi per ricostruire la configurazione. I dati possono però contenere dettagli infrastrutturali sensibili. Non pubblicare l’intero report in forum o screenshot aperti a chiunque.
Copiare le informazioni senza condividere dati riservati
WordPress mette a disposizione una funzione per copiare le informazioni del sito negli appunti. Prima di inviarle a un tecnico o a un fornitore, rileggi il contenuto e rimuovi ciò che non è necessario: percorsi interni, indirizzi email, dettagli del server, identificativi o altri dati che potrebbero esporre la configurazione. Non includere password, chiavi API, token o credenziali, neppure se qualcuno le chiede per “diagnosticare più in fretta”. In una richiesta di assistenza ben preparata bastano il messaggio specifico, il comportamento osservato, la versione dei componenti coinvolti e i passaggi per riprodurre l’errore. Se devi condividere un report completo, usa un canale privato e un destinatario affidabile.
Un metodo pratico in sette passaggi per risolvere gli avvisi
Primo: apri Site Health e annota i messaggi esatti, senza intervenire subito. Secondo: verifica se ci sono sintomi visibili, come pagine lente, errori di salvataggio o attività programmate ferme. Terzo: controlla gli aggiornamenti e le modifiche recenti: plugin installati, configurazioni di sicurezza, migrazioni e modifiche al server. Quarto: crea un backup e, per interventi rischiosi, usa uno staging. Quinto: affronta una sola causa alla volta, iniziando da quella più plausibile. Sesto: ripeti il test di Site Health e prova le funzioni importanti del sito. Settimo: documenta ciò che hai cambiato e il risultato. Se il messaggio scompare ma il malfunzionamento rimane, la diagnosi non è finita. Se invece il sito funziona e resta una raccomandazione non applicabile al tuo ambiente, documentane il motivo invece di forzare una modifica.
Esempio concreto: errore REST API dopo un plugin di sicurezza
Immagina che dopo aver modificato le impostazioni di un plugin di sicurezza l’editor non salvi più le pagine e Site Health segnali un problema REST API. La sequenza ragionevole è controllare quando è iniziato il problema, leggere l’errore restituito dall’editor e consultare i log del plugin o del server. In un ambiente di test puoi ripristinare temporaneamente la regola modificata e verificare se il salvataggio torna a funzionare. Se il comportamento cambia, hai un indizio forte da approfondire con una regola più specifica o con il supporto del produttore. Non è necessario disattivare tutte le protezioni del sito pubblico. Il principio vale anche per cache e CDN: cerca una relazione verificabile tra modifica e sintomo, non una soluzione casuale.
Esempio concreto: avviso PHP su un ecommerce funzionante
Un negozio online riceve un avviso relativo alla versione PHP. Il frontend funziona, gli ordini arrivano e non ci sono errori visibili. Ignorare per mesi l’avviso non è prudente, ma aggiornare direttamente in produzione durante un periodo di vendite può essere altrettanto rischioso. La procedura corretta è verificare compatibilità e requisiti, predisporre backup e staging, effettuare il cambio nell’ambiente di prova e testare pagine prodotto, varianti, carrello, pagamento, area cliente ed email. Solo dopo un esito positivo si pianifica l’aggiornamento sul sito pubblico, con possibilità di rollback. L’avviso di Site Health ha svolto il suo compito: ha evidenziato un’attività di manutenzione, non imposto una modifica immediata e non verificata.
Cosa fare quando Salute del sito segnala tutto verde
L’assenza di problemi critici è una buona notizia, ma non significa che WordPress sia immune da errori, attacchi o rallentamenti. Site Health non verifica ogni vulnerabilità dei plugin, non esegue una scansione completa del malware e non simula l’intero percorso di acquisto di un cliente. Mantieni una routine di aggiornamenti, controlla che i backup siano ripristinabili, verifica periodicamente i log e prova le funzioni fondamentali. Se il sito è commerciale, aggiungi controlli su checkout, messaggi email e account. La manutenzione è un processo continuo, non un traguardo rappresentato da un indicatore verde.
Errori frequenti da evitare durante la diagnosi
Il primo errore è installare plugin “riparatori” senza aver capito la causa del messaggio. Il secondo è cambiare più impostazioni contemporaneamente: se qualcosa migliora o peggiora, non saprai quale modifica sia responsabile. Il terzo è disattivare sicurezza, cache o protezioni dell’hosting in modo permanente soltanto per superare un test. Il quarto è condividere pubblicamente il report tecnico completo. Il quinto è concentrarsi sui suggerimenti facoltativi mentre un problema reale blocca editor, pagamenti o aggiornamenti. Infine, evita di considerare ogni avviso come un’emergenza: alcune raccomandazioni richiedono una valutazione contestuale. Se compare un errore critico di WordPress, la priorità diventa ripristinare il servizio e consultare i log, non perfezionare il punteggio di Site Health.
Domande frequenti su Site Health WordPress
Site Health rallenta il sito? I controlli vengono eseguiti nel contesto delle verifiche amministrative e non sono pensati come un monitoraggio continuo di tutte le visite. Se noti anomalie, valuta il contesto e gli eventuali plugin che aggiungono test personalizzati. Devo correggere ogni miglioramento raccomandato? No: ogni indicazione va valutata rispetto alla configurazione e al rischio dell’intervento. Se Site Health è verde, il sito è sicuro? No: sono necessari anche aggiornamenti, gestione degli accessi, backup e controlli specifici. Posso usare Site Health senza plugin? Sì, è integrato in WordPress. Posso inviare il report all’assistenza? Sì, dopo aver rimosso le informazioni non necessarie o sensibili. Un errore loopback significa che il server è guasto? Non necessariamente: può dipendere da firewall, timeout, DNS o altre configurazioni.
Conclusione: usare Site Health come strumento, non come pagella
La forza di Site Health WordPress sta nella capacità di far emergere problemi che potrebbero passare inosservati. Per sfruttarlo davvero, apri ogni segnalazione, verifica l’impatto sul sito e scegli interventi proporzionati. Un backup prima delle modifiche, test in staging quando opportuni e una verifica finale delle funzioni più importanti valgono più di qualsiasi corsa al risultato perfetto. Inserisci Salute del sito nella manutenzione periodica insieme al controllo degli aggiornamenti e dei backup. Così diventa una guida pratica per prendere decisioni migliori, non un elenco di avvisi da cancellare a caso.
Il team di The Waffle