Black Friday su PrestaShop: il prezzo barrato che rispetta la regola dei 30 giorni

Il prezzo barrato che PrestaShop mostra sulla scheda è sempre il prezzo del prodotto senza riduzioni. Non è il prezzo più basso degli ultimi 30 giorni, che è quello che la legge chiede di indicare quando annunci uno sconto: l’ho verificato nel codice del core e dei due temi ufficiali, e PrestaShop non tiene nemmeno uno storico dei prezzi da cui ricavarlo. Finché un prodotto non è mai stato scontato nel mese prima, le due cifre coincidono e non c’è niente da fare. Se invece hai fatto una promo a fine ottobre o per il Singles Day dell’11 novembre, il barrato del Black Friday del 27 novembre su quei prodotti è sbagliato.

⚠️ Cosa chiede la regola dei 30 giorni

La norma è l’art. 17-bis del Codice del consumo, introdotto dal D.Lgs. 26/2023 che recepisce la direttiva Omnibus. Due commi fanno tutto il lavoro. Il primo: “ogni annuncio di riduzione di prezzo indica il prezzo precedente”. Il secondo: per prezzo precedente si intende “il prezzo più basso applicato dal professionista alla generalità dei consumatori nei trenta giorni precedenti all’applicazione della riduzione”.

Il prezzo barrato è un annuncio di riduzione, e anche il “Risparmia” in euro o il “-20%” lo sono: la percentuale si calcola sul prezzo precedente, non sul listino. Le FAQ del Ministero delle Imprese lo dicono anche per il cartellino col prezzo barrato, e aggiungono che il prezzo precedente è quello “sul quale calcolare la riduzione percentuale”. Le linee guida della Commissione europea chiudono il caso che riguarda novembre: il prezzo più basso dei 30 giorni “deve includere gli eventuali prezzi precedenti ridotti praticati in quel periodo” (sezione 2.1). L’esempio della sezione 4.3 è proprio Singles Day, Black Friday e Cyber Monday uno dopo l’altro: per la seconda e la terza campagna il prezzo precedente è quello scontato della campagna prima.

C’è un’eccezione che conviene conoscere, al comma 5: se lo sconto cresce durante una stessa campagna, senza interruzioni, il prezzo precedente resta quello di prima della prima riduzione. Una “Black Week” dal 20 al 30 novembre che parte dal -10% e arriva al -30% si confronta sempre con il prezzo del 19 novembre. Due promo separate da una settimana a prezzo pieno no.

Che non sia teoria lo dice l’Antitrust: il 17 novembre 2025 l’AGCM ha sanzionato Tannico con 150.000 euro per prezzi presentati come promozionali che erano uguali o superiori al prezzo più basso dei 30 giorni precedenti.

🛠️ Cosa barra davvero PrestaShop

Il prezzo barrato nei temi ufficiali è la variabile regular_price. Nel tema Classic sta in product-prices.tpl, dentro un {if $product.has_discount}; in Hummingbird è lo stesso, con un’altra classe CSS. Da dove arriva quel valore lo dice il presenter del prodotto, ProductLazyArray.php nel ramo 8.2.x. Ecco le righe che contano, nel caso dei prezzi con IVA (quello senza IVA è identico con le varianti _tax_exc):

$price = $regular_price = $product['price'];
if ($product['specific_prices']) {
    $this->product['has_discount'] = (0 != $product['reduction']);
    $regular_price = $product['price_without_reduction'];
    $product['reduction'] = $regular_price - $price;
}
$this->product['regular_price'] = $this->priceFormatter->format($regular_price);

price_without_reduction è il prezzo del prodotto prima di prezzi specifici e regole catalogo. Il core non ha altro da mettere al suo posto: nello schema del database di sviluppo le tabelle sui prezzi sono quelle dei prezzi specifici e delle regole catalogo, nessuna registra lo storico, e fra le issue del progetto non ne ho trovata nessuna sulla direttiva Omnibus. I moduli che aggiungono il “prezzo più basso degli ultimi 30 giorni” esistono, sono di terze parti e, almeno quelli che ho guardato, cominciano a registrare i prezzi dal giorno in cui li installi.

Il controllo l’ho fatto anche sul campo, il 6 novembre, su quattro schede in sconto di due negozi PrestaShop che seguo, uno con un 8.2.0. Su tutte e quattro il barrato è il regular-price del core, accanto a un “-20%” o a un “Risparmia” in euro, e nell’HTML non c’è nessuna indicazione su quale prezzo sia: nessuna dicitura sui 30 giorni, nessun “prezzo precedente”. Questo non vuol dire che quei negozi siano fuori regola. Vuol dire che lo sono solo se quei prodotti avevano un prezzo più basso nel mese prima, e che il negozio da solo non lo sa.

