Sito PrestaShop in panne: le 10 cause più frequenti

Quando un sito PrestaShop cade, il rischio non è solo l’indisponibilità. Il vero problema spesso è la reazione sbagliata: svuotare cache a caso, modificare molte impostazioni insieme o rilanciare un aggiornamento su un negozio già instabile.

Questo articolo serve a fare una scrematura rapida. Al 15 settembre 2026, ecco 10 cause frequenti di un sito PrestaShop in panne, classificate per frequenza osservata su questo tipo di incidente, con per ciascuna due punti utili: il sintomo tipico e una verifica di 1–5 minuti da fare prima di un intervento più tecnico.

Imparerai anche a distinguere una vera indisponibilità da un falso positivo: modalità manutenzione attiva, cache CDN ingannevole o URL di amministrazione sbagliata. Spesso è proprio questo controllo che fa risparmiare più tempo.

Inizia distinguendo una vera panne da un falso positivo

Prima di cercare la causa profonda, metti il negozio in sicurezza ed escludi i casi semplici che possono sembrare una panne. Su PrestaShop un front-office volontariamente disabilitato, una cache esterna o un URL di admin errato possono farti perdere tempo se parti subito alla ricerca di un problema server.

Mettere il negozio in sicurezza senza peggiorare l’incidente

Se il negozio risponde in modo instabile, il riflesso giusto è prima proteggere i visitatori. La modalità manutenzione di PrestaShop disattiva temporaneamente il front-office dal back-office, in Impostazioni negozio > Impostazioni generali > Manutenzione.

Se non hai accesso al back-office, PrestaShop documenta, per le versioni dalla 1.7, una commutazione via app/config/parameters.php impostando maintenance_mode da false a true. Esiste anche una commutazione via database con PS_SHOP_ENABLE, ma è un metodo di ultima risorsa. Non usare questa strada senza un backup recente.

Se vuoi evitare manipolazioni sparse su un negozio in produzione, la pagina su la manutenzione mensile di un negozio PrestaShop presenta un quadro d’intervento più ordinato.

Scarta prima la modalità manutenzione, la cache e l’URL di amministrazione

Primo controllo semplice: il negozio è davvero in panne o è solo disattivato? Una modalità manutenzione rimasta attiva dopo un intervento è un caso frequente. Secondo controllo: prova in navigazione in incognito e, se puoi, senza Cloudflare, senza CDN e senza cache server. PrestaShop lo raccomanda per escludere un falso incidente di visualizzazione o accesso al back-office nella sua guida su l’accesso al back-office.

Terzo controllo: verifica l’URL esatto della cartella /adminXXXX. Se quella cartella è stata rinominata o eliminata, l’indirizzo precedente restituisce logicamente una 404 o una pagina bianca. Se il dubbio riguarda soprattutto l’accesso di amministrazione, inizia con la diagnosi di un back-office PrestaShop inaccessibile invece di correzioni più invasive.

Le 10 cause più frequenti di un sito PrestaShop in panne

Ecco il cuore del triage. L’elenco seguente è ordinato per frequenza osservata su questo tipo di incidente. Per ogni causa mantieni la stessa metodologia: individua il sintomo dominante, poi esegui una verifica breve. Se la risposta è positiva, hai già ridotto molto l’ambito diagnostico.

Le cause 1–5 da verificare per prime

1. Un modulo è stato appena aggiornato, installato o attivato.
   Sintomo tipico: la panne compare subito dopo un intervento, spesso con un errore 500, una pagina bianca o un back-office che non carica più.
   Verifica rapida: ricostruisci la cronologia esatta delle ultime azioni. PrestaShop segnala che un errore 500 si verifica frequentemente dopo un aggiornamento di tema o moduli, e che moduli obsoleti o incompatibili dopo una upgrade possono anche rompere il negozio. Se il sintomo principale è già una 500, guarda anche la diagnosi per un errore 500 PrestaShop.
2. Il tema è stato modificato o aggiornato.
   Sintomo tipico: il front-office diventa inaccessibile o si visualizza male, mentre il server non è necessariamente offline.
   Verifica rapida: chiedi cosa è stato cambiato subito prima della panne: aggiornamento del tema o intervento visivo. Se la panne coincide con quell’intervento, tieni questa pista in cima alla lista.
3. La modalità manutenzione è attiva.
   Sintomo tipico: il front-office sembra indisponibile mentre il back-office resta accessibile.
   Verifica rapida: controlla subito lo stato della modalità manutenzione in PrestaShop. È un controllo semplice da fare all’inizio.
4. La cache esterna mostra un incidente non più reale.
   Sintomo tipico: un dispositivo vede la panne, un altro no; l’accesso al back-office si blocca o si comporta diversamente a seconda del browser.
   Verifica rapida: prova in navigazione in incognito, poi senza Cloudflare, senza CDN o senza cache server se puoi farlo rapidamente. Se la resa cambia a seconda del contesto, non concludere ancora che si tratti di una panne del codice.
