WSOD WordPress: risolvere la schermata bianca in 10 minuti

WSOD WordPress: risolvere la schermata bianca in 10 minuti

6 min di lettura
Indice dell’articolo13 sezioni
  1. 01Cos'è davvero il WSOD
  2. 02Step 1 — Abilita il debug per vedere l'errore
  3. 03Step 2 — Disattiva tutti i plugin via FTP
  4. 04Step 3 — Cambia tema temporaneamente
  5. 05Step 4 — Aumenta la memoria PHP
  6. 06Step 5 — Reinstalla i core WordPress
  7. 07Step 6 — Restore da backup
  8. 08Casi reali dai nostri interventi
  9. 09Come evitare il prossimo WSOD
  10. 10Cosa portarsi a casa
  11. 11Conclusione
  12. 12Continua a leggere
  13. 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.php corrotto — 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.

  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.

Continua a leggere

Domande frequenti

Cos’è la schermata bianca della morte (WSOD)?
È quando il sito mostra una pagina bianca senza errori visibili. Di solito è un errore PHP fatale — un plugin, il tema o la memoria esaurita — che blocca il rendering. Quasi sempre è recuperabile senza perdere dati.
Come trovo la causa di un WSOD?
Attiva il debug di WordPress (WP_DEBUG) per far comparire il messaggio d’errore, oppure controlla il log del server. Da lì capisci se è un plugin, il tema o un limite di memoria PHP, e agisci di conseguenza.
Posso risolvere senza accedere alla bacheca?
Sì: si lavora via FTP o file manager. Si disattivano i plugin rinominando la cartella, si cambia tema, si alza il limite di memoria nel wp-config. Nei casi gravi si ripristina da backup. La bacheca non serve.

Contatti

Let's
Talk.

Hai un progetto in mente o vuoi ricevere maggiori informazioni? Siamo pronti a dare forma alle tue idee e trasformarle in realtà digitale.