WSOD WordPress: risolvere la schermata bianca in 10 minuti

Aprire il browser, digitare l’URL del tuo sito, e vedere una pagina completamente bianca. Niente errore, niente messaggio, niente di niente. È la White Screen of Death di WordPress, uno dei problemi più ansiogeni del CMS, ma quasi sempre risolvibile in 10-15 minuti se sai dove guardare. Guida pratica step-by-step per riportare il sito online.

Cos’è davvero il WSOD

WordPress è scritto in PHP. Quando PHP incontra un errore fatale (un plugin con un bug, un conflitto di funzioni, una memoria esaurita), interrompe l’esecuzione. Senza l’output corretto dell’HTML, il browser non riceve nulla, solo una pagina bianca. Non è un bug di WordPress, è il comportamento normale di PHP davanti a un crash.

Le cause più frequenti, in ordine di probabilità:

• Plugin appena aggiornato con bug o incompatibilità (70% dei casi)
• Tema appena aggiornato o personalizzazione rotta (15%)
• Memoria PHP esaurita, siti con molti plugin e poca RAM allocata (10%)
• File functions.php corrotto, modifica fatta a mano con sintassi errata (5%)

Non è sempre una pagina bianca: le varianti che vedi più spesso

La schermata bianca classica è sparita da un pezzo. Dalla versione 5.2 WordPress intercetta gli errori fatali e mostra qualcosa, quindi quello che vedi oggi è quasi sempre una di queste tre situazioni, e la cura cambia.

“Si è verificato un errore critico sul tuo sito”

È il messaggio più comune, e in realtà è una buona notizia: significa che WordPress ha capito cosa stava succedendo e si è fermato prima di rompere tutto. Quel messaggio dice anche un’altra cosa importante, cioè che è stata inviata una email all’indirizzo dell’amministratore del sito.

Quella email contiene il file e la riga esatta dell’errore, ed è la scorciatoia che fa risparmiare mezz’ora. Il problema è che spesso arriva a un indirizzo che nessuno controlla più, oppure finisce nello spam: se ti capita, controlla lì prima di iniziare a disattivare plugin a caso.

Il sito si vede ma il pannello no

Succede quando l’errore sta in una parte che gira solo nell’area di amministrazione, tipicamente un plugin di gestione o un tema che carica funzioni diverse a seconda del contesto. WordPress ha una via d’uscita pensata apposta: la modalità di ripristino, che si attiva dal link contenuto in quella stessa email e permette di entrare nel pannello con plugin e tema sospesi, per disattivare il colpevole senza toccare i file.

Bianco davvero, senza nessun messaggio

Questa è la situazione più antipatica e restringe il campo a poche cause: memoria PHP esaurita, un errore che avviene prima che WordPress possa gestirlo, oppure la visualizzazione degli errori spenta a livello di server. È il caso in cui serve davvero il debug, ed è il passaggio descritto qui sotto.

Prima di tutto: è successo qualcosa cinque minuti fa?

Prima di aprire il file di configurazione, fermati un secondo e rispondi a una domanda: cosa è cambiato poco prima che smettesse di funzionare?

Nella quasi totalità dei casi la risposta è una di queste quattro: un aggiornamento di plugin o tema, una modifica a un file fatta dall’editor del pannello, un plugin nuovo installato, un intervento sull’hosting come un cambio di versione di PHP.

Se sai cosa è cambiato, hai già la causa e puoi andare direttamente al rimedio: annullare quella modifica. Il percorso completo qui sotto serve quando quella risposta non ce l’hai, o quando annullare non basta.

Step 1: Abilita il debug per vedere l’errore

Prima di toccare niente, scopri cosa sta crashando. Accedi via FTP o file manager dell’hosting al file wp-config.php nella root del sito. Cerca questa riga:

define( 'WP_DEBUG', false );

Cambiala in:

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

Salva, ricarica il sito, e vai a leggere il file wp-content/debug.log che WordPress crea automaticamente. Le prime 10-20 righe ti dicono esattamente quale plugin o file ha causato l’errore.

Esempio reale: PHP Fatal error: Cannot redeclare function in /wp-content/plugins/easy-form/lib.php on line 42. Hai trovato il colpevole.

Step 2: Disattiva tutti i plugin via FTP

Se non riesci ad accedere al pannello admin (perché bianco anche lì), disattivi tutti i plugin rinominando la cartella via FTP/file manager.

1. Vai in wp-content/
2. Rinomina la cartella plugins in plugins_off
3. Ricarica il sito. Se ora si vede, il problema è in uno dei plugin.
4. Rinomina indietro a plugins, WordPress non li riattiva da solo, devi farlo tu dal pannello.
5. Vai in Plugin > Plugin installati, sono tutti disattivati. Attiva uno alla volta finché il sito non si rompe di nuovo. Quello è il colpevole.

