Il sito funzionava un secondo fa, stavi finendo un articolo o configurando WooCommerce e all'improvviso il nulla. Una schermata bianca al posto del pannello di amministrazione. Oppure è sparita la homepage, anche se la dashboard si apre ancora. Ti suona familiare? Benvenuto nel club, hai incontrato la White Screen of Death, nota anche come WSOD, o «schermata bianca della morte» WordPress.

Qui il panico è il primo nemico. La WSOD non significa quasi mai che il sito sia morto per sempre. Il più delle volte la causa è banale: un conflitto tra plugin dopo un aggiornamento, codice inserito male in functions.php o semplice mancanza di memoria per il processo PHP. In questa guida, quattro metodi collaudati per riportare in vita il sito e un quinto integrato nel core di WordPress che persino gli utenti esperti dimenticano.

💡 Panoramica rapida:

• Disattiva il plugin problematico via FTP (rinominando la cartella) o in blocco rinominando la directory plugins
• Disattiva il tema in conflitto con lo stesso metodo: cartella themes → rinomina la directory del tema attivo
• Aumenta il limite di memoria PHP con la riga WP_MEMORY_LIMIT in wp-config.php a 128M o 256M
• Attiva WP_DEBUG e WP_DEBUG_LOG per la diagnostica, scopri la causa esatta dell'errore dal file debug.log
• Usa la Recovery Mode (WordPress 5.2+), un meccanismo integrato che invia un link per accedere al pannello di amministrazione anche durante un errore fatale
• Ripristina il sito da backup se gli altri metodi non hanno funzionato

1. Disattivare il plugin problematico

I plugin sono la causa più comune della WSOD. Hai appena aggiornato il tuo plugin di caching preferito, lo schermo è diventato nero. Hai installato un nuovo slider, il sito ha smesso di aprirsi. La meccanica è semplice: il codice PHP del plugin causa un errore fatale e WordPress interrompe il caricamento dell'intera pagina.

Il problema è che non puoi accedere al pannello di amministrazione e cliccare «Disattiva», il pannello va in schermata bianca allo stesso modo. La soluzione: disattivare il plugin direttamente tramite file system.

Come disattivare un plugin via FTP:

• Connettiti al server via FTP (FileZilla, WinSCP) o tramite il file manager dell'hosting (cPanel → File Manager).
• Vai alla directory root di WordPress.
• Apri wp-content/plugins.
• Trova la cartella del plugin problematico, il nome corrisponde al titolo (per esempio, akismet, woocommerce o elementor).
• Rinomina la cartella: aggiungi un trattino basso o un suffisso, _akismet o akismet_disabled. WordPress percepirà la rinomina come assenza del plugin e lo disattiverà.

Subito dopo la rinomina, apri il sito nel browser. Funziona, il colpevole è stato trovato. Ora puoi ripristinare il nome originale della cartella e, dopo aver effettuato l'accesso al pannello di amministrazione, aggiornare il plugin a una versione compatibile oppure rimuoverlo e cercare un'alternativa.

Disattivazione in blocco di tutti i plugin in una volta sola. Se non è chiaro quale plugin esatto abbia causato il guasto, disattiva tutto in massa. Rinomina la cartella wp-content/plugins in plugins_old e crea accanto una nuova directory plugins vuota. Tutti i plugin sono disattivati. Poi riportali uno per uno: sposta la cartella del plugin da plugins_old di nuovo in plugins, accedi al pannello di amministrazione, attivalo e verifica il sito. Ripeti finché non trovi il colpevole.

Alternativa per chi ha WP-CLI. Un comando nel terminale sostituisce la danza FTP col tamburello:

1
wp plugin deactivate --all

E poi attiva uno per uno: wp plugin activate <slug>. Veloce, pulito, senza file manager.

2. Disattivare il tema in conflitto

Il secondo colpevole più frequente è il tema. Gli scenari sono gli stessi: hai aggiornato il tema a una nuova major release, hai installato un tema con un functions.php scritto male, oppure un plugin è entrato in conflitto con il tema attuale dopo un aggiornamento di WordPress.

Il meccanismo di correzione è quasi identico a quello dei plugin:

