Black Friday WooCommerce Preparation: The 8-Week Checklist

Black Friday WooCommerce preparation is not a week-before panic, it is an eight-week programme – and if you are reading this in mid-September, you are exactly on time. Black Friday lands on 27 November this year, which puts you roughly ten weeks out: enough time to audit your capacity, fix the slow pages, lock the offers, rehearse the checkout under load and write the runbook for the day itself. Stores that die on Black Friday almost never die because of Black Friday; they die because of decisions that were not made in September and October.

I have prepared WooCommerce stores for peak season for over a decade, for owners in Germany, the UK, the US and Australia, and the pattern is always the same: the store that treats the sale as an operations project has a boring, profitable day, and the store that treats it as a marketing date has a support inbox on fire and a payment gateway timing out at 9pm. This is the checklist I actually run with clients, organised as a countdown – what to do at eight weeks out, six weeks out, four, two, and in the week of the sale – plus the runbook for the day and the clean-up plan for the week after.

Table of contents

• Why Black Friday stores die in September
• The 8-week countdown at a glance
• T-8 weeks: the capacity audit and load reality check
• T-6 weeks: offers, stock and the mechanics in WooCommerce
• T-4 weeks: performance prep – cache, images and the script diet
• Landing pages and email sequences
• T-2 weeks: the dress rehearsal and checkout resilience
• Inventory and oversell protection
• Support prep and the fraud spike
• The week of: monitoring and the day-of runbook
• After the sale: returns, reviews and the debrief
• Frequently asked questions

Why Black Friday stores die in September

Every year I get two kinds of enquiry in November. The first, in early November, says “can you check our store is ready for Black Friday?” – and usually it is, because there is still time to fix what we find. The second arrives on the last Friday of November and says “the site is down and we are losing orders” – and by then the only honest answer is damage control. The difference between the two stores is never budget or hosting brand. It is lead time.

The reason lead time matters so much is that almost every Black Friday failure has a long fuse. A hosting plan that caps PHP workers at a level your normal Tuesday never touches. A hero product image that weighs 1.8 MB and was never noticed because regular traffic tolerates it. A payment gateway account with a fraud threshold that treats a 5x order spike as an attack. An email list that has not been mailed since May, so the launch campaign lands in spam. None of these can be fixed in an afternoon under fire; all of them are cheap to fix with six weeks of runway.

There is also a purely commercial reason to start now: the offers themselves. A discount strategy invented the week before the sale is almost always “20% off everything”, which is the least profitable offer you can run. Bundles, tiered discounts, doorbusters with capped stock and margin-protecting exclusions all need product data work, pricing decisions and a bit of building – which is to say, they need weeks, not days. The stores that make real money on Black Friday decided what to sell, at what margin, to which segment, back when the weather was still warm.

So treat this post as a project plan with dates on it. Work backwards from 27 November, put the milestones in your calendar, and give every workstream an owner – even if every owner is you.

The 8-week countdown at a glance

Here is the whole programme in one table. Each phase gets its own section below; the table is the version you print and stick next to your monitor. The weeks are labelled T-8 to T-0, counting down to sale day. If you start a week or two late, do not compress every phase equally – protect the capacity audit and the dress rehearsal, and trim the nice-to-haves instead.

Two principles run through the whole plan. First: everything that can be scheduled in advance is scheduled in advance – sale prices, emails, page publishing – so that sale day involves as few human actions as possible. Humans under pressure at midnight make typos in prices. Second: from one week out, the store is frozen. No plugin updates, no theme changes, no “quick improvements”. The version of the site that survived the dress rehearsal is the version that runs the sale.

T-8 weeks: the capacity audit and load reality check

Start with a number: how much traffic and how many orders should you plan for? The honest method is last year’s Black Friday weekend multiplied by your growth since, with a safety factor. If your store did 3x normal traffic last year and you have grown 30%, plan for 4x and test at 5x. If this is your first Black Friday, plan for 3-5x your best recent day – and remember the shape matters as much as the volume: the load arrives in spikes when emails go out, not as a smooth curve.

Then hold that number against what your hosting actually provides. This is where most surprises live, because shared and entry-level managed plans have limits that never show up in normal use:

• PHP workers. Every uncached request – and cart, checkout and my-account pages are always uncached – occupies a worker for the duration of the request. A plan with 4 workers and a 2-second checkout request can process roughly two checkouts per second before requests queue. Ask your host for your worker count and what an upgrade costs for a single month.
• Database capacity. WooCommerce hammers the database during checkout. A slow query that takes 80ms on a quiet day takes seconds when 40 of them run concurrently. If your product count is large or your orders table has years of history, a pre-season clean-up pays for itself.
• Traffic and CPU caps. Some hosts throttle or bill sharply past a threshold. Know the threshold and the overage price before November, not on the invoice in December.
• Email sending limits. Order confirmations count against hosting mail limits. A spike of 2,000 orders can hit a cap and silently stop transactional email. Use a dedicated transactional email service if you are not already.

Book a load test now, even a simple one. Tools like k6 or Loader.io can simulate a few hundred concurrent users adding to cart and reaching checkout against a staging copy. The point is not a perfect simulation; it is finding the first thing that breaks while you still have eight weeks to fix it. In my experience the first failure is almost never the home page – it is checkout, the search, or a filtered category page with an expensive query. I have written in detail about what scaling WordPress under real traffic involves in my guide to scaling WordPress for high-traffic websites; for Black Friday you do not need all of it, you need to know which parts apply to your store.

The output of T-8 is a decision: stay on the current plan, upgrade for November (most managed hosts let you scale up for a month), or move hosts entirely. Moving hosts is only realistic this far out – it is exactly the kind of change you must never make in November.

T-6 weeks: offers, stock and the mechanics in WooCommerce

Six weeks out, the commercial side gets locked. Not “we will do a sale” – the actual list: which products, what discount, what margin remains, what stock backs it, when each offer starts and ends. Write it as a table with a row per offer, because that table becomes your build list, your email content and your sale-day reference.

Be honest about sitewide vs targeted discounts. “20% off everything” is easy to build and easy to advertise, and it quietly gives away margin on products that would have sold anyway, including to customers who were about to buy at full price. Targeted offers work harder: deep discounts on selected doorbusters to drive traffic, moderate discounts on high-margin categories, bundles that raise average order value, and full price on your bestsellers that need no help. Most stores land on a hybrid – a modest sitewide hook plus hero offers – and that is usually right. What matters is deciding on margin, not on adrenaline.

Then build the mechanics in WooCommerce properly:

• Scheduled sale prices. WooCommerce supports scheduled sale prices natively on every product – set the start and end dates now and let the store switch itself over at midnight. Never plan to edit prices manually on the night; that is how a client’s store once sold a EUR 400 product for EUR 4 until morning.
• Coupons at scale. If you use coupon codes, cap them: usage limits per coupon and per customer, minimum spend, excluded sale items, and an expiry date. An uncapped code will leak to voucher sites within hours and run for months if you let it.
• Bundles and tiers. Product bundles and “spend X get Y” tiers need a plugin or a small custom build – which is precisely why they are a T-6 task. Test them with real tax and shipping settings; bundle edge cases love VAT.
• Strikethrough honesty. In the EU and UK, reference-price rules mean the “was” price generally needs to be a genuine prior price (in several countries, the lowest price of the last 30 days). Inflating the “was” price in October to fake a deeper cut in November is both illegal in many markets and increasingly detected by consumer watchdogs. Plan prices with the 30-day window in mind.

Order stock now. Six weeks is already tight for many suppliers in peak season. Decide per hero product how much stock backs the offer, and what happens when it runs out – hard stop, backorder with a stated ship date, or automatic switch to a smaller discount. That decision, made now, is what saves you from overselling later.

T-4 weeks: performance prep – cache, images and the script diet

A store that is slow on a normal Tuesday will be unusable under 4x load, because everything that is slow gets slower under concurrency. Four weeks out is the performance pass – late enough that the site is close to its sale-day shape, early enough to fix what you find.

