Un negozio PrestaShop può smettere di funzionare anche se nessuno ha toccato il codice il giorno prima. Nessuna nuova versione visibile, nessun modulo appena installato, eppure il sito diventa irraggiungibile, il pagamento si rompe o le email ordine smettono di partire.

Il punto utile non è solo riparare a posteriori. Bisogna distinguere ciò che interrompe l'intero negozio, ciò che rompe una funzione critica e ciò che rimane silenzioso fino al primo cliente bloccato.

In questo articolo trovi una checklist semplice, datata al 16 settembre 2026, per capire cosa monitorare automaticamente e cosa controllare ogni mese per anticipare un guasto PrestaShop prima che diventi visibile ai tuoi clienti.

Un negozio PrestaShop può cadere senza aggiornamenti visibili

Molti contenuti parlano soprattutto del dopo-guasto: errore 500, pagina bianca, modulo rotto. È utile una volta che il sito è fermo. Nella gestione quotidiana, il buon riflesso è classificare gli incidenti per livello di gravità per monitorare i punti giusti al momento giusto.

Risparmi tempo se separi tre scenari: interruzione totale, funzione critica rotta e guasto silenzioso. I controlli prioritari non sono gli stessi.

Ciò che interrompe tutto il sito

Qui il sintomo è chiaro: il negozio non risponde più, il front non si carica, il back-office diventa inaccessibile o appare un errore server. Questo tipo di incidente può derivare dall'hosting, da un disco saturo, da un dominio scaduto o da una modifica tecnica applicata fuori dal tuo radar.

Se sei già in questa situazione, puoi confrontare i sintomi con le cause più frequenti di un sito PrestaShop in panne. Il punto importante è semplice: un'interruzione totale non è sempre legata a un deployment recente.

Ciò che rompe solo una funzione chiave

In questo secondo caso, il negozio sembra ancora online. Le schede prodotto si visualizzano, la home page risponde, ma una funzione essenziale non funziona: carrello, checkout, pagamento, accesso cliente o accesso al back-office.

Questo scenario è insidioso, perché il problema può durare mentre il sito risponde ancora. Vedi traffico, ma gli ordini non passano correttamente.

Ciò che resta invisibile fino al primo cliente bloccato

Il terzo scenario è il più ingannevole. Il sito rimane visibile, però le email transazionali non partono più, alcune risorse non si caricano in HTTPS o una dipendenza esterna legata a un modulo non risponde più.

Su una pagina servita in HTTPS, i browser bloccano i contenuti misti critici. Dopo un rinnovo SSL o un cambiamento di dominio male finalizzato, alcuni script o fogli di stile ancora richiamati in HTTP possono quindi rompere una funzione senza far cadere l'intero sito.

Le scadenze silenziose da monitorare in priorità

Le scadenze dimenticate provocano interruzioni evitabili. Succede spesso fuori dalle finestre di aggiornamento, dunque quando nessuno si aspetta un incidente.

Il tuo obiettivo non è memorizzare queste date, ma toglierle dalla testa di una persona e inserirle in una routine documentata.

Certificato SSL pubblico e certificato di origine

Un certificato SSL pubblico scaduto è un classico. Let's Encrypt ricorda che i suoi certificati hanno una validità di 90 giorni e che il modello si basa sul rinnovo automatico, non manuale: durata di validità dei certificati Let's Encrypt. Se l'automazione fallisce e nessuno controlla la data di scadenza, il negozio può bloccarsi da un giorno all'altro.

Punto spesso dimenticato: se usi un CDN o un proxy, il certificato visibile al visitatore non è sempre l'unico da sorvegliare. Anche il certificato di origine può scadere in silenzio. L'errore classico è controllare solo il lucchetto nel browser. Evita questo: verifica anche il certificato usato tra il proxy e il server.

Nome di dominio e rinnovo

Un dominio scaduto non interrompe immediatamente il sito nello stesso modo presso tutti i registrar. ICANN indica che può esistere un periodo di grazia, ma il suo effetto visibile varia. La decisione corretta è trattare la scadenza del dominio come una data ferma, non come un margine di sicurezza.

Da verificare ogni mese: la data di scadenza, la modalità di rinnovo, il metodo di pagamento associato e la persona realmente responsabile dell'account registrar. Caso classico: un dominio ancora legato a una vecchia agenzia, a un dipendente che se n'è andato o a un indirizzo email poco monitorato.

Licenza del modulo e dipendenze esterne

Una licenza modulo scaduta non interrompe sempre l'intero negozio. Può però bloccare una funzione critica, un accesso API o impedire un aggiornamento necessario. È il tipo di incidente che lascia il front accessibile mentre un mattone di business diventa inutilizzabile.

Il buon riflesso è mantenere un inventario semplice: nome del modulo, ruolo, scadenza della licenza, eventuale dipendenza esterna, responsabile e test da eseguire dopo il rinnovo. Senza questo inventario scopri spesso il problema il giorno in cui il pagamento, il corriere o la sincronizzazione smettono di rispondere.

