Black Friday 2026: Your PrestaShop Preparation Checklist

Black Friday 2026 lands on Friday, 27 November, with Cyber Monday on 30 November — so the four-day surge runs 27–30 November, and the smart preparation window opens in late September. The stores that come out ahead aren't the ones with the deepest discounts; they're the ones whose PrestaShop install was load-tested, frozen, and rehearsed before the first wave of traffic arrived. This is a week-by-week prep countdown you can run against whichever Friday Black Friday falls on — in 2026, for example, that's 27 November — covering what to do, when to do it, and exactly where in the PrestaShop back office to do it.

The plan deliberately stays in its lane. How to build the discounts, schedule the flash deals, and recover the carts each gets its own deep treatment elsewhere in this cluster — this post is the timeline that tells you when to pull each lever, with the PrestaShop-specific readiness steps that the marketing guides assume you've already handled.

The 2026 countdown at a glance

Anchor every task to 27 November and work backwards. The dates below are the deadlines, not suggestions — most failures on the day trace back to a step that got compressed into the final week when it needed a buffer.

8 weeks out (early October): get the foundation right

Black Friday traffic commonly runs several times your normal volume — directional, not a promise, and your own analytics from last November are the only honest baseline. The point of starting here is that capacity and performance work cannot be rushed safely in the final week, because every change risks introducing a bug you then have no time to catch.

Load-test before you optimise

Don't guess where your store breaks — measure it. Tools like k6 or Loader.io can simulate hundreds of concurrent users hitting your category, product and checkout pages. Run the test against a staging copy, not production, and watch where response times climb: a database that's fine at 20 concurrent users can fall over at 300. The checkout flow (the order controller) is the page that must not fail — load-test it specifically, with items actually moving through to order confirmation.

Turn on the performance settings PrestaShop already ships

Most of what you need is in the back office under Advanced Parameters → Performance. Don't assume it's on — verify each one:

• Smarty cache: set caching to Yes and template compilation to "Never recompile". Recompiling templates on every request during a traffic spike is wasted CPU you can't spare.
• CCC (Combine, Compress, Cache): enable "Smart cache for CSS" and "Smart cache for JavaScript" so the browser pulls fewer, smaller files. Test the front office afterwards — CCC occasionally fights a poorly-built theme, and you want to find that now, not on 27 November.
• OPcache: confirm it's actually working, not just installed. Verify its status with your hosting/server tools or a phpinfo/OPcache status page rather than relying on the PrestaShop Performance screen; if it's off, a server change won't take effect until you clear it. Verify, then leave it alone.
• Caching (Redis/Memcached): under "Caching" on the same page, you can point PrestaShop's cache at Redis or Memcached if your host offers it — though depending on your version this often needs server or module configuration to work. This is one of the biggest levers for a database that's straining under concurrent carts. Moving sessions off disk is a separate job: it's configured at the server/PHP level (or via a module), not through this caching setting.

Also flatten your media: oversized product images are the quietest page-speed killer when thousands of people browse at once. Compress and right-size them now while you have time to spot-check the results.

6 weeks out (mid-October): update, then prepare to freeze

Update PrestaShop core, every module, and your theme now — not the week before. Updates can introduce unexpected behaviour, and the whole reason to do it six weeks out is to buy yourself weeks of buffer to catch and fix anything that breaks. Do the updates on a staging copy first, click through checkout and a test order, then promote to production.

The discipline that matters most: plan a hard code freeze for 1 November. After that date, no module installs, no theme edits, no core changes unless something is genuinely on fire. Every "quick tweak" in November is a chance to break checkout when you have the least time to notice. Tell anyone with back-office access the freeze date in advance so it isn't a surprise.

4 weeks out (late October): build and test the discounts in staging

This is where merchants conflate two different jobs. Designing the offer — how deep, percentage vs. fixed, tiered, bundled — is a strategy question covered in running a sale in PrestaShop: cart rules, specific prices and discount strategies, and the rule of thumb on protecting margin is in discount exclusion: why some products should never go on sale. What belongs here, on the checklist, is the readiness step: build whatever you've decided on, in a staging copy, and prove it applies correctly before it ever touches a live cart.

In PrestaShop, your two mechanisms are Catalog → Discounts → Cart Rules (vouchers, conditions, automatic codes) and Catalog → Discounts → Catalog Price Rules / per-product Specific Prices (a struck-through price shown directly on the product). The thing to verify, with real test carts:

• The discount actually applies to the products you intend — and not to the ones you've excluded.
• Discounts don't stack in ways that wipe your margin. A cart rule plus a catalog price rule plus a customer-group reduction can compound silently.
• Free-shipping thresholds and minimum-cart conditions trigger at the right amount, including with taxes where your store shows them.
• The "Available quantity" and date fields on a cart rule behave as expected — a voucher that runs out or expires mid-weekend is a support headache.