• Verify caching actually works. Full-page caching should serve your home page, category pages, product pages and landing pages without touching PHP. Test it logged out with response headers, not by feel – a surprising number of stores have a cache plugin installed and a cookie or session quietly bypassing it for every visitor. Cart, checkout and account pages are correctly excluded from page cache; that is exactly why the capacity work at T-8 matters.
• Warm the cache before the spikes. A cache is only fast when it is full. If your host or plugin supports cache preloading, schedule a warm-up after the midnight price switch, so the first thousand visitors hit cached pages, not a cold regeneration stampede.
• Run an image audit on the money pages. Home page, top categories, hero products, sale landing page: every image in WebP, properly sized, lazy-loaded below the fold, with the hero image preloaded. I still find multi-megabyte PNGs on the busiest page of stores that are otherwise well built.
• Put third-party scripts on a diet. List every external script the store loads – chat widgets, heatmaps, review badges, old pixels, that A/B tool from 2023. Every one of them slows the first paint for every visitor on the biggest day of the year. Keep analytics and the pixels you will actively use for the campaign; delay or remove the rest, at least for November.
• Check the database while you are there. Expired transients, old sessions, thousands of post revisions and a bloated options table all tax exactly the queries that spike under load. A careful clean-up (after a backup) is an hour well spent.

Measure before and after: a PageSpeed run and, more importantly, real timings on the product and checkout pages. If the numbers are stubbornly bad and you cannot see why, that is a job for a specialist – a focused pass like my WordPress speed optimisation service exists for exactly this “four weeks before the sale” moment, and it is far cheaper than the orders a slow checkout silently loses.

Landing pages and email sequences

Sending Black Friday traffic to your home page wastes the click. Ads and emails should land on a dedicated sale page: the offers above the fold, countdown to the end of the sale, clear categories, trust signals (delivery deadline for Christmas, returns policy, payment methods), and nothing else competing for attention. Build it at T-4, keep it unlisted, and you can also use it as the load-test target and the QA page for offer pricing. If landing pages are new territory for you, I have covered the structure that converts in WordPress landing pages that convert – the sale page is the same anatomy with a deadline attached.

Email is still where Black Friday revenue actually comes from for most small stores – it routinely beats paid ads on return because the list already trusts you. The sequence I see work, in its simplest form:

• Warm-up (from T-4). If the list has been cold, do not let its first email in months be a promotion. Send one or two genuinely useful emails first – gift guides, how-to content, early access sign-up. This rebuilds sender reputation so the campaign lands in inboxes, not spam.
• Teaser (T-1 week). Announce that the sale is coming, with the date and one concrete hint. An “early access” or VIP list segment here performs remarkably well and gives you a soft-launch audience for testing.
• Launch (day one). The offers, the landing page link, the end date. Send it at your list’s best hour, not midnight – midnight sends compete with every other store’s midnight send.
• Mid-sale nudge. Social proof and stock honesty: bestsellers, “X already sold”, back-in-stock notes. Only claim scarcity that is true.
• Last chance (final day). The highest-revenue email of the sequence for almost every store. Plain, direct, deadline-led.

Write and load all of these into your email platform by T-2, scheduled. On sale weekend you want to be watching dashboards, not writing copy.

T-2 weeks: the dress rehearsal and checkout resilience

Two weeks out, run the whole sale once, for real, on staging. Switch the scheduled prices to a test date, load the landing page, and buy things: as a guest, as a returning customer, on a phone, with a coupon, with a bundle, with the payment methods you actually offer. Then do it again while the load test runs, because checkout behaviour at 300 concurrent users is the only behaviour that matters in November. The rehearsal regularly finds things no checklist catches – a shipping method that vanishes for one country, a coupon that stacks with sale prices when it should not, a payment redirect that loses the cart on the back button.

Checkout deserves its own hardening pass, because it is where load, revenue and failure all concentrate:

• Ask your payment provider about limits. Stripe, PayPal, Mollie and the rest have risk systems, rate limits and sometimes rolling reserves that can react to a sudden 5x volume spike from a small account. A short message to support in advance (“we expect 5x volume on 27-30 November”) is often enough to have thresholds adjusted. Have a second payment method live as a fallback – when one provider hiccups on Black Friday, stores with only that provider simply stop selling.
• Strip the checkout down. Every optional field, every surprise at the shipping step, costs more on the busiest day. I have written a full guide to reducing cart abandonment at the WooCommerce checkout – two weeks out is the right moment to apply at least the quick wins: guest checkout on, express payment buttons up top, fields you never use removed.
• Decide your overload strategy. If demand truly exceeds capacity, it is better to make some visitors wait than to let everyone in and have checkout fail for all of them. Options range from a proper queue system to a simple static “you are in line” holding page your host or CDN can switch on. Even if you never use it, having the page ready is a ten-minute insurance policy.
• Prepare the static fallback. A cached, static version of the landing page with a sign-up form is your worst-case answer. “We will email you when we are back” retains a fraction of the demand that a white error page loses entirely.