I cambiamenti lato hosting che possono rompere il negozio da un giorno all'altro

L'hosting non è un fondale. È una fonte di guasti a sé. Un negozio stabile per mesi può uscire dal suo equilibrio dopo un cambio di versione PHP, una memoria insufficiente o uno spazio disco saturato.

Su questo punto, i controlli preventivi valgono più di un ticket aperto dopo l'interruzione.

Versione PHP e memory_limit: il duo da controllare da vicino

Un cambio di PHP applicato dall'hosting può rompere un negozio senza modifiche da parte tua. Per PrestaShop 9, la documentazione ufficiale raccomanda PHP 8.5 e un memory_limit minimo di 512M: requisiti di sistema di PrestaShop 9. Ricorda anche di testare tema, moduli e personalizzazioni prima della messa in produzione.

Al 16 settembre 2026, PHP ricorda che un ramo ha 2 anni di supporto attivo e poi 2 anni di correzioni di sicurezza. A quella data, PHP 8.2 non è più in supporto attivo e la fine del supporto di sicurezza è fissata al 31 dicembre 2026: versioni PHP supportate. Questo non significa cambiare alla cieca. Significa che una decisione su PHP dev'essere datata, testata e documentata.

Errore classico: lasciare che l'hosting cambi PHP e verificare solo se la home page si carica ancora. Evita questo: testa anche il back-office, il carrello, il tunnel e le email transazionali. Se prepari un aggiornamento di versione, puoi anche rileggere i punti da verificare prima di una migrazione a PrestaShop 9.

Disco pieno, inode saturi e database che non scrive più

Quando il disco è pieno, i sintomi possono essere bruschi: impossibilità di scrivere nel database, back-office instabile, ordini che non si registrano correttamente. cPanel documenta ad esempio l'errore MySQL «Got error 28 from storage engine» come un sintomo di disco pieno: errore MySQL 28 legato allo storage.

Questo problema resta spesso silenzioso fino alla soglia critica. Il negozio sembra normale, poi un'operazione di scrittura fallisce e compaiono più sintomi contemporaneamente. Il controllo utile non riguarda solo lo spazio disco globale, ma anche la sua evoluzione, i log, i backup, i file di cache e gli inode se il tuo hosting li limita.

Se il guasto è già visibile sul server, un primo inquadramento utile è lanciare una diagnosi di errore 500 su PrestaShop per distinguere un problema applicativo da un problema d'infrastruttura.

Perché il sito può rimanere aperto mentre gli ordini si perdono già

Un negozio accessibile non è necessariamente operativo. Il costo emerge quando un ordine non viene confermato, una password non può essere reimpostata o un pagamento fallisce senza allerta immediata.

Questi guasti parziali durano spesso più a lungo proprio perché nessuna pagina sembra completamente fuori servizio.

Quota email, code e deliverability rotta

Una quota email raggiunta non mette necessariamente il sito offline. Può però bloccare l'invio delle email d'ordine, di creazione account o di reimpostazione password. È una differenza importante: il cliente pensa di aver ordinato, ma non riceve nulla.

I punti da monitorare sono semplici: volume di invio, messaggi in ritardo, errori, caselle piene, quota di archiviazione mail e saturazione degli inode lato posta. L'errore classico è verificare solo che l'SMTP risponda. Evita questo: controlla anche se i messaggi escono davvero, in quali tempi, e se rifiuti o code si accumulano.

Checkout, pagamento e script bloccati senza interruzione totale

Dopo un rinnovo SSL mal finalizzato, un cambio di dominio o una risorsa ancora richiamata in HTTP, alcune parti del checkout possono smettere di funzionare mentre il negozio resta visibile. Il browser blocca allora i contenuti misti critici.

Il sintomo tipico è un tunnel che carica parzialmente, un passaggio che resta in loop, un pulsante di pagamento inattivo o uno script di terze parti che non si inizializza più. Se rilevi questo tipo di guasto parziale, un primo passo utile è richiedere un pre-audit di un pagamento PrestaShop che fallisce per isolare rapidamente il componente coinvolto.

Il monitoraggio minimo da mettere in piedi per essere avvisato prima dei tuoi clienti

Un monitoraggio efficace non si limita a un ping sulla home. Un negozio può rispondere con HTTP 200 mentre ha il carrello rotto, un pagamento in errore o email che non partono. L'approccio corretto combina alert automatici e un controllo mensile documentato.

Al 16 settembre 2026 questo schema può rimanere semplice: pochi punti seguiti seriamente valgono più di un dispositivo troppo ampio che non viene mai aggiornato.

Gli alert automatici da configurare

Primo livello: disponibilità. Devi essere avvisato se la home non risponde più o se il suo comportamento cambia anormalmente.

Secondo livello: scadenze. Programma promemoria per certificato SSL, dominio e licenze dei moduli critici.