5. L’URL del back-office non è più corretto.
   Sintomo tipico: 404 o pagina bianca sull’indirizzo /adminXXXX, mentre il negozio non è necessariamente totalmente offline.
   Verifica rapida: confronta l’URL chiamata con il nome reale della cartella di amministrazione sul server. Un rinominare basta a far credere a un blocco dell’accesso.

Le cause 6–10 da controllare dopo

6. La versione di PHP non è più compatibile con la tua branch di PrestaShop.
   Sintomo tipico: la panne compare dopo un cambiamento lato host, una migrazione o un tentativo di aggiornamento che non si avvia.
   Verifica rapida: confronta la versione PHP attiva con quella richiesta dalla tua versione di PrestaShop. Al 15 settembre 2026, la documentazione sistema di PrestaShop 9 indica che la branch 9.0 supporta PHP 8.1–8.4 e raccomanda PHP 8.4, mentre la 9.1 supporta PHP 8.1–8.5 e raccomanda PHP 8.5.
7. Il file .htaccess contiene un errore.
   Sintomo tipico: errore 500 apparso dopo una modifica legata agli URL del negozio.
   Verifica rapida: verifica se il .htaccess è stato toccato subito prima dell’incidente. La sua sintassi è severa; un solo errore è sufficiente a rompere l’accesso.
8. Il server interrompe l’esecuzione prima della fine.
   Sintomo tipico: la panne si manifesta durante un import CSV, un backup, un caricamento di traduzioni, un import/export o la rigenerazione delle miniature.
   Verifica rapida: controlla se l’incidente è iniziato durante un’operazione pesante. PrestaShop cita i timeout server tra le cause frequenti di errore 500 in queste operazioni.
9. Il codice e lo schema di database non sono più coerenti.
   Sintomo tipico: un aggiornamento rifiuta di partire, o il negozio si comporta male dopo una migrazione o un upgrade incompleto.
   Verifica rapida: verifica se un aggiornamento è stato interrotto. La FAQ di aggiornamento PrestaShop segnala che una discrepanza tra la versione del codice e la versione dello schema in DB può bloccare il processo.
10. Il problema riguarda assets CSS o JavaScript, non il server.
    Sintomo tipico: il negozio appare rotto o inutilizzabile dal punto di vista visivo, mentre il server risponde ancora.
    Verifica rapida: durante il debug di un tema o di una visualizzazione, disabilita le opzioni CCC che fondono e minificano CSS e JavaScript. La documentazione di PrestaShop 9 lo raccomanda per evitare falsi problemi di resa.

Per il dettaglio tecnico di una 500, di un .htaccess rotto o di un timeout, l’aiuto ufficiale sull’errore 500 PrestaShop conferma che il modulo non è l’unica pista: contano anche server e configurazione.

Controlla poi cosa è cambiato subito prima della panne

Un negozio che cade all’improvviso ha spesso un trigger molto vicino nel tempo. L’utile non è controllare tutto, ma ritrovare l’evento che ha preceduto l’incidente di qualche minuto o qualche ora.

I cambiamenti applicativi da verificare per primi

Inizia dalla parte applicativa: aggiornamento di modulo, cambio di tema, tentativo di aggiornamento PrestaShop, migrazione o patch urgente. Se la panne segue immediatamente uno di questi cambiamenti, hai già il principale sospettato.

Questo punto pesa ancora di più prima di una upgrade. Se stai preparando il passaggio all’ultima branch, rileggi cosa verificare prima di salire a PrestaShop 9: la compatibilità dei moduli e dell’ambiente resta il primo filtro.

I cambiamenti d’ambiente che rompono un negozio senza avviso

Lato hosting, due controlli ricorrono spesso: la versione PHP attiva e le risorse disponibili. Al 15 settembre 2026, le finestre di compatibilità di PrestaShop 9 sono precise, e una versione PHP troppo bassa o troppo alta può bloccare un aggiornamento. La documentazione sistema di PrestaShop 9 raccomanda inoltre un memory_limit di almeno 512M per script.

Controlla anche le impostazioni tecniche modificate dall’host o durante una migrazione. La stessa documentazione precisa per esempio che allow_url_fopen deve essere attivo, perché l’accesso a file remoti è essenziale per alcuni processi come il pagamento. Non è il primo controllo da fare, ma è una pista seria quando nulla è cambiato nel codice.

Evita le manipolazioni che confondono il diagnostic

Durante una panne reale, il tempo si spreca spesso meno nella ricerca che nei test sbagliati. L’obiettivo non è fare molte azioni, ma poche e tracciabili.

Non lasciare il mode debug o cambi temporanei in produzione

Il mode debug può aiutare a capire un incidente, ma non deve rimanere attivo su un negozio in produzione. La documentazione PrestaShop specifica che impatta significativamente le prestazioni e che va disattivato dopo il debug. In pratica può anche mostrare errori ai visitatori.

Altro punto spesso dimenticato: se modifichi parameters.php, la documentazione indica di cancellare manualmente la cache in /var/cache/(dev|prod). Altrimenti rischi di testare una configurazione che non è realmente quella caricata dal negozio.