Tempo medio: 5-10 minuti. Se il sito ha 30+ plugin, il binario splitting accelera: attiva la metà alla volta, vedi se gira, restringi.

Step 3: Cambia tema temporaneamente

Se disattivare i plugin non risolve, il colpevole è il tema. Stesso pattern:

1. Vai in wp-content/themes/
2. Rinomina la cartella del tema attivo in nometema-off
3. WordPress carica automaticamente Twenty Twenty-Five (o l’ultimo theme di default). Se non c’è, scarica e mettilo in themes/.
4. Se il sito ora si vede, il problema è nel tuo tema. Probabilmente è il functions.php, apri il file e cerca modifiche recenti.

Step 4: Aumenta la memoria PHP

Se il debug.log mostra “Allowed memory size of X bytes exhausted”, è un problema di RAM. In wp-config.php aggiungi prima della riga /* That's all, stop editing! */:

define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Se anche con 512M va in errore, il problema non è la memoria, è un plugin che fa loop infiniti. Torna allo Step 2.

Nota: il limite WP è applicato solo se php.ini del server lo permette. Su hosting condivisi economici potresti essere capped a 256M, quindi devi chiedere all’hosting di alzarlo.

Step 5: Reinstalla i core WordPress

Se nessuno dei passi sopra funziona, qualche file core potrebbe essere corrotto (raro ma succede). Scarica WordPress da wordpress.org/latest.zip, estrai e sovrascrivi i file della tua installazione (escluso wp-content/ e wp-config.php). Tipicamente risolve i casi residuali.

Step 6: Restore da backup

Hai provato tutto, non si riprende? Ripristina il backup precedente alla rottura. Se la rottura è iniziata stamattina, ripristini lo stato di ieri sera. Perdi le modifiche fatte oggi, ma il sito torna live in 5 minuti.

Se non hai backup, è il momento di fermarti e chiamare un professionista. Continuare a smanettare senza punto di ripristino aumenta il rischio di perdere dati. Mai modificare un sito in produzione senza un backup recente.

Casi reali dai nostri interventi

Tre WSOD che abbiamo risolto e che ci siamo segnati.

• E-commerce ceramica, marzo 2025, WSOD dopo aggiornamento WooCommerce. Causa: plugin di gestione varianti non aggiornato, incompatibile con WC 8.5. Fix: rollback del plugin, attesa update vendor (arrivato 2 giorni dopo).
• Blog professionista, settembre 2025, WSOD random durante la giornata, ok altre volte. Causa: hosting condiviso saturato in fasce orarie di picco. Fix: upgrade a piano superiore + cache aggressiva.
• Landing page event, gennaio 2026, WSOD dopo modifica funzione PHP in functions.php. Causa: punto e virgola dimenticato. Fix: rollback del file via FTP. 30 secondi.

Come evitare il prossimo WSOD

Tre regole per ridurre drasticamente il rischio.

1. Mai aggiornare in produzione senza prima testare su staging. È il consiglio che ripetiamo in ogni nostra guida sugli update.
2. Backup giornaliero esterno al sito. Hostinger, SiteGround, Kinsta hanno backup integrato; per chi è su altro hosting, UpdraftPlus o BlogVault sono lo standard.
3. Plugin essenziali e niente più. Ogni plugin aggiunto è un possibile punto di rottura futuro. Disinstalla quelli che non usi attivamente.

Cosa portarsi a casa

• WSOD = errore PHP non gestito. Il debug log ti dice sempre il colpevole, abilitalo prima di smanettare.
• Disattiva via FTP rinominando la cartella plugins. È il singolo trick che risolve il 70% dei casi.
• Backup è la rete di sicurezza. Senza backup non si tocca un sito WordPress. Mai.

“La strategia si aggiusta sui risultati reali.” Vale anche in emergenza: ogni WSOD risolto migliora il tuo protocollo per il prossimo.

Conclusione

La schermata bianca della morte fa paura solo finché non sai cosa fare. Una volta capito il pattern (debug log, plugin off, tema default) è 10 minuti di lavoro nel 90% dei casi. Conviene esercitarsi una volta sul sito di test, prima di trovartelo davanti in produzione di sabato sera.

Se preferisci che siano altri a gestirlo, è esattamente cosa facciamo per i clienti in manutenzione continuativa. Niente vetrine, solo strumenti che vendono, e che restano in piedi.

Domande frequenti

Se il sito è tornato online ma non sai perché si era rotto, la risposta sta quasi sempre nella manutenzione: ne parliamo anche nella pagina audit digitale.

Se vuoi che ne parliamo, scrivici.