La diagnosi di un 500 Internal Server Error inizia dai log
Un 500 internal server error significa che il server di un sito web ha riscontrato una condizione imprevista e non ha potuto completare una richiesta. È un HTTP status code, cioè un numero restituito da un server per descrivere cosa è accaduto quando un browser ha richiesto una pagina. Il gruppo più ampio dei codici 5xx riguarda i malfunzionamenti lato server, mentre 500 è il codice generico usato quando il server non riesce a classificare il problema con maggiore precisione. Le indicazioni pubblicate da Sucuri il 14 ottobre 2026 sottolineano che la spiegazione utile si trova generalmente nell'error log, anziché nella pagina di errore pubblica.
Questo distingue il codice 500 dagli errori correlati. Un 502 indica che un server ha ricevuto una risposta non valida da un altro server upstream. Un 503 significa che il servizio non è disponibile o è sovraccarico, mentre un 504 indica che una richiesta upstream è andata in timeout. Un vero 500 non è normalmente un problema del browser, della rete o del Domain Name System (DNS). Il DNS associa un nome di dominio al server che lo ospita. Con un 500, la richiesta ha raggiunto il server, ma qualcosa non ha funzionato mentre il server preparava la risposta.
I visitatori possono vedere diverse versioni del malfunzionamento, tra cui un breve messaggio di internal server error, una pagina bianca completamente vuota o l'avviso di WordPress secondo cui il sito web ha riscontrato un critical error. WordPress può intercettare un fatal PHP error e sostituire la risposta grezza del server con un proprio messaggio. PHP è il linguaggio di programmazione utilizzato per eseguire gran parte di WordPress e molti altri siti web. Anche una pagina vuota può contenere una risposta 500 senza contenuto visibile; lo status effettivo può essere verificato nella scheda Network dei developer tools del browser oppure tramite una richiesta da command line.
Tra le cause comuni rientrano un plugin, un'extension o un theme difettosi, in particolare quando un aggiornamento introduce codice che la versione di PHP installata non è in grado di eseguire. Due plugin potrebbero definire la stessa funzione, oppure un theme potrebbe richiamare codice che non esiste più. Un'altra causa frequente è un file .htaccess non funzionante, ossia un file di configurazione Apache che controlla redirect, rewriting degli indirizzi e impostazioni a livello di directory. Un errore di battitura, un'istruzione non supportata o una regola copiata da un altro server possono influire su tutte le pagine contenute in quella directory.
Altre cause includono l'esaurimento della memoria PHP, un'incompatibilità della versione di PHP dopo un upgrade, ownership e permissions dei file errate, errori di connessione al database oppure un errore non gestito in uno script pianificato, un'integrazione personalizzata o un servizio esterno. Sui sistemi di hosting sottoposti a hardening, possono causare problemi sia permissions troppo restrittive sia permissions eccessivamente aperte. PHP dannoso o regole .htaccess alterate possono produrre lo stesso risultato, quindi un 500 senza una spiegazione non dovrebbe essere considerato automaticamente un normale errore di configurazione.
Il troubleshooting dovrebbe iniziare ricaricando una volta la pagina, per escludere un picco momentaneo nell'uso delle risorse, e proseguire con una verifica da un altro dispositivo, un'altra rete o un servizio esterno di controllo dello status. Se il malfunzionamento è visibile a un solo visitatore, la causa potrebbe essere una risposta memorizzata nella cache di un content delivery network (CDN), di un proxy o di una page cache. Una CDN è una rete che memorizza e distribuisce copie dei contenuti di un sito web da più località. Se tutti ricevono l'errore, l'indagine deve essere svolta sul server.
Prima di apportare qualsiasi modifica, crea un backup completo dei file e del database. Apri quindi l'error log del control panel dell'hosting oppure il log documentato di Apache, Nginx o PHP-FPM. Spesso indicherà il file e la riga in cui si è verificato l'errore. In caso contrario, abilita il debug logging dell'applicazione affinché gli errori vengano scritti in un file privato. Non mostrare mai pubblicamente errori dettagliati su un sito web live, perché potrebbero rivelare path interni dei file e altre informazioni.
Successivamente, rinomina temporaneamente .htaccess e ricarica il sito. Se questo risolve l'errore, gli utenti WordPress possono rigenerare il file salvando nuovamente le impostazioni dei permalink; sulle altre piattaforme, le istruzioni dovrebbero essere ripristinate gradualmente finché non viene individuata quella difettosa. Disabilita i plugin e testali singolarmente, quindi passa temporaneamente a un theme predefinito. Quando la dashboard non è disponibile, queste modifiche possono essere effettuate rinominando le directory dei plugin o dei theme tramite Secure File Transfer Protocol (SFTP), un metodo cifrato per gestire i file su un server.
Aumenta il PHP memory limit solo quando il log segnala che la memoria consentita è stata esaurita e considera la modifica un passaggio diagnostico, non una soluzione permanente per un plugin inefficiente. Se l'errore è comparso dopo un upgrade di PHP, il ripristino temporaneo della versione precedente può confermare un problema di compatibilità, ma una versione di PHP non supportata non dovrebbe rimanere in uso a tempo indeterminato. Nella maggior parte degli hosting condivisi, i file devono generalmente utilizzare permissions 644 e le directory 755, con l'ownership assegnata all'account di hosting. Un file impostato su 777 rappresenta un problema sia funzionale sia di sicurezza. Infine, svuota page cache, object cache, CDN cache e reverse-proxy cache e comunica al provider di hosting il timestamp esatto e la voce del log se il malfunzionamento riguarda un database server, un resource limit o un server module che non è sotto il controllo del cliente.
WordPress offre altri due percorsi di ripristino. I core files danneggiati possono essere sostituiti caricando una nuova copia di WordPress e conservando wp-content e wp-config.php. Un aggiornamento interrotto può lasciare un file .maintenance nella root directory del sito; la rimozione di tale file sblocca il sito. Testare le modifiche su una staging copy, cioè un duplicato privato del sito web live, evita di esporre errori dettagliati o di apportare modifiche rischiose in production.
Una possibile compromissione richiede una risposta diversa. Tra i segnali di allarme rientrano la comparsa di un 500 senza che siano stati eseguiti aggiornamenti o deployment, recenti timestamp di modifica senza spiegazione, file sconosciuti, file .htaccess inattesi o voci di log che indicano codice non installato dal proprietario. Malfunzionamenti condizionali che interessano solo determinati visitatori, tipi di browser o persone provenienti dai motori di ricerca possono indicare cloaked malware, sebbene la cache possa causare un comportamento simile. Nessun singolo segnale dimostra la presenza di un'infezione.
L'indagine dovrebbe includere una scansione server-side o un file integrity check rispetto a core files noti come integri, l'ispezione dei file .htaccess in ogni directory, una verifica degli account amministratore creati di recente e l'esame degli access logs relativi al momento del primo malfunzionamento. Se viene confermata la presenza di codice dannoso, pulisci i file interessati, modifica le credenziali di hosting, SFTP, database e amministratore del CMS e applica una patch all'entry point. Ripristinare un backup pulito senza correggere la vulnerabilità può lasciare il sito esposto a una nuova infezione.
È improbabile che un 500 di breve durata provochi danni duraturi al posizionamento nei motori di ricerca, perché i crawler generalmente riprovano dopo malfunzionamenti temporanei del server. Gli errori che continuano per giorni possono ridurre il crawling e far uscire le pagine interessate dall'indice di ricerca. Anche gli errori memorizzati nella cache possono rimanere visibili dopo la correzione del problema originale. L'uptime monitoring delle risposte 5xx, log accessibili e i report sugli errori del server di Google Search Console possono ridurre la durata delle interruzioni. Gli aggiornamenti di plugin, theme e PHP dovrebbero essere testati uno alla volta su staging, con backup automatizzati ripristinabili e senza plugin superflui o directory world-writable.