“Si è verificato un errore critico sul tuo sito web.” È uno dei messaggi meno rassicuranti che WordPress possa mostrare, soprattutto quando compare subito dopo aver aggiornato un plugin, cambiato tema o modificato qualche riga di codice.
La buona notizia è che errore critico WordPress non significa automaticamente sito perso, database distrutto o necessità di ricominciare da zero. Significa che durante l’esecuzione WordPress ha incontrato un errore PHP abbastanza grave da impedirgli di completare normalmente la richiesta. Il messaggio che vedi è quindi il sintomo; il lavoro vero consiste nell’individuare la causa.
Da WordPress 5.2 esiste inoltre una funzione integrata, la Recovery Mode, pensata proprio per aiutare l’amministratore quando un plugin, un tema o del codice personalizzato provoca un errore fatale. Prima di disattivare tutto a caso, conviene quindi capire cosa WordPress sa già del problema.
Cosa significa davvero “errore critico” in WordPress
WordPress è scritto principalmente in PHP e, per generare una pagina, esegue il core insieme al tema attivo, ai plugin e ad eventuale codice personalizzato. Se uno di questi componenti genera un errore fatale, l’esecuzione può interrompersi.
WordPress intercetta determinati errori fatali e, invece di mostrare al visitatore dettagli tecnici potenzialmente incomprensibili o sensibili, può presentare il messaggio che segnala un errore critico. La documentazione ufficiale sulla Recovery Mode spiega che questa funzione è stata introdotta con WordPress 5.2 proprio per gestire situazioni nelle quali un errore PHP fatale impedisce il normale funzionamento del sito.
Questo dettaglio cambia il modo in cui conviene affrontare il problema. Il messaggio non ti sta dicendo quale componente è guasto. Ti sta dicendo che WordPress non è riuscito a terminare correttamente l’esecuzione. La diagnosi viene dopo.
Errore critico WordPress: le cause più comuni
La documentazione WordPress dedicata agli errori comuni indica tra le possibili cause conflitti tra plugin, incompatibilità con il tema, una versione PHP incompatibile, il raggiungimento del limite di memoria e file WordPress corrotti. A queste situazioni si aggiunge naturalmente il codice personalizzato: una modifica errata a un plugin custom, a uno snippet o a un file PHP può essere sufficiente per fermare l’esecuzione.
Non significa che ogni errore critico appartenga a una di queste categorie, ma sono punti di partenza sensati. Ancora più importante è il contesto temporale.
Se il sito funzionava cinque minuti fa e l’errore è comparso immediatamente dopo l’aggiornamento di un plugin, quel plugin merita attenzione prima di qualunque teoria esotica. Se hai appena modificato functions.php e il sito è caduto al salvataggio, il primo sospettato non è il database. Sembra banale, ma una diagnosi ordinata parte da ciò che è cambiato.
Prima cosa: controlla l’email dell’amministratore
Quando WordPress attiva la Recovery Mode in seguito a un errore fatale durante il normale caricamento di una pagina, può inviare un’email all’indirizzo dell’amministratore del sito. Il messaggio contiene informazioni sul problema e un collegamento speciale per accedere al sito in modalità di recupero.
Quell’email è preziosa perché può indicare il plugin o il tema coinvolto. Invece di iniziare disattivando venti plugin, potresti già avere un’indicazione concreta.
Controlla quindi la casella associata all’amministratore WordPress, compresa la cartella spam. L’assenza del messaggio non dimostra che la Recovery Mode non abbia tentato di intervenire: la documentazione ufficiale segnala che, in alcune configurazioni, l’email potrebbe non essere recapitata correttamente.
Come funziona la Recovery Mode di WordPress
La Recovery Mode non è una seconda installazione di WordPress e non “ripara” automaticamente il componente difettoso. Crea piuttosto una sessione speciale per l’amministratore nella quale il plugin o il tema che ha causato l’errore può essere messo in pausa per quella sessione, consentendo l’accesso alla dashboard.
Una volta entrato tramite il link ricevuto via email, WordPress mostra avvisi che aiutano a identificare l’estensione problematica. Puoi quindi disattivarla, correggere il codice o intervenire sulla configurazione e, terminato il lavoro, uscire dalla Recovery Mode.
È un meccanismo intelligente perché evita una soluzione brutale: spegnere tutto il sito solo per riuscire ad accedere all’amministrazione.
Non confonderla però con la modalità manutenzione WordPress. La manutenzione viene normalmente utilizzata durante gli aggiornamenti per impedire l’accesso mentre i file vengono sostituiti; la Recovery Mode interviene invece in presenza di determinati errori fatali. Due schermate sgradevoli, due problemi completamente diversi.
Se l’email di recupero non arriva
Se non hai ricevuto il link oppure l’errore impedisce comunque l’accesso, devi passare a una diagnosi manuale. La regola resta la stessa: raccogliere informazioni prima di modificare il sito alla cieca.
Il primo strumento utile è il log degli errori. WordPress mette a disposizione le costanti WP_DEBUG, WP_DEBUG_LOG e WP_DEBUG_DISPLAY. La documentazione ufficiale sul debugging spiega come usarle e raccomanda di verificare prima di ogni modifica di avere un ambiente di staging oppure un backup adeguato.
Una configurazione comunemente usata per registrare gli errori senza mostrarli ai visitatori è:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Con WP_DEBUG_LOG impostato a true, il log viene normalmente scritto in wp-content/debug.log. Qui puoi cercare il fatal error e soprattutto il percorso del file coinvolto. Se il percorso punta chiaramente a una cartella sotto wp-content/plugins/nome-plugin/, hai un’indicazione molto più concreta di “forse è un plugin”.
Il debug non va lasciato acceso per abitudine sul sito live
Attivare il debug per diagnosticare un problema è una cosa; trasformarlo in una configurazione permanente su un sito pubblico è un’altra. La documentazione WordPress specifica che gli strumenti di debug sono pensati soprattutto per ambienti locali e di staging e sconsiglia il loro uso continuativo sui siti live.
C’è anche una questione di sicurezza. I log possono contenere percorsi del server, dettagli tecnici e altre informazioni che non è opportuno rendere accessibili pubblicamente. WordPress segnala esplicitamente il rischio di conservare file di log in posizioni raggiungibili via web.
Quindi: attiva ciò che serve, raccogli le informazioni, risolvi il problema e ripristina una configurazione appropriata alla produzione. Il debug è uno stetoscopio, non un accessorio da lasciare appeso al sito.
Se il problema è un plugin e non puoi entrare in WordPress
Se il log o l’email indicano un plugin preciso ma la dashboard resta irraggiungibile, puoi disattivarlo agendo sui file. WordPress documenta una procedura semplice: tramite FTP/SFTP o file manager dell’hosting, rinomina temporaneamente la cartella del plugin interessato all’interno di wp-content/plugins.
Per esempio, se il componente problematico fosse nella cartella mio-plugin, rinominarla temporaneamente impedirebbe a WordPress di caricarlo normalmente. Dopo l’operazione puoi verificare se il sito torna accessibile.
Se non sai quale plugin sia responsabile, esiste anche la possibilità di disattivare tutti i plugin rinominando la directory plugins, una tecnica riportata nella documentazione sugli errori comuni. È però una misura molto più invasiva e non dovrebbe essere la prima mossa quando hai già elementi per isolare il colpevole.
Su un e-commerce o un sito con funzioni critiche, disattivare indiscriminatamente tutto può avere conseguenze evidenti. Meglio un bisturi quando hai già individuato il punto, non una motosega.
E se il responsabile è il tema?
Anche un tema può provocare un errore fatale, soprattutto dopo una modifica al codice, un aggiornamento o un cambio di versione PHP. Se il problema è iniziato subito dopo aver attivato o modificato un tema, il collegamento temporale è ancora una volta importante.
La documentazione WordPress sugli errori comuni suggerisce, quando possibile, di passare a un tema predefinito. Se non hai accesso alla dashboard, la gestione può richiedere un intervento via filesystem.
Prima di rinominare cartelle o intervenire manualmente, però, assicurati che sul sito sia installato un tema alternativo funzionante e che tu sappia quale risultato aspettarti. Fare cambiamenti casuali mentre il sito è già in errore rende più difficile capire cosa abbia realmente risolto il problema.
Versione PHP, memoria e compatibilità
Non tutti gli errori critici nascono da un componente semplicemente “rotto”. Un plugin può funzionare per mesi e iniziare a generare un fatal error dopo un cambio di ambiente. Un aggiornamento della versione PHP, per esempio, può far emergere codice non compatibile. Allo stesso modo, l’esaurimento della memoria disponibile può interrompere l’esecuzione.
Il log serve proprio a distinguere questi casi. Un messaggio relativo a una funzione inesistente, un errore di tipo, un problema di sintassi e un messaggio di memoria esaurita raccontano storie diverse. Limitarsi a leggere “critical error” sul frontend elimina proprio le informazioni che servono per scegliere la cura.
Se il problema nasce dopo una modifica alla versione PHP effettuata dal pannello hosting, verifica i requisiti dei componenti utilizzati e le indicazioni del provider. Non cambiare ripetutamente versione sperando che una funzioni: individua prima l’incompatibilità.
Un aggiornamento ha causato l’errore critico: che fare?
Se l’errore compare immediatamente dopo un aggiornamento, non significa necessariamente che WordPress debba essere “downgradato”. Devi capire quale componente ha fallito e perché.
Controlla l’email di Recovery Mode, il log e lo stato del componente aggiornato. Se l’aggiornamento si è interrotto, verifica anche che i file siano completi. Se invece la nuova versione introduce un’incompatibilità con un altro plugin o con il tuo ambiente, ripristinare temporaneamente una copia funzionante può essere più prudente che modificare il sito di produzione sotto pressione.
Qui torna utile avere una strategia di backup seria. La nostra guida al backup WordPress spiega perché una copia è utile solo se contiene ciò che serve e può essere realmente ripristinata.
Per aggiornamenti importanti, testare prima su staging riduce ulteriormente il rischio: l’errore critico è molto meno critico quando compare su una copia che nessun cliente sta usando.
Non ripristinare un backup come prima reazione
Avere un backup non significa che debba essere il primo pulsante da premere. Se il problema è un singolo plugin appena aggiornato e la Recovery Mode permette di identificarlo e disattivarlo in pochi minuti, un ripristino completo potrebbe essere sproporzionato.
Inoltre, su siti dinamici, un restore può riportare indietro anche dati modificati dopo la creazione della copia: ordini, utenti, commenti, contenuti o altre informazioni, a seconda di cosa viene ripristinato.
Il backup è una rete di sicurezza. Prima di usarla, devi sapere da quale altezza stai cadendo.
Cosa controllare dopo aver risolto l’errore
Il fatto che la homepage sia tornata visibile non chiude automaticamente il lavoro. Se hai disattivato un plugin, devi verificare quali funzioni forniva. Se hai corretto uno snippet, controlla le pagine che lo utilizzavano. Se hai cambiato PHP, verifica le aree più importanti del sito.
Per un e-commerce significa almeno controllare navigazione, account, carrello e checkout. Per un sito con moduli, invia un test. Per una membership, verifica accesso e contenuti protetti. Il controllo deve seguire ciò che è stato toccato.
Infine, disattiva le impostazioni di debug temporanee che non devono restare attive e conserva l’informazione sulla causa. Sapere che “il sito è tornato” è utile; sapere perché era caduto evita di ripetere la stessa scena al prossimo aggiornamento.
Una procedura semplice per non peggiorare la situazione
Davanti a un errore critico WordPress, l’ordine delle operazioni conta più della velocità con cui riesci a cliccare.
- Ricorda cosa è cambiato immediatamente prima dell’errore.
- Controlla l’email dell’amministratore per il messaggio della Recovery Mode.
- Se disponibile, entra tramite il collegamento di recupero e identifica il componente segnalato.
- Se non basta, consulta i log o abilita temporaneamente il logging seguendo la documentazione WordPress.
- Intervieni sul componente effettivamente coinvolto, evitando disattivazioni casuali.
- Se necessario, usa un backup verificato per tornare a uno stato funzionante.
- Dopo il ripristino, testa le funzioni legate al problema e rimuovi le configurazioni di debug temporanee.
È una sequenza meno spettacolare del “disattiva tutto e vediamo”, ma produce una cosa molto più utile: una diagnosi.
L’errore critico è un messaggio generico, non una sentenza
La schermata di errore critico è volutamente generica. Protegge il visitatore dai dettagli tecnici e ti segnala che WordPress non è riuscito a completare l’esecuzione. Per risolvere il problema devi quindi passare dal messaggio visibile alle informazioni diagnostiche.
Recovery Mode, email dell’amministratore e log sono i primi strumenti da usare. Plugin, tema, codice personalizzato, compatibilità PHP, memoria e file danneggiati sono possibili cause, non verdetti da scegliere a caso.
La differenza tra un intervento ordinato e mezz’ora di panico sta quasi sempre qui: prima individua cosa si è rotto, poi modifica ciò che serve. WordPress ti mette già a disposizione buona parte degli strumenti necessari per farlo.
Il team di The Waffle