Traffic spikes from press or TV: why static sites survive them
What happens to a website when a television mention or a news story sends thousands of visitors at once, and why the architecture decides the outcome.
The short answer
A television mention, a newspaper story or a viral post sends most of its visitors in the first few minutes, nearly all to one or two pages. That is the worst possible shape of traffic for a website that builds each page on demand: a server that comfortably handles a few visitors a minute is asked to run database queries, templates and plugin code for thousands at once, runs out of capacity in seconds, and shows everyone an error during the business’s best moment. A static site behaves differently by construction. The pages are files, already built, served from an edge network with many locations near visitors, so ten thousand visitors in a minute are ten thousand cached file deliveries, which is routine for the network. The parts that can still fail are the dynamic ones, forms, functions and third-party services, and those are protected with limits, caps and fallbacks. The site that goes down during its media moment was built to compute pages; the one that stays up was built to serve them.
Two architectures under the same spike
| Moment | Server-rendered site | Static site on an edge network |
|---|---|---|
| Minute zero: the mention airs | A few visitors; the server is fine | A few visitors; files served from cache |
| Minute one: thousands arrive | Every visit runs queries and templates; capacity is exhausted; errors begin | Every visit is a cached file from the nearest location; nothing computes |
| Minute two: social sharing multiplies it | The server is unreachable; the host may suspend the account | The network absorbs it; response times unchanged |
| The form on the page | Never reached; the page is down | Reached; protected by rate limits and caps; submissions stored if downstream is slow |
| The next morning | Apologies, a bigger server, a post-mortem | A traffic record and a full inbox |
Getting the benefit
- Build the site static, or at least the pages a media moment would land on.
- Serve it from an edge network with a filtering layer in front.
- Keep the landing pages light so each of those thousands of deliveries is small.
- Protect the dynamic parts: rate limits, function limits, provider caps.
- Add fallbacks for forms and payments so a downstream limit does not lose submissions.
- Monitor so you watch the record happen instead of hearing about the outage.
- Know the story page in advance where possible, and make sure it is static and cached.
Why the edge network does not mind
Edge networks are built to serve files to the whole internet; a small business’s spike is a rounding error to them. Each location serves nearby visitors from its cache, the load is spread across many locations, and the origin is not involved at all. This is the same infrastructure that serves the largest sites in the world, available to a small business site at the price of static hosting, which is often nothing.
What this means for you
Build your website so a media moment is a traffic record rather than an outage: static pages served from an edge network, light landing pages, and limits, caps and fallbacks on the dynamic parts. The architecture costs nothing extra and decides whether the twenty minutes that matter go to your business or to an error page.
Frequently asked questions
Our site went down when we were on television. Why?
Almost certainly because each visitor's page was being built on a server at the moment they asked for it: database queries, template rendering, plugin code, for every one of thousands of simultaneous visitors. The server ran out of capacity within seconds and everyone saw an error. A static site would have served the same page as a file from the nearest edge location, and the moment would have been a traffic record instead of an outage.
Can we prepare a traditional site for a spike we know is coming?
Partly: aggressive caching, a network layer in front, bigger servers for the day. It works if everything is cached and nothing personalised, which is close to making the site static for the occasion. If you know the moment is coming and the site is not static, the most reliable preparation is a static landing page for the story, served from the edge, with the rest of the site behind it.
What about the form or the order flow during a spike?
Those are the parts that still compute per visitor, so they are where preparation goes: rate limits per source so a flood is bounded, provider caps so cost is bounded, a fallback that stores submissions if a downstream service is overwhelmed, and monitoring on success rates. The pages will be fine; the flows need the attention.