Un errore 500 su PrestaShop può bloccare l’intero negozio. A volte appare solo nel back-office, su una scheda prodotto, nel carrello o al momento del pagamento. Il problema è che il messaggio Internal Server Error da solo non dice quasi nulla.

Il riflesso giusto non è cambiare tutto insieme. Devi prima recuperare il messaggio d’errore reale, poi testare seguendo un ordine logico: mode debug, log, ultima modifica, moduli, cache e ambiente server. Alla fine di questa guida saprai cosa controllare, in quale ordine, e quando è meglio fermarsi per evitare di peggiorare la situazione.

Cosa significa davvero un errore 500 su PrestaShop

Il codice 500 è un sintomo generico. Prima di toccare file o server, comincia a precisare l’esatto perimetro del guasto.

Capire perché il codice 500 non basta da solo

Secondo MDN, al 20 ottobre 2026, il codice HTTP 500 indica che il server ha incontrato una condizione inaspettata senza poter restituire un codice 5xx più preciso. In altre parole, la 500 non è una causa. È il sintomo visibile di un errore più preciso che devi trovare nel mode debug o nei log.

Lo stesso sintomo può provenire da un modulo incompatibile, da una cache obsoleta, da un cambiamento di PHP, da un .htaccess invalido, da mancanza di memoria o da permessi errati. Se ripristini tutto troppo in fretta rischi di perdere tempo e di dover effettuare un rollback complesso mentre la correzione poteva essere mirata.

Identificare se il guasto interessa tutto il sito, il back-office o un’azione precisa

Prima di ogni test, annota cosa si rompe esattamente:

Questa fase ti fa risparmiare tempo, perché non cercherai nello stesso posto se cade tutto il sito o se si rompe solo una tappa del funnel. Se vuoi ampliare il controllo oltre la sola 500, puoi anche consultare le cause frequenti di un sito PrestaShop in panne.

Far emergere il messaggio d’errore reale con il mode debug e i log

Finché non hai il messaggio reale procedi alla cieca. L’obiettivo di questa fase è semplice: far parlare PrestaShop e poi incrociare con i log PHP e server.

Attivare il mode debug se il back-office è inaccessibile

Per default PrestaShop nasconde gli errori lato front. La documentazione ufficiale raccomanda, al 20 ottobre 2026, di attivare il mode debug impostando _PS_MODE_DEV_ a true in /config/defines.inc.php, oppure dal back-office se resta accessibile: documentazione PrestaShop 9.

Esegui questo test solo per il tempo del diagnostico. La stessa documentazione precisa che il mode debug impatta significativamente le prestazioni e deve essere disattivato dopo l’analisi. Lo scopo è ottenere il messaggio preciso, il file, la classe, il modulo o la funzione coinvolta, poi tornare alla configurazione normale.

Se la tua amministrazione non risponde proprio, il diagnostico supera presto la semplice lettura dell’errore. In tal caso puoi confrontare i sintomi con la pagina dedicata a un back-office PrestaShop inaccessibile.

Leggere i log utili: PrestaShop, PHP, Apache o Nginx

Il mode debug aiuta, ma spesso sono i log a fornire la causa sfruttabile. Riproduci la panne, annota l’ora esatta, poi leggi le voci corrispondenti in:

Il manuale PHP ricorda che in produzione non bisogna lasciare l’output degli errori attivo, e che log_errors permette di registrare gli errori nel file definito da error_log. Sul server, i log di errore sono risorse diagnostiche fondamentali. Ciò che cerchi non è una lunga storia, ma la prima riga d’errore utile al momento in cui riproduci la 500.

Concretamente, annota il file coinvolto, il modulo citato, un errore di memoria, un’incompatibilità di versione, una direttiva rifiutata o un errore di sintassi. Senza questa riga precisa rischi di correggere un effetto secondario invece della causa.

Tornare prima sull’ultima modifica fatta nel negozio

La domanda giusta è spesso semplice: cosa è cambiato subito prima del guasto? È spesso il miglior punto d’ingresso, molto prima delle ipotesi generali.

Testare i moduli installati o aggiornati poco prima della 500

Il centro assistenza PrestaShop indica, al 18 luglio 2025, che una 500 dopo l’installazione o l’aggiornamento di un modulo può derivare da incompatibilità tra moduli, incompatibilità con la versione di PrestaShop, cache obsoleta, conflitto di codice o aggiornamento incompleto: aiuto PrestaShop sull’errore 500 dopo aggiornamento modulo.