Discount bugs during Black Friday are expensive and embarrassing in equal measure. The fix is boring: test them four weeks out, in staging, with a checklist.

Decide what runs on a timer vs. by hand

You do not want to be manually flipping prices at 6 AM on the 27th. PrestaShop's cart rules and specific prices both carry "from / to" date ranges, so a deal can be configured weeks ahead and go live on schedule untouched. For the mechanics of making promotions start and stop on their own — and the gotchas with server time zones — see scheduled discounts: setting up promotions that start and stop automatically. If your plan involves rotating deals across the weekend rather than one static sale, the automation side is covered in Black Friday prep: automating discounts and promotions, and our own Sales Revolution module handles scheduled flash deals so the rotation runs without you babysitting it. The honest framing on urgency tactics — countdown timers, "while stocks last" — is in flash sales: creating urgency without being manipulative.

2 weeks out (mid-November): schedule, dry-run, and prep the feeds

With the freeze in place and discounts tested, this fortnight is about scheduling and rehearsal rather than building.

• Set the go-live dates. Enter the 27 Nov start and the 30 Nov (or 1 Dec) end on every cart rule and specific price. Double-check the store's time zone under International → Localization → Localization — a deal set for "midnight" fires on server time, which may not be your customers' midnight.
• Build the landing destination. A dedicated Black Friday category or CMS page is where your email and ad traffic lands. Create it now (set it un-indexed or unpublished until launch if you prefer), so on the day you're flipping a switch, not building under pressure.
• Banners without a designer. The hero/promo graphics that announce the sale don't need a design agency — see banner revolution: creating eye-catching promotions without a designer.
• Google Merchant Center feed. If you run Shopping ads, populate the sale_price and sale_price_effective_date attributes so Google shows the struck-through price during the window. Submit early; feed re-processing isn't instant.
• Full dry-run. Walk one complete journey as a customer: land on the Black Friday page, add a discounted product, apply a voucher if you're using codes, reach order confirmation. Then do it again on a phone. This single rehearsal catches more real problems than any checklist item.

1 week out (~20 November): operational readiness

The code is frozen and tested; now make sure the business behind it can cope.

• Inventory. Verify stock levels under Catalog → Stocks for everything you're promoting. Overselling and then cancelling orders does more lasting damage to trust than missing a sale. Decide your out-of-stock behaviour (deny / allow back-order) per product deliberately.
• Backups. Take a full database and file backup the day before, and confirm you can actually restore it. A backup you've never tested is a hope, not a safety net. PrestaShop's Advanced Parameters → Database → DB Backup covers the database; your host or a dedicated routine should cover files.
• Monitoring. Point an uptime monitor (UptimeRobot, Pingdom) at your homepage and a deep page like checkout, so you're alerted in minutes if the site stumbles — not when a customer emails you.
• Support & shipping. Confirm carrier cut-off dates and plan extended support cover. Pre-write answers for the predictable questions: "is my code working?", "when will it arrive?", "what's the return policy?". Setting realistic delivery expectations at checkout is exactly what an automated estimated-delivery display is for.

The weekend itself (27–30 November): execute and watch

If you've done the work above, the weekend is mostly observation. Your scheduled deals go live on their own; your job is to catch anomalies fast.

• Confirm the deals fired. First thing on the 27th, load the front office as a customer and verify the discounted prices are actually showing. A timezone slip is the classic 6 AM panic.
• Watch the right dashboards. Keep an eye on server load, error rates, and checkout completion. In Google Analytics 4, watch real-time conversions — a sudden drop usually means something broke, not that demand vanished.
• Keep response times honest. If load creeps up, you have the headroom you built in October. Resist the urge to "just install a quick caching module" mid-weekend — that's exactly the change the freeze was meant to prevent.
• Recover what leaks. Even a flawless weekend loses some carts. The abandoned-cart and post-purchase follow-up sequences that win a share back are worth having ready — and they're a campaign, not a checklist item, so plan them as part of your wider seasonal promotions calendar.

After the weekend: capture what you learned

Black Friday isn't a standalone event — it's the loud opening of a season that runs through Christmas and into New Year planning. Before the dust settles, write down the numbers while they're fresh: which products sold, which channels drove revenue, where the store strained, and which discount mechanic actually moved orders. That document is next year's head start — and it's how a chaotic first Black Friday becomes a calm, repeatable one.

The pattern underneath all of it is the same every year: the winning is done in the weeks before, in staging, under load test, behind a code freeze. The 2026 date is fixed at 27 November. Everything else is just working backwards from it with enough buffer to fix what you find.