• Accedi via FTP a wp-content/themes.
• Trova la cartella del tema attivo (quello attualmente installato sul sito).
• Rinominala, per esempio aggiungi _disabled alla fine del nome.

WordPress, non trovando il tema attivo, passerà automaticamente al tema predefinito Twenty Twenty-Five (o Twenty Twenty-Four, a seconda della versione di WP). Il sito si caricherà con il design predefinito, ma tutti i tuoi contenuti resteranno al loro posto. Importante: non eliminare il tema predefinito, altrimenti non ci sarà nulla su cui passare e otterrai un altro giro di WSOD.

Temi codificati male e aggiornamenti di WordPress. Dopo un rilascio maggiore di WordPress, i vecchi temi che usano funzioni o hook deprecati possono rompersi. I temi di qualità di sviluppatori verificati vengono aggiornati entro pochi giorni dal rilascio del core. Se il tuo tema non viene aggiornato da sei mesi o più, è un campanello d'allarme: passa a uno che sia mantenuto attivamente.

Modifiche a functions.php e ad altri file del tema. Un refuso in functions.php, una parentesi di troppo, una chiamata a un hook sbagliata e il sito va giù. Se hai modificato i file del tema subito prima che comparisse la WSOD, sostituisci il file modificato con la versione originale da un backup o dalla distribuzione del tema. Senza backup, scarica di nuovo il tema dalla fonte e carica il file pulito.

3. Superamento del limite di memoria PHP

Il sito è cresciuto, i plugin si sono moltiplicati, il traffico è aumentato e all'improvviso WSOD. Un sintomo classico che il processo PHP ha esaurito la RAM. Particolarmente rilevante sugli hosting economici, dove un server serve centinaia di siti e il limite per cliente è tagliato al minimo.

WordPress raccomanda ufficialmente un minimo di 64 MB di memoria, ma questa raccomandazione risale all'era di PHP 5.6 e cinque plugin per sito. Nel 2026, un minimo realistico per un sito funzionante è 128 MB, e per installazioni con Elementor, WooCommerce e diverse decine di plugin, 256 MB.

Come aumentare il limite di memoria:

Apri il file wp-config.php (si trova nella root di installazione di WordPress) e aggiungi una riga prima del commento /* That's all, stop editing! */:

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

Se il provider limita rigidamente la memoria PHP a livello di server, questa direttiva non funzionerà, allora c'è solo una via d'uscita: cambiare piano o hosting. Gli hosting WordPress gestiti (SiteGround, WP Engine, Kinsta) configurano limiti adeguati di default e il problema della memoria non si incontra praticamente mai.

4. Diagnostica tramite WP_DEBUG

A volte né i plugin, né il tema, né la memoria sono responsabili, la causa della WSOD sfugge. Allora devi far sì che WordPress ti dica esattamente cosa è andato storto.

WordPress porta con sé da decenni un debugger integrato WP_DEBUG. Di default è disattivato (schermata bianca invece degli errori, l'idea è non esporre ai visitatori le interiora del sito). Ma per l'amministratore questa modalità è impagabile.

Aggiungi a wp-config.php:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Cosa succede:

• WP_DEBUG attiva la modalità debug;
• WP_DEBUG_LOG scrive gli errori nel file wp-content/debug.log, comodo da leggere senza mostrarli ai visitatori;
• WP_DEBUG_DISPLAY con valore false nasconde gli errori dallo schermo (vedi una schermata bianca, ma i log vengono scritti).

Dopo l'attivazione, apri il sito, riproduci il problema e guarda in wp-content/debug.log. Ci sarà una riga con il file, il numero di riga e il tipo di errore, per esempio Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. Questo è l'indirizzo esatto del problema.

Importante: non lasciare WP_DEBUG attivo in produzione dopo la diagnostica, i log crescono rapidamente e possono riempire lo spazio su disco.

5. Recovery Mode, il salvatore integrato di WordPress 5.2+

Dalla versione 5.2, WordPress può rilevare da solo gli errori fatali e offrire un percorso di ripristino. La Recovery Mode (modalità di ripristino) è una funzionalità che molti amministratori ancora non usano semplicemente perché non la conoscono.

Come funziona. Quando il codice PHP in un plugin o tema causa un errore fatale, WordPress lo intercetta, ferma l'estensione problematica e invia un'email all'email dell'amministratore. L'email contiene un link che apre l'accesso al pannello di amministrazione bypassando il codice problematico. Accedi, vedi il plugin andato in crash contrassegnato come «causa errore», lo disattivi e il sito è di nuovo vivo. Niente FTP, niente rinomina di cartelle.

Limitazioni della Recovery Mode:

• Il link è valido per un tempo limitato (circa un giorno) ed è legato a un indirizzo IP;
• Richiede l'invio di mail configurato dal sito (plugin SMTP o mail dell'hosting);
• Non salva da errori a livello di server (mancanza di memoria, .htaccess corrotto).

