A traffic spike is a good problem and it behaves like a bad one. The site slows, then stops answering, and by the time you are looking at it the visitors who came have already left.
Most of the work is done before the spike. What you can do during one is limited but not nothing.
What actually breaks first
Rarely bandwidth. On shared hosting it is almost always concurrent PHP processes. The number of requests your account may execute at the same time.
Beyond that limit, requests queue rather than fail. Visitors wait, then the page loads. So the symptom is a site that hangs and then works, not one that errors, and that is why it gets misdiagnosed as a code problem.
On a VPS the equivalent is memory: enough concurrent PHP workers to exhaust it, and the kernel kills the database. Configuring swap and memory goes into that specific failure.
Page caching is the whole answer
A cached page never occupies a PHP process at all. That is not an incremental improvement in this context. It changes what your capacity is.
An uncached site might serve five or ten concurrent visitors on a shared plan. The same site with server-level page caching serves hundreds, because most requests are a file being sent.
If you do one thing before an expected spike, this is it. Caching layers deals with which layer you are missing.
A CDN absorbs the rest
With a CDN caching HTML at the edge, a large share of requests never reach your server. During a spike that is the difference between your server being busy and your server being irrelevant.
Set it up in advance. Adding one during a spike means a nameserver change that takes hours to propagate, by which time the traffic has gone. Choosing and setting up a CDN explains the setup, including the mail records that must bypass it.
What to do while it is happening
Four things, in order of how quickly they help.
Turn caching on if it is off, and raise the cache lifetime. A page cached for an hour during a spike is fine; freshness matters less than being reachable.
Disable the expensive extras. Live search, related-post queries, anything that hits the database on every page load. Whatever you can switch off without breaking the page is capacity returned immediately.
Serve a static version of the busy page. If one page is taking all the traffic, an HTML copy of it removes the application from the path entirely.
Ask your host. Some can raise process limits temporarily. It is a five-minute ticket and it is worth sending early rather than after an hour of tuning.
What not to do
Do not upgrade the plan mid-spike as a first move. A migration takes time you do not have, and an uncached site on a bigger plan is still uncached.
Do not start optimising code. Profiling during an incident is how the incident gets longer.
Do not block traffic broadly. Rate-limiting during a genuine spike blocks the visitors you wanted.
Tell the difference from an attack
Worth checking early, because the response is opposite.
Real traffic has a referrer, arrives at varied pages, and comes from many addresses across many networks. An attack or an aggressive crawler hits the same path repeatedly, often from a narrow set of addresses, with no referrer and an odd user agent.
Real traffic is served, and traffic that is not real is blocked; the access log tells you which within a minute. For reading it, see viewing website statistics.
Preparing for an expected one
When you know it is coming. A campaign, a launch, a mention somewhere large.
Confirm page caching is on and working, and check that the specific landing page is cached rather than excluded.
Load-test with a tool that simulates concurrent visitors, at a quiet time, and find your actual ceiling instead of assuming one.
Freeze changes. A spike arriving the day after a plugin update is two problems at once, and the plugin will be blamed for the capacity limit or the reverse.
And have the monitoring alert set to reach a phone instead of an inbox nobody is watching. For making the alert arrive, see uptime monitoring.
Shops need more care
Cart and checkout pages cannot be cached: caching them can serve one customer's cart to another. So the pages that matter most are exactly the ones that always reach the application.
That means a shop's real capacity is decided by how many people can check out simultaneously, not by how many can browse. Test that path specifically, and consider whether the plan is right before a sales period rather than during one. See preparing a store for a sales peak.
Afterwards
Read what happened rather than being relieved it ended.
Where did the traffic come from, which page took it, and what was the actual limit you hit? That last number is the useful one: it tells you what to fix before the next one, and whether the fix is caching, a plan, or a page.
Then check whether the spike cost you anything you have not noticed: a bandwidth overage, a suspended account, or a rise in resource usage that persists because something is now caching badly.
A spike that does not appear in analytics is not visitors, and the response is different. There is more on telling them apart in How to Stop Bots and Scrapers from Consuming Resources.
If the traffic does not appear in analytics at all, it is a different situation with a different response. How to Recognise and Handle a DDoS Attack sets out telling them apart.