Schermata bianca. Cinque cifre: 500. Nessun pannello di amministrazione, nessun sito, nessun indizio sulla causa. Ti suona familiare?

L'errore interno del server 500 di WordPress è il più silenzioso di tutti gli errori. Non ti dice cosa si è rotto esattamente, il che non fa che aumentare il panico. Ma la realtà è banale: in 9 casi su 10 il colpevole è un plugin, un tema o una singola riga scritta male in .htaccess. Il server non è impazzito; ha semplicemente incontrato codice che non può eseguire.

Analizziamo i tre scenari principali e risolviamoli passo dopo passo. Niente panico, niente chiamate al tuo host alle tre di notte. Con le tue mani, in 15 minuti.

💡 Panoramica rapida:

• Disattiva tutti i plugin in una volta sola rinominando la cartella plugins via FTP; se l'errore scompare, il colpevole è tra loro
• Ripristina .htaccess al modello standard di WordPress: una direttiva di caching o redirect scritta male può mandare in crash il sito all'istante
• Attiva WP_DEBUG in wp-config.php per vedere il file e la riga esatti con l'errore fatale
• Se il tuo sito si è appena trasferito su un nuovo host, controlla la versione PHP: WordPress a partire dal 2026 richiede PHP 8.3 o superiore, e i vecchi plugin sono spesso incompatibili

Codici di risposta HTTP: cosa sta cercando di dirti il server

Prima di immergerci nel debug, è utile capire le basi delle risposte HTTP. Il server risponde sempre al browser con un codice a tre cifre, e la prima cifra ti dice già dove cercare il problema.

• 1xx, informativo: "la connessione è in fase di creazione, attendere". Questi non hanno nulla a che fare con gli errori.
• 2xx, successo. Il famoso 200 OK significa che il server ha consegnato la pagina senza problemi.
• 3xx, redirect. Ad esempio, 301 (redirect permanente) o 307 (temporaneo). Il browser naviga al nuovo indirizzo in silenzio; questo è un comando, non un errore.
• 4xx, errore lato client. 404 Not Found significa che la pagina è stata cancellata o l'URL è stato digitato male. Il server è attivo; il contenuto semplicemente non esiste.
• 5xx, errore lato server. Qui inizia il nostro territorio.

Tra i codici 5xx, ci sono tre "pazienti" principali: 503 Service Unavailable (il server è sovraccarico; si risolve con la cache o passando a un piano più potente), 502 Bad Gateway (PHP-FPM è andato in crash o ha perso la connessione con il web server; un problema di configurazione), e infine **500 **Internal Server Error, il più generico e quindi il più insidioso. È di questo che parleremo.

Tre cause principali dell'errore 500 e soluzioni passo dopo passo

L'errore 500 non è misterioso; è solo generico. Il server dice: "Non ho potuto eseguire il codice, ma non ti dico quale". La diagnosi significa esaminare metodicamente tre sospetti standard.

1. Incompatibilità della versione PHP durante la migrazione di un sito

Uno scenario classico: hai spostato il tuo sito da un vecchio host con PHP 7.4 a uno nuovo con PHP 8.3 o 8.4. E hai subito ottenuto una schermata bianca.

Il motivo è semplice: un vecchio plugin o tema usa funzioni che sono state deprecate o rimosse del tutto nelle versioni più recenti di PHP. L'interprete si rifiuta di eseguirle e il sito va in crash.

Come risolvere. Fai un backup completo delle cartelle wp-content/plugins/ e wp-content/themes/. Poi rinomina la cartella plugins in plugins_old via FTP o dal file manager del tuo hosting; questo disattiva immediatamente tutti i plugin in una volta sola. L'errore è scomparso? Il colpevole è tra i plugin. Ripristinali uno per uno, controllando il sito ogni volta. Quello dopo il quale ricompare l'errore 500 è il problema.

La stessa logica si applica ai temi: passa a un tema standard di WordPress (Twenty Twenty-Five o più recente). Il sito è tornato in vita? Il problema è nel tuo tema; aggiornalo o sostituiscilo.

Questo scenario si presenta più spesso quando si migra un sito tra host con versioni PHP diverse. La maggior parte degli host non offre più PHP 7.x nei propri pannelli di controllo, e i requisiti minimi di WordPress dal 2026 partono da PHP 8.3. Il vecchio codice senza aggiornamenti è condannato in quell'ambiente.

2..Htaccess corrotto, il killer invisibile

Hai configurato un plugin di caching, attivato dei redirect o aggiunto le tue regole a .htaccess, e il sito è andato giù. All'istante e senza preavviso.

Il file .htaccess (Apache) controlla il web server al volo: una direttiva viene scritta, una direttiva viene eseguita. Un errore di sintassi, un flag errato o un conflitto di regole, e l'intero sito risponde con un 500.

Come risolvere. Connettiti al tuo sito via FTP o tramite il file manager del tuo hosting. Trova .htaccess nella cartella root (public_html, www o htdocs). Copia il suo contenuto in un file di testo come backup. Poi sostituisci tutto con il modello standard di WordPress:

1
 # BEGIN WordPress
2
 
3
<IfModule mod_rewrite.c>
4
RewriteEngine On
5
RewriteBase /
6
RewriteRule ^index\.php$ - [L]
7
RewriteCond %{REQUEST_FILENAME} !-f
8
RewriteCond %{REQUEST_FILENAME} !-d
9
RewriteRule . /index.php [L]
10
</IfModule>
11
 
12
 # END WordPress

Questo codice ripristina le regole standard di riscrittura degli URL (permalink leggibili) e rimuove tutto ciò che è superfluo. Il sito dovrebbe tornare in vita immediatamente. Puoi riconfigurare il tuo plugin in seguito, ma ora sai dove guardare se qualcosa va storto.

