Come vedere gli errori di WordPress (e capire cosa vogliono dire)

Quando il sito non si apre, o compare la scritta «C'è stato un errore critico su questo sito», WordPress non ti sta dicendo cosa è successo: ti dice solo che qualcosa si è rotto. Quasi sempre c'entra il PHP, il linguaggio con cui WordPress e i suoi plugin sono scritti. Il motivo però è scritto da qualche parte, e in quasi tutti i casi si legge in pochi minuti. Qui sotto trovi i quattro posti dove guardare, in ordine. Si parte da quello che hai già davanti agli occhi e si arriva al file di log, che è quello che dice tutto.

Risposta breve. I posti dove si vede l'errore sono quattro. 1) La pagina che ti dice «errore critico» o resta bianca. 2) L'email che WordPress manda all'amministratore, con il link alla modalità di ripristino. 3) Strumenti → Salute del sito, dentro il pannello. 4) Il file debug.log nella cartella wp-content, che si crea accendendo il debug in wp-config.php. Il file di log è quello che dice la riga esatta dell'errore: il nome del file, la riga e la causa. E va spento appena hai finito di leggere. E poi cancella il file: spegnere il debug smette di scriverlo, ma debug.log resta dov'è — e su molti hosting è raggiungibile dal browser all'indirizzo tuo-sito.it/wp-content/debug.log. Un file che racconta i tuoi errori, servito a chiunque lo chieda, è una porta aperta.

Dove si vedono gli errori di WordPress?

1. La pagina: cosa vuol dire «errore critico» o «pagina bianca»?

Quello che compare nella pagina ti dice quanto è grave, non cosa è rotto. Ci sono tre casi e li riconosci a colpo d'occhio:

• «C'è stato un errore critico su questo sito»: WordPress ha capito che il guasto è nel codice PHP e ha fermato la pagina. È il caso migliore, perché questo messaggio arriva insieme a un'email (vedi il punto 2).
• Pagina bianca (la chiamano «schermata bianca della morte»): la pagina si apre vuota, senza messaggio. Significa che l'errore è avvenuto così presto da non poter nemmeno scrivere il messaggio.
• Errore 500 del server: il browser dice che il server ha avuto un problema interno. In una pagina WordPress l'errore 500 è quasi sempre lo stesso guasto del caso 1 o 2, solo comunicato dal server prima che WordPress intervenisse.

In tutti e tre i casi la pagina non ti dirà il nome del file e la riga: per quello serve il log. Tieni presente dove hai visto l'errore: solo in una pagina del sito? Solo nel pannello? Su tutto il sito? È la prima cosa che restringe la ricerca.

2. Come si entra in modalità di ripristino dall'email?

Quando WordPress intercetta un errore fatale durante l'apertura di una pagina, mostra l'avviso ai visitatori. Nello stesso momento manda un'email all'indirizzo dell'amministratore del sito, con i dettagli dell'errore e un link per accedere in «modalità di ripristino». Cerca quella mail: a volte finisce nello spam, quindi controlla anche lì. La procedura è descritta nella pagina ufficiale sulla modalità di ripristino.

La modalità di ripristino esiste da WordPress 5.2 ed è una specie di stanza di sicurezza: dentro quella sessione i plugin e i temi che stanno causando il guasto vengono messi in pausa solo per te, così puoi entrare nel pannello e sistemare. I visitatori non la vedono e non cambia niente per loro. Il percorso è questo:

1. Apri il link ricevuto per email ed entra nel sito.
2. Guarda gli avvisi in alto: indicano quale plugin o tema ha fallito.
3. Vai in Plugin (o Aspetto → Temi) e disattiva quello segnalato.
4. Se avevi modificato del codice — per esempio functions.php — correggilo prima di uscire.
5. Dalla barra in alto del pannello clicca Esci dalla modalità di ripristino e controlla che il sito si apra.

Se l'email non arriva, non è tutto perso: WordPress segnala i casi in cui il server non riesce a inviarla. Si passa allora agli strumenti del punto 4, oppure si chiede al supporto dell'hosting: ha visibilità sui log del server, che spesso non vedi dal pannello. Conviene dire l'ora esatta in cui è successo e chiedergli di guardare quelli.

