Rivisto in vista della prossima stagione. Date confermate: Black Friday 2026 = venerdì 27 novembre; Cyber Monday = 30 novembre. I percorsi del back office si applicano a PrestaShop 1.6, 1.7, 8 e 9.
Il Black Friday 2026 cade di venerdì 27 novembre, con il Cyber Monday il 30 novembre, quindi il picco di quattro giorni va dal 27 al 30 novembre, e il periodo migliore per prepararsi si apre a fine settembre. I negozi che ne escono meglio non sono quelli con gli sconti più aggressivi; sono quelli in cui l'installazione PrestaShop è stata sottoposta a test di carico, congelata e provata prima dell'arrivo della prima ondata di traffico. Questo è un conto alla rovescia settimana per settimana che puoi applicare a qualsiasi data cada il Black Friday. Nel 2026, ad esempio, è il 27 novembre, con cosa fare, quando farlo e dove intervenire esattamente nel back office di PrestaShop.
Il piano resta volutamente concentrato sul proprio scopo. Come costruire gli sconti, programmare le offerte lampo e recuperare i carrelli viene approfondito in altri articoli di questo gruppo. Questo post è la timeline che ti dice quando attivare ogni leva, con i passaggi specifici per PrestaShop che le guide di marketing danno spesso per già completati.
Il conto alla rovescia 2026 in sintesi
Ancora ogni attività al 27 novembre e lavora a ritroso. Le date qui sotto sono scadenze, non suggerimenti, la maggior parte dei problemi del giorno stesso nasce da un passaggio compresso nell'ultima settimana quando avrebbe avuto bisogno di margine.
| Finestra | Date (2026) | Priorità |
|---|---|---|
| 8 settimane prima | ~2 ott | Base tecnica: capacità, test di carico, configurazione delle prestazioni |
| 6 settimane prima | ~16 ott | Aggiorna tutto, poi pianifica il blocco delle modifiche |
| 4 settimane prima | ~30 ott | Crea & testa gli sconti in una copia di staging |
| Blocco del codice | 1 nov | Niente più modifiche a moduli/tema/core, salvo emergenze critiche |
| 2 settimane prima | ~13 nov | Programma le promozioni, prova tutto il flusso da cima a fondo |
| 1 settimana prima | ~20 nov | Magazzino, backup, monitoraggio, assistenza |
| Il fine settimana | 27–30 nov | Esegui il piano e controlla le dashboard |
8 settimane prima (inizio ottobre): metti a posto le fondamenta
Il traffico del Black Friday è spesso diverse volte superiore al volume normale. È un'indicazione, non una promessa, e le tue analisi dello scorso novembre sono l'unica base davvero onesta. Il motivo per cui si parte da qui è che capacità e prestazioni non possono essere sistemate in sicurezza nell'ultima settimana, perché ogni modifica rischia di introdurre un bug che poi non avresti il tempo di individuare.
Esegui un test di carico prima di ottimizzare
Non tirare a indovinare dove il negozio cede, misuralo. Strumenti come k6 o Loader.io possono simulare centinaia di utenti simultanei che visitano pagine di categoria, prodotto e procedura d'acquisto. Esegui il test su una copia di staging, non in produzione, e osserva dove i tempi di risposta iniziano a salire: un database che regge bene 20 utenti simultanei può andare in crisi a 300. Il flusso di pagamento (il controller order) è la pagina che non deve fallire, testalo in modo specifico, con prodotti che arrivano davvero fino alla order confirmation.
Attiva le impostazioni di prestazione già incluse in PrestaShop
La maggior parte di ciò che ti serve si trova nel back office in Parametri avanzati → Prestazioni. Non dare per scontato che sia già attiva, verifica ogni voce:
- Cache Smarty: imposta la cache su Sì e la compilazione dei template su "Non ricompilare mai". Ricompilare i template a ogni richiesta durante un picco di traffico consuma CPU che non puoi permetterti di sprecare.
- CCC (Combina, Comprimi, Cache): abilita "Cache intelligente per CSS" e "Cache intelligente per JavaScript" così il browser scarica meno file, e più leggeri. Dopo, testa il front office, il CCC a volte entra in conflitto con temi costruiti male, e vuoi scoprirlo ora, non il 27 novembre.
- OPcache: conferma che sia davvero funzionante, non soltanto installato. Verificane lo stato con gli strumenti del tuo hosting/server o con una pagina di stato
phpinfo/OPcache, invece di affidarti solo alla schermata Prestazioni di PrestaShop; se è disattivato, una modifica lato server non avrà effetto finché non lo svuoti. Verifica, poi lascialo stare. - Cache (Redis/Memcached): nella sezione "Cache" della stessa pagina puoi indirizzare la cache di PrestaShop verso Redis o Memcached se il tuo hosting lo offre. Anche se, a seconda della versione, spesso servono configurazioni server o di modulo per farla funzionare. È una delle leve più importanti quando il database è sotto pressione per molti carrelli simultanei. Spostare le sessioni fuori dal disco è un lavoro separato: si configura a livello server/PHP (o tramite un modulo), non con questa impostazione di cache.
Riduci anche il peso dei media: le immagini prodotto sovradimensionate sono il killer più silenzioso della velocità di pagina quando migliaia di persone navigano nello stesso momento. Comprimile e portale alle dimensioni corrette ora, mentre hai ancora tempo per controllare i risultati.
6 settimane prima (metà ottobre): aggiorna, poi preparati al blocco
Aggiorna adesso il core di PrestaShop, tutti i moduli e il tema, non la settimana prima. Gli aggiornamenti possono introdurre comportamenti inattesi, e il motivo per farli sei settimane prima è proprio guadagnare settimane di margine per intercettare e correggere eventuali rotture. Esegui prima gli aggiornamenti su una copia di staging, prova la procedura di pagamento e un ordine di test, poi porta tutto in produzione.
La disciplina più importante è questa: pianifica un blocco rigoroso del codice per il 1 novembre. Dopo quella data, niente installazioni di moduli, niente modifiche al tema, niente cambiamenti al core, salvo problemi davvero critici. Ogni "ritocchino veloce" a novembre è un'occasione per rompere la procedura di acquisto nel momento in cui hai meno tempo per accorgertene. Comunica in anticipo la data di blocco a chiunque abbia accesso al back office, così non sarà una sorpresa.
4 settimane prima (fine ottobre): crea e testa gli sconti in staging
È qui che molti commercianti confondono due lavori diversi. Progettare l'offerta, quanto sconto applicare, percentuale o importo fisso, livelli, pacchetti, è una questione strategica trattata in come gestire una promozione in PrestaShop: regole carrello, prezzi specifici e strategie di sconto, mentre la regola pratica per proteggere il margine è in esclusione dagli sconti: perché alcuni prodotti non dovrebbero mai essere messi in promozione. Quello che appartiene qui, nella checklist, è il passaggio di preparazione: costruire ciò che hai deciso, in una copia di staging, e dimostrare che si applica correttamente prima che tocchi un carrello reale.
In PrestaShop hai due meccanismi: Catalogo → Sconti → Regole carrello (buoni sconto, condizioni, codici automatici) e Catalogo → Sconti → Regole prezzi catalogo / Prezzi specifici per prodotto (un prezzo barrato mostrato direttamente sulla scheda prodotto). Da verificare con carrelli di test reali:
- Lo sconto si applica davvero ai prodotti previsti, e non a quelli che hai escluso.
- Gli sconti non si sommano in modi che cancellano il margine. Una regola carrello più una regola prezzo catalogo più una riduzione per gruppo cliente possono combinarsi in silenzio.
- Le soglie per la spedizione gratuita e le condizioni di importo minimo del carrello scattano alla cifra corretta, tasse incluse quando il tuo negozio le mostra.
- I campi "Quantità disponibile" e le date di una regola carrello si comportano come previsto, un buono che si esaurisce o scade a metà fine settimana diventa subito un problema per l'assistenza.
I bug sugli sconti durante il Black Friday sono costosi e imbarazzanti in egual misura. La soluzione è noiosa: testarli quattro settimane prima, in staging, con una checklist.
Decidi cosa parte con un timer e cosa resta manuale
Non vuoi modificare i prezzi a mano alle 6 del mattino del 27. Le regole carrello e i prezzi specifici di PrestaShop includono entrambi intervalli di date "da / a", quindi un'offerta può essere configurata settimane prima e andare online all'orario previsto senza interventi. Per la parte pratica di far partire e fermare le promozioni da sole, e per le insidie dei fusi orari del server, vedi sconti programmati: configurare promozioni che iniziano e finiscono automaticamente. Se il piano prevede offerte a rotazione durante il fine settimana invece di una promozione statica, l'automazione è trattata in preparazione al Black Friday: automatizzare sconti e promozioni in PrestaShop, e il nostro modulo Sales Revolution gestisce offerte lampo programmate così la rotazione procede senza doverla sorvegliare. Il modo corretto di usare le leve dell'urgenza (timer alla rovescia, "fino a esaurimento scorte") è spiegato in vendite lampo: creare urgenza senza essere manipolativi.
2 settimane prima (metà novembre): programma, fai una prova completa e prepara i flussi di dati
Con il blocco attivo e gli sconti testati, queste due settimane servono a programmare e provare, non a costruire.
- Imposta le date di pubblicazione. Inserisci l'inizio al 27 nov e la fine al 30 nov (o 1 dic) su ogni regola carrello e prezzo specifico. Ricontrolla il fuso orario del negozio in Internazionale → Localizzazione → Localizzazione, un'offerta impostata per "mezzanotte" scatta sull'ora del server, che potrebbe non coincidere con la mezzanotte dei tuoi clienti.
- Crea la destinazione di atterraggio. Una categoria dedicata al Black Friday o una pagina CMS è il punto in cui far arrivare il traffico da email e annunci. Creala ora (puoi tenerla non indicizzata o non pubblicata fino al lancio, se preferisci), così il giorno stesso dovrai solo attivarla, non costruirla sotto pressione.
- Banner senza designer. Le grafiche hero/promozionali che annunciano la vendita non richiedono un'agenzia creativa, vedi banner revolution: creare promozioni d'impatto senza designer.
- Flusso di dati per Google Merchant Center. Se usi annunci Shopping, valorizza gli attributi
sale_priceesale_price_effective_datecosì Google mostra il prezzo barrato durante la finestra promozionale. Invialo in anticipo; la rielaborazione del flusso di dati non è immediata. - Prova completa. Percorri l'intero viaggio come cliente: arrivo sulla pagina Black Friday, aggiunta di un prodotto scontato, applicazione di un buono se usi codici, conferma dell'ordine. Poi rifallo da telefono. Questa singola prova intercetta più problemi reali di qualsiasi voce della checklist.
1 settimana prima (~20 novembre): prontezza operativa
Il codice è congelato e testato; ora assicurati che l'azienda dietro al negozio possa reggere.
- Magazzino. Verifica le giacenze in Catalogo → Scorte per tutto ciò che stai promuovendo. Vendere oltre disponibilità e poi annullare gli ordini danneggia la fiducia più a lungo di una vendita mancata. Decidi in modo consapevole il comportamento per i prodotti esauriti (negare / consentire il riordino) prodotto per prodotto.
- Backup. Esegui un backup completo di database e file il giorno prima, e conferma di poterlo davvero ripristinare. Un backup mai testato è una speranza, non una rete di sicurezza. Parametri avanzati → Database → Backup DB di PrestaShop copre il database; il tuo hosting o una routine dedicata dovrebbe coprire i file.
- Monitoraggio. Punta un monitor di uptime (UptimeRobot, Pingdom) sulla homepage e su una pagina profonda come la procedura di acquisto, così vieni avvisato in pochi minuti se il sito inciampa, non quando ti scrive un cliente.
- Assistenza & spedizione. Conferma le date limite dei corrieri e pianifica una copertura di assistenza estesa. Prepara in anticipo le risposte alle domande prevedibili: "il mio codice funziona?", "quando arriverà?", "qual è la politica di reso?". Impostare aspettative di consegna realistiche durante la procedura di pagamento è esattamente lo scopo di una visualizzazione automatica della consegna stimata.
Il fine settimana stesso (27–30 novembre): esegui e monitora
Se hai fatto il lavoro sopra, il fine settimana è soprattutto osservazione. Le offerte programmate partono da sole; il tuo compito è intercettare rapidamente le anomalie.
- Conferma che le offerte siano partite. Per prima cosa il 27, apri il front office come cliente e verifica che i prezzi scontati siano effettivamente visibili. Un errore di fuso orario è il classico panico delle 6 del mattino.
- Guarda le dashboard giuste. Tieni d'occhio carico del server, tassi di errore e completamento della procedura di acquisto. In Google Analytics 4, controlla le conversioni in tempo reale. Un calo improvviso di solito significa che qualcosa si è rotto, non che la domanda sia sparita.
- Mantieni onesti i tempi di risposta. Se il carico sale, hai il margine che hai costruito a ottobre. Resisti alla tentazione di "installare al volo un modulo di cache" durante il fine settimana. È proprio il tipo di modifica che il blocco doveva impedire.
- Recupera ciò che si disperde. Anche un fine settimana impeccabile perde qualche carrello. Le sequenze per il recupero dei carrelli abbandonati e il follow-up post-acquisto che ne riconquistano una parte vale la pena averle pronte, e sono una campagna, non una voce di checklist, quindi pianificale dentro il tuo più ampio calendario delle promozioni stagionali.
Dopo il fine settimana: raccogli ciò che hai imparato
Il Black Friday non è un evento isolato. È l'apertura rumorosa di una stagione che continua fino a Natale e arriva alla pianificazione del nuovo anno. Prima che la polvere si posi, annota i numeri mentre sono ancora freschi: quali prodotti hanno venduto, quali canali hanno generato ricavi, dove il negozio è andato sotto pressione e quale meccanica di sconto ha mosso davvero gli ordini. Quel documento è il vantaggio di partenza del prossimo anno, ed è così che un primo Black Friday caotico diventa un processo calmo e ripetibile.
Lo schema di fondo è lo stesso ogni anno: la vittoria si costruisce nelle settimane precedenti, in staging, sotto test di carico, dietro un blocco del codice. La data del 2026 è fissata al 27 novembre. Tutto il resto consiste solo nel lavorare a ritroso da lì, con abbastanza margine per correggere ciò che trovi.
Domande frequenti
Qual è la data del Black Friday 2026 e quando dovrei iniziare?
Il Black Friday 2026 è venerdì 27 novembre; il Cyber Monday è il 30 novembre. Lavora a ritroso: fondamenta tecniche e test di carico circa 8 settimane prima (inizio ottobre), aggiornamenti entro 6 settimane prima, sconti creati e testati in staging entro 4 settimane prima, blocco del codice il 1 novembre, programmazione e prove complete due settimane prima, e prontezza operativa (scorte, backup, monitoraggio) nella settimana del 20 novembre.
Un'offerta che avevo programmato per "mezzanotte" è partita all'ora sbagliata. Perché?
PrestaShop valuta il "valido da / fino a" della regola carrello rispetto al fuso orario del negozio, impostato in Internazionale → Localizzazione → Localizzazione, cioè l'ora del server, non necessariamente la mezzanotte locale dei tuoi clienti. Controlla questa impostazione prima del fine settimana e inserisci le date tenendo conto dello scostamento. Questo errore di fuso orario è il classico panico delle 6 del mattino del 27.
Devo creare gli sconti in produzione o su una copia di staging?
In staging, sempre. Crea gli sconti e dimostra che si applicano correttamente, e che non si applicano ai prodotti esclusi, prima su una copia, poi porta in produzione la configurazione testata. Anche i test di carico dovrebbero girare su staging, non sul negozio in produzione, così una prova con centinaia di procedure di acquisto simultanee non blocca il traffico reale.
Posso installare un modulo di cache durante il fine settimana se il sito rallenta?
No. È esattamente ciò che il blocco del codice serve a evitare. Un nuovo modulo durante il picco di traffico è la modifica più rischiosa che puoi fare, con il minor tempo possibile per intercettare una regressione nella procedura di acquisto. Costruisci il margine a ottobre. Se il carico sale il giorno stesso, affidati alla cache e alla capacità che hai già testato, controlla il completamento della procedura di acquisto e resisti alla "correzione veloce."
Mi serve uno storage separato per le sessioni se sposto la cache su Redis?
Sì. Sono due lavori diversi. Puntare la cache oggetti di PrestaShop su Redis o Memcached (in Parametri avanzati → Prestazioni → Cache) riduce il carico del database su disco, ma spostare le sessioni PHP fuori dal filesystem si configura separatamente a livello server/PHP o tramite un modulo. Sistemarne uno non sistema l'altro; pianifica entrambi se la tua concorrenza lo richiede.