Eppure, se l'email è arrivata, risparmi una dozzina di minuti di nervi e movimenti FTP.

Guarda una breve guida su come correggere la WSOD, tutti i metodi descritti con dimostrazione dal vivo:

⁉️🤔 Domande frequenti

Perché la schermata bianca compare solo nel pannello di amministrazione, ma il sito si apre normalmente?

L'errore è localizzato in codice che viene eseguito solo nel pannello di controllo: un metabox di un plugin, la pagina delle impostazioni del tema, un widget admin personalizzato. Disattiva uno per uno i plugin installati di recente, il colpevole si troverà in fretta. Se non aiuta, attiva WP_DEBUG_LOG e controlla il log dopo aver tentato di accedere al pannello di amministrazione.

Schermata bianca solo su un articolo o una pagina di ingresso, cos'è?

Molto probabilmente il problema è nel contenuto della voce specifica: uno shortcode di un plugin inesistente, HTML rotto nel testo, conflitto con campi personalizzati. Apri la voce tramite Modifica rapida nel pannello di amministrazione e cambia temporaneamente lo stato in «Bozza». La pagina si carica? Allora scava dentro il contenuto.

Si può evitare del tutto la WSOD in futuro?

Eliminarla completamente no, ma minimizzare il rischio è realistico. Tre regole: (1) testa sempre gli aggiornamenti di plugin e temi su una copia di staging del sito prima di distribuirli in produzione; (2) mantieni backup giornalieri di file e database; (3) non installare plugin e temi da fonti discutibili, specialmente versioni nulled.

La Recovery Mode non ha inviato un'email, cosa fare?

La posta da un sito WordPress senza un plugin SMTP configurato funziona in modo instabile. Imposta SMTP (Post SMTP, FluentSMTP o WP Mail SMTP) come misura preventiva. Se l'email non è già arrivata, torna al metodo FTP della sezione 1, funziona sempre.

Quanto dura il link della Recovery Mode?

Il link è valido per 24 ore (più precisamente, fino alla scadenza del token nonce). Dopodiché devi riprodurre di nuovo l'errore, WordPress invierà di nuovo l'email.

Cosa fare se nulla ha aiutato?

Se i quattro metodi sopra e la Recovery Mode non hanno riportato in vita il sito, il problema è più profondo. Forse il file .htaccess è danneggiato (rinominalo e accedi al pannello di amministrazione, WordPress ne creerà uno nuovo tramite «Impostazioni → Permalink → Salva»). Oppure incompatibilità della versione PHP: WordPress moderno richiede PHP 7.4+, ma l'host potrebbe avere ancora PHP 5.6.

Un altro strumento diagnostico è il plugin Health Check & Troubleshooting del team WordPress.org. Può avviare una sessione in modalità sicura: disattiva tutti i plugin e passa al tema predefinito, ma solo per il tuo browser (i visitatori vedono il sito normale). Con esso puoi attivare in sicurezza i plugin uno per uno e catturare il colpevole senza toccare la produzione.

Niente tempo per indagare, ma il sito deve essere online subito? Ripristina il backup. Se non c'è backup, una lezione per il futuro: i backup automatici giornalieri costano pochi dollari al mese e si ripagano il primo giorno di un disastro. Praticamente ogni hosting offre questa funzionalità nel pannello di controllo.

E soprattutto, non temere la WSOD. È spiacevole, ma risolvibile. Ora hai un algoritmo di azione passo dopo passo, non il panico e uno schermo vuoto.