«Si è verificato un errore critico sul sito» è il messaggio che WordPress mostra quando una parte del sito si blocca e la pagina non riesce a caricarsi. Spaventa, ma un errore critico non cancella i contenuti: testi, foto e dati restano dove sono. Sono Martina Tempesta, web designer a Roma con MarTe Graphics, e su questi errori intervengo spesso, anche su siti fatti da altri. La causa si trova, a patto di non cancellarne le tracce.
In breve: l’errore critico vuol dire che il programma del sito si è fermato a metà, di solito per un componente aggiornato, incompatibile o difettoso, oppure per un cambio fatto dall’hosting. I contenuti, di norma, non sono persi. Conviene non cancellare componenti a caso e non ripristinare copie senza sapere cosa è cambiato: si perdono le tracce della causa, e a volte anche i dati più recenti.
Cosa vuol dire «Si è verificato un errore critico»?
Vuol dire che durante il caricamento della pagina il codice del sito si è fermato per un errore che non riesce a gestire, e WordPress, invece di mostrare una pagina rotta a metà, mostra quel messaggio. Dalla versione 5.2, uscita nel 2019, WordPress manda anche un’email all’indirizzo dell’amministratore, con un link per entrare in una modalità di recupero.
Il messaggio è generico di proposito: non dice ai visitatori cosa si è rotto, perché quell’informazione sarebbe utile anche a chi vuole attaccare il sito. Il dettaglio sta nei registri degli errori del server, che indicano quale file e quale componente hanno bloccato la pagina. Da lì parto ogni volta, perché senza leggere quel registro si va a tentativi.
La modalità di recupero non ripara niente. Mette in pausa il componente che ha causato l’errore solo per chi entra da quel link, mentre i visitatori continuano a vedere il messaggio, come spiega la nota tecnica con cui WordPress l’ha introdotta. È una porta per entrare nel pannello: la riparazione resta tutta da fare.
Perché compare all’improvviso, anche se non hai toccato niente?
Compare all’improvviso perché un sito WordPress cambia anche quando nessuno lo tocca: i componenti si possono aggiornare da soli, l’hosting può cambiare la versione di PHP, cioè il linguaggio su cui il sito gira, e un servizio esterno collegato può smettere di rispondere. Basta che uno di questi cambi non vada d’accordo con il resto perché una pagina si blocchi.
Le cause che trovo più spesso
- Un plugin o il tema aggiornati da soli, che non vanno più d’accordo con un altro componente.
- Il passaggio a una versione di PHP più recente, che i componenti vecchi non reggono.
- Lo spazio sul server esaurito, o un limite di memoria raggiunto.
- Un file modificato a mano, o caricato solo a metà.
- Un intervento dell’hosting sullo spazio web, fatto senza sapere cosa c’era sopra.
- Più di rado, un’intrusione che ha alterato i file.
Mi è capitato uno spazio di hosting ancora su una versione di PHP che non riceve aggiornamenti da più di dieci anni. Su una base così, il giorno in cui l’hosting impone una versione attuale, i componenti scritti per quella vecchia smettono di funzionare tutti insieme. Secondo il sito ufficiale di PHP, a ottobre 2026 ricevono correzioni di sicurezza solo le versioni dalla 8.2 in su.
Quanto pesano invece i componenti lasciati indietro lo spiego nell’articolo su cosa succede se non aggiorni WordPress e i plugin.
Errore 500, pagina bianca, sito senza grafica: sono la stessa cosa?
Sono sintomi diversi della stessa famiglia di problemi. L’errore 500 è la risposta generica del server quando qualcosa va storto e non sa dire cosa; la pagina bianca è lo stesso blocco senza nessun messaggio; l’errore critico è il modo in cui WordPress lo comunica. Il sito senza grafica è un caso a parte: le pagine arrivano, ma i file dello stile no.
| Cosa vedi | Cosa c’è dietro, di solito | Il sito si apre? |
|---|---|---|
| Errore critico | Un componente o il tema si bloccano | No, sulle pagine colpite |
| Errore 500 | Il server non riesce a completare la pagina | No |
| Pagina bianca | Lo stesso blocco, senza messaggio | No |
| Sito senza grafica | I fogli di stile non vengono caricati | Sì, ma è illeggibile |
| Errore 503 | Server sovraccarico o in manutenzione | Spesso è temporaneo |
Su un sito che ho poi ricostruito, alcune pagine online erano senza grafica: testi e immagini c’erano, ma i fogli di stile generati dal costruttore di pagine davano errore, e il browser mostrava tutto in colonna, come un documento grezzo. Per chi arrivava sembrava un sito abbandonato, anche se tutto il resto funzionava.
Distinguere il sintomo serve a non cercare nel posto sbagliato. Un errore critico porta a un componente, un errore 500 a volte al server, un sito senza grafica ai file dello stile o alla memoria temporanea del sito. Il controllo è un lavoro tecnico che faccio io: a te basta descrivermi cosa vedi e da quando.
Cosa evitare di fare quando succede?
Quando compare l’errore critico conviene evitare alcune mosse istintive, come cancellare plugin o file a caso finché il sito non riparte, ripristinare la prima copia di sicurezza disponibile senza sapere cosa è cambiato o aggiornare tutto di corsa sperando che si sistemi. Sono mosse che a volte funzionano, ma più spesso nascondono la causa o fanno perdere dati recenti.
- Cancellare componenti a tentativi. Insieme al plugin se ne vanno le sue impostazioni, e a volte i dati che conservava: moduli, prenotazioni, ordini.
- Ripristinare una copia senza guardarne la data. Tutto quello che è successo dopo, richieste e ordini compresi, sparisce, e se la causa è sul server l’errore torna.
- Aggiornare tutto in blocco. Se il problema è un’incompatibilità, cambiare dieci cose insieme rende impossibile capire quale.
- Seguire guide trovate online che chiedono di modificare i file del server. Un errore in quei file può spegnere tutto il sito, non solo una pagina.
- Aprire il link di un’email senza sapere da dove arriva. Prima di cliccare, chiedi a chi ti segue se arriva davvero dal tuo sito.
Quello che serve, invece, sono tre informazioni: quando hai visto l’errore, cosa era successo poco prima (un aggiornamento, un’email dell’hosting, una modifica) e l’email di WordPress, se è arrivata. Con queste la causa si trova molto prima.
Un errore critico dice dove guardare. Le mosse fatte di corsa cancellano proprio quel segnale.
Il sito e i dati sono persi?
Di norma no. L’errore critico blocca la pagina mentre si carica, ma i contenuti stanno nel database e nei file, che restano dove sono. Si perdono dati quando si interviene male dopo: una copia ripristinata sopra quella attuale, una cartella cancellata, un reset dello spazio web fatto al momento sbagliato. Per questo la prima regola è non sovrascrivere niente.
I dati sono davvero a rischio in altri casi: un server guasto senza copie fuori dallo spazio web, un’intrusione che ha cancellato o alterato i file, copie di sicurezza conservate solo dentro lo stesso sito che si è rotto. Per questo le copie dei siti che seguo stanno fuori dal server: se si rompe il sito, la copia resta intatta.
Se insieme all’errore vedi pagine strane, utenti che non conosci o un avviso dell’hosting, il problema può essere un’intrusione. In quel caso leggi cosa fare con un sito hackerato, perché le priorità cambiano.
Come si evita che ricapiti?
Si evita che ricapiti con una manutenzione fatta prima, non dopo: aggiornamenti provati e controllati, copie di sicurezza conservate fuori dal server, una versione di PHP seguita insieme all’hosting, componenti inutili tolti e qualcuno che si accorge dell’errore prima dei clienti. Il rischio zero non esiste, ma su un sito seguito un errore si ripara partendo da una copia recente.
Su un sito seguito so quali componenti ci sono, quando sono stati aggiornati e quale copia è sana. Su un sito che nessuno guarda da anni, ogni errore parte da zero: prima si ricostruisce com’è fatto, poi si cerca la causa.
Se il sito l’ha fatto un altro e oggi non lo segue nessuno, si parte da un controllo dello stato attuale: è il metodo che descrivo nella guida all’assistenza siti web.
La lettura dei registri, la ricerca della causa e il ripristino sono un lavoro tecnico che faccio io. A te serve sapere cosa è successo e cosa è stato cambiato. Se il tuo sito mostra questo errore, raccontami la situazione.
Domande frequenti
Le risposte più richieste
Di solito no. Nei casi che ho seguito nasce quasi sempre da un’incompatibilità fra componenti, da un aggiornamento o da un cambio sul server. Un’intrusione può causarlo, quando chi è entrato modifica i file in modo maldestro, e allora si accompagna ad altri segnali: pagine in lingue strane, utenti sconosciuti, avvisi dell’hosting o di Google. Se li vedi, va trattato come un sito violato.
Quell’email esiste davvero: dalla versione 5.2 WordPress la manda all’amministratore quando il sito si blocca, con un link alla modalità di recupero. Il link mette in pausa il componente difettoso solo per chi lo apre, mentre i visitatori continuano a vedere l’errore. Conservala e girala a chi gestisce il sito, dopo aver verificato che arrivi davvero dal tuo sito: di solito indica il componente che ha causato il blocco.
Spesso sì, in senso stretto: l’errore nasce dentro il sito, nei componenti o nel tema, e l’hosting fornisce solo lo spazio su cui girano. A volte però è un cambio fatto dall’hosting a scatenarlo, come il passaggio a una versione di PHP più recente o un intervento sullo spazio web. In quel caso la soluzione stabile è rendere il sito compatibile con la versione nuova.
Se l’hosting te lo permette dal pannello puoi farlo, ma conviene sapere cosa comporta. Il ripristino sostituisce il sito attuale con quello della data scelta: richieste, ordini e modifiche successivi spariscono. E se la causa è un aggiornamento automatico o un cambio sul server, l’errore torna appena le condizioni si ripetono. Prima va capito cosa è cambiato, poi si sceglie la copia giusta.
Succede di più con i componenti che fanno tante cose insieme: costruttori di pagine con i loro pacchetti aggiuntivi, negozi online, strumenti di velocità e di sicurezza, che intervengono su tutto il sito. E succede di più con i componenti abbandonati, che non vengono adattati alle nuove versioni di WordPress e di PHP. Anche il numero conta: più plugin ci sono, più combinazioni possono entrare in conflitto.
Un blocco breve di solito non lascia segni. Secondo la documentazione di Google, quando un sito risponde con errori del server la scansione rallenta e le pagine già indicizzate vengono conservate, ma quelle che continuano a dare errore vengono tolte dall’indice. Un sito fermo per giorni comincia quindi a perdere pagine nei risultati, e con loro le visite. Per questo un errore critico va risolto presto.
Martina TempestaWeb designer a Roma, titolare di MarTe Graphics. Dal 2013 progetto siti per studi professionali, aziende e attività locali.