Comincia quindi dalla lista delle modifiche recenti:

Il metodo utile è semplice: verifica la compatibilità dichiarata, poi disattiva i moduli recentemente installati o aggiornati uno per uno per individuare il colpevole. Se devi scegliere un solo punto di controllo prioritario dopo aver letto i log, comincia dall’ultimo modulo modificato. Per evitare questo tipo di interruzioni in anticipo, puoi anche leggere come individuare un modulo PrestaShop mal codificato prima dell’installazione.

Svuotare la cache correttamente prima di andare oltre

Svuotare la cache può bastare se la panne è comparsa dopo un’installazione, un aggiornamento o una modifica di codice che non è stata presa correttamente. PrestaShop raccomanda di eliminare la cartella ./var/cache/prod via FTP, oppure di farlo dal back-office quando è ancora accessibile.

Però non farne un riflesso universale. Se i log mostrano chiaramente un’incompatibilità PHP, un errore di memoria o una direttiva server invalida, svuotare la cache non risolverà la causa. Usalo come test mirato, non come risposta automatica a ogni 500.

Verificare la base server: .htaccess, versione PHP, memoria e permessi

Se il guasto non dipende da un modulo recente, risali di un livello: l’ambiente di esecuzione. Spesso è lì che si nascondono gli errori comparsi dopo un cambio di hosting o di configurazione server.

Controllare il file .htaccess senza considerarlo una causa universale

PrestaShop cita un .htaccess mal configurato tra le possibili cause di una 500, in particolare riguardo la riscrittura URL e le Friendly URLs. Ma questo controllo ha senso solo se il tuo negozio gira su Apache. La documentazione di sistema di PrestaShop 9 ricorda infatti, al 20 ottobre 2026, che PrestaShop può funzionare su Apache o su Nginx.

Su Apache la sintassi del .htaccess è rigida. Una direttiva non autorizzata o un errore di sintassi può provocare una 500, generalmente visibile nell’error log. Se la panne è sopraggiunta subito dopo una modifica di riscrittura, un copia-incolla di regole o una rigenerazione azzardata, verifica rapidamente questo file. Se sei su Nginx, non perdere tempo su questo punto: cerca piuttosto la configurazione del server e i log corrispondenti.

Confrontare la versione PHP e la memoria disponibile con i prerequisiti di PrestaShop

Una modifica della versione PHP può rompere un negozio che funzionava il giorno prima. È tipico dopo un cambio di hosting, un upgrade dal pannello o una salita di versione senza verifica di compatibilità.

Secondo i requisiti di sistema di PrestaShop 9, al 20 ottobre 2026, PrestaShop 9.0 supporta PHP 8.1 fino a 8.4. Il ramo 9.1 supporta PHP 8.1 fino a 8.5, con PHP 8.5 raccomandato per la 9.1. La stessa documentazione consiglia un memory_limit minimo di 512M.

Due punti pratici:

Non confondere i requisiti di PrestaShop 9 con quelli di un’altra branch. La diagnosi corretta dipende dalla tua versione reale.

Verificare i permessi senza aprire eccessivamente i diritti

Il centro assistenza PrestaShop indica anche i permessi errati tra le possibili cause di una 500. L’importante è restare misurati: permessi troppo restrittivi bloccano l’esecuzione, ma permessi troppo aperti degradano la sicurezza.

Se la panne compare dopo un deploy manuale, un trasferimento FTP, una migrazione o un intervento sui file, confronta ciò che è cambiato. E non prendere chmod 777 come rimedio standard. I permessi attesi dipendono dal server e dalla sua configurazione. Anche qui, il log del server è spesso il miglior arbitro.

Procedere nell’ordine giusto secondo l’area interessata

Non serve lo stesso percorso di diagnosi se cade tutto il negozio o se si rompe una sola azione. Ecco l’ordine più efficace per evitare deviazioni.

Se l’intero negozio restituisce una 500

Quando tutto il sito è interessato, procedi in questo ordine:

  1. riprodurre la panne e annotare l’ora esatta;
  2. attivare brevemente il mode debug per far emergere il messaggio reale se possibile;
  3. leggere i log PHP e del server nella stessa finestra temporale;
  4. verificare l’ultima modifica: modulo, aggiornamento, cambio PHP, intervento server;
  5. svuotare la cache solo se il contesto lo giustifica;
  6. controllare poi .htaccess, versione PHP, memoria e permessi.

