Errore 500 WordPress: procedura sicura per trovare la causa e ripristinare il sito

Un errore 500 WordPress segnala che il server non è riuscito a completare una richiesta per una condizione inattesa. Il codice non identifica la causa: può dipendere da un errore PHP, da un plugin o tema, da una configurazione del server, da permessi non corretti, da risorse esaurite o dall’hosting.

Per risolverlo senza creare nuovi problemi, parti dai log e modifica un solo elemento alla volta. Evita aggiornamenti, reinstallazioni, cambi della versione PHP e ripristini completi eseguiti contemporaneamente: potresti perdere l’indizio utile per individuare la causa.

Procedura rapida per un errore 500 WordPress

1. Annota URL, ora dell’errore e ultima modifica effettuata.
2. Verifica se il problema riguarda tutto il sito, solo /wp-admin/ o una funzione specifica.
3. Controlla i log disponibili nel pannello hosting.
4. Se il log indica un plugin o un tema, disattiva prima il solo componente coinvolto.
5. Se non hai accesso a log, file manager, SFTP o backup, apri un ticket al provider con orario e URL dell’errore.

Se il sito è un e-commerce, riceve richieste commerciali importanti o mostra segnali di compromissione, limita gli interventi al minimo necessario e coinvolgi subito il provider o un tecnico.

Prima di intervenire: delimitare il problema

Prima di modificare file, database o impostazioni, annota l’ora precisa del primo errore, incluso il fuso orario. Raccogli anche l’URL interessato, l’estensione del problema e l’ultima modifica effettuata: aggiornamento di WordPress, plugin o tema, cambio della versione PHP, modifica di .htaccess oppure configurazione dell’hosting.

• Il 500 riguarda tutto il sito, solo /wp-admin/, una pagina o una funzione?
• Si verifica sempre oppure a intermittenza?
• Compare durante upload, import, checkout, chiamate REST o AJAX?
• È disponibile un backup recente di file e database?

 
Un codice 500 è diverso da 502, 503 o 504, che in genere indicano indisponibilità, timeout o problemi di comunicazione tra servizi del server. Se il browser o il provider mostra uno di questi codici, segui le indicazioni del relativo log anziché applicare automaticamente una procedura per WordPress.

Provare il recupero dall’area amministrativa

Da WordPress 5.2, alcuni errori fatali possono attivare la Recovery Mode. In questi casi WordPress può inviare all’indirizzo email dell’amministratore un link riservato per accedere al sito in modalità di recupero. Il funzionamento del gestore degli errori fatali è documentato dal progetto WordPress nella pagina dedicata alla Recovery Mode.

1. Controlla la casella email dell’amministratore e la posta indesiderata.
2. Apri il link ricevuto da un ambiente sicuro.
3. Individua il plugin o il tema segnalato e disattivalo.
4. Verifica la pagina che generava l’errore, il frontend e l’area di amministrazione.

La Recovery Mode può aiutare solo se WordPress riesce ad avviarsi abbastanza da intercettare l’errore. Non risolve problemi che avvengono prima del caricamento di WordPress, come regole del server non valide, crash di PHP o limiti dell’infrastruttura.

Se il backend è irraggiungibile, accedi al pannello hosting e cerca file manager, SFTP o FTP, error log, versione PHP, utilizzo delle risorse e backup. Non inviare password o token in chiaro nei ticket di assistenza.

Leggere i log prima di scegliere la correzione

I log sono la fonte diagnostica principale. Il file debug.log di WordPress può essere utile, ma non sostituisce i registri del server: un errore può avvenire prima che WordPress possa scrivere un log.

Controlla prima i registri messi a disposizione dal provider e verifica quali informazioni contengono. A seconda dell’hosting, errori del web server, PHP e PHP-FPM possono comparire nello stesso pannello, essere aggregati oppure essere disponibili in file distinti. Se l’errore è immediato, coinvolge tutto il sito o menziona PHP-FPM, FastCGI, rewrite o direttive del server, il log dell’hosting è prioritario.

Riproduci il problema una sola volta, annota ora, URL e azione eseguita, quindi cerca le righe registrate nello stesso intervallo. Cerca soprattutto il tipo di errore, il percorso del file, il numero di riga e il componente coinvolto.

• PHP Fatal error: errore PHP non recuperabile; verifica file, riga e componente citato.
• Allowed memory size ... exhausted: memoria PHP esaurita.
• Permission denied: possibile problema di ownership, permessi, ACL o policy del server.
• Errori FastCGI o PHP-FPM: possibile problema del processo PHP o della comunicazione con il web server.
• rewrite o internal redirection cycle: possibile ciclo nelle regole di routing.

Un percorso in wp-content/plugins/ è un indizio verso un plugin; un percorso in wp-content/themes/ orienta verso il tema. Non è sempre una prova definitiva: il file indicato può essere il punto in cui l’errore emerge. Verifica l’ipotesi con un test mirato.

Non pubblicare log completi in forum, chat o ticket aperti: possono contenere percorsi interni, dati personali, token e dettagli della configurazione.

