Si è verificato un errore critico sul tuo sito web: cosa significa e come risolverlo

Quel messaggio significa che PHP ha generato un errore fatale mentre costruiva la pagina, e che WordPress lo ha intercettato prima che diventasse una schermata bianca. L’errore è reale, specifico e registrato: WordPress si limita a non stamparlo nel browser, perché uno stack trace su una pagina pubblica rivela percorsi dei file e codice a chiunque passi di lì.

Per questo la soluzione non passa mai dai tentativi a caso. Si legge l’errore vero, poi si agisce su quello che dice.

Cosa sta succedendo davvero

Da WordPress 5.2 il core include un gestore degli errori fatali. Quando PHP muore a metà richiesta, il gestore entra in azione, sostituisce l’output del crash con la frase generica e — se riesce a capire quale plugin o tema l’ha causato — prova a inviare all’amministratore del sito un’email con un link alla modalità di ripristino.

È per questo che vedi questo messaggio al posto della vecchia schermata bianca della morte. È un miglioramento, ma significa anche che le informazioni diagnostiche restano nascoste per impostazione predefinita. Il messaggio esiste in più varianti:

Cosa vedi	Dove	Cosa ti dice
”Si è verificato un errore critico sul tuo sito web.”	Front end, senza login	Errore fatale avvenuto, nessun dettaglio esposto
La stessa riga più “Scopri di più sulla risoluzione dei problemi di WordPress”	Front end o wp-admin	Stesso errore, WordPress ti propone la pagina del manuale
”…Controlla la casella email dell’amministratore del sito per le istruzioni.”	Front end	Il gestore ritiene di aver inviato l’email di ripristino

La terza variante è quella utile. Significa che WordPress ha attribuito il crash a un plugin o a un tema preciso e ha provato a darti una via d’ingresso.

Passo 1: controlla l’email della modalità di ripristino

WordPress invia il link di ripristino all’indirizzo email amministrativo del sito — quello in Impostazioni, Generali — che spesso non è l’indirizzo con cui accedi. Controlla quella casella, e controlla lo spam.

L’email contiene un link lungo che finisce con qualcosa tipo ?action=enter_recovery_mode. Aprendolo entri in wp-admin in modalità di ripristino, dove il plugin o il tema responsabile è sospeso e segnalato in un avviso rosso in alto. Da lì puoi disattivarlo normalmente.

Due avvertenze oneste. La prima: l’email è generata dallo stesso processo PHP appena andato in crash, su un server che potrebbe non avere alcun sistema di posta funzionante — la mancata consegna è comune e la sua assenza non ti dice nulla sull’errore. La seconda: il link di ripristino scade (circa un giorno, per impostazione predefinita), quindi una vecchia email nella casella potrebbe semplicemente non funzionare più; provoca un nuovo crash ricaricando il sito e aspetta l’email successiva.

Se vuoi che l’email arrivi dove la leggi davvero, impostala esplicitamente in wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Passo 2: leggi l’errore vero

È il passaggio che trasforma un sito rotto in una riparazione da cinque minuti. Aggiungi queste righe a wp-config.php, sopra la riga che dice di non modificare oltre:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_DISPLAY impostato su false conta parecchio: tiene l’errore fuori dal browser continuando però a scriverlo su disco, così non esponi percorsi ai visitatori mentre fai debug.

Ricarica una volta la pagina che non funziona, poi apri wp-content/debug.log. L’ultima voce sarà più o meno così:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Il percorso del file è la risposta. Se punta dentro wp-content/plugins/, la causa è quel plugin. Se punta dentro wp-content/themes/, è il tema — molto spesso qualcosa incollato di recente in functions.php.

Se debug.log non compare, la directory potrebbe non essere scrivibile, oppure un plugin di sicurezza potrebbe aver spostato altrove i log. In quel caso ripiega sul log degli errori PHP dell’hosting: quasi tutti i pannelli di controllo hanno una sezione “Log degli errori” o “Log”, e lo stesso errore fatale sarà lì con un orario.

