WordPress at a Million Visitors

The Short Answer

A WordPress site can serve a large audience, but monthly visitor totals do not describe its capacity. The expensive work is often in the request path: a single origin server answering every request personally, media files chained to one machine's disk, a database absorbing traffic that a cache should have answered. The platform gets blamed for decisions the platform never made.

We run this architecture on udx.io, but that is evidence of an operating pattern, not a capacity guarantee for another site. A million cached page views and a burst of uncached checkout requests are different workloads. Load-test the actual plugins, queries, logged-in flows, cache-hit mix, and burst rate before promising a traffic target.

One honest caveat before the diagrams, because it will save some readers the rest of the page: if your traffic is steady and modest, and an hour of downtime costs you little, you do not need any of this. A good managed host is the right answer for most sites, and pretending otherwise is how agencies sell Kubernetes to bakeries. This page is for the sites where the graph goes vertical, the stakes are real, and "we'll upgrade the plan" has stopped working.

What a Month of Traffic Actually Looks Like

Scaling plans tend to imagine a million human visitors arriving with good intentions. The logs tell a stranger story. We analyzed thirty days of CloudFront traffic for this site, 575,092 requests and 13.84 gigabytes served, including substantial automated traffic. A missing or scripted user agent alone does not establish malicious intent; the requested paths, responses, and request pattern provide the useful context. More than 62,000 requests arrived with no user agent, and about half were blocked outright. Another 27,851 came from curl, the bulk of it automated probing: seventeen thousand of those requests hammered paths that do not exist, hunting for exposed backups and login endpoints, and scanners methodically enumerated the user APIs of every WordPress membership plugin on the market against a site that runs none of them.

Then there is the newest constituency: AI crawlers. Bytespider, ByteDance's crawler, made 1,824 requests and pulled 147 megabytes on its own; ClaudeBot followed at 1,329. This category barely existed a few years ago and now shows up in every log review we do, which means your architecture is serving an audience your analytics never shows you.

Two design consequences follow. First, a meaningful slice of your capacity will always be spent on non-humans, so the economics matter: a cache hit avoids origin work, while an uncached request reaching PHP occupies a worker a customer could have used. Edge requests still have delivery and security costs. Let the edge do that work. Second, blunt instruments cut both ways. Our own firewall rules turned out to be silently blocking the SEO crawlers we very much wanted visiting, and we use robots.txt to express preferences to cooperating crawlers. It does not enforce access control; unwanted or abusive traffic still needs appropriate authentication, rate limits, or firewall rules.

What Breaks First

The encouraging thing about WordPress scaling failures is how predictable they are. After enough launches, you stop being surprised and start keeping a list. Ours, roughly in the order sites hit them:

Uploads on local disk is almost always first. The moment a second server exists, media written to one is missing from the other, and the support tickets begin. This is why stateless media is the first move in the architecture, not a refinement for later. Its smaller sibling, PHP sessions on disk, produces the same split-brain in miniature; shared sessions need an explicitly configured store with suitable expiration, concurrency, and failure behavior. An evictable object cache is not automatically a safe session store; avoid server-side sessions when the application does not need them.

Cache stampedes arrive next: a popular page expires and a thousand concurrent requests all volunteer to regenerate it at once, briefly turning your cache into a denial-of-service tool aimed at your own database. Request coalescing, expiration policies, and bounded regeneration can reduce the burst, but the behavior must be tested with the cache and application you actually use. WP-Cron compounds the problem at the worst moments, because traffic triggers checks for due scheduled tasks by default. A separate scheduler makes that trigger predictable, but jobs still need concurrency controls, resource limits, and monitoring.

And then there is the plugin you forgot about: one modest-looking plugin writing to the options table on every page view will happily hold a database lock through your biggest traffic hour of the year. The lesson is to load-test the site you actually run, production plugins and all, rather than the clean install that exists nowhere. If this list reads uncomfortably like a diagnosis of your own site, that is precisely what our enterprise WordPress work exists for.