Yes, WordPress can handle heavy traffic, and plenty of large news sites and publishers run on it. It holds up when most visitors get a cached copy of each page, and when the parts that can't be cached, such as logins, search, carts and checkout, have enough server behind them for your busiest hour instead of your average one.
When a WordPress site does go down under traffic, the usual story is a setup sized for an ordinary Tuesday meeting a link from a big newsletter or a TV segment.
Why a cached page is cheap and an uncached one is expensive
Every time WordPress builds a page from scratch, the server runs PHP, loads WordPress core, your theme and every active plugin, then asks the database for the content, the menus, the widgets and the settings. On a typical site that's dozens of database queries, sometimes hundreds, before anything goes back to the visitor.
A cached page skips all of that. The finished HTML was saved the first time it was built, and the next visitor gets the saved copy. A modest server that struggles to build a few dozen pages a second can hand out ready-made copies by the thousand. If the cache sits at the edge of a CDN, most requests never reach your server at all. So for a busy site, the number to watch is how many requests miss the cache.
What breaks first when WordPress gets heavy traffic
These are the requests that slip past the cache and make WordPress do the full job every time.
- Uncached pages. A page that was never cached, or whose cache was just cleared, gets built fresh. If a link goes out with tracking codes on the end and your cache treats each version as a separate page, every click can be a miss.
- Logged-in users. Members, subscribers and your own editors normally get a freshly built page, because it might show their name or account.
- Search. Every search is different, so results are almost never cached, and WordPress's built-in search gets slow on a site with years of articles.
- WooCommerce cart and checkout. These pages are personal to each shopper. A sale that sends a thousand people to the cart at once means a thousand uncached requests.
- admin-ajax.php. Many plugins make background requests to this file for live counters, add-to-cart buttons and the like. Each one loads all of WordPress, and none are cached.
- WP-Cron. WordPress runs scheduled tasks when visitors load pages, so emails, imports and cleanups can kick off in the middle of a spike and compete with visitors for the server.
- The database. Everything above ends up here. A query that takes half a second goes unnoticed at ten visitors a minute and becomes crippling at a few hundred a second, because queries start queuing behind each other.
Why logged-in visitors and stores need more server
A news site where nearly every reader is anonymous can take an enormous amount of traffic on modest hardware, because almost all of it comes from cache. A membership site, an online course or a busy store is a different job. A large share of those visitors are logged in or carrying a cart, so a large share of requests go straight to PHP and the database.
When you plan for capacity, count the uncached traffic separately. Ten thousand people reading one article is mostly a caching problem. Five hundred people checking out in the same ten minutes needs enough PHP workers (the processes that build pages, each handling one request at a time) and a fast database. When every worker is busy, new requests wait in line, and visitors see a spinning page and then an error. We wrote about preparing a shop for this in getting your store ready for peak season.
Page caching at the edge
For most content sites, the biggest improvement available is caching full pages at the edge, meaning in a CDN's data centers close to your visitors instead of only on your own server. When a story takes off, the CDN absorbs the readers and your server builds each page once per cache period.
Edge caching needs rules. Pages should be cached for anonymous visitors and skipped for anyone with a login or cart cookie. The admin area, cart, checkout and account pages should never be cached. Publishing or updating a post should clear that post and the pages that list it, such as the homepage and its category, so readers see the change within seconds.
Be careful with "purge everything" during a spike. Clearing the whole cache while thousands of people are on the site forces every page to be rebuilt at once, which is a common way for a busy site to go down right after someone fixes a typo.
Object caching and a tuned database
Page caching does nothing for logged-in users, carts or search. Object caching helps with those. A persistent object cache such as Redis keeps the results of common database lookups in memory, so WordPress can reuse them on the next request instead of asking the database again. On a store or membership site it's usually one of the first things worth adding.
The database needs attention too. On older sites the usual problems are an options table stuffed with settings from long-gone plugins, missing indexes, and too little memory for the database server. A slow query log shows which queries are dragging, so you fix those instead of guessing. Running WP-Cron from a real server schedule, instead of page visits, takes scheduled jobs out of the traffic path.
Offloading media and heavy files
Images, video and downloads shouldn't compete with page building for the same server. Serve images and other static files through the CDN, so they come from the edge after the first request. Host video on a video platform and embed it, rather than serving large video files from your WordPress server.
Size counts as well as location. A news page with five full-resolution photos is heavy wherever it's served from, and every extra megabyte costs bandwidth during a spike. Our post on why your media library is probably the problem covers how that weight builds up and how to clear it.
How to host a high-traffic WordPress site
If you're choosing hosting for a busy site, look for these and ask about them.
- Full-page caching at the edge, with sensible bypass rules and automatic purging when you publish.
- Room for peaks. Ask how many uncached requests the server can handle at once, and what happens at that limit. Budget shared hosting often caps how many PHP processes an account can run at the same time, and a spike reaches that cap fast.
- Clear fair-use terms. Find out whether a spike gets your site throttled, suspended or billed extra. "Unlimited" plans usually have limits in the small print.
- An object cache and a tuned database if you run a store or a membership area.
- Monitoring and a person to contact, so someone knows the site is struggling before your readers tell you.
- A load test before a known event, run against the uncached pages on a staging copy.
On Hosterr, every site sits behind Cloudflare edge caching and a web application firewall, and bandwidth and visits are unmetered under fair use. Uptime monitoring is included, and when something looks wrong you email the developer directly and hear back the same day. Deeper work such as database tuning is $95/hour, quoted before we start, and dedicated servers are quoted separately. There's more on how we host high-traffic WordPress sites.
Frequently asked questions
How much traffic can a WordPress site handle?
There's no fixed limit in WordPress itself. With full-page caching at the edge, a site can serve very large numbers of anonymous readers, because the CDN does most of the work. The limit you'll hit is how many uncached requests your server can build at once, which depends on the hosting, the plugins and the database. The only dependable figure for your site comes from testing it.
Is WordPress good for a news website?
Yes, and many large publishers use it. A news site suits WordPress because most readers are anonymous and pages cache easily. For a fast-loading news site, use short cache lifetimes on the homepage and section pages so breaking stories stay fresh, move search for a large archive to a dedicated search service, and plan capacity for any paywall or membership area, since those readers are logged in and skip the page cache.
Do I need a dedicated server for a high-traffic WordPress site?
Usually not at first. Get the caching right before buying hardware, because a well-cached site on modest hosting will usually outlast a poorly cached one on a big server. A dedicated server makes sense when you have steady, heavy uncached traffic, such as a large store or a busy membership site, and the caching and database work is already done.
