For many stores, Black Friday is one of the busiest days of the year, and there isn’t much room for mistakes. What breaks often isn’t the home page. It’s checkout slowing down, a payment method failing, order emails not arriving or sale prices not showing up. In 2026 Black Friday falls on Friday, November 27, and Cyber Monday on Monday, November 30.
This checklist covers the technical side of a WooCommerce store: what to do, and when, so the store holds up when the sale starts, and what to do if it goes down anyway.
The timeline
Most of the work belongs in the weeks before. The closer you get to the sale, the fewer changes you make.
| When | What |
|---|---|
| 4 weeks before | Update WordPress, WooCommerce, the theme and plugins. Talk to your hosting provider about capacity. |
| 3 weeks before | Test the whole purchase with every payment and shipping method. Load test the store. |
| 2 weeks before | Set up sale prices and coupons, and check them on a copy of the store. |
| The week before | Freeze changes. Clear the scheduled actions queue. Take a backup and check that it can be restored. |
| The day before | Place another test order. Check that order emails arrive. |
| When the sale starts | Check the prices in the store, add a product to the cart, and watch response times and errors. |
| The week after | Clean up, and write down what went wrong. |
Update now, then freeze
Updates need to be done well ahead. A new version of WooCommerce or a payment plugin can change something in checkout, and you want to find that out three weeks before, not on the day. Update a copy of the store first, go through a purchase, and then update the live store.
From the week before the sale, freeze changes: no new plugins, no updates and no new design. The only exception is security updates, and you test those on the copy first, even when it’s urgent.
Test the whole purchase, including payment
One test order going through with one payment method isn’t enough. Go all the way through for every combination your customers use:
- Pay with every payment method you offer through your payment gateway: cards, wallets and any local methods (in Denmark, MobilePay).
- Choose every shipping method, including pickup points, and check that the customer can pick a location.
- Use a sale coupon, and check that the discount and tax are right on the order and the invoice.
- Check that the order gets the right status and doesn’t get stuck on “Pending payment” even though the payment went through.
- Check that both the customer and you receive the order emails, and that they don’t land in spam.
- Check that the order reaches your shipping and accounting systems, if you have an integration.
- Refund the test order, and check that the refund goes through at the payment provider.
Also ask your payment provider whether your agreement has amount or transaction limits that could kick in on a day with far more orders than usual.
Can the store handle the traffic?
The hard part about traffic in a store is that the pages that matter most can’t be cached. Product and category pages can come from a page cache, but as soon as a customer has something in the cart, every page has to be built from scratch. On Black Friday that’s many customers at once, and each of them occupies a PHP process on the server while their page is built. When there are no free ones left, the rest wait in line, and the store feels slow or returns an error.
So ask your hosting provider specific questions: how many PHP processes does your plan have, what happens when they’re used up, and can you get more temporarily during the sale? Many providers can upgrade you for a period. What else to look for in hosting for a store is in our guide to choosing WordPress hosting.
Then load test the store on a copy with the same hosting. A load testing tool can send many visitors through home page, product, cart and checkout at once, and you can see when response times start to climb. What server response time means and how to bring it down is in our guide to high TTFB. If they climb earlier than the traffic you expect, find the cause now. The step-by-step troubleshooting is in our guide to a slow WooCommerce store. What often helps most on the pages that can’t be cached is an object cache such as Redis and fewer heavy plugins in checkout. The setup is in our guide to Redis object cache.
Sale prices and the cache
WooCommerce can schedule sale prices with a start and end date on each product. The switch happens through a scheduled job, so check that the prices have actually changed when the sale starts, on the product page, in the categories and in the cart. If many products are part of the sale, export them before and after and compare.
The page cache can show old prices if it isn’t cleared when prices change. Clear it when the sale starts and ends, and check a product page as a logged-out visitor afterward.
Prior prices: the lowest price in 30 days
If you sell to consumers in the EU and show “was” prices or “save 25%”, the price-indication rules say the prior price is the lowest price you sold the product for in the 30 days before the reduction. If the price varied during that period, the lowest one is what you compare against. A price you raised in October to cut it in November can’t be used as the prior price. In Denmark the rules and examples are in the Consumer Ombudsman’s guidelines on price marketing (in Danish); other EU countries have their own guidance.
WooCommerce doesn’t track the lowest price of the last 30 days by itself. If you show prior prices, either use a plugin that stores price history or write the prices down yourself before you set up the sale.
Background jobs and emails
Every order starts work in the background: emails, stock updates, syncing to shipping and accounting. WooCommerce runs it through a queue, Action Scheduler, which you’ll find under WooCommerce → Status → Scheduled Actions. If there are already many pending or failed actions before the sale, it only gets worse. Find out what’s failing and clean up while there’s time. Our guide to Action Scheduler shows how.
By default the queue is triggered when someone visits the store. Have your hosting provider run WP-Cron from the server on a fixed schedule instead, so background jobs don’t run on top of customers’ page views. And send order emails through a proper email service instead of the server’s own mail function, so they arrive even when many go out at once.
If the store goes down
Make the plan before you need it. Write down who to call at your hosting provider, how to get into the server, and who’s allowed to change things on the day. When the store is down, there’s no time to look for login details.
If the store shows a 502, 503 or 504 error, or keeps loading, the server has often run out of free PHP processes or memory. The first step is to contact your hosting provider, who can see the load and can often add resources right away. Meanwhile you can ease the pressure by turning off things a purchase doesn’t need: heavy filters, live chat, pop-ups and plugins that run reports or syncs.
Don’t update plugins in a panic, and don’t try out new caching plugins on the live store during the sale. That can create a new problem instead of solving the old one. If the store is down for long, tell customers on the channels you have, and extend the sale once it’s back.
After the sale
Check the scheduled actions queue again, and look for orders that got stuck. Write down what was slow or failed, and at what time of day. It’s the best basis you’ll get for preparing the store for the next sale, and it’s easier to fix now than next October.
Want help?
If your store is already slow on an ordinary day, it will be slower on Black Friday. If you’d like it reviewed before the sale starts, read about optimizing your WooCommerce store. We take a free look at the store first and tell you what can be done before the sale.