“Si è verificato un errore critico sul tuo sito web”: cause e soluzioni

Apri il sito e al posto della home trovi una sola frase: “Si è verificato un errore critico sul tuo sito web”. A volte anche la bacheca è irraggiungibile. È uno dei problemi più frequenti su WordPress e fa paura perché non dice nulla sulla causa. L’errore critico di WordPress però segue quasi sempre gli stessi schemi, e con un po’ di metodo la causa si trova.

Cosa significa “errore critico” su WordPress?

Significa che durante il caricamento della pagina il codice PHP del sito si è bloccato con un errore fatale e WordPress, invece di mostrare una pagina bianca o il messaggio tecnico, mostra un avviso generico. Il sito non è “rotto” in modo irreparabile: un singolo pezzo di codice ha smesso di funzionare.

Questa protezione esiste da WordPress 5.2, che ha introdotto la gestione degli errori fatali e la modalità di recupero. Prima di allora lo stesso problema produceva la famosa pagina bianca, di cui parliamo nella guida alla pagina bianca su WordPress.

Le cause più frequenti, in ordine di probabilità nella pratica quotidiana, sono:

• un plugin aggiornato, appena installato o incompatibile con un altro;
• il tema o il child theme, spesso dopo una modifica al file functions.php;
• memoria PHP insufficiente per ciò che il sito deve fare;
• un cambio di versione PHP sul server, deciso da te o dall’hosting;
• file di WordPress danneggiati da un aggiornamento interrotto o da un’infezione.

Il primo passo quindi è leggere il messaggio di errore reale, prima di provare soluzioni a caso.

Cosa fare prima di toccare qualsiasi cosa?

Prima di tutto fai un backup completo di file e database, anche se il sito non funziona. Ogni intervento successivo diventa reversibile e, se qualcosa va storto, non peggiori la situazione.

1. Backup. Usa lo strumento di backup del pannello hosting, oppure scarica via FTP la cartella del sito ed esporta il database da phpMyAdmin. Trovi i dettagli nella guida ai backup di WordPress.
2. Ricostruisci cosa è cambiato. Aggiornamenti fatti oggi, un plugin nuovo, una modifica al tema, un’email dell’hosting sul cambio di PHP: nella maggior parte dei casi la causa è l’ultima cosa cambiata.
3. Verifica l’estensione del problema. L’errore compare su tutto il sito, solo in bacheca, o solo su una pagina?
4. Procurati gli accessi. Ti servono l’accesso al pannello dell’hosting, un client FTP/SFTP (o il file manager dell’hosting) e, se possibile, phpMyAdmin.

Hai ricevuto l’email di recovery mode?

Controlla la casella dell’indirizzo email di amministrazione del sito: quando rileva un errore fatale, WordPress invia un’email con il nome del plugin o del tema che ha causato l’errore e un link speciale per entrare in modalità di recupero. È il modo più rapido per risolvere.

Secondo la documentazione di WordPress, in modalità di recupero il plugin o il tema difettoso viene messo in pausa solo per la tua sessione, così puoi entrare in bacheca, vedere l’avviso che indica il componente responsabile e disattivarlo, senza usare l’FTP. I visitatori, nel frattempo, continuano a vedere l’errore finché non risolvi.

1. Apri l’email e clicca sul link di recovery mode (ha una scadenza, quindi usalo appena possibile).
2. Accedi con le tue credenziali di amministratore.
3. Leggi l’avviso in bacheca: indica il plugin o il tema e spesso il file e la riga dell’errore.
4. Disattiva il plugin indicato, oppure attiva un tema predefinito se il problema è nel tema.
5. Esci dalla modalità di recupero con il pulsante apposito nella barra in alto e controlla il sito da una finestra in navigazione privata.

L’email a volte non arriva: se il sito non invia bene la posta, o se l’errore blocca proprio il plugin che gestisce le email, il messaggio si perde. Controlla anche lo spam. Se non trovi nulla, passa al file di log.

Come leggere l’errore vero con WP_DEBUG e debug.log?

Attivando la modalità di debug di WordPress con il salvataggio su file, l’errore completo viene scritto in wp-content/debug.log, con il percorso del file responsabile. Quel percorso ti dice quasi sempre quale plugin o tema è il colpevole.

Apri via FTP il file wp-config.php nella cartella principale del sito e, prima della riga che dice di smettere di modificare, inserisci (o modifica se già presenti) queste righe, come indicato nella documentazione ufficiale sul debug:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Con WP_DEBUG_DISPLAY impostato su false gli errori non vengono mostrati ai visitatori, ma solo salvati nel file. Ricarica la pagina con l’errore, poi apri wp-content/debug.log e cerca le righe che contengono PHP Fatal error. Un esempio tipico:

PHP Fatal error:  Uncaught Error: Call to undefined function ...
in /home/utente/public_html/wp-content/plugins/nome-plugin/includes/file.php:123

La parte che conta è il percorso: plugins/nome-plugin indica il plugin, themes/nome-tema il tema. Se il messaggio parla di “Allowed memory size … exhausted” il problema è la memoria; se cita funzioni non definite subito dopo un cambio di PHP, è probabile un’incompatibilità.

Anche il pannello dell’hosting di solito offre un log degli errori del server: se debug.log resta vuoto, guarda lì.

Quando hai finito, rimetti WP_DEBUG su false e cancella il file debug.log: la documentazione sconsiglia di lasciare il debug attivo su un sito in produzione, e il file di log può contenere percorsi e informazioni utili a un attaccante.

Come disattivare i plugin se non entri in bacheca?

Puoi disattivare i plugin rinominando la loro cartella via FTP o dal file manager dell’hosting: WordPress non trova più i file e li disattiva automaticamente. È la soluzione più comune all’errore critico.

Se sai quale plugin è il colpevole

1. Collegati via FTP e apri wp-content/plugins/.
2. Rinomina la cartella del plugin indicato nel log, per esempio da nome-plugin a nome-plugin-off.
3. Ricarica il sito. Se torna a funzionare, hai trovato la causa.

Se non sai quale plugin è il colpevole

1. Rinomina l’intera cartella wp-content/plugins in plugins-off. Tutti i plugin vengono disattivati.
2. Se il sito torna a funzionare, rinomina di nuovo la cartella in plugins: i plugin risulteranno disattivati in bacheca.
3. Riattivali uno alla volta dalla bacheca, ricaricando il sito dopo ognuno. Quando ricompare l’errore, l’ultimo attivato è il responsabile.

Attenzione ai siti in produzione: con i plugin disattivati possono sparire moduli di contatto, carrello, SEO e cache. Se hai un negozio online, fai questa prova nel momento di minor traffico, o meglio su una copia di staging (un ambiente di prova identico al sito).

Se usi WP-CLI, lo strumento a riga di comando di WordPress disponibile su molti hosting, lo stesso risultato si ottiene con:

wp plugin deactivate nome-plugin
wp plugin deactivate --all

Una volta trovato il plugin, controlla se esiste un aggiornamento che corregge l’errore, oppure torna alla versione precedente. Se l’errore è comparso dopo un aggiornamento, la guida su come aggiornare WordPress senza rompere il sito spiega come evitare che ricapiti.

E se la colpa è del tema?

Se il log indica un file dentro wp-content/themes/, o se l’errore è comparso dopo una modifica al tema, fai passare il sito a un tema predefinito di WordPress. Se il sito torna a funzionare, il problema è nel tema o nel child theme.

1. Verifica via FTP che in wp-content/themes/ ci sia un tema predefinito, per esempio uno dei temi “Twenty” (Twenty Twenty-Five, Twenty Twenty-Four). Se non c’è, scaricalo da wordpress.org e caricalo.
2. Rinomina la cartella del tema attivo, per esempio da mio-tema a mio-tema-off. WordPress passerà a un tema predefinito disponibile.
3. In alternativa, da phpMyAdmin, nella tabella wp_options (il prefisso può essere diverso) cambia i valori delle righe template e stylesheet con il nome della cartella del tema predefinito.

Con WP-CLI basta wp theme activate twentytwentyfive. La causa più frequente in questo caso è un frammento di codice aggiunto a functions.php: un punto e virgola mancante è sufficiente a bloccare tutto. Se hai modificato quel file, ripristina la versione precedente dal backup.

Come aumentare il limite di memoria PHP?

Se il log riporta “Allowed memory size of … bytes exhausted”, WordPress ha finito la memoria che PHP gli concede. Si risolve aumentando il limite in wp-config.php, entro quanto consente l’hosting.

La documentazione di wp-config.php indica che il valore predefinito di WP_MEMORY_LIMIT è 40 MB per un sito singolo e 64 MB per un multisito. Per aumentarlo aggiungi, prima della riga che chiude le modifiche:

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

Due precisazioni:

• WordPress non può superare il limite impostato dal server (il parametro memory_limit di PHP). Se l’hosting ti dà 128 MB, scrivere 256 MB non serve: devi alzare il limite dal pannello dell’hosting, se il piano lo permette.
• Aumentare la memoria risolve il sintomo, non sempre la causa. Un plugin che consuma memoria in modo anomalo va comunque individuato, altrimenti l’errore torna appena il sito cresce.

La versione PHP può causare l’errore critico?

Sì. Un plugin o un tema scritto per una versione vecchia di PHP può smettere di funzionare quando il server passa a una versione più recente, e viceversa un plugin recente può richiedere una versione di PHP che il tuo server non ha.

