Indice dell’articolo13 sezioni
- 01Cos'è davvero il WSOD
- 02Step 1 — Abilita il debug per vedere l'errore
- 03Step 2 — Disattiva tutti i plugin via FTP
- 04Step 3 — Cambia tema temporaneamente
- 05Step 4 — Aumenta la memoria PHP
- 06Step 5 — Reinstalla i core WordPress
- 07Step 6 — Restore da backup
- 08Casi reali dai nostri interventi
- 09Come evitare il prossimo WSOD
- 10Cosa portarsi a casa
- 11Conclusione
- 12Continua a leggere
- 13Domande frequenti
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.phpcorrotto — modifica fatta a mano con sintassi errata (5%)
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.
- Vai in
wp-content/ - Rinomina la cartella
pluginsinplugins_off - Ricarica il sito. Se ora si vede, il problema è in uno dei plugin.
- Rinomina indietro a
plugins— WordPress non li riattiva da solo, devi farlo tu dal pannello. - 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:
- Vai in
wp-content/themes/ - Rinomina la cartella del tema attivo in
nometema-off - WordPress carica automaticamente Twenty Twenty-Five (o l’ultimo theme di default). Se non c’è, scarica e mettilo in
themes/. - 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.
- Mai aggiornare in produzione senza prima testare su staging. È il consiglio che ripetiamo in ogni nostra guida sugli update.
- Backup giornaliero esterno al sito. Hostinger, SiteGround, Kinsta hanno backup integrato; per chi è su altro hosting, UpdraftPlus o BlogVault sono lo standard.
- 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.