L’errore 500 WordPress, o “Internal Server Error”, indica che il server non riesce a completare la richiesta. Può presentarsi anche come pagina bianca, ma non rivela da solo la causa. Per risolverlo, parti dai log degli errori e poi isola estensioni, template e configurazione.
Cambiare impostazioni a caso può prolungare il blocco e complicare il recupero del sito aziendale. Ti consiglio di seguire questa procedura, intervenendo su un solo elemento alla volta.
Prima di intervenire: proteggi file e database
Annota l’orario dell’errore, la pagina coinvolta e l’ultima modifica effettuata. Un aggiornamento, una nuova estensione o un cambio di versione PHP sono indizi concreti.
Scarica una copia locale dei file e del database prima di modificare configurazioni o ripristinare copie precedenti. Un ripristino può sovrascrivere ordini, richieste e contenuti aggiunti dopo il backup. La guida ai backup automatici WordPress chiarisce cosa conservare per recuperare il sito.
Distingui anche i codici: il 500 segnala un errore interno; il 502 una risposta non valida ricevuta da un server a monte. Header eccessivi possono contribuire ad alcuni 502, ma non sono la definizione del problema.
Un 400 legato a cookie troppo grandi può invece risolversi cancellando i cookie del dominio nel browser.
1. Leggi l’error_log prima di cambiare impostazioni
Dove trovare i log
Accedi tramite SFTP, FTP o File Manager. Cerca error_log nella cartella principale del sito, spesso /public_html/ negli hosting condivisi. Il percorso dipende dall’hosting: alcuni server registrano gli errori solo nel pannello.
Nel pannello di controllo dell’hosting, in cPanel trovi gli errori nella sezione Metriche > Errori. In Plesk seleziona il dominio in Siti web e domini, poi Log.
Se serve il debug applicativo, modifica wp-config.php inserendo define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true); e define('WP_DEBUG_DISPLAY', false); prima del commento finale. Modifica le costanti già presenti senza duplicarle.
The documentazione ufficiale sul debug descrive queste impostazioni. Il log viene normalmente scritto in wp-content/debug.log. Disattiva il debug e proteggi o rimuovi il file al termine.
Quale messaggio cercare
Ricarica la pagina problematica e leggi le righe corrispondenti all’orario della prova. Queste firme aiutano a scegliere il controllo successivo.
| Messaggio nel log | Primo controllo |
|---|---|
Allowed memory size exhausted | Memoria PHP e consumo dei componenti |
Parse error | Sintassi del file indicato |
Uncaught Error | Estensioni, template e compatibilità del codice |
Invalid command | Direttive del server, anche in .htaccess |
Permission denied | Permessi e proprietario dei file |
Un warning non blocca necessariamente il sito. Cerca il primo errore fatale collegato alla richiesta.
Il percorso di un plugin nel log lo rende il primo componente da isolare, ma non dimostra da solo l’origine del guasto.
2. Isola plugin e tema
Disattiva i plugin, anche senza bacheca
Se accedi al pannello, apri la schermata Plugin installati. Seleziona tutti i plugin, scegli Disattiva nelle azioni di gruppo e clicca Applica.
Se il sito torna operativo, riattivali uno alla volta. Dopo ogni attivazione prova la pagina che generava l’errore, il modulo contatti e le funzioni commerciali.
Per disattivare i plugin senza bacheca, rinomina wp-content/plugins in plugins_old tramite FTP o File Manager. Riprova il sito. Se recuperi l’accesso, visita la schermata dei plugin mentre la cartella è rinominata. Ripristina poi il nome originale e riattiva le estensioni singolarmente.
Questo test non esclude le estensioni obbligatorie presenti in mu-plugins o alcuni componenti di cache.
Prova un tema predefinito
Se l’errore resta, attiva temporaneamente un tema ufficiale, come Twenty Twenty-Three, se installato e compatibile.
Quando la bacheca è bloccata, usa l’eventuale collegamento alla modalità di recupero ricevuto da WordPress. Senza accesso, il cambio può richiedere WP-CLI o un intervento tecnico.
Se il tema predefinito risolve il problema, raccogli il messaggio del log e contatta gli sviluppatori del tema originale. Evita modifiche improvvisate ai suoi file.
Per gestire conflitti e aggiornamenti trovi anche la mia guida all’assistenza WordPress per PMI.
3. Verifica il file .htaccess
Su Apache e server compatibili, una direttiva errata in .htaccess può generare un errore 500 prima dell’avvio di WordPress.
Apri la cartella principale del sito e abilita la visualizzazione dei file nascosti. Scarica una copia del file, poi rinomina .htaccess in .htaccess.old.
Ricarica il sito. Se funziona, entra in Impostazioni > Permalink e clicca Salva le modifiche senza cambiare la struttura degli indirizzi. WordPress rigenera le proprie regole se può scrivere nella cartella.
Confronta poi il vecchio file con quello nuovo: redirect e regole personalizzate non vengono recuperati automaticamente.
Direttive PHP non consentite, regole inserite male da un plugin o modifiche dovute a una compromissione possono causare il blocco. Se trovi redirect sconosciuti, serve anche un controllo di sicurezza.
Su Nginx, .htaccess non viene utilizzato: rinominarlo non corregge la configurazione del server.
4. Controlla versione PHP e memoria disponibile
Verifica cosa è cambiato nella versione PHP
Un aggiornamento automatico dell’hosting può rendere incompatibile codice datato. Anche una versione PHP troppo vecchia può bloccare componenti aggiornati.
In cPanel usa MultiPHP Manager; in Plesk apri Impostazioni PHP del dominio. Su IONOS la selezione della versione si trova nelle impostazioni PHP dell’area Hosting.
Se il problema coincide con un cambio di versione, tornare a quella precedente può essere una misura temporanea, se possibile. La soluzione stabile è aggiornare o sostituire il componente incompatibile, mantenendo una versione PHP supportata.
Aumenta la memoria soltanto quando serve
Se il log segnala il superamento del limite di memoria con Allowed memory size exhausted, apri il file di configurazione principale e aggiungi define('WP_MEMORY_LIMIT', '256M'); prima del commento finale, quello che invita a interrompere le modifiche.
Se la costante esiste, modifica il valore senza aggiungere una seconda definizione. Salva e ricarica la pagina.
256 MB sono un valore di prova, non una soluzione universale. Il limite effettivo dipende anche da memory_limit sul server.
Se l’esaurimento si ripete, analizza il consumo della componente coinvolta. Aumentare memoria, tempo di esecuzione e dimensione degli upload insieme rende meno chiara la diagnosi.
5. Escludi permessi errati e spazio esaurito
Come riferimento comune, molti ambienti WordPress utilizzano 644 per i file e 755 per le cartelle. Questi valori non sono universali: contano anche il proprietario dei file e l’handler di esecuzione configurato.
OVHcloud indica per alcune configurazioni 705 per la cartella radice e le directory, 604 per i file. Il valore 755 citato per uno script come php.cgi riguarda invece un eseguibile specifico: non va applicato indistintamente agli altri file.
Evita modifiche ricorsive senza conoscere la configurazione. Non impostare 777 per tentare di sbloccare tutto.
Su Aruba Hosting Linux, se il problema compare dopo un aggiornamento con permessi alterati, puoi utilizzare Riparazione Permessi nel pannello del servizio.
Controlla poi nell’area hosting la percentuale di spazio web occupato e i limiti del numero di file. Disco pieno o quota superata possono impedire la scrittura di cache, sessioni e log.
Scarica i vecchi archivi prima di rimuoverli. Non cancellare cartelle o database solo perché occupano molto spazio.
6. Se il log indica il database, separa le cause
Il messaggio “Errore nello stabilire una connessione al database” richiede controlli diversi rispetto a un conflitto tra estensioni.
Nel file di configurazione, confronta DB_NAME, DB_USER, DB_PASSWORD e DB_HOST con i dati del database assegnato. Credenziali errate, servizio database indisponibile e tabelle danneggiate sono problemi distinti.
La riparazione integrata serve per tabelle danneggiate, non per correggere una password. Dopo un backup, aggiungi temporaneamente define('WP_ALLOW_REPAIR', true); e apri /wp-admin/maint/repair.php sul tuo dominio.
Esegui la riparazione solo se pertinente al messaggio ricevuto. Rimuovi subito la costante al termine: la pagina di riparazione non richiede il normale accesso amministrativo.
Se il database non risponde affatto, serve l’intervento dell’hosting. Ripetere modifiche alle credenziali può introdurre un secondo problema.
Quando fermarti e coinvolgere l’hosting
Chiedi supporto quando i log non sono accessibili, compaiono errori PHP-FPM, risultano limiti di processi superati o il database è indisponibile.
Invia dominio, URL coinvolto, orario con fuso orario, messaggio del log e prove già effettuate. Non inviare password nel ticket.
Se sospetti file WordPress danneggiati, reinstalla il core da un pacchetto ufficiale, conservando configurazione e contenuti. Prima isola estensioni, template e configurazione del server.
Dopo la correzione, svuota le cache pertinenti: plugin, hosting, CDN e browser. Prova homepage, contatti, login e checkout. Una homepage visibile non garantisce che il sito sia operativo.
Per ridurre le ricadute, prova gli aggiornamenti su staging e mantieni backup separati dal server. Con la mia manutenzione dei siti web posso aiutarti a organizzare controlli e aggiornamenti del sito aziendale.
Domande frequenti sull’errore 500 in WordPress
Posso trovare l’estensione responsabile senza bacheca?
Sì. Rinomina wp-content/plugins in plugins_old e riprova il sito. Se recuperi l’accesso, ripristina il nome dopo aver aperto la schermata dei plugin, quindi riattivali singolarmente.
Cancellare i cookie risolve l’errore 500?
Normalmente no. Può risolvere un errore 400 causato da cookie troppo grandi, ma il 500 richiede una diagnosi sul server.
Ripristina il sito partendo dalla causa
Per risolvere un errore 500 in WordPress servono log, prove isolate e un backup recuperabile. Il messaggio registrato dal server deve guidare l’intervento.
Quando il sito torna online, verifica anche moduli e funzioni commerciali. La diagnosi è completa quando hai identificato il guasto e confermato che il sito funziona, non soltanto quando scompare la pagina di errore.
