Start in late summer. Audit your slow pages and heavy plugins in September, prove a backup actually restores, buy something from your own store as a real customer, confirm the order emails land, then stop changing things before the rush starts.
Peak season does not break websites. Change breaks websites, and peak season is simply when change becomes expensive. A plugin conflict you fix in September costs you an afternoon. The same conflict on the second Friday in December costs you orders you will never get back.
Work backwards from your busiest day
Pick the date you actually expect to be busiest. For most retailers that is somewhere between Black Friday and the middle of December. For a tax practice it is March. For a landscaping company it is April. The month does not matter. The sequence does.
Count backwards from that date in weeks. You want roughly eight weeks of work and testing, then two weeks of doing nothing at all. The doing-nothing part is not laziness. It is the part most businesses skip, and it is the part that saves them.
Write the dates down somewhere you will see them. A busy season sneaks up on people, and the work that protects it always feels less urgent than the work that fills it.
September: find out what is actually slow
Do not guess. Load your own site on your phone, on cellular data, away from your office wifi, and time how long it takes before you can tap something. Then do it for the three pages that matter most: your top product or service page, your category or pricing page, and your checkout or contact form.
Slow pages are usually slow for boring reasons. Enormous uncompressed images. A slider carrying a video nobody watches. Four analytics and chat scripts stacked on top of each other. A page builder rendering a layout that could have been plain HTML. We wrote more about diagnosing this in why your website feels slow, and almost none of the common causes require a redesign to fix.
While you are in there, count your plugins. Not to hit a number, but to ask an honest question about each one: is anything on this site still using it? Deactivated plugins that nobody has looked at in two years are the ones that tend to cause trouble later. Removing dead weight in September is easy. Removing it in December is a change you should not be making.
If a page is slow and you cannot see why, that is a reasonable thing to hand off. Our performance work exists for exactly this, and we quote it before we start.
September: prove a backup can be restored
Almost every host will tell you they take backups. Far fewer businesses have ever watched one come back. A backup you have never restored is a promise, not a safety net, and peak season is a poor time to discover the difference.
Ask your host directly: can you restore my site to a staging copy this week so I can look at it? Then look at it. Are the orders there? The products? The images? The custom fields your theme depends on? A restore that brings back the database but not the uploads folder is a restore that will still ruin your December.
Ask two more questions while you have their attention. How far back do the backups go, and where are they stored? A backup living on the same server as the site is not really a backup. We keep twice-daily verified off-site copies with thirty-day retention, which means the worst case is losing half a day rather than losing a season. There is more detail in our note on backups, monitoring, and recovery.
Early October: buy something from your own store
Not a test order through the admin panel. A real order, on a real card, from a browser you are not logged into, on your phone. Then do it again on a desktop. Then do it once with a coupon code, and once with an item that is nearly out of stock.
This is the single highest-value hour in the whole checklist, and it is the one most owners skip because it feels redundant. It is not redundant. Payment gateways change their requirements. Shipping plugins update. A theme change three months ago quietly broke the address autocomplete on iOS. You will not know until somebody tries, and you would rather it be you than a customer with a full cart.
Write down every step as you go: add to cart, view cart, checkout, payment, confirmation screen, confirmation email. If any step feels awkward to you, it feels worse to somebody who has never seen your site before.
If you are not an ecommerce business, the equivalent is your contact form or your booking flow. Submit it. Wait. Did anything arrive?
Early October: make sure the order emails arrive
Order confirmations, shipping notices, password resets, and contact form notifications all leave your site the same way, and they all fail the same way: silently. Nobody complains that they did not receive an email. They just assume you did not take their order and they call, or they do not.
Check three inboxes, not one. Send test orders to a Gmail address, an Outlook or Hotmail address, and whatever your own business email runs on. Then check the spam folder in each. If your confirmations are landing in spam at Gmail, that is a fixable configuration problem, and it is the sort of thing worth handing to somebody who has fixed it before rather than trying six plugin settings at random.
The common causes are dull: the site is sending mail directly from the web server instead of through a proper mail service, or the domain's sending records were set up years ago and no longer match reality. Both are quiet, both are invisible from inside your business, and both are much easier to sort out in October than during a sale.
Mid-October: stop changing things
Set a change freeze and mean it. From a date you choose, the only edits to the site are content: prices, product descriptions, stock, banners, blog posts. No new plugins. No theme updates. No new tracking scripts because an agency asked nicely. No redesigns of the homepage because somebody saw a competitor's.
Security patches are the exception, and they should still be applied by somebody who tests them first. That distinction matters. A freeze is not neglect. It means the risky category of change stops while the necessary category continues under supervision.
The freeze is unpopular because it arrives exactly when marketing energy peaks. Hold it anyway. Most peak-season outages we have seen started with a well-intentioned change made in the last two weeks by somebody who was sure it was small.
Know who to call before you need them
Sit down and answer four questions on paper. Who do I contact if the site is down? What is their email address, and does somebody other than me have it? How fast do they normally reply? What can they actually do at three in the afternoon on a Saturday?
Be honest about the answers. Plenty of hosts will open a ticket and route you to a queue. That is fine for a slow Tuesday and not fine when checkout is broken during your biggest week. If you do not like your answer to the last question, October is the month to change it. Migrations during a freeze are a bad idea, so if you are moving, move now. We handle migrations ourselves at no charge, and the reason we ask people to move early is precisely this.
Tell whoever supports your site when your peak actually is. It is a two-sentence email and it changes how the next incident goes. We would rather know your busiest fortnight in advance than find out from an outage.
Being boring by October is the goal
None of this is clever. There is no trick here, no setting that doubles your capacity, no plugin that makes a fragile site sturdy. The whole plan is a sequence of unglamorous checks, done early, in an order that leaves room to fix what they find.
A site that has been audited, restored from backup once, purchased from as a stranger, and left alone for two weeks is a site that will probably have an uneventful December. That is the entire ambition. Nothing broke. That is the product.
Frequently asked questions
How late is too late to start?
Two weeks out, do the checkout test and the email test and nothing else. Those two catch the failures that cost real money, and neither requires changing the site. Skip the audit and the plugin cleanup until January. Starting a performance project a fortnight before your busiest week creates more risk than it removes.
Should I move to a bigger server for peak season?
Usually not. Traffic spikes are rarely what takes a site down during a busy period. Slow queries, a bloated page, a plugin conflict, and broken email are far more common. Fix the specific slow thing first. If capacity genuinely turns out to be the constraint, that is a conversation worth having in September, not in the middle of a sale.
What if something breaks anyway?
Then you want somebody who already knows your site answering. We reply the same day, and we triage emergencies during business hours rather than pretending otherwise. If you are in the middle of a peak week right now and something is wrong, our emergency help page is the fastest way to reach us.
