Preparing Your Website for a Traffic Spike

The cruelest failure mode on the web goes like this: you spend months earning a big moment — a press feature, a TV mention, a launch, a post that unexpectedly catches fire — and the surge of visitors it produces kills your website within minutes. The audience you worked for arrives, meets an error page, and leaves. Most won't come back; the moment doesn't repeat.

The engineering behind surviving a spike isn't exotic. The sites that fall over almost always fail for the same two or three preventable reasons, and the fixes are largely configuration, not construction. This post covers how spikes actually break sites, what to set up in advance, what to do in the 48 hours before a moment you can see coming, and how to react when one arrives unannounced.

How spikes actually kill websites

Understanding the failure makes the fixes obvious. A normal small-business site might see a few hundred visits a day — call it one visitor every few minutes. A good press mention or viral moment can deliver 50 to 500 times that, compressed into an hour or two, with the sharpest burst in the first fifteen minutes.

What breaks first is almost never bandwidth. It's work per visitor. A dynamic site like WordPress, serving a page "fresh," does real computation for every single request: it runs PHP code, makes a dozen or more database queries, assembles the page, and ships it. At one visitor per minute, this is nothing. At fifty visitors per second, the server's worker processes are all busy, new requests queue, the queue grows faster than it drains, memory runs out, and the database starts refusing connections. Visitors see the request spin, then time out — and here's the vicious twist — then they hit refresh, doubling the load at the worst moment. The site doesn't degrade gracefully; it collapses in a spiral.

The insight that solves most of this: during a spike, nearly every visitor is requesting the same few pages — the one that got linked, plus your homepage. There is no reason to compute that page fifty times a second. Compute it once, store the result, and hand copies out.

The permanent setup: do this once, be ready forever

1. Full-page caching — the single biggest lever

Page caching means the server stores the finished HTML of a page and serves that stored copy to subsequent visitors instead of rebuilding it. The difference is not incremental — a cached page can be served hundreds of times more cheaply than a computed one. Under caching, a spike of identical page requests becomes almost free.

On managed WordPress hosting this is typically built in at the server level, already on, and the reason spikes are mostly a non-event there. If you self-manage, a caching plugin does the job — one, configured properly, not three fighting each other. Either way, verify it works: load a page in a private browser window twice and check the response headers (or simply confirm your host documents server-level caching as active). A cache you assume is on but isn't is the most common spike post-mortem finding.

One caveat worth knowing: caching applies to anonymous visitors. Logged-in users and carts bypass it. For content sites and brochure sites, that's fine — spike traffic is overwhelmingly anonymous. For stores, see section on commerce below.

2. A CDN in front of everything

A content delivery network puts copies of your site's assets — images, scripts, styles, and ideally whole cached pages — on servers around the world, so most requests never reach your origin server at all. During a spike, the CDN absorbs the flood and your server handles a trickle. The mainstream options have generous free tiers, and many hosts integrate one by default. If a single press mention could plausibly change your business, a CDN is not optional infrastructure — it's the difference between your server facing five hundred requests a second or five.

3. Lighten the pages people will land on

Every megabyte matters more under load. The landing page a journalist links to should be lean: compressed, properly sized images (the number one weight problem on real sites), no autoplaying video, no fifteen third-party scripts. As a rule of thumb, keep key landing pages under 1.5–2 MB total. Lighter pages don't just load faster — they cost less per visitor to serve, which stretches the same server across many more people.

4. Know your ceiling before the internet finds it

A basic load test answers the question you'd otherwise answer live: how many concurrent visitors can this site take? Simple tools (hosted load-testing services with free tiers, or command-line tools your developer will know) can simulate a few hundred simultaneous users against your homepage. You're looking for the point where response times climb past 2–3 seconds. Knowing that number turns "I hope it holds" into "we're good to roughly X thousand visitors an hour" — and if X embarrasses you, you've learned it on a quiet Tuesday instead of launch day.