Ciò che devi evitare: ripristinare un backup come primo riflesso senza aver identificato la causa. È un rollback pesante, non uno strumento diagnostico. Finché non hai un indizio preciso, concentrati sui log e sull’ultima modifica effettuata.

Se si rompe solo un’area: back-office, scheda prodotto, carrello o checkout

Quando la 500 interessa solo un’area, la diagnosi è più rapida. Riproduci esattamente l’azione che fallisce, poi cerca il log corrispondente nello stesso momento. Una 500 su una scheda prodotto non punta agli stessi componenti di una 500 al momento del pagamento.

Alcuni riferimenti semplici:

Se l’errore appare solo al momento dell’ordine, l’interruzione può costare vendite immediate. Puoi allora confrontare i sintomi con la pagina dedicata al bug di carrello o checkout PrestaShop.

Quando passare la mano per rimettere il negozio online senza peggiorare il guasto

Il momento giusto per fermare i tentativi è quando non portano più informazioni nuove. Da lì, è meglio consegnare un dossier chiaro che moltiplicare test rischiosi.

I segnali che giustificano un intervento tecnico immediato

Smetti di manipolare se ti trovi in uno di questi casi:

A questo punto il rischio non è più solo perdere tempo. Puoi anche nascondere la causa iniziale, creare una seconda panne o ritardare il ritorno alla normalità.

La checklist minima da trasmettere per risparmiare tempo

Se affidi il diagnostico a un tecnico, invia almeno:

Con questi elementi il diagnostico parte subito nella direzione giusta.

Se ti serve un intervento, la pagina diagnosi e correzione di un errore 500 PrestaShop presenta il quadro d’intervento. E se il negozio è offline o il tunnel di ordine è bloccato, puoi anche richiedere una presa in carico urgente per PrestaShop: diagnosi gratuita, risposta entro 24 h, preventivo entro 24 h lavorative e tariffa chiara a 70 € HT/h.

Domande frequenti

Come attivare il mode debug PrestaShop se il back-office è inaccessibile?

Se il back-office non risponde, puoi attivare il mode debug direttamente nei file del negozio. La documentazione PrestaShop 9 indica di impostare la costante _PS_MODE_DEV_ a true in /config/defines.inc.php. Fai questa operazione solo per il tempo del diagnostico: lo scopo è ottenere il messaggio d’errore reale e poi disattivare il mode debug terminata l’analisi.

Dove trovare i log utili per un errore 500: PrestaShop, PHP, Apache o Nginx?

Comincia dai log corrispondenti all’istante esatto in cui riproduci la panne. I più utili sono i log PHP e quelli del web server, Apache o Nginx a seconda dell’hosting. Se PrestaShop restituisce un messaggio in mode debug, incrocia quel messaggio con questi log. Cerca la prima riga d’errore utilizzabile: file, modulo, memoria, sintassi o direttiva rifiutata.

Un errore 500 può derivare da un modulo installato o aggiornato poco prima?

Sì. Il centro assistenza PrestaShop elenca tra le possibili cause un’incompatibilità con la versione di PrestaShop, un conflitto tra moduli, una cache obsoleta, un conflitto di codice o un aggiornamento incompleto. Il test giusto è partire dall’ultima modifica effettuata, verificare la compatibilità e poi disattivare i moduli recentemente installati o aggiornati uno per uno.

Come capire se il file .htaccess è responsabile dell’errore 500?

Il .htaccess è una pista sensata solo se il tuo negozio gira su Apache. Su questo server un errore di sintassi o una direttiva non autorizzata può scatenare una 500, generalmente visibile nell’error log. Se sei su Nginx, questo file non è l’angolo giusto da indagare. Verifica prima il tipo di server prima di perdere tempo su questo punto.

La versione di PHP può rompere un negozio PrestaShop da un giorno all’altro?

Sì, soprattutto dopo un cambio di hosting o una modifica della versione sul server. Se il negozio o un modulo non è compatibile con la versione PHP attiva, può comparire immediatamente una 500. Al 20 ottobre 2026 la documentazione PrestaShop 9 indica che il ramo 9.0 supporta PHP 8.1–8.4 e il ramo 9.1 PHP 8.1–8.5.

Una mancanza di memoria PHP (memory_limit) può provocare un errore 500?

Sì. Se il processo esaurisce la memoria durante un’operazione pesante la richiesta può fallire e restituire una 500. Il modo più sicuro per confermarlo è controllare i log o il messaggio ottenuto in mode debug. Per PrestaShop 9 la documentazione ufficiale raccomanda un memory_limit minimo di 512M al 20 ottobre 2026.