Attivare il debug WordPress in modo temporaneo

Se i log dell’hosting non sono sufficienti e hai accesso ai file, puoi registrare gli errori WordPress senza mostrarli ai visitatori. Inserisci queste righe in wp-config.php, prima del commento /* That's all, stop editing! Happy blogging. */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Con WP_DEBUG_LOG impostato a true, WordPress tenta normalmente di scrivere il log in wp-content/debug.log. Verifica che il file sia stato creato e che la directory sia scrivibile: il server può registrare gli errori anche in log separati oppure impedire la scrittura. La configurazione è descritta nella documentazione ufficiale sul debugging di WordPress e nella guida a wp-config.php.

Terminata l’analisi, disattiva il debug e rimuovi, proteggi o sposta il log se si trova in una directory pubblica. Non usare WP_DISABLE_FATAL_ERROR_HANDLER come rimedio su un sito pubblico: può esporre dettagli tecnici dell’errore.

Isolare plugin e tema con test reversibili

Se il log cita un plugin o l’errore è iniziato dopo il suo aggiornamento, disattiva prima quel singolo componente dalla Recovery Mode o dal backend. Se l’amministrazione non è accessibile, rinomina via SFTP o file manager la cartella del plugin sospetto dentro wp-content/plugins/, ad esempio aggiungendo il suffisso .hold. In questo modo WordPress non può caricare quel plugin, senza eliminarne i file o le impostazioni.

Se non hai un indizio preciso, rinominare temporaneamente l’intera cartella wp-content/plugins può essere un test di isolamento. Dopo averne ripristinato il nome originale, però, verifica lo stato effettivo dei plugin prima di riattivarli, aggiornarli o modificarli: la rinomina della cartella non deve essere considerata un metodo certo per disattivarli in modo persistente.

Con SSH e WP-CLI puoi disattivare tutti i plugin con:

wp plugin deactivate --all

Il comando e le relative opzioni sono documentati da WP-CLI. Se il sito torna disponibile, riattiva un componente alla volta e prova ogni volta la stessa URL o funzione che generava il 500.

Rinominare plugins non disattiva i must-use plugin presenti in wp-content/mu-plugins. Se l’errore persiste, il test non esclude codice caricato da quella directory.

Per il tema, il test più prudente è lavorare su staging o usare uno strumento di troubleshooting quando il backend è disponibile. Se intervieni sui file del tema attivo, verifica prima che sia installato un tema predefinito compatibile che WordPress possa usare come fallback. Non eseguire questa prova alla cieca su un multisite.

Controllare configurazione, risorse e permessi

.htaccess è pertinente ad Apache e ad alcune configurazioni LiteSpeed; Nginx non lo utilizza. Intervieni sul file solo se il log richiama rewrite, direttive non valide o una sua modifica recente. Su un ambiente Apache compatibile, conserva una copia e ripristina la versione precedente oppure rinomina temporaneamente il file. Se il sito torna disponibile, rigenera le regole da Impostazioni → Permalink → Salva modifiche dopo aver recuperato l’accesso amministrativo. La schermata Permalink è descritta nella documentazione WordPress.

Aumenta memory_limit, WP_MEMORY_LIMIT o WP_MAX_MEMORY_LIMIT solo se il log segnala memoria esaurita. Il limite effettivo può essere imposto dall’hosting e un aumento può nascondere un loop o un plugin inefficiente. Il comportamento di memory_limit è descritto nel manuale PHP.

Se compare Permission denied, verifica ownership, utente del processo PHP e directory coinvolta, in particolare upload, cache, backup e file temporanei. I valori 755 per le directory e 644 per i file sono riferimenti comuni, ma non sono validi per ogni server. Non applicare modifiche ricorsive casuali e non usare 777. WordPress fornisce indicazioni nella documentazione sui permessi dei file.

Controlla la versione PHP e gli eventuali cambi recenti del provider solo se cronologia e log indicano un problema di compatibilità. Per i requisiti aggiornati, consulta la pagina ufficiale di WordPress.

Verificare il ripristino e chiudere l’incidente

La homepage tornata online non basta. Controlla l’URL che generava il 500, una pagina interna, login e /wp-admin/, il salvataggio nell’editor e le funzioni coinvolte, come form, REST/AJAX, upload, import/export o checkout WooCommerce.

Se sono presenti cache o CDN, usa una sessione anonima e, quando necessario, svuota o bypassa temporaneamente la cache per verificare che il risultato non sia mascherato da contenuti memorizzati.

Apri un ticket al provider se non hai accesso a backup, log o SFTP, se il sito è critico, se sospetti un’intrusione, se il problema riguarda ownership o PHP-FPM oppure se i test non producono evidenze. Un ticket utile include dominio, URL, timestamp con fuso orario, ultime modifiche, test eseguiti e righe di log pertinenti, con credenziali e token oscurati.

Dopo il recupero, disattiva il debug temporaneo, proteggi o rimuovi i log, aggiorna o sostituisci il componente responsabile, crea un nuovo backup e annota causa, correzione, data e versioni coinvolte.