To prepare a WooCommerce store for Black Friday you start with the technical side, not the discounts. Banners, coupon codes and the mailing can be done in a week, but if the checkout stops taking payments on Friday morning, none of them will help. In 2026 Black Friday falls on 27 November and Cyber Monday on 30 November - four days in which the store gets more traffic than usual and in which every hour of downtime hurts the most.
This article is the checklist I go through with stores before the season. It is not about marketing. It is about making sure the store survives the sale: backups, code changes, speed, payments, emails and on-call cover. The order matters, because some of these points have to be closed weeks in advance.
When to start preparing for Black Friday
Ideally about five weeks before the sale, which means the second half of October. That is enough time to make bigger fixes, test them calmly and leave room for whatever turns up along the way.
The schedule that works for me:
| When | What |
|---|---|
| 5 weeks before | store review: versions, plugins, backups, speed, list of fixes |
| 3-4 weeks before | fixes and updates, each one followed by a purchase test |
| 2 weeks before | change freeze, last full backup with a restore test |
| 1 week before | test purchase with every payment and shipping method, coupon codes on a copy |
| sale day | monitoring, someone on call, no new plugins and no updates |
If you are reading this a week before Black Friday, do not try to do everything at once. Take a backup, test a purchase and leave the big changes for December. Fewer last-minute fixes means less risk.
A backup you know how to restore
The pre-season backup has to cover files and the database, sit outside the store’s server and be proven by a test restore. A backup nobody has ever restored is only a hope that it will work.
In a store the database changes with every order, so the backup rhythm matters too. A week-old backup restored on the Sunday after Black Friday means losing every order from Friday and Saturday. That is why during the season the database should be backed up more often than usual, and the restore has to be rehearsed on a copy of the store, not on production. What to back up, where to keep it and how to check the restore is covered in the piece on WooCommerce store backups.
Before the season I check three things:
- whether the database and file backups run on their own and land outside the store’s server,
- how long a full restore takes on a copy and whether the checkout works after it,
- who has access to the backups and to the hosting panel when the owner cannot be reached.
A change freeze two weeks before the sale
A change freeze means that from an agreed day you stop updating plugins, changing the theme and shipping new features until the sale is over. The only exception is security patches, applied with a backup and a test.
It is the simplest point on the checklist and the one broken most often. The usual story: a week before Black Friday someone installs a new countdown plugin for the sale or updates the theme because a new version came out. The home page looks fine, but the cart starts behaving differently or more slowly. In the middle of the season there is no time to find out why.
So I do all updates three to four weeks before the sale, one at a time and with a checkout test after each, exactly as in the safe WooCommerce updates checklist. After the freeze the store stays in a state that has been tested. New ideas go on a list for December.
Store speed under heavier traffic
A store that is slow under normal traffic will be even slower during a sale, because the server handles more carts and orders at the same time. Measure and improve speed before the change freeze, not in the week of the sale.
Most of the load in the season comes from pages that cannot be served from cache: the cart, the checkout, the customer account and search. A product page can be fast while the checkout still crawls, if the server has no headroom or the database is cluttered. My checklist covers:
- measuring the home page, a category, a product and the checkout on a phone, since that is where most of the traffic is,
- checking that the cache does not cover the cart and checkout (otherwise shoppers see someone else’s cart or an empty one),
- reviewing plugins that load on every page even though only one page needs them,
- talking to the host about limits: how many PHP processes, what memory limit, whether the plan can be raised for December.
Optimisation brings measurable results. At Złota Faza my work took the Lighthouse Performance score from 38 to 100 (desktop, measured 30-05-2026). That kind of work is not done in the week of the sale, though - it belongs in October, before the freeze. If the store is slow and you do not know where to begin, I handle that under site and store optimization.
Payments, shipping and emails - the full purchase path
Before the sale you need to go through a real purchase with every payment method and every shipping method, right up to the confirmation email and the order in the admin panel. A home page that loads proves nothing.
In the season it is usually the end of the path that breaks: the payment gateway fails for just one method, the parcel locker map does not load on mobile, the confirmation email lands in spam or never goes out. Shoppers do not report it. They simply buy elsewhere.
The test I run a week before the sale:
- a purchase with every payment method (BLIK, card, instant bank transfer, cash on delivery if offered),
- every shipping method, with the shipping cost both above and below the free shipping threshold,
- a purchase with the sale’s coupon code, on a copy of the store, before the code goes live,
- the email to the customer and the notification to the store - whether they arrive and stay out of spam,
- the hand-off of the order: invoice, shipping label, stock sync if the store is connected to another system.
Sales also bring price display into play. Under the Omnibus directive, a product on discount has to show its lowest price from the 30 days before the reduction - a legal requirement, not a marketing choice. Check that the sale plugin and the theme display it correctly once the discounts are switched on. This is not legal advice - confirm the details with a lawyer.
Monitoring and on-call cover on the day
On the day of the sale someone has to know about an outage before the customers do. A monitor that checks the site and the checkout every few minutes is enough, plus one person reachable by phone with access to the server and the backups.
Monitoring should check more than the status code of the home page. A store can answer correctly and still not take payments. That is why in the season I also watch the number of orders over time: if there are suddenly no orders for a long stretch during hours when they normally come in, it is a signal to check the checkout, even when the site is up.
On-call cover only makes sense when the person on call has everything at hand: access to the hosting and the store admin, knowledge of where the backup is, and a list of the latest changes. Put this in writing before the sale, not at 9:00 on Friday.
Plan B if the store goes down at the peak
Plan B is a written list of steps for an outage, agreed before the sale: who decides, what to switch off first, when to restore the backup and how to tell customers. Under stress nobody comes up with this from scratch.
My plan B for a store in the season usually has four steps:
- find out whether it is the store, the hosting or the payment gateway (each has a different fix),
- switch off the last change or plugin if the outage started right after it,
- restore the backup if the fix does not work - with a decision on what to do with orders placed since that backup,
- a notice for customers on the site and on social media if the break will last longer.
If the store runs on shared hosting, agree with the provider in advance how quickly their support answers at the weekend. In the season that matters more than the price of the plan.
Frequently asked questions
How far ahead should I start preparing a WooCommerce store for Black Friday? About five weeks before the sale. That gives time for fixes, testing and a change freeze two weeks before the day. One week ahead is only enough for a backup and a purchase test.
Should I update plugins right before Black Friday? No, apart from security patches. Do updates three to four weeks before the sale, one at a time with a checkout test, then freeze changes until the season is over.
Will my hosting handle the sale traffic? You cannot tell without measuring and talking to the provider. Check the process and memory limits, ask whether the plan can be raised temporarily and measure checkout speed before the traffic arrives.
What if the store goes down during the sale? Follow the written plan B: find where the outage is, roll back the last change and, if that does not help, restore a tested backup. Without a backup you have restored before, this step turns into guesswork.
Would rather not watch over it every month yourself? I take sites and stores under ongoing care - backups, updates, monitoring, and priority when something breaks. See the plans: ongoing support.