Schermata bianca. Cinque caratteri: 500 Internal Server Error. Il sito è offline, il cliente ti sta scrivendo e non hai idea da dove cominciare.

L'errore 500 è il codice di stato HTTP più frustrante. A differenza del 404 («pagina non trovata») o del 403 («accesso negato»), non indica un colpevole. Dice solo «qualcosa è andato storto sul server». Poi sei da solo: un plugin, un tema, codice PHP errato, hosting, .htaccess corrotto. Ci sono decine di possibilità e ognuna richiede una soluzione diversa.

La buona notizia: un errore 500 può sempre essere risolto. Senza panico, senza reinstallare WordPress da zero e, nella maggior parte dei casi, senza uno sviluppatore. In 7 passaggi (dalla diagnostica di 30 secondi alla sostituzione chirurgica dei file di sistema) troverai la causa e riporterai online il tuo sito. Ogni metodo include file specifici, righe di codice e screenshot.

💡 Panoramica rapida:

• Passaggio 1: attiva WP_DEBUG e leggi i log per vedere subito quale file è in errore
• Passaggio 2: escludi problemi di hosting mentre analizzi il codice
• Passaggio 3: correggi .htaccess, la causa numero uno secondo le statistiche dell'assistenza
• Passaggio 4: aumenta il limite di memoria PHP, un colpevole comune quando si caricano media o si accede all'admin
• Passaggio 5: ricarica il core di WordPress quando i file sono corrotti da un aggiornamento automatico fallito
• Passaggio 6: disabilita i plugin via FTP, un metodo che risolve più della metà di tutti i casi
• Passaggio 7: ripristina il tema predefinito, un passaggio spesso trascurato

Cos'è l'errore 500 e da dove proviene

HTTP 500 è una risposta del server che significa «errore interno». La richiesta dal browser è arrivata, Apache o Nginx l'ha accettata, PHP ha iniziato l'esecuzione e poi si è inceppato. A differenza del 404 o 403 (dove il server risponde consapevolmente «no»), un cinque all'inizio del codice significa che qualcosa si è rotto all'interno dello script e il server non sa cosa.

In WordPress, l'errore 500 si verifica in quattro scenari tipici:

• Hai installato o aggiornato un plugin ed è entrato in conflitto con altro codice nel sistema.
• Hai modificato .htaccess e un errore di sintassi ha mandato in crash Apache.
• Uno script PHP ha esaurito la memoria allocata (schermata bianca con Allowed memory size of X bytes exhausted nei log).
• I file del core sono corrotti: un aggiornamento automatico fallito, un trasferimento FTP interrotto, un plugin anomalo che ha manomesso le cartelle di sistema.

Meno comunemente: un tema con un errore fatale in functions.php, problemi lato hosting (sovraccarico, modulo PHP disabilitato) o uno shortcode non funzionante di un plugin rimosso all'interno del contenuto della pagina.

Prima di iniziare: esegui un backup completo del sito. Senza backup, qualsiasi azione sui file del server è un rischio. La maggior parte degli host offre un pulsante di backup nel pannello di controllo (cPanel, ISPmanager, aaPanel) con soli due clic.

1. Attiva WP_DEBUG e leggi i log

Il modo più rapido per trovare la causa è far sì che WordPress la riveli. Di default, il core nasconde gli errori PHP dietro una schermata bianca (è la modalità «non spaventare i visitatori»). Ma WordPress ha un meccanismo di debug integrato: le costanti WP_DEBUG.

Attivare la modalità debug

Apri wp-config.php nella root del tuo sito via FTP o tramite il file manager del tuo host. Trova questa riga:

1
/* That's all, stop editing! Happy blogging. */

Prima di essa, inserisci questo blocco:

1
// Enable debug mode
2
define( 'WP_DEBUG', true );
3
 
4
// Write errors to /wp-content/debug.log
5
define( 'WP_DEBUG_LOG', true );
6
 
7
// Do not show errors to visitors on screen
8
define( 'WP_DEBUG_DISPLAY', false );
9
@ini_set( 'display_errors', 0 );

Cosa succede qui:

• WP_DEBUG è l'interruttore principale; senza true, le altre costanti non funzionano.
• WP_DEBUG_LOG indirizza tutti gli errori su wp-content/debug.log invece che a schermo. I visitatori non vedono messaggi preoccupanti.
• WP_DEBUG_DISPLAY + @ini_set nasconde forzatamente gli errori dall'output della pagina.

Salva il file, ricarica la pagina problematica del tuo sito e scarica wp-content/debug.log via FTP. Nel log vedrai il file e la riga specifici: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Disattiva il debug dopo la diagnostica. Commenta o cancella le righe che hai aggiunto. WP_DEBUG su un sito live rallenta le prestazioni e debug.log può crescere fino a gigabyte nel tempo.

2. Contatta il tuo provider di hosting

Se i log sono vuoti o non sono stati creati, l'errore potrebbe essere lato server piuttosto che nel codice di WordPress. Questo è particolarmente comune sui piani di hosting condiviso economici con limiti di processo restrittivi.

Apri un ticket di assistenza e allega tre cose:

