Schermata bianca WordPress: diagnosi e recupero accesso
- Word press
- 2 settembre 2025
Indice dei contenuti
La schermata bianca di WordPress è un sintomo: indica che il browser non sta mostrando il contenuto atteso, ma non identifica la causa. Prima di reinstallare il sito, controlla se la richiesta restituisce un errore del server, una risposta vuota oppure una pagina presente ma nascosta da un problema di visualizzazione.
Il percorso utile è circoscrivere il guasto, trovare l’errore associato alla richiesta e recuperare l’accesso intervenendo sul componente indicato dalle prove. Una pagina bianca non giustifica da sola modifiche al database o un aumento della memoria.
Il sito è bianco ovunque o solo in una pagina?
Apri homepage, una pagina interna e l’indirizzo di accesso amministrativo. Ripeti il controllo da una sessione non autenticata. Annota se il problema cambia con utente, pagina o dispositivo e se è iniziato dopo un aggiornamento, una modifica al codice o un intervento hosting.
| Risultato | Indagine iniziale |
|---|---|
| Sito pubblico e accesso amministrativo non rispondono correttamente | Log PHP, servizio web e componenti caricati globalmente |
| Bacheca accessibile, sito pubblico bianco | Tema, template e codice usato nel frontend |
| Una sola pagina bianca | Contenuto, blocco o funzione specifica di quella pagina |
| Pagina normale per alcuni utenti | Cache, sessione e percorsi legati al ruolo |
| HTML presente ma contenuto invisibile | CSS e JavaScript nel browser |
Sono indicazioni per scegliere la prossima prova. Se il problema riguarda un reindirizzamento continuo o il rifiuto delle credenziali, non è lo stesso percorso diagnostico di una risposta vuota.
Leggere la risposta HTTP prima di modificare WordPress
Negli strumenti sviluppatore del browser, apri la scheda Rete, ricarica la pagina e seleziona la richiesta del documento principale. Registra codice di stato e contenuto della risposta. Un 500 richiede indagini sul server; un 200 con corpo vuoto non prova che l’applicazione abbia funzionato correttamente.
Se l’HTML contiene il contenuto atteso ma questo non appare, ispeziona gli elementi e gli errori JavaScript. Se il documento arriva da una cache, confrontalo con una richiesta controllata all’applicazione tramite gli strumenti dell’hosting. Non aggiungere parametri casuali presumendo che escludano ogni cache.
Questa distinzione evita interventi fuori bersaglio. Per esempio, una regola CSS che nasconde il contenitore principale può produrre una pagina apparentemente vuota senza un errore PHP.
Trovare il log corrispondente alla schermata bianca
Usa prima i log PHP disponibili nel pannello hosting. Riproduci il problema una volta, annota l’orario e cerca l’errore relativo a quella richiesta. I log possono usare un fuso orario diverso da quello del browser: controllalo prima di associare eventi.
Se serve il debug WordPress, configurarlo richiede accesso ai file e attenzione alle impostazioni già presenti. La documentazione ufficiale sul debug distingue attivazione del debug, registrazione e visualizzazione degli errori. Preferisci una copia di prova; sul sito pubblico evita di mostrare dettagli tecnici ai visitatori e proteggi i file di log.
Se il log WordPress resta vuoto, verifica che sia scrivibile e che l’errore non avvenga prima del caricamento del CMS. Un log vuoto non esclude un guasto. Per interpretare il messaggio trovato, passa alla guida sugli errori PHP e memoria WordPress.
Recuperare l’accesso quando un plugin blocca la bacheca
Controlla se è arrivata un’email amministrativa con indicazioni per la modalità di recupero. Il suo arrivo non è garantito: dipende anche dal tipo di errore e dall’invio email. Non inoltrare pubblicamente eventuali link di accesso.
Se l’errore individua un plugin ordinario e non puoi usare la bacheca, dopo aver conservato backup e log puoi impedirne temporaneamente il caricamento rinominando soltanto la sua cartella tramite SFTP o il gestore file dell’hosting. Annota il nome originale e controlla prima le dipendenze e le funzioni che saranno interrotte.
La tecnica non equivale a disinstallare il plugin e non copre automaticamente componenti obbligatori, drop-in o configurazioni Multisite. Se il guasto riguarda il tema, evita di rinominare cartelle alla cieca: va predisposto un tema alternativo compatibile e verificato il modo corretto di attivarlo.
Usare il recupero come prova, non come soluzione definitiva
Se il sito torna visibile senza il componente sospetto, riproduci il caso in staging e identifica la condizione precisa. La funzione rimossa potrebbe essere ancora necessaria: moduli, prenotazioni o aree riservate devono essere considerati nel recupero.
Un esempio ipotetico: il sito torna visibile dopo aver escluso un plugin di ricerca, ma la ricerca resta assente. Il risultato dimostra che quel percorso partecipa al guasto; serve ancora correggere il plugin, la dipendenza o i dati coinvolti e ripristinare la funzione.
Se il problema segue un aggiornamento incompleto, verifica anche la coerenza dei file con la diagnosi degli aggiornamenti falliti. Se non hai prove sufficienti, preserva lo stato e coinvolgi l’hosting prima di eseguire sostituzioni estese.
Controlli prima di dichiarare risolta la pagina bianca
Ripeti la richiesta originaria e verifica stato HTTP, contenuto e assenza del medesimo errore nei nuovi log. Prova accesso, salvataggio, moduli e altre funzioni coinvolte, da visitatore e amministratore. Controlla anche pagine non memorizzate in cache.
Ripristina le impostazioni di debug appropriate alla produzione e gestisci i log raccolti senza lasciarli pubblicamente accessibili. Documenta la causa verificata e le eventuali funzioni ancora sospese.
Se WordPress mostra una schermata bianca e non riesci a recuperare l’accesso, posso analizzare risposta e log del sito per individuare un intervento mirato e verificarne gli effetti.
