Il sito era online un’ora fa. Adesso al suo posto c’è una pagina che dice “Errore 500”, oppure una schermata completamente bianca, oppure il messaggio “Si è verificato un errore critico sul tuo sito web”. Tre facce dello stesso problema, e nessuna delle tre ti dice cosa sia successo.
La reazione istintiva è quella sbagliata: entrare via FTP e cominciare a cancellare plugin a caso. Esiste un percorso più rapido, e nella maggior parte dei casi il sito torna online in pochi minuti senza toccare un file.
In breve
Un errore 500 su WordPress è quasi sempre un errore fatale di PHP causato da un plugin, un tema, un limite di memoria esaurito o un file .htaccess corrotto. Prima di intervenire sui file, controlla la casella email dell’amministratore: WordPress invia in automatico un link di ripristino che ti fa rientrare nel pannello con il componente difettoso disattivato.
Errore 500, pagina bianca ed errore critico sono la stessa cosa
Vale la pena chiarirlo subito, perché cercando soluzioni si finisce su guide diverse per quello che è lo stesso guasto.
L’errore 500 è un codice di stato HTTP generico. Significa che il server ha provato a generare la pagina e qualcosa è andato storto durante l’esecuzione, senza che il server sappia spiegare cosa. È volutamente vago: il messaggio va all’utente finale, e i dettagli tecnici restano nei log per motivi di sicurezza.
La schermata bianca, quella che in inglese chiamano white screen of death, è la stessa situazione vista da un’angolazione diversa: PHP si è fermato prima di produrre qualsiasi output e il browser riceve una pagina vuota.
Il messaggio “Si è verificato un errore critico” è la versione moderna e più gentile. Da alcune versioni WordPress intercetta l’errore fatale prima che diventi una pagina vuota, mostra un avviso comprensibile e attiva un meccanismo di recupero. È lo stesso guasto di prima, gestito meglio.
In tutti e tre i casi la causa reale è quasi sempre un errore fatale di PHP. Cambia solo quanto in profondità è arrivata l’esecuzione prima di fermarsi.
Prima cosa da fare: apri la posta
È il passaggio che quasi nessuno conosce e che risolve il caso più frequente in due minuti.
Quando WordPress rileva un errore fatale, invia in automatico una email all’indirizzo dell’amministratore configurato in Impostazioni, Generali. L’oggetto è del tipo “Il tuo sito sta riscontrando un problema tecnico”. Dentro c’è un link di ripristino valido 24 ore.
Quel link ti fa entrare in una sessione speciale del pannello di controllo con il plugin o il tema colpevole messo in pausa. Da lì puoi disattivarlo, capire cosa è successo e uscire dalla modalità di ripristino. Nel frattempo i visitatori vedono la pagina di errore, ma tu hai il pannello funzionante.
Prima di aprire FTP, controlla la posta. Anche nello spam.
La email arriva all’indirizzo amministrativo del sito, che non sempre coincide con quello del tuo account utente. Se non la trovi, controlla nelle impostazioni quale indirizzo sia effettivamente configurato.
Se il link di ripristino non arriva
Capita, e il motivo è quasi sempre lo stesso: WordPress invia le email tramite la funzione PHP mail, che su molti hosting condivisi è bloccata, filtrata o finisce direttamente nello spam del destinatario.
È una situazione paradossale. Il sistema pensato per salvarti quando il sito si rompe dipende da un componente che spesso non funziona. Per questo, su qualsiasi sito che gestisci con continuità, conviene configurare l’invio via SMTP autenticato prima di averne bisogno, e verificare che le email partano davvero mentre tutto funziona.
Se il link non c’è, si passa al metodo manuale.
Leggere il log invece di tirare a indovinare
Il log ti dice esattamente quale file ha generato l’errore e a quale riga. È la differenza tra sapere e sperare.
Accedi ai file del sito via FTP o dal file manager dell’hosting, apri wp-config.php e cerca la riga che dice di non modificare oltre. Poco sopra, aggiungi:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );La terza riga è quella che molte guide dimenticano e serve a evitare che gli errori vengano mostrati ai visitatori mentre stai indagando. Ricarica la pagina che dava errore, poi apri il file debug.log che trovi nella cartella wp-content.
Cerca le righe che iniziano con PHP Fatal error. Il percorso del file indicato dopo la parola in ti dice se il problema è in un plugin, in un tema o nel core. Nella maggior parte dei casi il nome della cartella è già la risposta.
Attenzione alla sicurezza. Il file debug.log è accessibile pubblicamente dal browser, perché si trova dentro wp-content. Contiene percorsi assoluti del server e a volte informazioni sensibili. Quando hai finito la diagnosi, rimetti le tre costanti su false ed elimina il file.
Le cinque cause, in ordine di frequenza
1. Conflitto tra plugin, o aggiornamento andato male
La causa più comune in assoluto. Un plugin aggiornato che non va d’accordo con un altro, oppure con la versione di PHP del server, oppure con il tema. Il momento tipico in cui succede è subito dopo un aggiornamento automatico notturno, ed è il motivo per cui certi siti si rompono senza che nessuno abbia toccato niente.
Nel log lo riconosci dal percorso che contiene wp-content/plugins/ seguito dal nome della cartella del plugin responsabile.
2. Memoria PHP esaurita
Ogni processo PHP ha un limite di memoria assegnato dall’hosting. Quando WordPress, il tema e i plugin insieme lo superano, l’esecuzione si interrompe. Sui piani condivisi economici il limite è spesso basso, ed è il motivo per cui lo stesso sito funziona su un server e si rompe su un altro.
Nel log compare un messaggio che parla di memoria consentita esaurita, con il numero di byte. Puoi provare ad alzare il limite aggiungendo in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );Con una precisazione onesta: questa riga funziona solo se l’hosting consente di superare il limite. Su molti condivisi il tetto è imposto a monte e la costante viene ignorata. In quel caso la strada è il pannello dell’hosting o un piano con più risorse.
3. File .htaccess corrotto
Il file .htaccess nella radice del sito governa i permalink e le regole di riscrittura. Una direttiva sbagliata, spesso lasciata da un plugin di cache o di sicurezza disinstallato male, genera un 500 immediato su tutte le pagine.
Il test è rapido: rinomina il file in htaccess-old e ricarica il sito. Se torna online, hai trovato la causa. A quel punto entra in Impostazioni, Permalink e salva senza modificare nulla: WordPress rigenera un file pulito.
Attenzione a un dettaglio: se il sito torna online ma le pagine interne danno 404, è normale finché non rigeneri i permalink.
4. Versione di PHP incompatibile
Succede in due direzioni opposte. Un hosting che aggiorna PHP a una versione più recente manda in errore un plugin datato che usa funzioni ormai rimosse. Oppure un sito rimasto su una versione vecchia riceve un aggiornamento di plugin che richiede una versione superiore.
Nel log si riconosce da messaggi che parlano di funzioni non definite o di sintassi non valida. La verifica si fa dal pannello dell’hosting, dove si può anche tornare temporaneamente alla versione precedente per rimettere online il sito mentre si risolve.
5. File del core danneggiati o permessi sbagliati
Meno frequente, ma capita dopo un aggiornamento interrotto a metà, una migrazione fatta male o un attacco. Nel log il percorso dell’errore punta dentro wp-admin o wp-includes.
La soluzione è sostituire i file del core: scarica WordPress da wordpress.org, elimina dal server le cartelle wp-admin e wp-includes e carica quelle nuove. Non toccare wp-content né wp-config.php, perché contengono i tuoi contenuti e la configurazione. Fai un backup prima, sempre.
Isolare la causa senza spegnere il sito ai visitatori
Il consiglio classico è disattivare tutti i plugin e riattivarli uno alla volta. Funziona, ma ha un costo: mentre lo fai, chi visita il sito lo vede rotto o incompleto. Su un sito che vende, è tempo di fatturato perso.
Esiste un modo migliore. Il plugin ufficiale Health Check & Troubleshooting, disponibile su wordpress.org, ha una modalità di risoluzione dei problemi che disattiva plugin e tema solo per la tua sessione del browser. Tutti gli altri visitatori continuano a vedere il sito normale.
Il procedimento diventa questo: attivi la modalità di risoluzione, disattivi tutto, verifichi che l’errore sparisca, poi riattivi un componente alla volta finché non ricompare. L’ultimo che hai riattivato è il colpevole.
Un’avvertenza pratica: se il sito è completamente inaccessibile non puoi installare il plugin, quindi questo metodo serve nei casi in cui il pannello risponde ancora, oppure dopo essere rientrato con il link di ripristino.
Quando il 500 non dipende da WordPress
C’è una categoria di casi in cui puoi disattivare tutti i plugin del mondo senza cambiare niente, perché il problema è a monte.
Il segnale più chiaro è che l’errore compare in modo intermittente, magari solo in certi orari o sotto carico. Su un hosting condiviso significa quasi sempre risorse esaurite: troppi processi PHP contemporanei, limiti di CPU superati, o un vicino di server che sta consumando tutto.
Anche il codice cambia qualcosa. Un 503 indica un servizio temporaneamente non disponibile, tipicamente un sovraccarico. Un 502 riguarda una comunicazione fallita tra server. In entrambi i casi la diagnosi si sposta sull’infrastruttura, e il posto dove guardare è il log degli errori del server nel pannello dell’hosting, che è diverso dal debug.log di WordPress.
Se il sito rallenta prima di rompersi, spesso i due sintomi hanno la stessa radice. Ne parlo nel dettaglio nella guida su come trovare la causa di un sito WordPress lento, e se il sospetto ricade sul piano che stai usando, il confronto tra gli hosting condivisi per WordPress aiuta a capire se le risorse sono adeguate.
Come evitare che succeda di nuovo
Un errore 500 raramente è sfortuna pura. Quasi sempre è la conseguenza di un processo che manca.
- Aggiornamenti su staging. Prima sull’ambiente di prova, poi in produzione. È la misura che elimina da sola la causa numero uno.
- Backup automatici verificati. Un backup che non hai mai provato a ripristinare non è un backup, è una speranza.
- Email di sistema funzionanti. Configura l’invio via SMTP, così il link di ripristino ti arriva davvero quando serve.
- Aggiornamenti automatici disattivati sui plugin critici. Su quelli che toccano pagamenti, form o cache conviene aggiornare a mano, guardando.
- Accesso ai log dell’hosting. Sapere dove si trovano prima dell’emergenza fa risparmiare i minuti che contano di più.
Il sito è ancora giù?
Quando il log non è chiaro, l’errore torna dopo essere stato risolto o il sito genera fatturato e ogni ora conta, intervenire per tentativi peggiora le cose. In quei casi serve una diagnosi ordinata, fatta su una copia e non in produzione.
Domande frequenti
L’errore 500 danneggia il posizionamento su Google?
Se dura poche ore, l’impatto è trascurabile: il crawler ripassa e trova la pagina di nuovo raggiungibile. Se si protrae per giorni, le pagine possono uscire dai risultati e rientrare più lentamente. Su un’interruzione prolungata conviene verificare lo stato in Search Console una volta risolto.
Posso perdere i contenuti del sito?
L’errore in sé non cancella nulla: i contenuti restano nel database, che non viene toccato da un errore fatale di PHP. Il rischio nasce dagli interventi fatti male durante il recupero, ed è il motivo per cui il backup va fatto prima di mettere mano ai file.
Perché il sito si è rotto senza che io toccassi niente?
Nella quasi totalità dei casi è un aggiornamento automatico, di WordPress o di un plugin, andato in conflitto con qualcos’altro. Oppure un cambio di configurazione lato hosting, come un aggiornamento della versione di PHP.
Devo disattivare tutti i plugin per forza?
No, se il log indica già il file responsabile. La disattivazione a tappeto serve quando il log non è disponibile o non è chiaro, ed è comunque preferibile farla con la modalità di risoluzione dei problemi, che non tocca l’esperienza dei visitatori.