The 48-hour checklist for a spike you can see coming

Launching, running a big campaign, or expecting coverage? A short countdown:

1. Tell your host. Genuinely — a quick message saying "we expect unusual traffic Thursday" gets your account flagged, avoids automated anti-abuse throttling being your surprise bottleneck, and on some plans gets resources scaled up proactively. Good hosts appreciate the heads-up; it's their launch too.
2. Freeze changes. No plugin updates, no design tweaks, no experiments from 48 hours out. The site that has been stable for a week stays stable; the one changed last night has an unknown in it.
3. Take a fresh backup and confirm you know how to restore it fast.
4. Prune the landing page. Whatever URL will be linked: strip it to essentials, verify it's cached, and load it from a phone on mobile data as a stranger would.
5. Test the money path under a stopwatch. If the spike is meant to produce sign-ups or sales, walk that path end-to-end. A spike that lands on a broken form is worth exactly nothing.
6. Set up monitoring you'll actually see. An uptime monitor pinging every minute, alerting a phone someone will be holding during the event.
7. Prepare a fallback page. Ten minutes of work: a single static HTML page — logo, one paragraph, an email capture — that can be swapped in if everything else fails. Collecting emails from a crowd you couldn't otherwise serve turns a disaster into a delayed win.

When the spike arrives unannounced

Sometimes the first sign is your phone buzzing — the uptime monitor, or a friend saying "you're on the front page of somewhere." Triage order:

1. Confirm what's happening. Real-time analytics will show the surge and, crucially, where it's landing. That page is your priority; nothing else matters for the next few hours.
2. If the site is up but slow: resist the urge to fiddle. Verify caching is active on the hot page. If your host offers one-click resource scaling, use it now — an hour of a bigger plan costs less than lunch and buys you the whole moment.
3. If the site is down: contact the host immediately (this is what their emergency channel is for), and put the CDN into maximum-caching mode if you have one — most CDNs can serve a fully cached copy of your site even while the origin is dead, which is effectively a resurrection button.
4. Don't restart things randomly, and don't deploy changes mid-spike. Half of self-inflicted extended outages are panic edits layered on top of a load problem that caching or scaling would have solved.
5. Capture the moment even if degraded. Worst case, the static fallback page goes up. The visitors are here now; give them something to act on.

A special note for stores

E-commerce spikes are harder, because the interesting part — carts and checkout — can't be page-cached. The playbook adjusts: cache everything up to the cart aggressively (category pages, product pages), so the server's full capacity is reserved for the small fraction of visitors actually transacting. Keep the checkout brutally simple — every extra field, script, and "one more upsell" widget is load and friction at the worst place. And if you're running a genuinely large sale event, ask your host about it specifically; commerce under load is a resource-sizing conversation, not a guess.

Afterward: the debrief nobody does

The spike ends. Within a day or two, while the graphs are fresh, spend thirty minutes:

• Find your real ceiling. Peak concurrent visitors, response times at peak, whether anything queued or failed. This number recalibrates all future planning.
• Follow the cohort. Spike traffic converts worse than normal traffic — that's expected — but a good landing experience turns a slice into subscribers and followers. Check what the surge actually produced beyond the vanity graph.
• Fix the one thing that creaked. Something always creaks: the image that should have been smaller, the plugin that ate CPU, the form that got slow. Fix it now, while the memory of caring is vivid.

The quiet conclusion

Spike-readiness sounds like an enterprise concern, but it reduces to a short list of one-time decisions: caching that's genuinely on, a CDN in front, lean landing pages, a known capacity number, and a host you can talk to. None of it requires ongoing effort, and all of it also makes the site faster on ordinary days — spike preparation is just performance hygiene with higher stakes.

Big moments are rare and mostly unscheduled. The preparation isn't. Do it in the quiet weeks, and when your fifteen minutes arrives, your website will do the one thing it exists to do: be there.

Photo: Andreas Berget on Pexels