After the rehearsal, freeze. From one week out: no plugin updates, no theme edits, no new features. Take a full backup, verify you can restore it, and note the exact plugin versions running. If an update ships a security fix during the freeze, assess it deliberately – do not autopilot it.

Inventory and oversell protection

Overselling is the quietest Black Friday disaster: the sale looks like a triumph on Saturday and turns into refund emails on Tuesday. WooCommerce manages stock levels natively, but a few settings decide how it behaves under pressure, and they are worth reviewing deliberately at T-2.

• Turn stock management on per product for everything with limited stock, with real counts entered – counted, not estimated. If your stock lives in another system, reconcile them now and decide which is the source of truth for the sale.
• Use the hold-stock setting. WooCommerce can reserve stock for pending orders for a set number of minutes, which prevents two customers both buying the last unit while one is still paying. Shorten the hold window for the sale (10-15 minutes) so abandoned checkouts release stock quickly.
• Decide backorder policy per product, not globally. Backorders with an honest ship date can rescue revenue on hero items; silent backorders on gifts people need before Christmas create the angriest customers of the year.
• Set low-stock thresholds and notifications so a human hears about the last 10 units of a doorbuster while there is still time to switch the offer, not after 30 oversold orders.
• Watch multi-channel sync. If you also sell on Amazon, eBay or a POS, sync delays are amplified on high-velocity days. For your few genuine doorbusters, consider splitting stock allocations per channel in advance instead of trusting real-time sync at peak.

Finally, agree what happens when something does oversell anyway – who contacts the customer, what you offer (refund, wait with a discount, alternative product), and how fast. Having the email template written in advance turns a reputation risk into a minor apology.

Support prep and the fraud spike

Order volume multiplies, and so does everything attached to it: questions, complaints, payment issues and fraud attempts. The support side is straightforward to prepare and almost always neglected.

• Write macros for the top ten questions – where is my order, can I change the address, the coupon does not work, when does the sale end, can I get the sale price on yesterday’s order. Saved replies turn two-minute answers into ten-second answers, which is the difference between a manageable inbox and a backlog.
• Publish sale-specific answers in advance: a short FAQ on the landing page (delivery deadlines, returns window, price adjustment policy) prevents a large share of the tickets from existing at all.
• Extend cover honestly. You do not need 24/7 support; you need someone checking the inbox and chat during the traffic peaks – launch morning and the final evening especially – and an autoresponder that states real response times for the rest.
• Decide the price-adjustment policy before someone asks. “I bought it on Wednesday and now it is 30% off” will arrive within hours of launch. Whatever your answer, having it written down keeps it consistent and calm.

Fraud deserves its own paragraph, because fraud rings deliberately schedule their runs for peak season – high volume is camouflage, and stretched merchants review orders less carefully. Expect more stolen-card attempts, more coupon abuse and more “item not received” claims than in any other week. The preparation is the same as I describe in my WooCommerce fraud prevention guide, compressed: make sure your payment provider’s fraud tooling (3D Secure, risk scoring) is actually enabled, set a review threshold for unusually large orders, watch for many orders to one address with different cards, and do not let the sale-day rush pressure you into shipping an order your gut flags. One intercepted EUR 900 fraudulent order pays for the whole prep afternoon.

The week of: monitoring and the day-of runbook

By the final week, all the building is done – what remains is watching and responding. Set up a simple monitoring dashboard before Thursday, because “the site feels fine” is not data. You want, on one screen or one bookmarked set of tabs:

• Uptime and response time – an external monitor pinging the home page, a category page and (via a synthetic check) the checkout, alerting your phone, not your inbox.
• Server load – your host’s dashboard showing CPU, memory and PHP worker usage, so you see saturation building before visitors feel it.
• Orders per hour and checkout success – the WooCommerce dashboard plus your payment provider’s dashboard side by side; a gap between “checkouts started” and “payments completed” is the earliest signal of payment trouble.
• Error logs – a tail on the PHP error log and a look each hour; new errors under load are your first warning of a component failing.
• The status pages of your payment provider, host and CDN bookmarked – when something breaks, the first question is “us or them”, and these pages answer it in seconds.