• L'ora esatta in cui è apparso l'errore, con il fuso orario del server.
• L'URL della pagina in cui l'errore si riproduce.
• Uno screenshot dell'errore, se disponibile.

L'assistenza controllerà i log del server Apache o Nginx, il carico di CPU e memoria e i moduli PHP disponibili. Spesso i problemi si risolvono in questo passaggio: un amministratore di host riavvia PHP-FPM o regola il limite di processo.

Come capire da che parte sta il problema

Crea un file chiamato info.php con una sola riga:

1
<?php phpinfo(); ?>

Caricalo nella root del tuo sito via FTP e apri your-site.com/info.php. Se vedi una tabella con i parametri PHP, il server funziona e l'errore è nel codice di WordPress. Se vedi 500, l'errore è a livello server; fornisci questo URL all'assistenza.

Dopo il test, **cancella **info.php. phpinfo() espone versioni del server, percorsi e moduli, creando una falla di sicurezza.

3. Correggi il file.htaccess

.htaccess è un file di configurazione di Apache nella root del tuo sito. WordPress lo usa per URL leggibili, redirect e regole di sicurezza di base. Una parentesi di troppo, un conflitto tra regole di due plugin e l'intero sito va giù con un errore 500. Secondo le statistiche dei ticket di assistenza, .htaccess risulta essere la causa numero uno.

Verifica rapida: rinomina .htaccess in .htaccess_old via FTP e ricarica il sito. Se funziona, il problema è sicuramente in questo file.

Ora ripristina .htaccess: vai in amministrazione WordPress, Impostazioni → Permalink e clicca «Salva modifiche» senza cambiare la struttura. WordPress genererà un nuovo file .htaccess pulito con le regole standard:

1
RewriteEngine On
2
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]

Se avevi regole personalizzate in .htaccess (redirect, caching, sicurezza), reinseriscile una alla volta e verifica il sito dopo ciascuna. Così individui la riga che causa il problema.

4. Aumenta il limite di memoria PHP

Gli script PHP di WordPress hanno bisogno di RAM. Quando un plugin o un tema ne richiede più di quanta assegnata, lo script va in crash. Il risultato: un errore 500 o una pagina bianca con il messaggio Allowed memory size of X bytes exhausted.

Il limite standard su molti hosting è ancora 64 MB. Per un sito WordPress moderno con una dozzina di plugin, è catastroficamente basso. Il minimo consigliato è 256 MB.

Metodo 1: via wp-config.php (consigliato)

Aggiungi questa riga a wp-config.php prima di /* That's all, stop editing! */:

1
define( 'WP_MEMORY_LIMIT', '256M' );

Questa costante sovrascrive il limite PHP per il front end del sito. Per l'area di amministrazione, WordPress alza automaticamente il tetto a WP_MAX_MEMORY_LIMIT (256 MB di default).

Metodo 2: via php.ini (se il tuo host non ti permette di modificare wp-config)

Crea un file php.ini con questo contenuto:

1
memory_limit = 256M

Caricalo nella root del sito e nella cartella wp-admin/. Se non risolve, crea o modifica .user.ini nella root del sito con la stessa riga.

Se nessuno dei due metodi funziona, il tuo piano hosting limita fisicamente la memoria. È ora di passare a un piano superiore o cambiare fornitore.

5. Ricarica i file core di WordPress

Un file core corrotto è una causa rara ma insidiosa. Un fallimento dell'aggiornamento automatico, un trasferimento FTP interrotto, un plugin che ha modificato file di sistema, e wp-admin o wp-includes contengono spazzatura.

Procedura:

• Scarica un archivio ZIP fresco di WordPress da wordpress.org.
• Estrai l'archivio sul tuo computer.
• Via FTP, vai alla root del tuo sito e cancella le cartelle wp-admin e wp-includes (solo quelle due; non toccare wp-content!).
• Carica le cartelle wp-admin e wp-includes dall'archivio fresco.
• Non sovrascrivere wp-content; è lì che risiedono i tuoi temi, plugin e upload.

Anche i file root (wp-settings.php, index.php e altri) possono essere sostituiti con quelli freschi dell'archivio. Tranne wp-config.php; non toccarlo perché contiene le credenziali del tuo database. Dopo la sostituzione, aggiorna il sito; l'errore sparirà se la causa erano file di sistema corrotti.

6. Disattiva i plugin

Un plugin killer è la causa più probabile di un errore 500. Hai aggiornato diversi plugin insieme e uno è entrato in conflitto con un altro: ciao, schermata bianca.

Se l'area admin funziona

Vai a Plugin → seleziona tutto → azione di gruppo "Disattiva" → "Applica". Se l'errore scompare, riattiva i plugin uno per uno, aggiornando il sito dopo ciascuno. Quando trovi il colpevole, cancellalo o segnala il problema allo sviluppatore.

Se l'area admin è inaccessibile

Collegati al server via FTP e rinomina la cartella wp-content/plugins in plugins_off. WordPress smetterà di caricare tutti i plugin e il sito tornerà in vita. Riporta la cartella al suo nome originale e rinomina le sottocartelle dei plugin una alla volta; in questo modo troverai quello problematico senza entrare nell'admin.