Il caso più tipico: l’hosting aggiorna PHP, e un tema non più mantenuto usa funzioni rimosse. Per esempio, create_function() ed each() sono state rimosse in PHP 8.0; il codice che le usa genera un errore fatale.

1. Controlla la versione attuale nel pannello dell’hosting, oppure in Strumenti > Salute del sito > Info > Server se riesci a entrare in bacheca.
2. Se l’errore è comparso subito dopo un cambio di PHP, come soluzione temporanea torna alla versione precedente dal pannello dell’hosting.
3. Poi aggiorna o sostituisci il plugin o il tema incompatibile, e solo dopo riporta PHP alla versione nuova.

Tornare indietro deve restare una misura d’emergenza: le versioni vecchie di PHP non ricevono più correzioni di sicurezza. Come scegliere la versione giusta e aggiornarla senza rischi lo spieghiamo nella guida su come aggiornare la versione PHP di WordPress.

Come riparare i file core di WordPress corrotti?

Se il log indica file dentro wp-admin o wp-includes, i file di base di WordPress (il “core”) potrebbero essere danneggiati o modificati. Si risolve sostituendoli con una copia pulita della stessa versione.

1. Verifica la versione installata nel file wp-includes/version.php (riga $wp_version).
2. Scarica la stessa versione da wordpress.org e scompatta l’archivio sul computer.
3. Via FTP, sostituisci le cartelle wp-admin e wp-includes e i file nella cartella principale.
4. Non sovrascrivere la cartella wp-content né il file wp-config.php: contengono il tuo tema, i plugin, le immagini e la configurazione.

Con WP-CLI puoi prima verificare quali file sono diversi dall’originale e poi scaricarli di nuovo:

wp core verify-checksums
wp core download --skip-content --force

Se trovi file core modificati senza motivo, o file sconosciuti nelle cartelle di sistema, l’errore critico potrebbe essere l’effetto di un’infezione. In quel caso sostituire i file non basta: segui la guida su cosa fare se il sito WordPress è stato hackerato.

Il file .htaccess può essere la causa?

Raramente, e di solito con un sintomo diverso: un file .htaccess con errori provoca in genere un “500 Internal Server Error” più che il messaggio di errore critico. Vale comunque la pena controllarlo se hai modificato regole di redirect, cache o sicurezza.

Il file .htaccess si trova nella cartella principale del sito e contiene le regole del server web Apache (su server Nginx non viene usato). Per escluderlo:

1. Scaricane una copia sul computer.
2. Rinominalo sul server in .htaccess-off e ricarica il sito.
3. Se il sito torna a funzionare, crea un nuovo .htaccess con le regole standard di WordPress e poi aggiungi una alla volta le regole personalizzate che ti servono.

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Queste regole valgono per un sito installato nella cartella principale del dominio. In alternativa, dopo aver rinominato il file, entra in Impostazioni > Permalink e premi Salva: WordPress rigenera il file da solo.

Quando conviene chiamare un tecnico?

Conviene chiamare un tecnico quando il sito è critico per il lavoro e ogni ora di fermo costa, quando non hai accesso FTP o al database, o quando i passaggi precedenti non isolano la causa. Anche i segnali di un’infezione richiedono un intervento professionale.

Per orientarti in fretta:

Se non entri in bacheca per altri motivi, trovi le soluzioni nella guida su cosa fare se non riesci ad accedere a wp-admin. Nei siti che seguiamo in abbonamento con Dottor WP la prevenzione parte dagli aggiornamenti testati e dai backup quotidiani, che rendono questi errori rari e rapidi da annullare.

Domande frequenti

Perché compare l’errore critico dopo un aggiornamento?

Quasi sempre perché il plugin o il tema aggiornato non è compatibile con un altro componente, con la versione di WordPress o con la versione PHP del server. Disattiva il plugin aggiornato via FTP e verifica nel changelog se esiste una correzione.

L’errore critico significa che il sito è stato hackerato?

Di solito no: nella maggior parte dei casi è un problema di compatibilità o di memoria. Diventa sospetto se trovi file sconosciuti, file core modificati o utenti amministratori che non riconosci.

Perdo i contenuti se disattivo i plugin via FTP?

No. Rinominare la cartella di un plugin lo disattiva, ma i contenuti e quasi sempre le impostazioni restano nel database. Quando lo riattivi ritrovi la configurazione, salvo rari plugin che cancellano i dati alla disattivazione.

Non ho ricevuto l’email di recovery mode: cosa faccio?

Controlla lo spam e verifica quale indirizzo è impostato come email di amministrazione. Se non la trovi, attiva WP_DEBUG_LOG in wp-config.php e leggi il file debug.log per sapere quale componente causa l’errore.