How to prepare a store for a sales rush

A store that copes comfortably with its normal traffic can still fail badly on the one day everyone arrives at once. Sales events — Black Friday, a product launch, a viral mention — do not scale traffic gradually the way organic growth does; they multiply it quickly, often within a single hour, and a store's normal capacity margin can disappear faster than it takes to notice something is wrong.

Start with caching, because it is the highest-leverage fix

A properly cached shop, category and product page can be served to a huge number of visitors without touching the database or your PHP resources for each one — the difference between a page that costs almost nothing to serve repeatedly and one that is rebuilt from scratch every single time. Confirm caching is switched on and correctly configured well before any planned high-traffic event, not during it. Just as importantly, confirm cart, checkout and account pages are correctly excluded from that cache — see how to stop caching breaking your cart — because a spike in traffic makes a caching misconfiguration far more visible and far more damaging than it would be on a quiet day.

Know your plan's actual headroom before the day arrives

Check your account's resource usage in your control panel in the weeks leading up to a planned event, not just on a normal day. If your store is already using a meaningful share of your plan's resources under everyday traffic, a multiplied spike is likely to push past what the plan comfortably handles. This is the point to consider upgrading in advance — see how to tell when you have outgrown your plan — rather than discovering the limit live, during the sale, when upgrading under pressure is a worse experience for everyone.

Reduce what has to happen per visitor

• Turn off or defer anything non-essential during the event window. A resource-heavy recommendation widget, a live chat plugin, or an analytics script that is not critical to completing a purchase can be temporarily disabled to free up capacity for the parts of the site that actually take orders.
• Simplify the checkout path if you can. Fewer steps and fewer external scripts loading on the checkout page means less that can go wrong under load, on top of being generally good practice.
• Pre-generate anything that can be pre-generated. Category pages, popular product pages and the homepage benefit from being fully cached well before the surge starts, rather than being built fresh under pressure by the first wave of visitors.

Stock and oversell risk under high concurrency

A popular item can be added to many customers' carts simultaneously during a rush, and stock management needs to handle that correctly rather than allowing more orders than available stock. Confirm WooCommerce's stock management and "hold stock" settings are configured sensibly before a known high-demand event — an item that oversells during a sale creates a cancellation and refund problem that is considerably more work than preventing it would have been.

Have a plan for what to do if something does go wrong

After the event

Review what actually happened — where resource usage peaked, whether any orders needed manual correction, whether caching held up as expected — and keep notes for the next high-traffic event. A sales rush is not a one-off; treating each one as a chance to improve the next one is more useful than treating the whole thing as a fire to put out and forget.

Communicate honestly if something did go wrong

If the site slowed down, an order failed, or a payment had to be retried, a brief, honest message to affected customers tends to go further than silence. Customers arriving for a known, time-limited sale are generally more forgiving of a hiccup than they would be on an ordinary day, provided they are told what happened and what you are doing about it rather than left to wonder whether their order actually went through.