Black Friday falls on Friday 27 November this year, with Small Business Saturday on the 28th and Cyber Monday on the 30th. The six weeks that decide how that weekend goes for your website begin on 12 October — which, conveniently or otherwise, is Thanksgiving Monday. Realistically you start on the Tuesday.
Most Black Friday advice for small businesses is about the offer. What to discount, when to email, how to segment the list, how to write a subject line that gets opened. That advice is useful and it is also everywhere. What gets far less attention is the thing all of it depends on.
A promotion that works is, by definition, a promotion that sends more people to your website in a shorter window than at any other point in the year. The website is the part almost nobody stress-tests until it fails.
And it usually does not fail in the way people expect. Sites rarely fall over on Black Friday. They get slow. Product pages still load, but the cart takes eleven seconds. Checkout times out on the third attempt and the customer gives up. Order confirmation emails arrive an hour late, so support spends the afternoon fielding "did my order go through" messages. Nothing registers as an outage, so your uptime monitor stays green and you never learn what it cost. You just have a disappointing weekend and no explanation for it.
What follows is how to prepare your website for Black Friday, as distinct from how to prepare the promotion. This guide covers the other half of the job. Black Friday website preparation, in the sense that matters here, is the infrastructure and performance work that has to be finished before the marketing calendar takes over. Each of the six weeks below has one task, and the order matters, because the later weeks assume the earlier ones are done.
Why this is the half that gets skipped
Partly because it is less fun than designing a promotion, and partly because the consequences are invisible until they are not. But mostly because the numbers everyone quotes are the wrong numbers.
The Canadian picture from last year is solid. Salesforce data reported by Retail Insider put Black Friday spending in Canada at roughly $865 million across online and in-store, up about 6 percent year over year, with Cyber Monday online sales near $668 million. Cyber Week as a whole rose about 7 percent, on a 4 percent increase in order volume. Moneris, which processes a large share of Canadian card transactions, recorded transaction volumes climbing roughly 25 percent week over week around Black Friday.
A 25 percent lift sounds manageable. It is also almost useless as a planning number, for two reasons.
The first is that aggregates smooth. That figure spans every merchant in the country, including the ones running no promotion at all. An individual small business emailing its own list a real offer does not see 25 percent. It sees a spike that arrives in minutes, tied precisely to when the email lands, and then decays. Your traffic profile on Black Friday is not a broad plateau. It is three or four sharp bursts sitting on top of an elevated baseline.
The second reason is more interesting, and it points the other way. Salesforce also noted that average selling price in Canada fell about 2 percent while order volume rose. Deeper discounts, smaller baskets, more transactions. For a marketer that is a margin story. For your website it is a load story: more orders at lower value means more requests per dollar of revenue. Every one of those orders is a full pass through the least optimisable part of your site. A weekend where revenue rises 10 percent can easily be a weekend where checkout load rises 20 percent.
This is the gap between how web hosting for small business in Canada is usually sold and how it is actually consumed. Plans are marketed on monthly visits and storage, because those are easy to compare. Promotions are consumed in bursts of simultaneous requests, which is a different unit entirely, and nobody advertises it.
Which is why the metric that matters is not daily traffic. It is peak concurrency: how many people are trying to do something on your site in the same second. Daily totals are what you report afterwards. Concurrency is what breaks things.
Find your actual peak: 20 Canadian small-business types
Black Friday is the most heavily marketed peak in the calendar. It is not necessarily yours.
Two things vary considerably by what you actually sell. The first is when the spike arrives. The second, and the more consequential technically, is which part of your site it lands on — because different parts of a website fail in different ways.
A retailer's spike lands on cart and checkout, the two pages that can never be cached. An outdoor retailer's lands on product pages running heavy stock and variant queries. A contractor's lands on a contact form on a phone, during a storm. A clinic's lands on a booking calendar. A ticketing site's lands on three URLs in the space of about ninety seconds. Those are four genuinely different engineering problems wearing the same label.
The table below maps twenty common Canadian small-business types against their real peak, the resource that tends to bind first, and where the effort is best spent. Find the row closest to your own.
| Business type | When the real peak lands | What binds first | Priority |
| Apparel & accessories (online) | Black Friday through Cyber Monday, in email-triggered bursts | Cart and checkout — uncacheable | Checkout concurrency, payment timeouts |
| Outdoor & ski retailer | Black Friday, plus the first significant snowfall | Variant and stock queries on product pages | Object caching, slow queries |
| Winter tire & auto service | First snowfall and the provincial changeover deadline — not November sales | Booking system under a phone-and-web surge | Booking availability, form uptime |
| Home & furniture | Black Friday, Boxing Day, and long weekends | Large images, and cart persistence on high-value baskets | LCP, image weight, saved carts |
| Specialty food & coffee roaster | Black Friday to mid-December, against hard shipping cutoffs | Live shipping rate calculation at checkout | Carrier API timeouts, cutoff messaging |
| Brewery or distillery (DTC) | Black Friday and December gifting | Age verification and per-province shipping logic | Checkout logic, provincial rules |
| Cosmetics & skincare | Black Friday — sharp, and heavily mobile | Main-thread work on variant selectors and quick-add | INP, third-party scripts |
| Toy & hobby retailer | Black Friday through the final shipping date | Stock accuracy under concurrent orders | Inventory locking, oversell prevention |
| Electronics & gaming | Black Friday, concentrated in the first minutes on doorcrasher items | Extreme concurrency on a handful of URLs | Page caching, bot mitigation, queueing |
| Jewellery | Black Friday through to Valentine's Day | Fraud screening on high-value checkouts | 3DS behaviour, card-testing defence |
| Independent bookstore | Black Friday to mid-December | Catalogue search — an uncacheable query | Search load, faceted filtering |
| Pet supplies & subscriptions | Black Friday alongside ordinary subscription renewals | Recurring billing running concurrently with peak orders | Gateway limits, queue and cron contention |
| Restaurant or quick-service | Reservation and order-ahead surges at meal times and around events | Order-ahead system and third-party integrations | Integration uptime, peak-hour concurrency |
| Salon or spa | Black Friday gift-card sales, then January redemption | Gift card issuance, then the booking calendar | Two separate events — plan both |
| Fitness studio or gym | January, with Black Friday used to presell memberships | Signup forms and recurring billing setup | Form reliability, payment onboarding |
| Dental or medical clinic | September and January, plus insurance year-end in December | Appointment booking and intake forms | Form logging, privacy on intake data |
| Accounting or bookkeeping | February to April — not November | Contact forms and client document upload | Upload limits, form deliverability |
| HVAC or plumbing contractor | The first cold snap and the first heatwave, with no notice at all | Emergency enquiry surge, almost entirely mobile | Mobile speed, click-to-call, form uptime |
| Landscaping & snow removal | The first storm, and spring signup season | Contract and enquiry forms during a weather event | Form uptime, mobile performance |
| Event venue or ticketing | The on-sale moment — measured in seconds | Concurrency far beyond anything Black Friday produces | Queueing, caching, bot mitigation |
Four patterns in that table are worth drawing out, because each one changes how you should read the rest of this guide.
When your peak arrives without warning
The tire shop, the HVAC contractor and the snow removal company share a problem that retailers do not have: their peak is triggered by weather, and weather does not give six weeks' notice. The first serious cold snap generates a day of emergency enquiries that behaves exactly like a promotional spike, except nobody scheduled it and there was no email send to explain it.
The counter-intuitive consequence is that the discipline in this guide matters more for these businesses, not less. A retailer can afford to be sloppy in September because they can fix things in the six weeks before a date they control. A contractor cannot, because readiness has to be a standing condition rather than a project. The practical adaptation: run the six weeks once in the early autumn, then treat the freeze as the default state and require a real reason to break it. Deploying a theme change in mid-January is a decision to gamble on the weather.
When your peak is nowhere near November
An accounting firm's heaviest weeks are February to April. A fitness studio's are in January. A clinic sees September and a December rush as insurance benefits expire. For these businesses the six-week method is entirely applicable and the calendar in this guide is not — so count six weeks back from your own date and run the same sequence.
The fitness studio is the interesting hybrid, because it has two distinct events. Black Friday is used to presell memberships, which loads signup forms and payment onboarding in November. Then the members actually arrive in January, which loads class booking and the mobile app for weeks rather than hours. Those are different failures at different times, and preparing for one does nothing for the other.
When your peak is far sharper than Black Friday
A ticketed on-sale is the most demanding load a small business is likely to face. Where Black Friday spreads over a weekend in a handful of email-triggered bursts, an on-sale concentrates the entire demand curve into the first minute or two, aimed at two or three URLs. Electronics retailers running doorcrasher pricing face a milder version of the same shape.
For these businesses, one section of this guide outranks all the others: finding the knee in the degradation curve. Capacity planning based on average traffic is meaningless when your peak-to-average ratio is in the hundreds. This is also the one scenario where a queueing system — holding visitors in an orderly line rather than letting them all through to fail together — is worth genuine investment.
When the failure is silent
Every service business in that table shares a risk the retailers do not. When a checkout fails, a customer complains and revenue visibly drops. When a contact form fails, nothing happens at all. There is no order record whose absence you would notice, no angry email, no support ticket. You simply conclude that the campaign underperformed or that demand was softer than expected.
This makes form submission logging the single highest-value addition for any service business in this guide. Log every submission independently of the email notification, so you can reconcile enquiries received against enquiries recorded. A gap between those two numbers is the only evidence you will ever get.
Related, and frequently missed: for salons, spas, restaurants and studios, the actual Black Friday product is usually a gift card. That means the November event is gift card issuance and the real load arrives in January when people redeem them — landing on the booking calendar rather than on checkout, and sustained over weeks rather than concentrated in a weekend. Two technical events, months apart, from one promotion. Prepare for both or the second one will surprise you.
The six-week map
One job per week, working backwards from launch. Whatever your own peak date, the sequence is the same — count backwards from yours. The dates below are the only place in this guide where the calendar appears, so they are the only thing that needs changing year to year.
| When | Dates | The one job | Done when |
| 6 weeks out | Oct 12–18 | Find your ceiling | You know your peak multiple and where the site breaks first |
| 5 weeks out | Oct 19–25 | Make it fast before it is busy | Core Web Vitals pass in field data and cache hit rate is verified |
| 4 weeks out | Oct 26–Nov 1 | Harden it | Rate limiting live, certificates checked, admin access audited |
| 3 weeks out | Nov 2–8 | Backups and rollback | A restore has been tested and timed, and the freeze date is set |
| 2 weeks out | Nov 9–15 | Test the money path | A real discounted order completes end to end on a phone |
| 1 week out | Nov 16–22 | Rehearse, then freeze | Monitoring alerts to a phone and nothing is changing |
| Launch | Nov 27–30 | Watch and triage | You are answering customers, not editing the site |
| After | December | Measure and keep | Peak numbers recorded and the promo URL decision made |
Six weeks out: find your ceiling
You cannot prepare for a load you have not quantified. This week is measurement, and it is the week people skip because it produces no visible improvement to the site. It is also the week that determines whether the other five weeks are aimed at the right problem.
Start from your own numbers
Website traffic spike preparation begins with measurement, and the measurement is yours to take. Open your analytics and pull twelve months of sessions. Find last year's peak day. Find an ordinary Tuesday in the same period. Divide one by the other. That ratio is your historical multiple, and it is worth more than any industry benchmark, because it reflects your list, your channels and your customers.
Then go finer. Daily sessions hide the shape you actually care about, so look at hourly data for last year's peak day and find the busiest hour. If your analytics will give you concurrent users or active users in real time, note the highest figure you can find. That is the number to plan against.
If you have no historical data — a new site, or a first promotion — you are planning under genuine uncertainty, and the honest response is to build headroom rather than to guess a multiple. Everything below is about finding out where your limit sits, which matters more when you have no history to lean on.
What actually breaks first
Almost nobody runs out of bandwidth. Bandwidth is the resource people worry about and the one that is rarely binding on a small site. The things that actually run out are less visible.
| Resource | What it is | What running out looks like | Where to check |
| PHP workers | The number of requests your server can process at once | Requests queue. Time to first byte climbs while CPU looks fine | Host control panel, PHP-FPM status |
| Entry processes | A shared-hosting cap on concurrent connections | "508 Resource Limit Reached" for some visitors and not others | cPanel resource usage |
| Memory | Per-process RAM limit | White screens or 500 errors on specific heavy pages | PHP error log |
| Database connections | Maximum simultaneous connections | Intermittent "error establishing a database connection" | MySQL error log |
| CPU | Processing allocation, often shared | Everything slows more or less uniformly | Host resource graphs |
| Disk I/O | Read and write throughput | Slow queries and slow uploads with normal CPU | Host metrics |
| Bandwidth | Data transferred | Rarely the constraint. Check it, then move on | Host billing panel |
The distinction that matters most on shared and entry-level hosting is between capacity and concurrency. Your host does not usually limit how much work you can do in an hour. It limits how much you can do at once. Ten simultaneous checkout requests against a plan permitting twenty concurrent processes is comfortable. Ninety is not — and the ninety-first visitor sees an error page while your CPU graph looks entirely unremarkable. People chase the CPU number because it is the one they understand, and miss the process ceiling sitting quietly at 100 percent beside it.
Run an actual load test
Load testing has a reputation for being an enterprise activity. It is not; several services will run a modest test for the price of a coffee. The reason small businesses get little from it is that they test the wrong thing.
Test the journey, not the homepage. A homepage load test is close to worthless, because your homepage is cacheable and your checkout is not. Serving ten thousand cached homepages proves your cache works. Model the real path instead: landing page, category, product, add to cart, checkout. That sequence exercises the parts that cannot be cached, which is where your ceiling actually lives.
Look for the knee, not the verdict. The useful output is not "did it survive" but the shape of the degradation curve — response time plotted against concurrent users. For a while it rises gently. Then it turns and goes near-vertical. That inflection point is your capacity, expressed in the only unit that matters. Knowing it sits at 40 concurrent users rather than 400 changes every decision that follows.
Watch the error rate more closely than the average. Average response time is a comforting number that hides disasters. A 2 percent error rate at checkout looks like nothing in an average and is a catastrophe in reality. Track errors separately, by page.
Two practical notes. Test against staging where you can. And tell your host before you start, because an unannounced load test looks exactly like an attack and gets throttled or blocked, which produces results that mean nothing.
The upgrade decision, and why it belongs to October
If the test says your ceiling is below your expected peak, you have three levers: reduce the work per request (weeks five and two), raise the ceiling, or both. Raising the ceiling means changing environment.
| Environment | What it changes | Honest trade-off |
| Shared hosting | Nothing structural. You share a server and live within concurrency caps | Cheapest, and the caps are invisible until a promotion finds them |
| Managed WordPress | Tuned stack, server-level caching, often object caching included | Removes most performance work, but plugin restrictions can conflict with commerce setups |
| VPS | Dedicated, guaranteed resources you control | Real capacity, but somebody has to administer it — budget for that or buy it managed |
| Dedicated server | The whole machine | Rarely the right answer for a small business until sustained load justifies it |
For a great many small businesses the honest answer sits in the middle of that ladder. Managed WordPress hosting in Canada removes most of the performance work described in the next section — server-level caching, object caching and a tuned stack arrive configured rather than as a project — while a VPS is the right call once you need resources nobody else can contend for. Either way, the decision is about headroom on the weekend rather than about average monthly traffic.
The timing point is the one worth internalising. If you are going to change environment, the change must be complete and stable well before launch. Not the week before. Migration is itself a risk event: DNS needs to propagate, caching behaves differently on a new stack, a PHP version bump surfaces a plugin incompatibility, file permissions shift, cron jobs quietly stop. None of that is hard to fix given a fortnight. All of it is unfixable on Black Friday morning.
Give yourself at least two weeks of ordinary trading on the new environment before the freeze. Decide in the week of 12 October, migrate in the week of 19 October, and you have a month to find what broke. Decide in mid-November and you have made your infrastructure the largest untested variable in your biggest weekend.
There is a cost dimension too. Server memory pricing has been under real pressure through 2026 as AI infrastructure demand absorbed DRAM supply, and that has fed through to hosting and hardware costs. If more memory is part of your answer, waiting is not free.
Ten questions to ask your hosting provider
Most of this week's work is measurement you do yourself. This part is a conversation, and it is worth having in October while support queues are short. Any leading Canadian web hosting provider should be able to answer these without hesitation or escalation — and how quickly you get a straight answer tells you something useful in itself.
- What is my concurrent process or PHP worker limit, and what happens when I reach it? The answer is the single most important number in this guide, and it is rarely printed on a pricing page.
- Is that limit burstable, and can it be raised temporarily for a known peak weekend? Many providers can lift a cap for a weekend. Some will do it in minutes. You cannot benefit from a policy you have not asked about.
- Where is my server physically located, and does my data stay in Canada? This determines checkout latency for Canadian visitors and simplifies your PIPEDA position. Providers of web hosting for small business in Canada should be able to name the facility, not just the country.
- Is object caching available on my plan? Redis or Memcached is what keeps your uncacheable pages — cart, checkout, account — from hammering the database. On managed WordPress hosting in Canada it is often included; on entry-level shared plans it frequently is not.
- What is your support availability at three in the morning on a Saturday? Ask specifically about channel, not just hours. A ticket queue and a phone line are different products at 3am on Black Friday weekend.
- What backup frequency and retention do I have, and can I trigger a restore myself? Self-service restore is worth a great deal when the alternative is waiting in a queue behind every other site on the same platform.
- Do I get a staging environment, and does it mirror production? Staging that runs a different PHP version or has caching disabled will hide the exact bugs you are looking for.
- Is there a firewall or rate limiting at the network edge, or is that my responsibility? Absorbing bad requests before they consume one of your processes is worth more than any plugin-level equivalent.
- What is the process and notice period for a temporary upgrade, and can I downgrade afterwards? Ask about the downgrade before you upgrade, not in January.
- Will a load test be flagged as an attack, and how do I whitelist one? Ask before you run it, or your results will measure your provider's intrusion detection rather than your site.
The pattern in those answers matters more than any individual one. A provider who can tell you your process ceiling, lift it for a weekend, and point you at a staging environment is a partner in this work. A provider who cannot find the number is telling you where your ceiling is going to be discovered instead — which is on the morning itself. This is genuinely what separates a leading Canadian web hosting provider from a cheap one, and price comparisons almost never surface it.
Where the server sits, and why a CDN does not settle it
For a Canadian audience, server location is a performance question before it is a compliance one. A visitor in Halifax hitting a server in Toronto experiences a round trip measured in tens of milliseconds. The same visitor hitting a server in Virginia or Frankfurt pays that penalty repeatedly, and the multiplication is the point: a checkout is not one request but a sequence of them, each waiting on the last.
This is precisely where a content delivery network stops helping. A CDN caches static assets at an edge node near your visitor, and it does that well. It cannot cache your cart, your checkout or your account pages, because those are unique to each person and change on every request. Those requests travel all the way to your origin server every single time. Server location therefore determines checkout speed in a way no CDN can fix, which is the opposite of the usual assumption.
This is the practical case for choosing a Canadian web hosting provider rather than the cheapest option on a global marketplace: the distance between your server and your customer is a fixed cost paid on every uncacheable request, and it is the one performance variable you cannot optimise your way out of after the fact. Providers with Canadian infrastructure, 4GoodHosting among them, remove that penalty for a domestic audience by default.
The compliance layer sits on top. A promotion generates personal information — new subscribers, new customers, shipping addresses, purchase histories. PIPEDA obligations attach to that data wherever it is stored, so hosting in Canada is not a compliance shortcut. What it does do is simplify the cross-border transfer and disclosure questions, and make the answer to "where is my data" a short one. For businesses serving Quebec customers, Law 25 adds its own requirements on top of the federal regime.
Five weeks out: make it fast before it is busy
You now know where your ceiling is. This week is about reducing the work each request demands, which raises the effective ceiling without spending anything on infrastructure. Black Friday site speed is not a separate discipline from ordinary site speed — it is ordinary site speed measured on the one weekend when the margin for error disappears.
Core Web Vitals, and why passing today does not mean passing then
The three metrics Google evaluates, with the thresholds that count:
| Metric | What it measures | Good | Notes |
| LCP (Largest Contentful Paint) | How long until the main content renders | 2.5s or less | Includes server response time |
| INP (Interaction to Next Paint) | Responsiveness across every interaction in the visit | 200ms or less | Replaced First Input Delay in March 2024 |
| CLS (Cumulative Layout Shift) | Unexpected movement as the page loads | 0.1 or less | Usually images and ads without reserved space |
| TTFB (diagnostic only) | Server response time | 0.8s or less | Not a Core Web Vital, but it drives LCP |
All three are assessed at the 75th percentile of real visits, which is the detail that makes this a Black Friday problem rather than a general hygiene problem. You do not need every visit to be fast. You need three quarters of them to be. That sounds forgiving until your traffic mix changes.
And it changes considerably during a promotion. Deal traffic skews to mobile. It arrives from email and social rather than search. It is more often on cellular than on wifi. It lands on pages your cache has not seen recently. Every one of those shifts drags your 75th percentile in the same direction, and it happens before the server is under any strain at all. A site comfortably passing in October can fail in the field in late November purely on composition.
Then load arrives and compounds it. LCP contains server response time, so if your server answers in 400 milliseconds normally and 2.2 seconds at peak, your LCP fails at peak regardless of how well the front end is built. No amount of image optimisation rescues a slow server. This is the point at which hosting stops being a background expense and becomes a ranking and conversion input.
One measurement caution: Lighthouse and PageSpeed Insights run a single synthetic test on a simulated connection. Search Console reports field data from real Chrome users, which is what Google ranks on. Use the lab tools to diagnose and the field data to decide. A green Lighthouse score is not readiness.
Caching, and the promotion problem nobody warns you about
It helps to know which layer does what, because the failures are layer-specific:
- Browser cache — the visitor's own copy of your static files. Free, and irrelevant to a first-time visitor, which most promotional traffic is.
- Page cache — a pre-built HTML copy of a page, served without touching PHP or the database. The single biggest win available.
- Object cache — database query results held in memory, usually Redis or Memcached. Matters enormously for pages that cannot be page-cached.
- OPcache — compiled PHP held in memory so it is not recompiled per request. Usually on by default; confirm rather than assume.
Now the part that catches people out: your cache hit rate collapses at exactly the moment you need it, and for two avoidable reasons.
The first is tracking parameters. Every link in every campaign carries something like `?utmsource=email&utmcampaign=bf-early`. Many caching configurations treat each distinct URL as a distinct cache entry, so forty campaign variants pointing at one landing page become forty separate cache misses on the same page. The fix takes minutes: configure the cache to ignore known tracking parameters when generating cache keys. The cost of not doing it is that your most-visited page of the year is effectively uncached.
The second is personalisation. A "3 items in your cart" indicator in the header makes the entire page uncacheable, because the HTML now differs per visitor. Most commerce platforms can load that fragment separately after the page arrives. If yours cannot, consider whether the indicator is worth what it costs you.
Which leads to the structural point. Some pages can never be cached: cart, checkout, account, and anything showing live stock or personalised pricing. Every request to those hits PHP and the database in full. That is where your ceiling lives. Caching makes your product pages survive an enormous spike. It does nothing whatsoever for the four pages where money changes hands. Plan accordingly, and stop treating a high cache hit rate as evidence of readiness.
Worth noting where this work has already been done for you: a managed WordPress hosting in Canada environment typically arrives with server-level page caching and object caching configured, which removes most of this section from your list. On an entry-level shared plan it is generally yours to build.
One practical habit: pre-warm the cache after any change. Crawl your own promo page and top products so the first real visitor is not the one paying to generate the cache entry.
The database
Databases accumulate. On a site that has been trading a few years, a meaningful share of the tables is material nobody will ever read again: post revisions, expired transients, orphaned metadata, log tables from plugins removed long ago, and abandoned session and cart data.
Three things to check specifically:
- Autoloaded options. On WordPress, everything marked autoload in the options table is loaded on every single request, including checkout. Bloated autoload is a tax on every page view. Measure it; anything past a few hundred kilobytes deserves investigation.
- Session and cart tables. Commerce plugins generate a row per visitor session. On a site that has never been cleaned, these are frequently the largest tables present, and they are queried during checkout.
- Slow queries. Turn on the slow query log for a week. Queries that are merely slow at twenty concurrent users are site-ending at two hundred, and they are almost always the same handful of queries.
Do this now rather than later, because the verified backup you take at the freeze should be of a clean database.
The front end
Images first, because they are usually the LCP element. Serve WebP or AVIF, at the dimensions actually displayed, with explicit width and height attributes so the browser reserves space and CLS stays low. Lazy-load everything below the fold — and specifically do not lazy-load the LCP element itself, which is a common own-goal that adds a full round trip to your headline metric.
Then third-party scripts, which is where INP goes to die. Every chat widget, heatmap recorder, review embed, advertising pixel and A/B testing script executes JavaScript on the main thread, and the main thread is what has to be free for the browser to respond to a tap. A site running four analytics tools has four competing claims on the resource that determines whether your "add to cart" button feels instant.
A defensible rule for the promotion period: load only what you will act on. If nobody will look at the heatmaps until January, the heatmap tool can wait until January.
Four weeks out: harden it
A well-publicised promotion is a signal to more people than your customers. This week is about the traffic you did not ask for, and about closing the doors you will not want to touch once the freeze begins.
Peak season is bot season
Three patterns intensify predictably during a sale:
Scrapers. Competitors and price-aggregation services hitting product pages hard to track your pricing. The traffic looks legitimate, carries no malicious payload, and consumes real server capacity — often at precisely your busiest hour, because that is when your prices change.
Credential stuffing. Automated attempts to log in using passwords leaked from other breaches. Elevated at peak for a rational reason: a compromised customer account is worth more when it holds a saved card and there is a plausible flood of legitimate orders to hide inside.
Card testing. The one that catches small businesses out, because it does not look like an attack. Someone runs stolen card numbers through your checkout in small amounts to identify which are live. The costs stack up quickly: per-transaction gateway fees on hundreds of declines, chargebacks on the successes, and a rising fraud ratio that can put your merchant account under review. For our purposes there is a fourth cost — a card testing run hammers the single least cacheable page you have. It can slow your checkout as effectively as a genuine traffic spike, and you will spend an hour looking for a performance problem that is actually a fraud problem.
What to put in place:
- Rate limiting on login, checkout, coupon validation and the REST API. Coupon endpoints deserve specific attention during a sale, because discount-code brute forcing is a real and seasonal behaviour.
- A web application firewall at the edge, so bad requests are absorbed before they reach your server and consume a worker.
- CAPTCHA placed with care — on login and coupon submission, not on checkout, where it costs measurable conversions. Bot mitigation that reduces sales is not a win.
- Gateway-side controls. Velocity rules and 3D Secure thresholds are configured with your payment processor, not on your site. Have that conversation this week, because it is not a same-day change.
- Close what you do not use. Disable XML-RPC if nothing depends on it, restrict access to the login page, and check whether your REST API is enumerating usernames to anyone who asks.
Certificates, and the dates nobody diarises
Check the expiry date on every certificate you own, and look specifically for anything falling due between mid-November and mid-December. If you find one, renew it now rather than trusting auto-renewal to work unattended on a holiday weekend.
An expired certificate on Black Friday morning does not degrade your conversion rate. It ends it, because every visitor meets a full-page browser security warning before they see your site. It is a low-probability, total-loss event, and it takes five minutes to rule out.
While you are there, check for mixed content — a single asset loaded over plain HTTP on the checkout page will trigger browser warnings on the page you can least afford them — and confirm the certificates covering subdomains, any CDN custom domain and your payment callback URL, all of which are easy to forget because they are not the main site.
Access, before the freeze
Audit who holds administrator access, and be unsentimental about it. The developer who built the site in 2023. The agency you stopped working with. The former employee. The plugin support engineer you granted temporary access to and never revoked.
Rotate shared passwords, enforce two-factor authentication on every administrator, and reduce roles to what each person actually needs to do their job. Content editors do not need the ability to install plugins.
This belongs at four weeks out for two reasons. Permission changes have a habit of breaking integrations in ways that take a few days to surface, so you want them well clear of the freeze. And an administrator account compromised through credential harvesting aimed at site owners is a problem you want to have discovered in October, not at nine o'clock on Black Friday morning.
PIPEDA, Law 25 and CASL during a promotion
Promotions are data-collection events. New subscribers, new customer records, shipping addresses, contest entries, purchase histories. Three obligations are worth being deliberate about before the volume arrives.
Consent under PIPEDA must be meaningful and purpose-specific. A checkout that quietly enrols people in marketing because they bought something is a consent problem dressed up as a growth tactic. Keep the marketing opt-in separate, unchecked, and clearly worded.
Know your breach process before you need it. PIPEDA requires organisations to report breaches to the Office of the Privacy Commissioner and notify affected individuals where the breach creates a real risk of significant harm, and to keep records of breaches regardless. Decide now who makes that assessment and who contacts the regulator. Working it out during an incident, on a weekend, is how deadlines get missed.
CASL applies to the campaign itself. Express or implied consent, clear sender identification, and a working unsubscribe on every commercial message. Implied consent arising from an existing business relationship expires, so a list you have not mailed in a long time may not be a list you are entitled to mail. Check the basis before you send, not after a complaint.
For businesses with Quebec customers, Law 25 layers additional requirements over the federal regime, including a designated person responsible for privacy and assessments for certain projects. If a promotion involves new data collection or a new tool processing personal information, that is worth a conversation with counsel rather than an assumption.
Three weeks out: backups and the rollback plan
Everything so far has been about avoiding failure. This week is about surviving it, which is a different discipline and the one most likely to be handled with unfounded optimism.
A backup you have not restored is a hypothesis
The uncomfortable truth about backups is that most people know they have them and almost nobody knows whether they work. Backups fail quietly, for mundane reasons: the job stopped running months ago, it excludes the uploads directory, it captures files but not the database, it captures the database but not the tables a plugin created, or it succeeds perfectly and takes nine hours to restore.
So restore one. To a staging environment, this week, and then check specifics rather than glancing at the homepage. Does the site load. Do the most recent orders exist. Do product images resolve or is the uploads directory empty. Does checkout complete. Do customer logins work. Are the coupon codes there.
And time it. That number is your recovery time, and it is the number that turns an abstract reassurance into a decision.
Two numbers, in plain language
Underneath backup strategy sit two questions worth answering explicitly:
How much data can you afford to lose? This sets backup frequency. An overnight backup means that a failure at 4pm on Black Friday loses a day of orders — orders your customers have paid for and expect to receive. During the peak window specifically, consider increasing database backup frequency to hourly or continuous. Note the asymmetry: during a sale the database changes constantly while your files barely change at all, so increase database frequency and leave file backups alone.
How long can you afford to be down? This sets your restore approach. If a full restore takes six hours, that is six hours of Black Friday, and a faster restore path is worth paying for.
Then there is location. A backup on the same server as the site is not protection against server failure, and a backup inside the same hosting account is not protection against account compromise. Keep at least one copy somewhere you can reach without access to your hosting account.
Staging, and what it is actually for
Build the promo page, the site-wide banner, the coupon logic and any theme change on staging. Not on production at eleven at night with the offer going live in the morning.
For staging to be useful it has to resemble production: the same PHP version, the same plugin versions, and the same caching layer if at all possible. A staging site with caching switched off will not reveal the caching bug, which is the class of bug most likely to bite you. Then push to production once, deliberately, with a rollback ready — not incrementally over a fortnight.
The change freeze
Pick a date and write it down where the whole team can see it. One week out is a reasonable freeze for a small business; two is better if your build allows.
What the freeze covers: plugin and theme updates, PHP version changes, new integrations or tracking scripts, hosting migrations, DNS changes, and anything touching checkout.
What it does not cover: security patches for actively exploited vulnerabilities, factual corrections to prices and content, and stock updates. A freeze that stops you fixing a wrong price is a bad freeze.
Write the exception process down too, in one line: who approves an exception, and the standing rule that any exception is preceded by a fresh backup. Exceptions are not the problem. Undocumented exceptions made at speed by whoever happened to be logged in are the problem.
The rollback plan
Not a concept. A single page, written now, that answers:
- Who has access to revert, and confirmation that their credentials currently work — test this, do not assume it
- The exact steps to restore the previous version, specific enough for someone else to follow
- How long that takes, from the timed restore you just ran
- Who decides to do it, so nobody is seeking permission during an incident
- What customers see while it happens — draft the holding message now, when you can write it calmly
Keep it somewhere that does not depend on the site being up. Printed, or in a shared document. A rollback plan stored only in the WordPress admin is a rollback plan you cannot read when you need it.
Two weeks out: test the money path
Everything up to here has been infrastructure. This week is the conversion path, tested as a path rather than as a collection of pages.
Test the journey, then break it deliberately
Run the whole sequence with a real card at the real discount: land on the promo page, browse, add to cart, apply the coupon, check out, pay, receive the confirmation email, see the order appear in admin, then refund it.
Then run it again under conditions that resemble reality. On a phone. On cellular data rather than office wifi, because your customers are not on your office wifi. In a different browser. As a logged-out guest. As a returning customer with a saved address.
Then break it on purpose, because every one of these will happen this month:
- An invalid coupon code, and an expired one
- A valid coupon applied to an excluded product
- A quantity larger than your actual stock
- A declined card, then a successful retry
- The browser back button pressed mid-payment
- Two tabs open, both adding to the same cart
What you are looking for is not whether these are prevented but whether they fail comprehensibly. A customer who sees "coupon not valid for this item" recovers. A customer who sees a blank page leaves and does not come back.
Plugins and the update paradox
Two things are both true. Unpatched plugins are the leading route by which small WordPress sites are compromised. And updating plugins is the leading route by which small WordPress sites break. The resolution is sequencing: patch now, freeze after.
So this week, update everything — on staging first, then production, then run the money path test again, because a plugin update that breaks checkout is exactly the failure this exercise exists to catch.
While you are in there, audit what actually loads on checkout. A great many plugins enqueue their scripts and styles site-wide when they are needed on one page. A booking calendar's assets have no business loading on your checkout, but by default they very often do. Every unnecessary script there costs you INP and adds work to a page that cannot be cached. Conditional asset loading on checkout is the highest-leverage optimisation most small commerce sites never make.
Then deactivate and delete what you do not use. A deactivated plugin still has its code sitting on your server, still reachable, still a potential vulnerability. Deactivated is not removed.
Payments and tax
Sign in to your payment processor and check four things:
- Processing limits, monthly and per transaction. A weekend that triples volume can meet a cap you have never approached and never thought about.
- Payout schedule across the holiday period, and any incomplete account verification. A held payout in December is not an inconvenience, it is a cash flow event.
- Timeout behaviour. If the gateway responds slowly, does your checkout create a duplicate order, lose the order, or handle it gracefully? Test it, because at peak the gateway will be slow at some point.
- 3D Secure behaviour on mobile, which is where the majority of your promotional traffic will be, and where authentication flows most often go wrong.
On tax: confirm GST, HST, PST and QST handling is correct for every province you ship to, and that discounts apply before tax in the right order. Sale pricing routinely exposes a tax configuration that was quietly wrong all year, because a discount is the first thing that makes the arithmetic visible.
Transactional email is the email that must not fail
There is a meaningful difference between the two kinds of email you send that weekend. A marketing send landing in spam is a disappointing campaign. An order confirmation failing is a support crisis, a trust problem and a chargeback risk, because a customer who cannot see proof of purchase assumes something went wrong.
Three things to get right:
Authentication. SPF, DKIM and DMARC configured for your sending domain. Major mailbox providers now require authentication from bulk senders, so this affects delivery of the campaign as well as the receipts.
Do not send transactional email from your web server. Shared hosting IP addresses carry poor sender reputation through no fault of yours, and your web server should not be spending capacity on SMTP during peak. Route it through a dedicated transactional provider.
Separate the streams. Keep transactional and marketing email on different subdomains or different providers, so a campaign that generates complaints cannot damage the deliverability of your order confirmations.
Then test properly: send a real order confirmation to a Gmail address, an Outlook address and a corporate address, and check the inbox rather than the sent folder. Finally, check whether email sends synchronously during checkout. If it does, a slow mail server slows your checkout, and moving sends to a background queue is a genuine performance fix.
If you sell services rather than products
The same logic applies to a different path: the booking form, calendar availability, the confirmation email, the deposit payment, and the reminder sequence.
One distinction is worth flagging. Forms fail silently far more often than checkouts do, because there is no order record whose absence you would notice. A checkout failure produces an angry customer. A form failure produces silence, and you conclude the campaign underperformed. Add submission logging, so that you can prove an enquiry arrived and reconcile against your enquiries received.
One week out: rehearse, then freeze
No new work this week. Confirmation, then stillness.
The dress rehearsal
Do it as one continuous sequence, in one sitting, with the people who will be working the weekend:
- Publish the promo page to a staging URL and click every single link, including the footer
- Send the first campaign email to yourself and two colleagues, then click through from the actual email on an actual phone
- Place a real discounted order, end to end, and let the confirmation arrive
- Raise a support enquiry and answer it using the template you intend to use
- Open your monitoring dashboard and confirm it is showing live data rather than a blank panel
Fix what breaks. Then freeze.
Monitoring you will actually notice
Four layers, none expensive:
- Uptime monitoring at one-minute intervals from several locations — checking a real page such as a product or checkout page rather than only the homepage, and checking for expected content rather than a 200 status code. A page can return 200 and display an error.
- Real user monitoring for performance, so you are seeing what visitors experience rather than what a synthetic test experiences.
- Error logging with alerting for PHP errors, JavaScript errors and failed payments. A spike in payment failures is arguably the single most valuable alert available to you.
- Server resource alerts from your host on CPU, memory and process count, set to fire at eighty percent of your limit rather than at a hundred.
Alerts go to a phone. Nobody reads email on Black Friday morning.
And set one more, which is not technical at all: a transaction alert. If orders per hour fall to zero during a window when you would expect orders, something is broken. That single alert catches whole classes of failure no infrastructure monitor will ever see — a coupon that stopped applying, a payment method silently rejecting, a form no longer submitting. It is the closest thing to a universal canary.
The one-page war sheet
Everything on a single page, printed and shared with everyone working the weekend:
- Host support: phone number, chat URL, account number and the escalation path — the answers you collected in October from your provider, whether that is 4GoodHosting or anyone else. Establish now whether your plan includes live support at three in the morning on a Saturday, because assuming it does is a common and painful discovery.
- Payment gateway support line and your merchant ID
- Developer or agency contact, and their actual availability that weekend — ask them, do not assume
- Domain registrar and DNS provider logins
- Where administrator credentials are stored
- The rollback document
- Who is on call, in which hours, with what authority to act
Cutoffs and expectations
Carriers publish their holiday shipping deadlines during the autumn. Look up the current published dates for the carriers you actually use, then work backwards through your own handling time — and be honest about it, because one-day handling becomes three-day handling on a four-hundred-order weekend.
Publish the resulting order-by dates everywhere a customer might look: product pages, the cart, the promo page and every email. Then set the rest of your expectations on the site itself, in plain terms: shipping timelines, support hours, and the return window for sale items, which is the question your support inbox will receive most.
Then take a fresh backup, confirm the restore works, and stop changing things.
Launch weekend: watch and triage
If the six weeks are done, this weekend contains no building. It contains observation, customer service, and occasionally triage.
The diagnostic order
When the site slows, the instinct is to start changing things. Resist it, and work through this in sequence instead:
- Is it actually slow, or is it one person's connection? Check your monitoring and try a second network before acting on a single report.
- Is it slow everywhere, or on one page? A slow checkout alongside fast product pages points at the database or the gateway. Slow everywhere points at the server.
- Is time to first byte high, or is rendering slow? High TTFB is server-side: your host, your database, your PHP. Slow rendering with healthy TTFB is front-end, and is usually a third-party script.
- Read the error log before you touch anything. It usually just tells you.
- Check your host's resource graphs and look for a resource pinned at 100 percent of its limit — remembering that the process ceiling is the one that hides behind a calm CPU graph.
- Check whether the traffic is real. A spike with no corresponding email send or ad spend is a bot, and the fix is blocking rather than scaling.
Levers you can pull safely
In rough order of increasing disruption:
- Increase cache aggressiveness and extend cache lifetimes
- Turn off site search and faceted filtering, both of which are expensive uncached database queries
- Disable non-essential plugins: heatmaps, A/B tests, review widgets, related-product recommendations
- Disable the cart-count fragment so pages become fully cacheable again
- Serve a static holding version of the promo landing page
- Ask your host to temporarily raise your resource limits — many can do this within minutes if you ask, and none can if you do not. This is the lever you established in October when you asked your provider question two
- Rate-limit or block a specific bad actor by IP address or user agent
What not to do, under any circumstances
Do not deploy code. Do not update plugins. Do not change hosting. Do not change DNS. Do not install a new caching plugin to see whether it helps.
Each of those has a failure mode considerably worse than a slow site, and you have no time to test and no appetite for a rollback mid-weekend. If you genuinely must change something, take a backup first — yes, even at seven in the morning.
Record what happens
Ten minutes of note-taking during the weekend is worth more than a day of reconstruction in January. Screenshot the resource graphs at peak. Write down peak concurrent users and peak orders per hour. Note the time of each email send and what traffic did in the twenty minutes afterwards. Note anything that broke and what you did.
You will not remember any of it accurately, and this is next year's baseline.
After: measure and keep
The post-mortem, within a week
Hold it while the detail is still recoverable. Four questions:
- What was our actual peak, in concurrent users and orders per hour?
- Where did the degradation curve turn out to be, compared with the load test?
- What broke, and was it what we expected to break?
- What did we spend time on that turned out not to matter?
That last question is the valuable one, and the one most post-mortems skip. Record the peak numbers formally somewhere you will find them, because next year's six-weeks-out task begins with this document rather than with guesswork.
What to do with the promo URL
This gets almost no attention in Black Friday content, and it has real consequences.
You built a landing page. Through November it earned links, social shares and traffic. On 1 December it sells nothing. There are three options and the two obvious ones are both poor:
- Delete it. Anything it earned is discarded, and anyone following an old link meets a 404.
- Redirect it to the homepage. Search engines generally treat a redirect to an irrelevant destination as a soft 404, so most of the accumulated value evaporates anyway.
- Keep one permanent URL and repurpose it annually. This is the answer. Use a year-agnostic slug, refresh the content each season, and let the page accumulate authority and links across years rather than starting from nothing each autumn. Between seasons, turn it into a standing offers-and-promotions page, which quietly captures everyone searching your brand name alongside "discount" or "sale" for the other eleven months.
The corollary matters as much: do not create a fresh dated URL every year. A folder of near-identical seasonal pages competing with each other for the same query is a textbook route to thin, duplicative content that search engines crawl and decline to index. One URL, updated.
The downgrade question
If you upgraded your environment in October, do not reflexively downgrade in December. Look at December and January traffic first, and note that Canadian retail carries a second peak on Boxing Day that some businesses find comparable to Black Friday. Decide in February, with three months of data, rather than in December on instinct.
Common mistakes
| The mistake | Why it costs you |
| Optimising the homepage and ignoring checkout | The homepage is cacheable and cheap. Checkout is neither, and it is where the money is |
| Load testing only cacheable pages | Proves the cache works. Says nothing about the ceiling that actually binds |
| Treating a green Lighthouse score as readiness | Lab data on one simulated connection. Google ranks on field data at the 75th percentile |
| Migrating hosts in November | Makes your infrastructure the biggest untested variable in your biggest weekend |
| Backups that have never been restored | An untested backup is a belief, not a capability. Most failures are silent |
| Uptime monitoring that checks the homepage for a 200 | A cached homepage can return 200 while checkout is entirely broken |
| No transaction alert | Technical monitoring stays green through a coupon failure, a payment rejection or a broken form |
| Adding tracking scripts in the final week | Each one competes for the main thread that determines whether your buttons feel responsive |
| One person holding every credential | That person will be unreachable at the moment you need them. Assume it |
| A new dated landing page every year | Builds a folder of near-duplicate pages that compete with each other and struggle to get indexed |
The Black Friday checklist: six weeks at a glance
Six weeks out — find your ceiling
- Pull twelve months of analytics; identify last year's peak day and peak hour
- Calculate your peak-to-normal multiple
- Identify which resource binds first: processes, memory, database connections, CPU
- Run a load test on the full purchase journey, not the homepage
- Find the knee in the degradation curve and record it
- Decide on any environment change, and schedule it for next week at the latest
Five weeks out — make it fast
- Check Core Web Vitals in Search Console field data, not just PageSpeed Insights
- Confirm the cache ignores tracking parameters when generating cache keys
- Identify which pages can never be cached and accept them as your ceiling
- Clean the database; check autoloaded options and session tables
- Enable the slow query log and review it
- Convert images to WebP or AVIF with explicit dimensions; stop lazy-loading the LCP element
- Audit third-party scripts and remove what you will not act on
Four weeks out — harden it
- Rate-limit login, checkout, coupon validation and the REST API
- Confirm WAF coverage at the edge
- Discuss velocity rules and 3D Secure thresholds with your payment processor
- Check every certificate expiry date; renew anything due Nov–Dec now
- Check for mixed content, especially on checkout
- Audit and revoke administrator access; enforce two-factor authentication
- Confirm marketing opt-in is separate and unchecked at checkout
- Identify who assesses and reports a privacy breach
Three weeks out — backups and rollback
- Restore a backup to staging and verify orders, images, checkout and logins
- Time the restore and record the number
- Increase database backup frequency for the peak window
- Confirm at least one backup copy lives outside the hosting account
- Set up staging matching production, including caching
- Set the freeze date and publish it to the team
- Write the one-page rollback plan and store it off-site
Two weeks out — test the money path
- Complete a real discounted order end to end, then refund it
- Repeat on a phone, on cellular data, as guest and as returning customer
- Test the failure cases: bad coupons, excluded items, declined cards, back button
- Update all plugins on staging, then production, then retest checkout
- Audit and conditionally load checkout assets
- Check processing limits, payout schedule, timeout behaviour and 3DS on mobile
- Verify provincial tax handling and discount-before-tax ordering
- Confirm SPF, DKIM and DMARC; move transactional email off the web server
One week out — rehearse, then freeze
- Run the full dress rehearsal in one sitting with the weekend team
- Confirm uptime, RUM, error and resource monitoring are live and alerting to phones
- Set the transaction alert on orders per hour
- Complete the one-page war sheet and print it
- Publish carrier order-by dates everywhere a customer looks
- Take a fresh backup, verify the restore, and freeze
FAQ
When should I start preparing my website for Black Friday?
Black Friday website preparation should start six weeks before the date, which means mid-October for a late-November Black Friday. That runway exists because the tasks have dependencies: you cannot decide whether to upgrade hosting until you have load-tested, you should not load-test a database you are about to clean, and you need at least two weeks of ordinary trading on any new environment before you freeze changes. Marketing preparation can start earlier and often should. Technical preparation compresses badly, because each step assumes the last one is finished.
Will my website crash on Black Friday?
Probably not, and that is part of the problem. Complete outages are relatively rare. What happens far more often is degradation: pages still load but slowly, checkout times out for some visitors, confirmation emails queue up. None of that registers as downtime, so uptime monitoring stays green and the lost revenue is invisible. Plan for slowness rather than for a crash, and monitor checkout specifically rather than the homepage.
How much traffic can my hosting plan handle?
Almost certainly not the number in your plan's marketing material, because those figures describe monthly visits or bandwidth and neither is what constrains you. The binding limit is normally concurrency — how many requests your plan lets you process simultaneously — and on shared hosting that is often a fixed process cap you can hit while your CPU usage looks entirely normal. The only reliable answer comes from load-testing your own purchase journey and finding where response time turns sharply upward. Ask your Canadian web hosting provider directly for your concurrent process limit — it is the number that governs everything else, and it is almost never stated on a pricing page.
Do I need to upgrade hosting for Black Friday?
Only if a load test shows your ceiling is below your expected peak, and even then reducing the work per request is often cheaper and faster than adding capacity. Where an upgrade is the answer, the usual step for web hosting for small business in Canada is from a shared plan to either managed WordPress hosting in Canada or a VPS, depending on whether you want the performance work handled for you or want resources nobody else contends for.
Timing is the harder constraint. If you do upgrade, do it six to five weeks out, never in November. Migration carries its own risks — DNS propagation, caching differences, plugin incompatibilities after a PHP version change — and those are routine to resolve with a month of trading ahead of you and impossible to resolve on the morning itself.
How do I test my website under load?
Use a load-testing service to simulate concurrent users following your real purchase path: landing page, category, product, add to cart, checkout. Do not test the homepage alone, because it is cacheable and will pass regardless. Watch three things — average response time, the error rate broken down by page, and the shape of the curve as concurrency rises. The point where response time stops rising gradually and turns near-vertical is your practical capacity. Test against staging where possible, and tell your host beforehand so the test is not mistaken for an attack.
When should I stop making changes to my site before Black Friday?
One week out at minimum; two is better. The freeze should cover plugin and theme updates, PHP version changes, new integrations and tracking scripts, hosting migrations and DNS changes. It should not cover security patches for actively exploited vulnerabilities, price and content corrections, or stock updates. Write down who can approve an exception and make a fresh backup a precondition of every one.
What backups do I need before Black Friday?
A backup you have actually restored and timed. Restore to staging three weeks out and verify specifics — recent orders present, product images resolving, checkout completing, customer logins working — rather than just checking the homepage loads. Keep at least one copy outside your hosting account, since a backup in the same account offers no protection against account compromise. During the peak weekend, increase database backup frequency to hourly or continuous, because the database changes constantly while your files barely change at all.
What if my business does not peak on Black Friday?
Then use your own date and run the same sequence backwards from it. Accounting firms peak between February and April, fitness studios in January, clinics in September and again as insurance benefits expire in December, and tire shops with the first snowfall. The method is date-agnostic: measure your ceiling, reduce the work per request, harden the site, test a restore, test the conversion path, rehearse, freeze. Businesses whose peak is weather-triggered — heating and plumbing contractors, snow removal — should run the six weeks once in the early autumn and then treat the change freeze as their normal state, because an unscheduled peak leaves no window to prepare in.
Should I delete my Black Friday landing page afterwards?
No. Keep one permanent, year-agnostic URL and refresh it each season. Deleting the page discards the links and traffic it earned, and redirecting it to your homepage usually fares no better, because search engines tend to treat a redirect to an unrelated destination as a soft 404. Between seasons, repurpose it as a standing sales-and-promotions page. Above all, avoid creating a new dated URL every year; that produces a set of near-identical pages competing for the same queries, which is a reliable way to end up with content that gets crawled and never indexed.