Cosa tenere d'occhio: plugin di caching (W3 Total Cache, WP Rocket) a volte scrivono le proprie regole in .htaccess e wp-config.php. Dopo aver disattivato un plugin del genere, l'errore potrebbe persistere; controlla questi file e rimuovi le righe tra marcatori come # BEGIN W3TC e # END W3TC o simili.

7. Passa al tema predefinito

Il tema attivo è una fonte sottovalutata ma reale di errori 500. Specialmente se hai aggiunto uno snippet con un errore fatale a functions.php.

La verifica è semplice: via FTP, rinomina la cartella del tema attivo in wp-content/themes/ (per esempio, mytheme → _mytheme). WordPress rileverà che il tema attivo non c'è e passerà automaticamente a uno standard: Twenty Twenty-Five o un altro tema predefinito installato nel sistema.

Se il sito funziona con il tema predefinito, il problema è nel tuo. Riporta il nome originale del tema, apri functions.php e cerca errori nel codice personalizzato. Se non hai aggiunto tu il codice, contatta lo sviluppatore del tema.

⁉️🤔 Domande frequenti

Cosa devo fare se l'errore 500 compare solo quando accedo all'admin?

Molto probabilmente, il limite di memoria PHP non è sufficiente specificamente per il pannello di amministrazione, che carica tutti i plugin insieme ed è più pesante del front end. Aggiungi la riga define( 'WP_MAX_MEMORY_LIMIT', '512M' ); a wp-config.php; questo è un limite separato per l'admin, più alto del WP_MEMORY_LIMIT del front-end. Controlla anche la cartella dei plugin: nella nostra esperienza, i colpevoli più comuni sono i plugin di sicurezza come Wordfence o i plugin di backup che consumano memoria caricando la barra di amministrazione. Disattivali via FTP (la cartella plugins_off del passo 6) e verifica.

Posso risolvere un errore 500 senza accesso FTP?

Sì. La maggior parte degli host fornisce un file manager nel pannello di controllo: cPanel → File Manager, ISPmanager → Files. Attraverso di esso puoi rinominare .htaccess, le cartelle di plugin e temi, e modificare wp-config.php; tutti i passaggi sono gli stessi. Senza alcun accesso ai file, la tua unica opzione è il team di supporto dell'host. Consiglio da pro: se hai installato un plugin per snippet (Code Snippets, WPCode) e la tua ultima azione è stata aggiungere uno snippet, prova ad aprire your-site.com/?code_snippets_safe_mode=1 o un URL simile in modalità provvisoria per il tuo plugin. Questo disabilita tutti gli snippet senza FTP.

L'errore 500 compare solo su una pagina. Qual è la causa?

Una funzione o uno shortcode difettoso all'interno del contenuto di quella pagina specifica. Apri la pagina nell'editor di WordPress (se l'admin funziona) e rimuovi temporaneamente tutti gli shortcode, i blocchi Gutenberg e gli embed di codice. Se l'admin è inaccessibile, trova l'articolo nel database via phpMyAdmin (la tabella wp_posts), copia il contenuto in un editor di testo e rimuovi gli shortcode sospetti. I colpevoli più comuni: shortcode di plugin cancellati ([dead_plugin] rimane ma il plugin non c'è più), PHP difettoso in blocchi di contenuto, o blocchi Gutenberg annidati in modo errato.

Dopo il ripristino, l'errore 500 ritorna dopo qualche ora. Come trovo la causa?

Un errore ciclico con un intervallo è quasi sempre uno di tre scenari: un'attività cron di WordPress esegue un processo difettoso a orari programmati, un plugin di caching genera cache corrotta, oppure l'host raggiunge periodicamente i limiti di processo (specialmente su piani condivisi economici). Installa WP Crontrol e controlla la lista delle attività cron; trova quella che coincide con l'orario del crash. Pulisci la cache del tuo plugin di caching. Chiedi al tuo host informazioni sul limite di Entry Processes o PHP Workers; sui piani condivisi sono spesso limitati a 5-10, e un picco di traffico manda giù il sito.

Devo seguire tutti e 7 i passaggi, o posso saltarne alcuni?

I primi due passaggi (WP_DEBUG e hosting) sono diagnostici: non rompono nulla e forniscono informazioni. Nella nostra esperienza di supporto a siti WordPress, il passo 3 (.htaccess) e il passo 6 (plugin) risolvono la stragrande maggioranza dei casi. Il resto riguarda la memoria PHP, il core corrotto e il tema. In una situazione tipica risolverai il problema al passo 3 o 6 senza dover percorrere l'intera catena.

Da dove iniziare subito

Non ripetere lo scenario tipico: panico → cancelli tutto a caso → peggiori le cose. Segui l'ordine dalla diagnosi alla soluzione:

La regola principale per le riparazioni WordPress: un'azione, una verifica. Non fare mai due correzioni insieme; non saprai quale ha funzionato. E annota esattamente quale plugin o modifica ha causato l'errore. La prossima volta risolverai tutto in 30 secondi.