3. Cosa dice «Salute del sito»?

Dentro il pannello, nel menu a sinistra, c'è la voce Strumenti → Salute del sito. Se il sito è così rotto che non arrivi nemmeno alla bacheca, questa strada non è percorribile: si parte dal punto 4. Non è un log: è un controllo che WordPress fa su sé stesso (documentazione di Salute del sito). Ha due schede e vanno lette per due motivi diversi.

• Stato: elenca i problemi divisi per gravità — problemi critici, miglioramenti consigliati, test superati. Qui trovi le cose che possono rompere il sito o la sua sicurezza, per esempio «il sito è impostato per mostrare gli errori ai visitatori»: vuol dire che il debug è rimasto acceso, ed è la prima cosa da spegnere.
• Info: è la fotografia tecnica del sito — versione di WordPress, spazio delle cartelle, tema e plugin attivi e inattivi, versione di PHP e del database, permessi dei file. C'è anche un pulsante per copiare tutto negli appunti: è quello che si incolla quando si chiede aiuto al supporto, e fa risparmiare tre scambi di email.

Attenzione a cosa non è: la Salute del sito ti dice se ci sono problemi generali, non ti dice perché quella pagina ha dato errore. Per quello serve il log.

4. Il file debug.log: come si accende e come si legge?

Questo è il posto che dice la verità: file, riga e causa dell'errore.

Prima di toccare qualsiasi cosa: il backup

La raccomandazione che WordPress mette in testa alla sua guida sul debug è semplice e vale sempre: prima di modificare un file, abbi una copia del sito. Se il tuo hosting ha un piano con backup automatici, controlla che ce ne sia uno recente e da dove si ripristina. Se non ce l'hai, scarica la cartella del sito e esporta il database prima di aprire wp-config.php. Sono cinque minuti che evitano di perdere il sito per un punto e virgola sbagliato.

Per creare il file si aggiungono alcune righe nel

wp-config.php

(

guida ufficiale al debug

), il file di configurazione che sta nella cartella principale del sito. Le righe vanno messe

prima

della scritta

/* That's all, stop editing! Happy blogging. */

.

define( 'WP_DEBUG', true );           // accende la modalità diagnostica
define( 'WP_DEBUG_LOG', true );       // scrive gli errori in wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );  // non li fa vedere ai visitatori

Un dettaglio che sbaglia quasi tutti la prima volta: true e false vanno scritti senza virgolette. Con le virgolette diventano una stringa e WordPress li legge come «acceso» anche quando non lo sono. Aggiungi le righe, ricarica la pagina che dà errore e poi cerca il file debug.log dentro wp-content, usando lo strumento file del tuo hosting o un programma FTP.

Nel file trovi una riga per ogni errore, con la data, il percorso del file e la riga. Le prime righe dall'alto sono le più vecchie: scorri in fondo per vedere l'ultimo errore. Se il file non compare, controlla due cose: che WP_DEBUG sia a true e che la cartella wp-content sia scrivibile. La Salute del sito, nella scheda Info, ti dice anche questo.

Il debug su un sito visitato va spento appena hai finito. WordPress stesso lo tratta come un problema critico, perché un log accessibile racconta di te più di quanto vuoi: percorsi dei file, nomi dei plugin, a volte anche dati. Per le prove lunghe si lavora su una copia del sito, non su quello pubblicato.

Se l'errore compare solo in una pagina o con un plugin

Il posto in cui vedi l'errore è già un indizio. Se succede solo aprendo una pagina precisa, il guasto sta nel contenuto di quella pagina o in un plugin che interviene lì. Se succede solo con il pannello, il sospetto è un plugin di amministrazione o un problema di risorse del server. Se compare solo con i page builder la causa è spesso la versione del builder che non è allineata con WordPress. Elementor è quello per cui se ne parla di più: si aggiornano entrambi e si riprova. Se invece il sito intero è giù, si parte dalla modalità di ripristino.