Non ha funzionato? Ripristina il vecchio .htaccess dal tuo backup e passa al passo successivo. Su Nginx, .htaccess non funziona; controlla i log in /var/log/nginx/error.log, il problema è nella configurazione del blocco server.

3. Errore fatale nel codice PHP

Un plugin o un tema chiama una funzione che non esiste, passa un tipo di argomento sbagliato o fa riferimento a una classe inesistente. PHP interrompe l'esecuzione e ti trovi di fronte al solito 500.

Senza informazioni di debug, stai tirando a indovinare. Fortunatamente, WordPress può mostrare gli errori; devi solo abilitare la modalità debug.

Attivare WP_DEBUG

Apri il file wp-config.php nella root del tuo sito. Trova la riga:

1
define( 'WP_DEBUG', false );

Sostituisci false con true. Se quella riga non esiste, aggiungila prima di /* That's all, stop editing! */:

1
define( 'WP_DEBUG', true );

Dopo aver salvato, ricarica la pagina. Invece di una schermata bianca, vedrai un messaggio come:

1
Fatal error: Call to undefined function wpsupercache_gc() in
2
/home/user/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 342

L'errore mostra: il tipo di problema (undefined function), il file incriminato (wp-cache.php) e la riga (342). Questa è un'indicazione diretta del plugin che ha causato il crash. Disattivalo rinominando la cartella del plugin e il sito funzionerà di nuovo. Poi aggiorna il plugin, trova un'alternativa o contatta lo sviluppatore.

Assicurati di reimpostare WP_DEBUG su false dopo la diagnosi. Su un sito live, mostrare gli errori ai visitatori è inutile e può rivelare i percorsi interni del server. Se vuoi raccogliere i log senza mostrarli a schermo, aggiungi queste righe a wp-config.php: define( 'WP_DEBUG_LOG', true ); e define( 'WP_DEBUG_DISPLAY', false );. Gli errori verranno scritti in wp-content/debug.log.

⁉️🤔 Domande frequenti

Posso semplicemente riavviare il server per eliminare l'errore 500?

No. A differenza del 503, che spesso scompare dopo un riavvio (quando il picco di carico si è attenuato), l'errore 500 è causato da un problema nel codice. Riavviare il server non lo risolverà: dopo l'avvio, il sito incontrerà lo stesso codice difettoso e andrà di nuovo in crash.

Come faccio a determinare se la colpa è di un plugin o del tema se il pannello di amministrazione non è accessibile?

Connettiti via FTP o tramite il file manager del tuo hosting. Rinomina la cartella wp-content/plugins; questo disattiva immediatamente tutti i plugin. Il sito è tornato in vita? Il problema è nei plugin. Se no, rinomina la cartella del tema attivo in wp-content/themes. WordPress passerà automaticamente al tema predefinito. È tornato in vita? Il problema è nel tema.

Devo attivare WP_DEBUG su un sito live?

No, su un sito funzionante WP_DEBUG dovrebbe essere disabilitato (false). Attivalo solo durante la diagnosi e disattivalo subito dopo. Per una raccolta continua degli errori senza mostrarli ai visitatori, usa la combinazione di WP_DEBUG_LOG (scrive in wp-content/debug.log) e WP_DEBUG_DISPLAY (disabilita l'output a schermo).

E se nessuno dei tre metodi ha funzionato?

Controlla il limite di memoria PHP (memory_limit in php.ini). A volte gli script non hanno abbastanza megabyte allocati e vanno in crash con un 500. Aumentalo a 256M o 512M. Se ancora non funziona, contatta il supporto del tuo hosting: chiedi loro di controllare i log degli errori del server (error_log per Apache/Nginx). Lì ci sarà la causa esatta, che non puoi vedere dal lato WordPress.

Il mio sito è su Nginx; cosa faccio con.htaccess?

Nginx non usa .htaccess. Le regole di riscrittura sono specificate nella configurazione del blocco server (nginx.conf o sites-available/your-site). Se sei su Nginx e hai ottenuto un 500, controlla i log in /var/log/nginx/error.log. Un .htaccess errato su un server Nginx non causa problemi; viene semplicemente ignorato.

Come posso prevenire l'errore 500 in futuro?

Tre regole per la prevenzione. Primo: aggiorna regolarmente plugin, temi e il core di WordPress (ogni mese, non una volta all'anno). Secondo: non aggrapparti a estensioni abbandonate; se un plugin non viene aggiornato da oltre un anno, cerca un'alternativa viva. Terzo: prima di installare qualsiasi plugin, controlla la data dell'ultimo aggiornamento e la compatibilità con la tua versione PHP sulla pagina del plugin nella directory di WordPress. Dieci minuti di manutenzione al mese fanno risparmiare ore di debug d'emergenza.

Cosa fare subito se il tuo sito è giù con un 500

L'errore 500 è un puzzle con una soluzione prevedibile. Nella stragrande maggioranza dei casi, risolverai il sito in quindici minuti seguendo tre passi nell'ordine giusto: disattiva i plugin, ripristina .htaccess, attiva WP_DEBUG. L'ordine è importante: dal più probabile e veloce al più dettagliato.

Se hai migrato il sito su un nuovo host, inizia controllando PHP. Se hai configurato caching o redirect, inizia con .htaccess. Se hai aggiornato i plugin e il sito è andato in crash, inizia con WP_DEBUG. E se non hai fatto nulla e un 500 è apparso da solo, esegui tutti e tre i passi in sequenza; uno di loro funzionerà quasi certamente.

Non rimandare la diagnosi: ogni minuto di inattività del sito significa visitatori persi e posizionamento sui motori di ricerca. Apri FTP, fai un backup e inizia.