La pagina bianca WordPress, detta anche White Screen of Death, indica in genere che PHP ha interrotto l’esecuzione prima di generare una risposta visibile. Può comparire nel frontend, nella bacheca o soltanto in una sezione del sito dopo un aggiornamento, l’attivazione di un plugin o una modifica al tema.

Non esiste un singolo file da sostituire in ogni caso. La soluzione corretta parte dal log dell’errore e procede per esclusione, mantenendo sempre una copia recuperabile del sito.

Prima di intervenire: backup e controllo dell’errore

Se il sito è ancora parzialmente accessibile, crea un backup di file e database. Se è completamente bloccato, evita operazioni distruttive e conserva almeno una copia dei file che intendi rinominare o sostituire. Annota l’ora in cui è apparso il problema: aiuterà a trovare la riga corretta nei log.

Controlla inoltre il codice HTTP con gli strumenti del browser o con curl. Una pagina vuota può restituire 200, ma può anche nascondere un errore 500; questa distinzione restringe la diagnosi.

1. Usare la modalità di ripristino di WordPress

Quando WordPress rileva un errore fatale, può inviare all’indirizzo amministrativo un messaggio con oggetto relativo a un problema tecnico. Il link contenuto nell’email apre la Recovery Mode e sospende per quella sessione il componente responsabile, consentendo di accedere alla bacheca.

Controlla anche la cartella spam e verifica che l’indirizzo amministrativo sia aggiornato. Se l’email non arriva o il link è scaduto, passa ai log e alla disattivazione manuale.

2. Leggere i log PHP e WordPress

Nel pannello hosting cerca la sezione dedicata agli errori PHP oppure il file di log configurato per il dominio. La riga decisiva contiene spesso PHP Fatal error, il percorso del file e il numero di riga. Il percorso permette di capire se il problema nasce da un plugin, dal tema o dal core.

Attivare temporaneamente WP_DEBUG_LOG

Se non è disponibile un log utile, aggiungi temporaneamente queste direttive in wp-config.php, prima della riga che indica di interrompere le modifiche:

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

Riproduci una sola volta l’errore e controlla wp-content/debug.log. Disattiva il debug e rimuovi o proteggi il log appena terminata la diagnosi: può contenere percorsi, query o altri dati tecnici. La configurazione è descritta nella guida ufficiale al debug di WordPress.

3. Disattivare il plugin responsabile

Se il log indica un plugin e la bacheca è accessibile, disattivalo dal menu Plugin. Se non puoi entrare in amministrazione, usa File Manager o SFTP e rinomina soltanto la cartella del plugin, per esempio da nome-plugin a nome-plugin.off. Non cancellarla: la rinomina è reversibile e preserva i file per l’analisi.

Con accesso SSH e WP-CLI puoi eseguire:

wp plugin deactivate nome-plugin
wp plugin status

Se non sai quale plugin causa l’errore, rinomina temporaneamente l’intera cartella wp-content/plugins, verifica il sito, ripristina il nome originale e riattiva i plugin uno alla volta. WordPress documenta questa procedura nella propria guida alla risoluzione dei problemi.

Per una procedura più dettagliata consulta anche la guida su cosa fare quando un plugin WordPress causa un crash.

4. Verificare il tema attivo

Se il log punta al tema o il problema resta con tutti i plugin disattivati, passa temporaneamente a un tema predefinito compatibile. Da WP-CLI:

wp theme list
wp theme activate twentytwentysix

Usa il nome di un tema predefinito realmente installato. Se la pagina torna visibile, controlla funzioni personalizzate, template e compatibilità PHP del tema prima di riattivarlo.

5. Controllare versione PHP e limite di memoria

Incompatibilità PHP

Un plugin o tema datato può usare funzioni rimosse nelle versioni recenti di PHP; un componente moderno può invece richiedere una versione minima superiore a quella attiva. Il log mostra in genere errori come funzione non definita, errore di tipo o sintassi non valida. Non cambiare PHP alla cieca: confronta i requisiti di WordPress e dei componenti, poi prova la modifica in staging.

Memoria esaurita

Un messaggio Allowed memory size exhausted indica che il processo ha superato il limite disponibile. Aumentare la memoria può sbloccare il sito, ma non sostituisce l’analisi: query inefficienti, loop, importazioni e plugin difettosi possono consumare risorse senza controllo.

6. Verificare manutenzione e aggiornamenti incompleti

Dopo un aggiornamento interrotto può rimanere nella directory principale il file .maintenance. Se l’aggiornamento non è più in corso e il sito resta bloccato sul messaggio di manutenzione, rimuovi soltanto quel file e aggiorna nuovamente la pagina.

Controlla spazio disco, inode, permessi e proprietà dei file. Un disco pieno o permessi errati possono impedire a WordPress di completare la copia dei nuovi file.

7. Controllare l’integrità dei file core

Non sovrascrivere un singolo file core basandoti sul nome visto in una vecchia guida. Prima verifica i checksum ufficiali:

wp core verify-checksums

Il comando segnala file modificati o mancanti. Se il core è corrotto, crea un backup e reinstalla la stessa versione da una fonte ufficiale, senza toccare wp-content e wp-config.php. Da bacheca puoi usare “Reinstalla”; da shell, dopo aver verificato versione e lingua, è possibile usare:

wp core download --force --skip-content

Questa operazione va eseguita soltanto dopo aver escluso plugin e tema e aver verificato i checksum. Non caricare pacchetti provenienti da siti non ufficiali.

8. Svuotare le cache e verificare il frontend

Dopo la correzione svuota cache applicativa, page cache, object cache e CDN. Controlla sia una finestra anonima sia la bacheca, perché una cache può mostrare ancora la pagina bianca oppure nascondere un errore non risolto.

Verifica home page, login, modifica articoli, moduli, checkout e attività pianificate. Controlla nuovamente i log per assicurarti che non continuino a essere generati fatal error.

Cosa non fare

• non disattivare definitivamente gli aggiornamenti automatici come soluzione generale;
• non cancellare plugin o tema prima di averne conservato una copia;
• non sostituire indiscriminatamente wp-admin o wp-includes senza verificare i checksum;
• non mostrare gli errori PHP ai visitatori su un sito in produzione;
• non ripristinare l’intero sito se basta disattivare un singolo componente;
• non lasciare debug e log pubblicamente accessibili dopo la diagnosi.

Checklist finale

1. conserva backup e ora del malfunzionamento;
2. leggi il fatal error nei log;
3. usa Recovery Mode o disattiva il componente indicato;
4. controlla compatibilità PHP, memoria e spazio disco;
5. verifica i checksum prima di reinstallare il core;
6. svuota le cache e testa le funzioni principali;
7. riattiva gli aggiornamenti e applica la correzione definitiva in staging.

Conclusione

La pagina bianca WordPress è un sintomo, non una diagnosi. Il percorso più sicuro consiste nel leggere il log, isolare il componente responsabile e applicare una soluzione reversibile. Copiare file a caso o bloccare tutti gli aggiornamenti può nascondere il problema e lasciare il sito vulnerabile.