Errore 500 sul tuo PrestaShop ?
lo correggiamo oggi.
Diagnosi e correzione di errore 500 PrestaShop da parte di un esperto certificato
HTTP ERROR 500, Internal Server Error, pagina bianca con un 500 nell'intestazione :
il tuo negozio è visibile ma inutilizzabile. Leggiamo i log, individuiamo la causa principale,
rimettiamo il sito online in meno di 2 h in 9 casi su 10.
I 9 volti dell'errore 500 PrestaShop
Descrivi ciò che vedi. Più sei preciso, più rapida è la diagnosi.
HTTP ERROR 500
This page isn't working
→ Errore server fatale
500 Internal Server Error
The server encountered an
internal error...
→ Pagina Apache predefinita
500 Internal Server Error
nginx/1.x.x
→ PHP-FPM down o in crash
Fatal error: Allowed memory
size of 134217728 bytes
exhausted
→ Memory limit superato
PHP Fatal error: Uncaught
Error: Class "XYZ" not
found in /classes/...
→ Override rotto / classe mancante
PHP Fatal error: Uncaught
Exception in /modules/
monmodule/hook.php:42
→ Modulo difettoso
mod_fcgid: HTTP_INTERNAL_
SERVER_ERROR error,
premature end of script
→ Timeout PHP-CGI
Invalid command 'RewriteEngine',
perhaps misspelled or
defined by a module not
included...
→ Rigenerazione .htaccess
RuntimeException:
The service "..." has a
dependency on a non-existent
service "..."
→ Container Symfony rotto
Le 7 cause più frequenti di un errore 500 PrestaShop
Individuate su oltre 80 interventi d'urgenza. Una sola può essere presente, oppure più cumulate.
memory_limit PHP
Il più frequente (≈ 35 % dei casi). Provocato da un hook esoso su actionProductSave che carica tutte le combinazioni in memoria, una migrazione Doctrine che entra in loop, o un export catalogo troppo voluminoso. Visibile in error_log con Allowed memory size of X bytes exhausted. Fix : aumentare il memory_limit a 512M o addirittura 1024M nel php-fpm pool o nel php.ini, ma soprattutto individuare l'hook colpevole.
.htaccess corrotto o rigenerato male
≈ 20 % dei casi. Si verifica dopo una rigenerazione dal BO (Preferenze → SEO & URL), una migrazione di dominio, o un aggiornamento PrestaShop che ha sovrascritto delle direttive custom (compressione, redirect). Errore Apache tipico : Invalid command 'RewriteEngine'. Fix : confronto con la versione git precedente, ripristino delle regole custom, verifica della presenza del modulo mod_rewrite.
≈ 15 %. Dopo un aggiornamento PrestaShop, i tuoi override in /override/classes/ e /override/controllers/ possono fare riferimento a metodi che hanno cambiato firma o sono spariti. PHP lancia allora Fatal error: Class "X" not found oppure Cannot redeclare method Y. Fix : disattivare temporaneamente /override/ rinominandola, individuare il file colpevole, portarlo sulla nuova versione.
≈ 12 %. Un modulo progettato per PrestaShop 1.7 che non è mai stato verificato con PHP 8.x, o un modulo esterno che non ha seguito un passaggio 1.7 → 8.x. PHP rifiuta allora un tipo strict (TypeError) o una sintassi deprecata. Fix : disattivazione del modulo via SQL (UPDATE ps_module SET active=0 WHERE name='X') o eliminando la cartella, individuazione della correzione lato editore, deploy di una patch locale se necessario.
≈ 8 %. Si verifica tipicamente dopo un ripristino FTP brusco, o un trasferimento di hosting. PHP-FPM non riesce più a leggere /var/cache/prod/, scrivere in /var/logs/, o eseguire uno script CLI. Log Apache : Permission denied. Fix : chmod -R 755 dirs / 644 files, chown -R www-data:www-data sulla struttura sensibile.
≈ 6 %. Specifico delle versioni moderne. Un modulo che dichiara un servizio con una dipendenza inesistente, o un services.yml con nome errato. PrestaShop restituisce un 500 già dal bootstrap, prima ancora di toccare Smarty. Fix : svuotare /var/cache/prod/, lanciare php bin/console cache:clear, ispezionare il services.yml del modulo sospetto, dichiarare il servizio mancante o eliminare la dipendenza fantasma.
≈ 4 %. OPCache che serve ancora codice obsoleto dopo un deploy, display_errors=Off che maschera la vera causa, max_execution_time troppo basso che uccide gli script lunghi (import CSV, generazione di sitemap). Fix : riavvio di PHP-FPM, audit del phpinfo(), allineamento del php.ini CLI vs FPM.
Cronologia di un errore 500 corretto in 1 h 47
Caso reale · Negozio cosmetici bio · PrestaShop 8.1.5 · Hosting OVH Performance · Aprile 2026.
tail -f /var/log/apache2/error.log in SSH. Primo errore visibile : PHP Fatal error: Allowed memory size of 268435456 bytes exhausted in /modules/xfilters/classes/FilterCollection.php on line 217.
xfilters caricava tutte le combinazioni di tutti i prodotti in memoria per calcolare i suoi aggregati. Su 2 800 prodotti × 12 combinazioni in media, ≈ 33 600 combinazioni in una volta → il memory_limit esplode.
FilterCollection.php : lettura delle combinazioni a blocchi di 500 (generatore PHP). Test OK su 4 schede prodotto rappresentative.
(1 h 47 × 60 €/h)
Tariffe comunicate in anticipo
Diagnosi gratuita. Per l'intervento, sai esattamente quanto costa prima che io tocchi il codice.
Diagnosi
- Lettura error_log +
php-fpm.log - Causa principale individuata (memory_limit, .htaccess, override...)
- Preventivo dettagliato inviato immediatamente
- Decidi tu se continuare
Intervento mirato
- Backup file + DB prima dell'intervento
- Correzione mirata dell'errore 500 (hook, .htaccess, override, modulo)
- Test front + back-office + tunnel d'acquisto
- Report scritto causa principale + correzione
- Garanzia 30 giorni sulla correzione
Manutenzione mensile
- Monitoraggio 5 min · avviso SMS prima dei tuoi clienti
- Backup automatici giornalieri esternalizzati
- Intervento prioritario in caso di errore 500
- Monitoraggio CVE PrestaShop + hotfix applicati
Un errore 500 non è...
I bug simili si confondono spesso. Verifichiamo che tu sia nel posto giusto.
Se il tuo sito mostra assolutamente nulla, solo il bianco, senza messaggio di errore, è una pagina bianca PrestaShop (display_errors=Off maschera il vero errore). Non è un 500 mostrato dal server.
Un 502 (Bad Gateway) significa che Nginx non riceve risposta da PHP-FPM (spesso un crash di PHP-FPM). Un 504 (Gateway Timeout) significa che PHP ha superato il suo tempo di esecuzione. Le cause sono collegate ma i fix sono diversi.
Se il tuo sito risponde ma impiega 15 s a caricare una scheda prodotto, non è un 500 (il server risponde bene, solo lentamente). È un problema di prestazioni : cache, DB, moduli, hosting.
Vedi la scheda prestazioni →Domande frequenti sugli errori 500 PrestaShop
memory_limit PHP (spesso provocato da un hook di modulo sulle schede prodotto), un .htaccess corrotto dopo un aggiornamento, un override di classe rotto in seguito a un update PrestaShop, permessi dei file errati, o un modulo che lancia un'eccezione non gestita durante il bootstrap. La diagnosi richiede sempre la lettura di error_log Apache e php-fpm.log, mai una supposizione.memory_limit, .htaccess, hook fatale), il sito viene rimesso online in meno di 2 h dopo la presa in carico, di cui 15-30 min di diagnosi. Per i casi complessi (override corrotto, conflitto di moduli dopo un update importante), bisogna calcolare da mezza giornata a una giornata. La tempistica esatta ti viene comunicata dopo la diagnosi gratuita iniziale, mai prima..htaccess, config/defines.inc.php, o un override. Questo richiede un accesso FTP o SSH al server. Se hai perso i tuoi accessi, recuperiamo prima le credenziali presso il tuo hosting. È generalmente fattibile in 1-4 h a seconda dell'hosting.Evita il prossimo errore 500 prima che si verifichi
Sorveglianza 24/7, backup giornalieri, hotfix di sicurezza, intervento prioritario : a 50 €/mese senza impegno, il contratto di manutenzione ammortizza ampiamente un solo errore 500 evitato.
Vedi le formule di manutenzione →Errore 500 sul tuo sito in questo momento ?
Descrivi ciò che vedi, controlliamo entro 30 min in orario lavorativo. Diagnosi gratuita, preventivo entro 24 h lavorative.