La schermata bianca della morte di WordPress, spiegata

La schermata bianca della morte è un errore fatale PHP che non riesci a vedere. WordPress ha incontrato un errore irrecuperabile a metà del rendering, PHP si è fermato e, poiché la visualizzazione degli errori è disattivata sui server di produzione, la pagina è tornata vuota invece di stampare il motivo. La soluzione quasi mai è una questione di tentativi: attiva il log di debug, apri wp-content/debug.log e leggi l’ultima riga fatale. Indica il file esatto — quasi sempre un plugin o un tema — e quella singola riga è tutta la riparazione.

Perché la schermata è vuota

PHP ha un’impostazione chiamata display_errors. Su una macchina di sviluppo di solito è attiva, quindi un errore fatale stampa uno stack trace sullo schermo. Su un host reale è disattivata per impostazione predefinita, perché esporre percorsi dei file ed errori ai visitatori è un problema di sicurezza. Quindi quando qualcosa genera un errore fatale — una chiamata a una funzione che non esiste più, una classe che non viene caricata, un errore di sintassi in un aggiornamento di un plugin — PHP muore e non invia nulla. Il tuo browser mostra un documento vuoto. Questa è la “schermata bianca”.

Da WordPress 5.2 esiste un gestore degli errori fatali (WP_Fatal_Error_Handler) che cerca di intercettarli. Quando funziona, non ottieni una pagina vuota — ottieni “Si è verificato un errore critico sul tuo sito web”, oltre a un’email all’indirizzo dell’amministratore che spesso contiene l’errore vero e proprio e un link alla Modalità di ripristino. Una schermata davvero vuota di solito significa che l’errore si è verificato prima che quel gestore potesse entrare in funzione: un errore di parsing/sintassi (intercettato in fase di compilazione), un must-use plugin difettoso, o un errore fatale nel functions.php del tema attivo. In ogni caso, la causa è scritta da qualche parte. Devi solo attivare la scrittura.

Risolvilo, nell’ordine giusto

1. Attiva il log. Modifica wp-config.php via SFTP e aggiungi questo sopra la riga /* That's all, stop editing! */:

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 tiene gli errori fuori dalla pagina pubblica mentre WP_DEBUG_LOG li scrive in wp-content/debug.log. Ricarica una volta la pagina difettosa per generare una voce fresca.

2. Leggi l’ultimo errore fatale. Apri wp-content/debug.log e guarda in fondo:

tail -n 30 wp-content/debug.log

Stai cercando una riga come questa:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

Il percorso indica il colpevole: plugins/some-addon. Questa è la tua risposta. Se il trace è lungo o il messaggio è criptico (Allowed memory size exhausted, Cannot redeclare, un nome di classe che non riconosci), incollalo nel nostro decoder del log errori — elimina il rumore, ti dice a quale plugin o tema punta il percorso, e spiega cosa significa quello specifico tipo di errore.

3. Disattiva il componente indicato. Non riesci a raggiungere /wp-admin, quindi fallo via SFTP. Rinomina la cartella del plugin incriminato, ad esempio some-addon → some-addon.off. WordPress non può caricare una cartella che non riesce a trovare, quindi disattiva il plugin e il sito torna online. Se il log punta al tuo tema, passa a un tema predefinito rinominando la cartella del tema attivo — WordPress ripiega su un twentytwentysomething incluso.

4. Se il log non viene scritto, wp-content non è scrivibile, oppure l’errore è a livello di server. Controlla invece il log degli errori PHP dell’host:

find . -name "error_log" -newermt "-1 hour"

Stesse informazioni, file diverso. Gli stack cPanel/Apache spesso lasciano un error_log nella root del sito o nella directory che sta fallendo.

Cosa non fare

Non limitarti ad aumentare il memory limit. Il consiglio più ripetuto online è di portare WP_MEMORY_LIMIT a 256M o 512M. Questo risolve la WSOD solo se il log dice effettivamente Allowed memory size of N bytes exhausted. Se l’errore è Call to undefined function, più memoria non serve a nulla — hai cambiato un’impostazione a caso e la schermata è ancora bianca. Leggi il log prima, poi aumenta la memoria solo se la memoria è il problema dichiarato.

Non svuotare la cache e considerarla una diagnosi. La schermata bianca è PHP che muore sul server prima che esista qualsiasi HTML. Una risorsa in cache obsoleta non può causare un documento vuoto. (Un plugin di caching difettoso sì — ma il log lo indicherà, che è proprio il punto.)

Non modificare o reinstallare il core di WordPress. L’errore fatale quasi mai è in wp-includes o wp-admin; è nel plugin o nel tema che il log indica. Reinstallare il core è lento, rischioso, e cura un sintomo che non hai confermato.

Non disattivare tutti i plugin per riattivarli uno per uno alla cieca. La bisezione funziona, ma è la strada lenta. Il log ti dice la cartella esatta in un solo passaggio. Ricorri al metodo “spegni tutto” solo quando non c’è alcun errore leggibile.

Non lasciare display_errors attivo in produzione. Una volta che il sito è tornato online, rimuovi le define di debug (o riporta WP_DEBUG su false). Gli errori stampati ai visitatori espongono i tuoi percorsi.

Ancora bloccato?

Se il log indica un plugin ma disattivarlo non risolve la schermata, c’è un secondo errore fatale sotto il primo — riattiva il log e leggi la nuova ultima riga; gli errori fatali si accumulano. Se è il messaggio stesso a essere il muro, buttalo nel decoder del log errori e lascia che traduca per te il tipo di errore e il percorso del file. La schermata bianca resta un mistero solo finché il log è disattivato.