⚠️ I tre casi in cui il barrato del 27 novembre è sbagliato

1. Il prodotto era già in promo dopo il 28 ottobre. Uno sconto per Halloween, il Singles Day, un prezzo specifico di prova lasciato attivo per una settimana: il prezzo precedente del Black Friday diventa quello scontato, e PrestaShop continua a barrare il prezzo pieno. È il caso più frequente e quello del provvedimento Tannico.
2. Il prezzo pieno è stato alzato nelle ultime settimane. Un aggiornamento listino a inizio novembre, magari per un aumento vero del fornitore, sposta in alto il regular_price. Se il prodotto era venduto a meno nei 30 giorni prima dello sconto, il barrato è più alto del prezzo precedente, e lo sconto mostrato è più grande di quello reale.
3. Due campagne di novembre staccate. Black Friday e Cyber Monday con il weekend a prezzo pieno in mezzo sono due campagne, non una che cresce: per il 30 novembre il prezzo precedente è quello del 27. Se il Cyber Monday mostra di nuovo il barrato pieno, lo sconto annunciato è gonfiato.

✅ Il controllo da fare prima del 20 novembre

Il punto di partenza è la tabella dei prezzi specifici, dove PrestaShop salva sia gli sconti messi a mano sul prodotto sia quelli generati dalle regole catalogo. Questa query elenca le riduzioni ancora attive o finite dopo il 28 ottobre, cioè quelle che cadono nella finestra dei 30 giorni prima del Black Friday (prefisso ps_, lingua e negozio 1: adattali al tuo):

SELECT sp.id_product, pl.name, sp.reduction, sp.reduction_type,
       sp.`from`, sp.`to`, sp.id_specific_price_rule
FROM ps_specific_price sp
JOIN ps_product_lang pl
  ON pl.id_product = sp.id_product AND pl.id_lang = 1 AND pl.id_shop = 1
WHERE sp.id_cart = 0 AND sp.id_customer = 0 AND sp.id_group = 0
  AND (sp.`to` = '0000-00-00 00:00:00' OR sp.`to` >= '2026-10-28')
  AND sp.`from` < '2026-11-27';

Ha un limite da sapere: la tabella dice cosa c’è oggi, non cosa c’è stato. Un prezzo specifico cancellato a mano o una regola catalogo eliminata non lasciano traccia. Per questo la fonte più affidabile è un backup del database di fine ottobre, che quasi ogni hosting tiene: confrontare il prezzo dei prodotti del Black Friday in quel backup con quello di oggi risolve anche il secondo caso, il listino alzato. Gli ordini sono il terzo segnale: in ps_order_detail ogni riga conserva il prezzo unitario a cui il prodotto è stato venduto, quindi il prezzo più basso venduto dal 28 ottobre è un indizio rapido. Solo un indizio, perché dentro ci sono anche gli sconti per gruppo di clienti, che non sono prezzi “alla generalità dei consumatori”.

✅ Cosa fare sui prodotti che non passano il controllo

Le strade sono due, e su un negozio vero di solito si usano tutte e due.

1. Niente annuncio di sconto su quei prodotti. La regola vale per gli annunci di riduzione, non per i prezzi bassi. Se su un prodotto non puoi mostrare il prezzo precedente corretto, abbassane il prezzo base per il periodo della promo invece di creare un prezzo specifico: PrestaShop non mostra barrato né percentuale, e il prodotto può comunque stare nella pagina del Black Friday. È la soluzione più sicura quando la lista è corta.
2. Un barrato con il prezzo precedente vero. Serve un modulo che registri lo storico e mostri il prezzo più basso dei 30 giorni accanto al prezzo, e va installato adesso: calcola il minimo solo da quando è attivo, quindi messo oggi il 27 novembre avrà 21 giorni di storico, e per i prodotti scontati fra il 28 ottobre e oggi il dato va corretto a mano. Installato il 25 novembre, a questo Black Friday non serve. Quale scegliere lo decidi con le domande della sezione qui sotto.

In tutti e due i casi c’è una cosa da ricalcolare: la percentuale. Se a fine ottobre un prodotto da 100 EUR era in promo a 80, il -20% del Black Friday si calcola su 80 e porta il prezzo a 64. Una regola catalogo al -20% su PrestaShop lo porta a 80, cioè allo stesso prezzo di un mese fa, presentato come uno sconto.

⚠️ Cosa controllare in un modulo Omnibus prima di installarlo

