When a Post Takes Off and Your Website Cannot Take the Weight

More people are looking at your business today than in a normal year. A video landed, or somebody with reach shared you, and the thing you have wanted for ages is happening right now. Except the site is struggling, or the enquiries are arriving faster than anyone can read them, and you can feel the window closing while you work out what to do.

Everything you search returns advice on getting more traffic, which is the exact opposite of your problem. So, this is written for the other direction, and it starts with the one distinction that decides what you should do in the next hour.

Your website failing to serve pages and your business failing to answer people are different problems. They look the same from the outside, they feel identical, and they have almost nothing in common as fixes. Work out which one you have before you touch anything.

Two minutes, done from a phone on mobile data rather than from the machine you are signed in on.

Load the public page as a visitor. Note what actually happens: does it load, how slowly, and what status comes back. Then follow the route that matters most, whether that is a product page, a booking, or the enquiry form, all the way to the end. Write down the time, the URL, the device, the error if there is one, and whether it fails every time or only sometimes.

If pages load and the enquiry arrives, your website is fine and your problem is capacity to respond. That is a real problem, and it is an operations problem: who answers, how fast, and what you say to people you cannot get to today.

If pages are slow or failing, then it is worth finding out what is actually under load. Static files, HTML pages, an API route, checkout, booking, login, search, or form submissions all behave differently, and treating them as one thing leads to the wrong fix. Google itself recommends looking at server access logs to understand the source of a sharp increase in crawling, and the same instinct applies here: look at what is being requested before deciding what to change.

Preserve one clear path for the people arriving.

Put up, or keep, a simple public page that says what the offer is, whether it is still available, what somebody should do next, and a fallback way to reach you if the main route is struggling. Make sure that whatever the next action is produces something observable at your end: a form confirmation, an email receipt, a booking record, a stored row somewhere.

This matters more than any technical fix, because attention is the thing you are short of. A visitor who reaches a page that tells them the truth and gives them one thing to do is a visitor you might keep. A visitor who reaches a spinning loader leaves and does not come back.

If your normal enquiry route is unreliable right now, give people an alternate one that you are actually watching. An inbox nobody is reading is the same as no inbox at all.

In rough order of safety.

Cache the static things. Images, stylesheets, scripts. This is the lowest-risk change available and it takes real load off the origin.

Then consider caching anonymous public pages, but only after checking what those pages depend on: cookies, query strings, personalisation, cart contents, inventory, and whether the visitor is signed in. Cloudflare's cache documentation covers how this is configured. Do not cache private or transactional responses as a reflex, because serving one customer's page to another is a much worse day than a slow site.

Protect the expensive routes. Login, search, form submissions, account creation, carts and any API route that does real work. Cloudflare's rate-limiting rules are defined by a matching expression, counting characteristics, a period, requests per period, a mitigation timeout and an action, and that structure is useful precisely because it forces you to say what you are limiting and for how long rather than throttling everything.

Keep a change record. Every emergency cache rule and rate limit you add now is something you will want to unwind next week. Write down what you changed and when, or you will be living with a mystery configuration for a year.

Traffic spikes have a billing dimension that catches people out, and it is worth thirty seconds during the incident rather than a surprise afterwards.

Platform behaviour differs, and it is genuinely specific rather than general. Vercel, as one published example, says Hobby deployments pause when they reach the included free-tier usage limit, while Pro teams can set usage alerts and, at 100 percent, use controls that pause deployments, trigger a webhook or send an SMS. Whether your host pauses, throttles or simply bills you is worth knowing today.

The point is not that one arrangement is better. It is that you should know which one you are on before the spike rather than during it.

This is the check people skip, and it is the one that costs the most.

Submit a real test enquiry as a stranger would. Confirm it left the site, confirm the provider delivered it, confirm it landed in the inbox or system somebody is watching, and check whether it went to spam. Look at what the visitor sees on success and on error, because a form that fails silently looks exactly like nobody being interested.

If you take one thing from this article and the spike is already over, make it this test. It costs two minutes and most small sites have never had it done.

Something true, and quickly.

If you are overwhelmed, say so plainly along with what happens next: how long a reply will take, whether the offer is still available, and whether there is a queue. People are extraordinarily forgiving of a business that is honest about being busy and unforgiving of silence, and silence is what a full inbox looks like from outside.

Keep the message somewhere permanent rather than only in replies to comments, because a post's comment thread scrolls and a page does not. This is also where the simple public page earns its place: one address you can point everyone at, which you can update as the situation changes.

Most of the value in this whole subject is here rather than in the emergency, and that is worth saying plainly because it is the less exciting half.

Find out which dependency gives way first. For most small sites it is not raw page serving at all; it is a form provider, a booking integration, an inventory lookup, or a database query on one page. Knowing which one means the next spike has a known first move.

Write the traffic-spike page now, while nothing is happening, and leave it unpublished. Note who has access to the host, the DNS and the form provider, and how to reach them out of hours. Pick a couple of monitoring thresholds so you find out from a machine rather than from a customer. And rehearse the test submission and the rollback once, so the first time you do it is not during the incident.

None of that prevents an outage, and nothing published here promises uptime. It shortens the part where nobody knows what is happening, which is the expensive part.

If the spike involves collecting more personal information than usual, through forms, sign-ups or bookings, it is worth knowing that Texas has its own data privacy and security framework, published by the state. A sudden increase in collection is a reasonable moment to check what you are gathering and where it goes, rather than a year later.

Should I upgrade my hosting mid-spike? Only if you know that page serving is the constraint, and often it is not. Changing platform under load introduces a new set of unknowns at the worst possible moment. Cache first, look at what is actually under load, and change one thing at a time.

Will the traffic be worth anything? Some of it. The value is mostly in the people who take one clear action, which is why preserving that single path matters more than serving every visitor a perfect page.

How long does a spike last? Usually days rather than weeks, which is why the honest holding message is worth writing. The attention leaves faster than most people expect.

Is this a reason to rebuild my site? Not by itself. It is a reason to find out which dependency gives way first and to write the plan for next time. A rebuild decided during an incident tends to be a decision about panic rather than about the site.

Can I stop the spike? You can slow specific expensive routes with rate limiting, and you should not try to slow the whole thing. The attention is the opportunity; the goal is to survive it with one path open.

The worst part of this is not the technical failure. It is standing there watching something you have wanted for years go past while you guess at what is wrong. Two minutes checking from outside tells you which of the two problems you have, and from there the list is short and mostly safe. Then, when it is quiet again, spend an hour on the version of this you can prepare, because that hour is worth more than everything you can do during the hour itself.

If you would like somebody to look at which dependency would give way first on your site, before anything happens, that is a good use of a quiet week. We are Arlington Website Designer, working across Arlington and the Tarrant County towns nearby. We build static sites, which changes what breaks first and makes that question answerable. Have a look at the projects we have built, and get in touch.