Then write the runbook – one page, printed. Who is on duty in which hours across the sale weekend. What gets checked hourly (the dashboard sweep above). Thresholds and actions: at what CPU level do you call the host, at what point does the queue page go on, who has the credentials for hosting, DNS, payments and the email platform (with a second person able to reach everything). Escalation contacts with actual phone numbers: host support, your developer, the payment provider’s merchant line. And the golden rule, in bold at the top: nobody changes anything that is not in this runbook. No settings tweaks, no plugin updates, no CSS fixes on sale day. If I am the developer on call for a store, my job on the day is usually thirty seconds of glancing every hour – and that is exactly the outcome eight weeks of preparation buys.

A note on the roles: the sweep works best split three ways. Whoever is technical watches the site and server signals; the owner watches orders, stock on the hero products and coupon behaviour; whoever handles support watches the inbox, the chat and social mentions. In a one-person store you rotate through all three – which is precisely why everything else was automated in advance.

After the sale: returns, reviews and the debrief

The sale does not end when the discount ends; it ends about three weeks later, when the last return is processed. Plan the wind-down in advance and the post-sale period turns from a hangover into a second harvest.

• Expect the returns wave and staff for it. Peak-season return rates run noticeably higher than normal – more gift purchases, more impulse buys, more “ordered two sizes”. Make the returns process smooth and self-service where possible; a painful return converts a one-time sale customer into a never-again customer, while an easy one is quietly one of the strongest loyalty signals you can send.
• Harvest reviews while the orders are fresh. A review request email 7-10 days after delivery, when the product is in hand and the experience is recent, converts a spike of one-time buyers into permanent social proof on your product pages. This is the cheapest lasting asset the whole sale produces – do not skip it.
• Run the follow-up sequence, gently. New customers from the sale should get a short welcome flow – who you are, bestsellers at normal prices, a reason to come back that is not a discount. Do not train them to wait for the next sale.
• Hold a debrief while memory is fresh. One hour in the first week of December, notes written down: peak traffic and orders against the forecast, what saturated first, which offers made money and which just made work, what the support inbox complained about, what the runbook was missing. This document is the single most valuable input to next year’s T-8 audit – my longest-running store clients are on their fourth iteration of it, and their Black Fridays have become genuinely boring.

Also remember the unglamorous clean-up: expire the coupons, unschedule anything left, let sale prices end on schedule and check they did, take a fresh backup of the post-sale state, and lift the code freeze deliberately – running the updates you postponed, one at a time, now that the pressure is off.

Want a developer in your corner before the sale?

This is work I do for store owners every autumn: the capacity audit, the performance pass, checkout hardening, the load test and being the on-call developer in the runbook. If you want your store peak-ready without doing it all yourself, see my WooCommerce development services and portfolio, or tell me about your store – I reply within 24 hours, and in September there is still time to fix everything this checklist finds.

Frequently asked questions

How do you prepare a WooCommerce store for Black Friday?

Work backwards from the sale date on an 8-week countdown: capacity audit and load test at T-8, offers and stock at T-6, performance and landing pages at T-4, a full dress rehearsal and checkout hardening at T-2, then a code freeze and a written runbook for the sale weekend itself.

When should I start preparing for Black Friday?

Eight weeks before the sale at the latest – late September or very early October for a late-November Black Friday. Hosting changes and stock orders need that lead time; starting in early November limits you to quick wins.

How much traffic should I plan for on Black Friday?

Take last year’s Black Friday peak, adjust for growth, and add a safety factor – for most small stores that means planning for 3-5x a normal strong day and load testing above that. The spikes when emails go out matter more than the daily average.

Should I run a sitewide discount or targeted offers?

Usually a hybrid: a modest sitewide hook plus deeper offers on selected products chosen for margin and stock. A blanket “20% off everything” is easy but gives away margin on products that would have sold anyway.

How do I stop my store overselling during the sale?

Enable per-product stock management with real counts, use the WooCommerce hold-stock setting so pending orders reserve inventory, set low-stock alerts on doorbusters, and pre-split stock across channels instead of trusting real-time sync at peak.

What should I monitor on Black Friday itself?

Uptime and response times, server load and PHP workers, orders per hour against payments completed, the error log, and your payment provider’s status page – checked hourly by named people following a one-page runbook, with a strict no-changes freeze on the site.

Is Black Friday worth it for a small WooCommerce store?

Usually yes, if the offers are planned on margin and the store is prepared – it compresses weeks of revenue into days and recruits new customers you can keep with good follow-up. It is not worth it if the only plan is a deep blanket discount on an unprepared site.