Cerca “omnibus prestashop” su Google e trovi solo moduli, gratuiti e a pagamento. Ho letto il codice di quello gratuito più visibile su GitHub, dc_ps_omnibus (versione 3.3.0, ultimo commit a luglio 2026), perché è l’unico che si può aprire senza comprarlo. Sul piano della sicurezza è piccolo e pulito: nessuna query SQL, nessun controller, nessuna chiamata esterna. Sui prezzi ha quattro limiti, e sono le stesse domande da fare a qualunque altro modulo:

1. Da quando registra? Parte vuoto all’installazione e annota un prezzo solo quando salvi il prodotto o un suo prezzo specifico. Nessun modulo può inventarsi lo storico di prima, a meno di importarlo da un backup.
2. Cosa mostra quando non ha dati? Qui restituisce il prezzo pieno attuale, cioè lo stesso numero del barrato del core, presentato però come “prezzo più basso degli ultimi 30 giorni”. Senza storico è un’affermazione che nessuno ha verificato, scritta in pagina.
3. Esclude lo sconto in corso? Il prezzo precedente è quello di prima della riduzione. Un modulo che mette nel conto anche il prezzo scontato di oggi rischia di mostrare come “prezzo più basso” lo stesso prezzo della promo.
4. Vede le regole catalogo e i gruppi di clienti? Questo non ha hook sulle regole catalogo, che su molti negozi sono il modo in cui si fa il Black Friday, e calcola un solo prezzo, senza distinguere gruppo, paese o valuta.

Ci sono poi due dettagli di installazione: lo storico finisce in file di testo dentro una cartella del modulo creata con permessi 0777 e protetta da un .htaccess che nginx ignora, e la frase mostrata in pagina è fissa in polacco. Se un modulo a pagamento risponde bene alle quattro domande, vale quello che costa. Se non risponde, mostra un numero in più, non un numero giusto.

🛠️ Pagine, dati strutturati e feed: quello che vede Google

La pagina del Black Friday deve sopravvivere al Black Friday. Una categoria o una pagina CMS con un indirizzo senza anno, tipo /black-friday, riusata ogni novembre, accumula link e storico; /black-friday-2026 che va in 404 a dicembre li butta. Finita la promo la pagina resta online con un testo che rimanda all’anno dopo e alle offerte del momento, e i prodotti usciti di catalogo per sempre restituiscono 410, non un redirect alla home.

I dati strutturati del core non conoscono il prezzo barrato. Nel JSON-LD del tema Classic l’Offer porta come prezzo solo quello finale, senza priceSpecification né prezzo barrato, e priceValidUntil è calcolato come oggi più 15 giorni, a prescindere dalla data di fine dello sconto. I due negozi che ho controllato usano temi di terze parti con i microdata, e lì priceValidUntil vale 31 dicembre 2026 su uno e 31 dicembre 2999 sull’altro: in nessuno dei due casi coincide con la fine della promo. Google per le schede prodotto accetta il prezzo pieno come priceSpecification con priceType StrikethroughPrice, ma vale la stessa regola della pagina: se lo aggiungi, il valore deve essere il prezzo precedente corretto, non il listino. Sul peso reale del markup nel posizionamento ho già raccontato il mio test sullo schema markup: qui conta la coerenza, non il ranking.

Il feed Merchant Center ha regole sue. Il prezzo scontato va in sale_price, con le date in sale_price_effective_date così lo sconto parte e finisce da solo. Per mostrare il prezzo barrato negli annunci Shopping in Italia, Google chiede che il prezzo base sia stato valido per almeno 30 giorni negli ultimi 200, che lo sconto stia fra il 5% e il 90% e che prezzo pieno e scontato compaiano entrambi sulla pagina di destinazione. È un controllo diverso da quello di legge e non lo sostituisce. Se il tuo feed vende su più paesi, la parte sui prezzi per mercato l’ho descritta nel pezzo sul feed Google Merchant multi-paese.

E il sito deve reggere il picco. Il giorno in cui arrivano più visite dell’anno non è il giorno per aggiornare moduli o tema: il blocco delle modifiche una settimana prima è una regola che conviene darsi. Cache, immagini e tempi di risposta li ho messi in fila nel pezzo sulle performance PrestaShop e Core Web Vitals.

✅ Prima del 27 novembre

Fai la lista dei prodotti del Black Friday, passala nella query e nel backup di fine ottobre, e dividila in due: quelli senza prezzi più bassi nel mese prima, dove il barrato di PrestaShop è giusto così com’è, e quelli con una promo recente, dove togli l’annuncio di sconto o lo mostri sul prezzo precedente vero. Il resto delle regole sugli sconti e sulle recensioni l’ho raccolto nel pezzo sulle nuove regole per chi vende online, e se il negozio ha bisogno di una mano sul tema, sui prezzi o sul feed è il lavoro che faccio come tecnico PrestaShop. Se vuoi che il controllo lo faccia io, scrivimi o usa uno dei canali qui sotto.