Terzo livello: funzioni di business. Prevedi almeno un controllo regolare del back-office, del carrello, del pagamento e dell'invio di un'email transazionale. È questo livello che individua i guasti silenziosi prima dei tuoi clienti.

I controlli mensili da documentare

Una volta al mese ripeti sempre la stessa lista:

Il punto decisivo è assegnare un responsabile per ogni controllo. Una checklist senza proprietario viene spesso dimenticata. Se preferisci delegare questo monitoraggio, la manutenzione mensile di un negozio PrestaShop permette di stabilire una routine seguita nel tempo.

Metti in piedi una checklist anti-interruzione già questa settimana

Non serve rifare tutto per ridurre il rischio. Occorre soprattutto togliere i punti critici dall'improvvisazione. Inizia creando una lista di scadenze, test di business e persone responsabili. Poi adatta gli strumenti.

La checklist in 30 minuti per ripartire su basi sane

  1. Elenca le tue scadenze: SSL, dominio, licenze dei moduli critici.
  2. Annota la versione PHP attiva e l'ambiente di hosting realmente utilizzato.
  3. Verifica lo spazio disco disponibile e i segnali di saturazione.
  4. Controlla le quote email e lo stato degli invii transazionali.
  5. Testa un percorso breve: home, scheda prodotto, aggiungi al carrello, checkout, email.
  6. Identifica chi riceve gli alert e chi interviene per primo.

Questa base già struttura i controlli più utili sulle cause silenziose viste sopra. L'errore classico è fare queste verifiche una sola volta. Il ritmo giusto è mensile, con una traccia scritta e datata.

Quando passare da un controllo interno a un supporto esterno

Se dipendi da più fornitori, da un hosting, da un CDN e da moduli terzi, la coordinazione diventa rapidamente il punto debole. Dal momento in cui nessuno è chiaramente responsabile della sorveglianza, è più sicuro formalizzare un supporto ricorrente o un intervento puntuale con perimetro definito.

Se mantieni il controllo internamente, usa questa checklist come procedura base prima di aprire un ticket. Se la sorveglianza non ha un proprietario chiaro, il supporto PrestaShop, puntuale o mensile consente di inquadrare sia il monitoraggio sia l'intervento. Su KLN-WEB intervengo direttamente per gli e-commerçanti e in white label per le agenzie, con diagnosi gratuita e risposta in 24 h.

Domande frequenti

Perché un negozio PrestaShop può cadere senza alcun aggiornamento apparente?

Perché un guasto non deriva sempre dal codice rilasciato. Un negozio può cadere per un certificato SSL scaduto, un dominio non rinnovato, un cambio PHP applicato dall'hosting, un disco saturo o una licenza modulo scaduta. In molti casi nessuno ha toccato il sito il giorno prima, ma l'esercizio è derivato fino al punto di rottura.

Come sapere in anticipo se il certificato SSL o il dominio sta per scadere?

Il metodo più affidabile è combinare un promemoria automatico con un controllo mensile documentato. Verifica la data di scadenza del certificato pubblico e, se usi un proxy o un CDN, controlla anche il certificato di origine. Per il dominio, non presumere che un periodo di grazia ti salvi: annota la scadenza, la modalità di rinnovo e la persona responsabile dell'account registrar.

Un cambio di versione PHP da parte dell'hosting può rompere PrestaShop da un giorno all'altro?

Sì. Una versione PHP modificata dall'hosting può far uscire il negozio dalla sua fascia di compatibilità o mettere in luce una memoria insufficiente. Il rischio aumenta se tema, moduli o personalizzazioni non sono stati testati su quella versione. Occorre quindi monitorare la versione PHP attiva, datare la decisione tecnica e testare front, back-office e tunnel dopo ogni cambiamento.

Quali quote monitorare per evitare un guasto silenzioso: disco, inode, email, database?

Monitora prima di tutto lo spazio disco disponibile, perché un disco pieno può impedire le scritture in database e provocare sintomi bruschi. Controlla anche gli inode se il tuo hosting li limita, oltre alle quote e alle code email. Per il database, il punto utile non è solo la sua dimensione, ma la capacità di continuare a scrivere senza errori durante gli ordini.

Perché il sito resta accessibile mentre le email d'ordine o di password non partono più?

Perché la visualizzazione del sito e l'invio delle email transazionali poggiano su componenti differenti. Un negozio può quindi continuare a servire le pagine mentre una quota email è stata raggiunta, una coda si allunga o una casella è piena. È un guasto silenzioso tipico: il cliente vede il sito, ma parte del percorso post-ordine non funziona più.

Quale monitoraggio minimo impostare per essere avvisato prima dei clienti?

Imposta tre livelli. Primo, un alert di disponibilità se il sito non risponde più. Secondo, promemoria di scadenza per SSL, dominio e licenze critiche. Infine, un controllo business regolare del back-office, del carrello, del pagamento e di un'email transazionale. Un semplice ping della home non basta, perché un negozio può rispondere pur perdendo ordini.