Will Your WooCommerce Store Survive Black Friday? The 10-Point Checklist We Run

Black Friday falls on 27 November 2026, Cyber Monday on 30 November. For most stores that weekend is worth several normal weeks. It is also the one weekend when a slow checkout, a fragile plugin and a hosting limit all show up in the same hour — while your ads are spending at their highest rate of the year.

This is the WooCommerce Black Friday checklist we work through with every store we get ready. It is ordered by when to do each thing, and every point says what it costs you if you skip it and how to check it yourself in about ten minutes.

A change shipped on 24 November is exactly the kind of change that breaks on 27 November. That is why this work sits in October, not in the last week.

Before you test anything, write down three numbers from last year’s Black Friday, or from your busiest day: orders in the busiest hour, visitors in that hour, and how both compare with a normal day. For stores that email and advertise it is usually 3–5× normal.

That is your target. A load test “at 1,000 users” means nothing if your real peak is 150 — or 3,000.

If you skip it: you will test the wrong number and feel safe for the wrong reason.

Check it in ten minutes: Google Analytics for visitors by hour, WooCommerce → Reports → Orders for orders by day. Write the three numbers somewhere your developer and your host can both see them.

Your homepage is almost certainly cached and fast. Black Friday shoppers do not stay there: they search, filter a category, add to cart and check out — and those pages are built for each visitor.

Test the whole journey on a staging copy: category → product → add to cart → checkout with a test payment, at 1×, 3× and 5× your peak. Watch two numbers — the 95th-percentile response time and the error rate. The first thing that breaks is your number one fix.

If you skip it: your speed report says 95 out of 100 and your checkout still times out at 8pm on Friday.

Check it in ten minutes: open your own checkout on a phone, on mobile data, with three items in the cart. If it is slow now, it will be much slower under load.

The moment a shopper adds something to the cart, WooCommerce gives them session cookies, and most page caches stop serving them cached pages. From then on every page they open is built by PHP and the database — and that is the shopper who pays you.

In plain wordsYour store is fast for people who are just browsing and slow for people who are buying. Speed reports grade the first group. Your revenue comes from the second.

Three things to check: which cookies make the cache step aside (cart and session cookies are normal, anything else is a bug), whether cart fragments run on every page view, and whether you have a persistent object cache — Redis or Memcached — so those uncached pages are at least cheap.

If you skip it: the busiest hour of your year is spent building pages from scratch for everyone who has a full cart.

Check it in ten minutes: run the free snapshot below. It loads your homepage from cache and the way a shopper with a cart gets it, and puts both numbers side by side.

Uncached requests are served by PHP workers. When every worker is busy, new requests wait in a queue — and at peak, waiting turns into timeouts and 502 or 504 pages.

Ask your host, in writing: how many PHP workers you have, how many database connections, and whether they can add capacity for the Black Friday weekend. Most managed hosts sell temporary capacity, and it is far cheaper than an outage. Check your CDN rules too: images and static files should never reach your server.

If you skip it: you find your ceiling at the worst possible moment, and nobody can raise it on a Friday night.

Check it in ten minutes: one email to your host with those three questions.

Your checkout is not only your code. One order waits for the shipping rate service, the tax service, the fraud check, the payment gateway and often the ERP — inside the same request the shopper is staring at.

So test it the way it is actually used: pay with every method you offer, including 3-D Secure cards and wallets, on a phone. Test coupons, free-shipping thresholds and the shipping rules for each region. Have a backup gateway you can switch on if the main one throttles. And protect checkout from card-testing bots — bot traffic spikes around Black Friday too.

If you skip it: one slow third-party service holds your checkout, and shoppers see an error with a full cart. One store came to us after a Black Friday where a slow checkout cost about 15% of orders — what we found and fixed.

Check it in ten minutes: place one real order on your phone and count the seconds from “Place order” to the thank-you page.

Black Friday orders trigger a lot of work you never see: stock updates, ERP and marketplace syncs, emails, webhooks, scheduled actions. When that work runs in the same PHP and database as checkout, it competes with your shoppers for the same workers.

If you skip it: the queue grows all evening, orders reach your ERP hours late, and stock stops matching reality.

Check it in ten minutes: WooCommerce → Status → Scheduled Actions. Hundreds of pending or failed actions on a normal day will be thousands at peak. Check your email provider’s sending limit while you are there.

Black Friday week is when ads cost the most — and when tracking breaks most often. Campaigns optimise on the orders they can see, so a gap between your store and your ad accounts is budget spent on the wrong audience.

If you skip it: you cannot tell which campaign paid for itself, and the algorithm cannot either.

Check it in ten minutes: compare yesterday’s WooCommerce orders with purchases in GA4 and in Meta. More than a few per cent apart means it is broken now — and it gets worse under load. Server-side tracking makes purchase events far more reliable.

Update WordPress, WooCommerce, plugins and the theme in October, on staging first, and remove what you do not use. After the freeze nothing gets updated unless it is a security fix you have tested.

If you skip it: you either go into the peak on old code with known bugs, or you update in the worst week of the year.

Check it in ten minutes: count the plugins with pending updates, and the plugins nobody can name a use for.

A code freeze is not bureaucracy. It is how you make sure the store you tested is the store that takes the orders.

Write down on one page: how to restore yesterday’s backup, how to switch payment gateways, how to turn a plugin off safely, and who does each step.

If you skip it: at 9pm on Friday three people are guessing in a group chat.

Check it in ten minutes: open your backup system and find when a restore was last tested. Not taken — tested.

From Friday morning to Monday night someone should watch uptime, checkout and payments, and know the store well enough to act in minutes. If there is nobody in-house, that is what WooCommerce support is for. Give that person the contacts for your host and your payment provider before Friday, not during the incident.

If you skip it: the store is down for two hours before anyone notices, and the first to notice is a customer.

Check it in ten minutes: name the person and write down their phone number. If you cannot, that is the gap.

Of the ten points above, three cause most of the damage we see: uncached pages for shoppers with a cart, a hosting limit nobody asked about, and one slow service inside checkout. Making those uncached pages fast is the core of our WooCommerce speed optimization work. They have something in common — all three look fine in a normal week and only appear under load. That is what a load test is for.

If you are handing this over, these are the specifics worth checking in the code and the configuration:

• Cache bypass: which cookies are in the bypass list; whether wc-ajax=get_refreshed_fragments runs on every page view; whether the object cache is persistent, and its hit rate at peak.
• Load test: staging on the same PHP and database version, a catalogue and order table of the same size, scenarios for category → product → add to cart → checkout, run at 1×, 3× and 5× the measured peak; watch p95, error rate and PHP worker saturation, not averages.
• Checkout path: timeouts and retries for every outbound call — shipping rates, tax, fraud checks, the gateway; what happens when one of them stops answering; which of those calls can move out of the request.
• Background work: Action Scheduler queue depth and failure rate, cron run from the system rather than from page views, heavy syncs on a queue and off-peak.
• Tracking: purchase events sent server-side with deduplication, and a daily comparison of orders against GA4 and the ad platforms.

This is what our Black Friday readiness check covers: a load test on a staging copy, checkout and payments under that load, hosting limits, integrations and order tracking. You get a written risk list with fixes and hours within 48 hours of getting access. It costs $490, and that price is credited if you go on to a fix sprint.