Non moltiplicare modifiche simultanee

Evita di concatenare molte modifiche: disattivazione di un modulo, cambio di PHP, svuotamento cache, modifica del .htaccess, poi ritocco del DB. Dopo pochi minuti non saprai più quale azione ha avuto effetto.

Evita anche modifiche dirette al database senza backup recente. PrestaShop segnala questa via come rischiosa e da usare come ultima risorsa. Infine, non presumere che una semplice purge di cache risolva la maggior parte dei casi: le cause ufficiali includono anche PHP, lo schema DB, il .htaccess, i timeout e moduli incompatibili.

Se il sito resta in panne dopo questi controlli, passa al giusto livello d’intervento

Dopo questo triage, dovresti essere in grado di rispondere a tre domande semplici: la panne è reale o apparente, quale cambiamento probabilmente l’ha scatenata, e quale sintomo domina realmente. Se non hai queste tre risposte, continua il triage. Se le hai, interrompi i test improvvisati.

I segnali che impongono un intervento immediato

Non perdere altro tempo se il sito è totalmente irraggiungibile, se il back-office è offline, se l’errore ritorna dopo ogni test semplice o se la panne segue un aggiornamento, una migrazione o un cambio d’ambiente chiaramente identificato. A questo punto il riflesso giusto è puntare al ripristino della disponibilità prima di una ricerca esaustiva di tutte le cause secondarie.

Se la tua priorità è la disponibilità, opta per un intervento d’urgenza su PrestaShop piuttosto che su una lunga serie di tentativi in produzione.

Accessi e informazioni da preparare per risparmiare tempo

Prepara la versione di PrestaShop, la versione PHP attiva, l’ora d’inizio dell’incidente, l’ultima azione eseguita prima della panne e il sintomo esatto: errore 500, pagina bianca, back-office inaccessibile, front in manutenzione, visuale rotta o timeout durante un’operazione specifica. Questi elementi fanno guadagnare tempo già nelle prime minuti.

Se sei arrivato al termine di questi controlli, il passo logico è il ripristino di un sito PrestaShop irraggiungibile. KLN-WEB interviene su riparazioni urgenti, emergenze e manutenzione PrestaShop, con diagnosi gratuita e un quadro chiaro prima di ogni intervento.

Domande frequenti

Perché il mio sito PrestaShop mostra un errore 500 subito dopo un aggiornamento di modulo o tema?

Perché è una delle cause frequenti documentate da PrestaShop. Un aggiornamento di modulo o tema può introdurre un’incompatibilità, specialmente dopo una upgrade di versione. Il primo riflesso utile è verificare la cronologia: cosa è stato modificato, installato o attivato subito prima dell’errore e su quale versione esatta di PrestaShop.

Cosa verificare per primo se il front-office non si carica ma non ho ancora identificato la causa?

Inizia scartando i falsi positivi. Controlla prima se la modalità manutenzione è attiva. Prova poi in navigazione in incognito e, se possibile, senza Cloudflare, senza CDN e senza cache server. Infine verifica se il back-office resta accessibile. Questi tre controlli richiedono poco tempo ed evitano di partire subito su una panne server.

Come sapere se la versione PHP del mio hosting è incompatibile con la mia versione di PrestaShop?

Devi confrontare la versione PHP effettivamente eseguita dall’hosting con l’intervallo supportato dalla tua branch di PrestaShop. Al 15 settembre 2026, PrestaShop 9.0 supporta PHP 8.1–8.4 e 9.1 supporta PHP 8.1–8.5. Una versione troppo bassa o troppo alta può bloccare un aggiornamento o provocare una panne dopo un cambio d’ambiente.

Come mettere il negozio in manutenzione se il back-office PrestaShop è inaccessibile?

Per le versioni dalla 1.7, PrestaShop documenta una commutazione via file app/config/parameters.php impostando maintenance_mode da false a true. Esiste anche un metodo via database con PS_SHOP_ENABLE, ma dovrebbe rimanere un’ultima risorsa. In entrambi i casi è meglio avere un backup recente prima di agire.

Perché il mio back-office restituisce una 404 o una pagina bianca su /adminXXXX?

La prima ipotesi da verificare è semplicemente che l’URL chiamata non sia più corretta. Se la cartella admin è stata rinominata o rimossa, il vecchio indirizzo non funziona più. Questo punto è documentato da PrestaShop e provoca spesso un falso allarme di panne completa mentre il problema riguarda solo l’accesso di amministrazione.

Cloudflare, la cache server o un CDN possono far sembrare che il mio sito PrestaShop sia in panne?

Sì. PrestaShop raccomanda esplicitamente di testare senza cache CDN, senza cache server o in navigazione in incognito quando l’accesso al back-office dà problemi. Una cache esterna può mantenere uno stato di errore, un loop o una visualizzazione rotta. Prima di concludere che si tratti di una panne reale, verifica sempre se il comportamento cambia a seconda del contesto di navigazione.