Nelle sezioni di supporto di WordPress i casi che tornano più spesso sono quattro, e si riconoscono dal momento in cui il guasto è comparso. Il primo: un page builder appena aggiornato che non è allineato con la versione di WordPress. Il secondo: un plugin attivato dopo il quale il sito non si è più aperto. Il terzo: un errore 500 che compare solo quando pubblichi un articolo. Il quarto: la schermata bianca dopo una modifica fatta a mano a un file del tema. In tutti e quattro i casi la strada è la stessa: prima si legge l'errore nel log, poi si disattiva il componente sospetto, un pezzo per volta.

Cosa vuol dire la riga che hai trovato?

Qui sotto ci sono i messaggi che si incontrano più spesso. Se invece il sito si apre ma va piano, il problema è un altro: lo trovi nella guida su gli errori di hosting. Se non hai ancora chiaro come è fatto WordPress, parti da WordPress per principianti. Non serve capirli tutti: cerca nel tuo log la parte che somiglia a una di queste righe e guarda la colonna di destra.

Nel log leggi…Cosa succedeCosa fareAllowed memory size of … bytes exhaustedPHP ha esaurito la memoria disponibileAumentare il limite di memoria (dal pannello hosting o da wp-config.php) e cercare il plugin che la consumaMaximum execution time of … seconds exceededUn'operazione ha superato il tempo massimoDi solito è un plugin o un backup: si alza il limite, ma la causa va trovataCannot modify header information – headers already sentQualcosa ha scritto output prima di WordPress: uno spazio o una riga vuota in un file modificatoSi guarda l'ultimo file toccato (di solito functions.php) e si toglie lo spazio di troppo — PHP dice già quale file e quale riga: è scritto nel messaggio stessoFailed opening required …/wp-load.phpManca un file che WordPress si aspetta di trovareFile cancellato o plugin rimosso a metà: si reinstallano plugin e coreCall to undefined function …Del codice chiama una funzione che non esiste piùAggiornamento incompleto: plugin, tema o core non sono allineatiError establishing a database connectionWordPress non riesce a parlare con il databaseCredenziali o database non disponibile: si controlla dal pannello dell'hosting

Come disattivo un plugin se il pannello non si apre?

Capita quando la modalità di ripristino non parte e l'email non arriva. C'è un modo semplice, documentato da WordPress, che funziona anche senza pannello: rinominare la cartella del plugin. Si entra nello spazio file del sito (FTP o strumento file dell'hosting), si va in wp-content/plugins/ e si cambia il nome della cartella sospetta: da nome-plugin a nome-plugin-off. WordPress non trova più quel plugin e lo considera disattivato: il sito torna a caricare e tu puoi entrare a fare le cose con calma.

Due regole prima di farlo. Cambia il nome, non cancellare: così puoi tornare indietro rinominando di nuovo. E fallo su un plugin per volta, ricaricando il sito dopo ogni tentativo. Se il sito torna su, hai trovato il colpevole. Se non sai da quale cominciare, parti dall'ultimo plugin installato o aggiornato: è la causa più frequente. Per riattivarlo non basta invertire il nome: si rimette a posto e si ricarica, poi si riaccende dalla bacheca. E se il sospetto è l'insieme dei plugin, la variante è rinominare tutta la cartella /plugins/: WordPress parte con tutti disattivati, e da lì si riaccende uno per volta.

Domande frequenti

In sintesi

• La pagina ti dice che c'è un errore; il log ti dice quale, con file e riga.
• L'email all'amministratore e la modalità di ripristino sono la via più rapida per rientrare senza toccare i file.
• Strumenti → Salute del sito serve per i problemi generali (e per accorgersi che il debug è rimasto acceso), non per l'errore di una pagina.
• Il file debug.log si crea con tre righe in wp-config.php, senza virgolette su true e false, e va spento appena finito.
• Se il pannello non si apre, si rinomina la cartella del plugin sospetto: un plugin per volta, partendo dall'ultimo aggiornato.

Procedure lette sulla documentazione ufficiale di WordPress (Debugging in WordPress, Recovery Mode, Site Health) il 29 settembre 2026. Per il passo successivo, quando l'errore è già risolto, vedi gli errori di hosting che rallentano un sito e gli errori di sicurezza più comuni.