Incolla la voce nel decodificatore dei log di errore WordPress per tradurre il linguaggio di PHP in cosa significa nella pratica e quale file guardare per primo.

Rimuovi queste righe di debug quando hai finito. Lasciare WP_DEBUG attivo in produzione riempie il disco e, se WP_DEBUG_DISPLAY viene rimesso su true, stampa pubblicamente i percorsi del server.

Passo 3: torna dentro wp-admin

Se anche wp-admin è irraggiungibile e non è arrivata nessuna email di ripristino, disattiva tutti i plugin a livello di filesystem. Collegati via SFTP (o dal file manager dell’hosting) e rinomina una cartella:

mv wp-content/plugins wp-content/plugins-off

WordPress non trova più i plugin, quindi li disattiva tutti e l’accesso all’amministrazione quasi sempre torna. Poi:

1. Rinomina la cartella di nuovo in plugins. Resta tutto disattivato: WordPress li ha registrati come inattivi.
2. Riattiva i plugin uno alla volta, caricando il front end dopo ognuno.
3. Quello che fa ricomparire l’errore è il tuo colpevole.

Se il sito resta rotto anche con tutti i plugin spenti, il sospettato è il tema. Rinomina la cartella del tema attivo dentro wp-content/themes/ e WordPress ripiegherà su un tema predefinito, se ne hai uno installato.

Le tre cause che vale la pena conoscere

Un aggiornamento di plugin o tema che genera un errore fatale. Di gran lunga la più comune. Il log nomina il file direttamente. Riporta quel singolo plugin alla versione precedente, oppure lascialo disattivato e scrivi allo sviluppatore allegando la riga di log.

Una versione di PHP incompatibile. Gli hosting aggiornano PHP secondo un calendario, a volte con poco preavviso. Codice scritto per PHP più vecchio può non essere più nemmeno interpretato su una versione recente. Il segnale è che tu non hai toccato nulla e all’improvviso si è rotto tutto. Riportare PHP indietro di una versione minore dal pannello dell’hosting è una diagnosi valida, ma consideralo un modo per guadagnare tempo, non una soluzione: le vecchie versioni di PHP smettono di ricevere patch di sicurezza.

Memoria esaurita. Nel log leggi “Allowed memory size of X bytes exhausted”. Alzare il limite in wp-config.php è ragionevole:

define( 'WP_MEMORY_LIMIT', '256M' );

Sii onesto su cosa fa davvero: toglie il tetto, non risolve ciò che ha consumato 256MB per generare una singola pagina. Se il limite continua a dover salire, il problema vero è qualcos’altro — di solito un’importazione, un page builder o una query scritta male.

Consigli che puoi tranquillamente ignorare

“Aumenta il limite di memoria.” Ha senso solo se il log dice davvero che la memoria è esaurita. Altrimenti non cambia nulla e nasconde il fatto che non hai mai letto l’errore.

“Reinstalla il core di WordPress.” I file del core sono raramente la causa, e sostituirli fa perdere il tempo che potresti impiegare a leggere una riga di log.

“Disattiva il gestore degli errori fatali.” Esiste una costante per disabilitarlo, e il risultato è che l’errore grezzo viene stampato sul tuo sito pubblico invece di essere intercettato. Questo espone i percorsi dei file ai visitatori. Usa invece WP_DEBUG_LOG con WP_DEBUG_DISPLAY disattivato: stesse informazioni, nessuna esposizione.

“Svuota la cache.” Un errore fatale avviene in PHP prima che un plugin di cache possa servire qualsiasi cosa. Se viene servita una copia in cache della pagina di errore, svuotarla aiuta dopo aver risolto la causa, mai al posto di risolverla.

Ancora bloccato?

Se il log punta a un file del core invece che a qualcosa dentro wp-content, la spiegazione più probabile è un plugin caricato prima che ha rotto lo stato su cui il core fa affidamento, non un core corrotto. Spegni tutto rinominando la cartella, verifica che il sito si carichi pulito, poi reintroduci i plugin uno per uno: l’ultimo che attivi prima che l’errore ritorni è quello da segnalare, allegando la riga di log.