Scaling WordPress for Global Traffic and Multiple Domains

Scaling WordPress globally is mostly a caching problem, and scaling it across many domains is mostly an architecture decision you make once and live with. The technical work is well understood; the part that goes wrong is choosing multisite when you needed separate installs, or the reverse, and discovering it eighteen months later.

There are two separate questions bundled in this topic. How do I serve WordPress fast to users on other continents has a standard answer. How do I run twenty domains without twenty maintenance burdens has a genuine trade-off. Taking them in order.

Table of contents

• Global traffic: the caching ladder
• The database is the scaling ceiling
• Multiple domains: multisite or separate installs?
• Media, uploads, and the shared-filesystem problem
• Handling spikes without over-provisioning
• A sensible order of work
• How this fits the rest of the stack
• FAQ

Global traffic: the caching ladder

WordPress generates HTML by running PHP against MySQL. That work is identical for every anonymous visitor to a given page, which makes it enormously cacheable. Each layer below removes work from the one beneath it.

1. CDN edge cache — full HTML served from a location near the visitor. The origin is not contacted at all. This is what makes a site fast in Sydney when the server is in Frankfurt.
2. Full-page cache at the origin — finished HTML held on the server, so PHP does not run.
3. Object cache — query results held in memory across requests, for pages that cannot be fully cached.
4. OPcache — compiled PHP bytecode, so the interpreter is not reparsing files.
5. The database — the layer everything above exists to protect.

Latency is physics, and only the first layer addresses it. A request from Sydney to Frankfurt takes roughly 250ms round trip before the server does anything. No amount of server-side optimisation touches that number; only serving from somewhere closer does.

So for genuinely global audiences, edge caching of HTML — not just images and CSS — is the single change that matters. It is also the one most sites skip, because caching HTML requires getting the exclusions right.

# Cache HTML at the edge, but never for logged-in users or carts
# Bypass when any of these are present:
#   - wordpress_logged_in_* cookie
#   - woocommerce_items_in_cart / woocommerce_cart_hash
#   - comment_author_* cookie
#   - URLs under /wp-admin/, /cart/, /checkout/, /my-account/

Get that wrong and you serve one user’s account page to another. It is worth testing deliberately: log in, load a page, then load it in a private window and confirm you are anonymous.

The database is the scaling ceiling

Caching protects the database, and when caching misses, the database is what breaks. Two failure modes account for most of it.

Connection exhaustion. Each PHP worker holds a connection. Scale to twenty application instances with fifty workers each and you are asking for a thousand connections, which most database plans will refuse.

SHOW STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'max_connections';

-- What is actually running right now
SHOW FULL PROCESSLIST;

Autoloaded options. Every WordPress request loads every option marked autoload=yes, before caching helps. A site that has accumulated megabytes there pays that cost on every uncached request forever.

SELECT ROUND(SUM(LENGTH(option_value))/1024) AS autoload_kb
FROM wp_options WHERE autoload = 'yes';

SELECT option_name, ROUND(LENGTH(option_value)/1024) AS kb
FROM wp_options WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC LIMIT 20;

Anything above roughly 800KB deserves investigation, and orphaned options left by removed plugins are common.

Give the database its own plan with headroom. Running it alongside the application on one small instance means a traffic spike causes both to compete for the same CPU. RunxBuild’s managed MySQL and Postgres have their own plan ladder with connection limits and backups documented — see database connection limits — which makes the ceiling a number you chose rather than one you discover.

Multiple domains: multisite or separate installs?

This is the decision that is expensive to reverse. Both options are legitimate and they suit different situations.

WordPress Multisite — one installation, one codebase, one database, many sites. Plugins and themes are managed network-wide.

• Good when: the sites are genuinely similar, one team runs all of them, and you want to update plugins once rather than twenty times. Franchise sites, university departments, multi-region versions of one brand.
• Bad when: sites need different plugin sets, different clients need isolated access, or one site’s traffic would affect the others.
• The hard truth: you share a failure domain. A bad plugin update takes down every site at once, and one site’s runaway query slows all of them.

Separate installations — one WordPress per domain.

• Good when: sites are genuinely different, clients need isolation, or you want to update and scale them independently.
• Bad when: you have forty of them and no automation, at which point maintenance dominates.
• The advantage that matters: failure is contained. One site down is one site down.

A useful rule: if the sites share content or users, multisite. If they only share an owner, separate installs. Multisite’s real benefit is a shared user table and shared media; if you are not using those, you are taking on a shared failure domain for administrative convenience alone.

Domain mapping is built into multisite now and no longer needs a plugin, so that historical argument against it has gone.

Media, uploads, and the shared-filesystem problem

This is where multi-instance WordPress most often breaks, and the symptom is confusing: images upload successfully and then appear missing about half the time.

The cause is that wp-content/uploads is local to whichever instance handled the upload. Another instance serving the next request has no such file.

• Shared persistent storage attached to all instances. Simple, and the filesystem becomes a bottleneck under load.
• Offload to object storage with a plugin that rewrites URLs to the bucket. The standard answer at scale, and it removes uploads from the application entirely.
• A single instance with a CDN in front. Perfectly reasonable for most sites and worth saying out loud — many sites reaching for horizontal scaling do not need it.

Solve this before scaling horizontally, not after. Adding a second instance to a site with local uploads produces intermittent missing images that look like a CDN problem and are not.

On RunxBuild, persistent storage attaches to a service — see the storage documentation — which covers the shared-volume approach. For very large media libraries, object storage with a rewriting plugin remains the better shape.

Handling spikes without over-provisioning

Global multi-domain setups usually have uneven traffic: a campaign launch, a regional news cycle, an admissions deadline. Provisioning permanently for the peak is expensive; provisioning for the average falls over.

Autoscaling between a floor and a ceiling plan is the answer, and the numbers should be deliberate:

• Floor — comfortably handles normal traffic. Do not set this so low that ordinary evenings trigger scaling.
• Ceiling — the most you are willing to spend. It is a budget control as much as a technical one.
• Scale-up threshold — around 70-80% CPU. Higher and you are already degraded before scaling starts.
• Scale-down threshold — around 20%, with a delay. Aggressive scale-down causes flapping.
• Warm-up time — an instance is not useful the instant it starts; PHP needs to warm its caches.

Autoscaling does not fix an unscalable database. Ten application instances pointing at one small database instance means ten times the connection pressure on the same bottleneck. Scale the data layer first, or at least alongside.

RunxBuild supports autoscaling on WordPress, services, tools, and databases, bounded by plans you pick — the autoscaling documentation covers the thresholds. WordPress plans run from $3/month Starter up through WpPro at 2 vCPU and 4GB.

A sensible order of work

1. Measure. TTFB, cache hit ratio, database connection count, slow query log. Without these you are guessing.
2. Fix the origin. Current PHP version, OPcache on, autoloaded options cleaned, slow queries indexed.
3. Add full-page caching with correct exclusions for logged-in users and commerce paths.
4. Add a CDN and cache HTML at the edge. This is the one that fixes international latency.
5. Give the database its own plan with connection headroom.
6. Solve uploads — object storage or shared volume — before adding instances.
7. Then, and only then, scale horizontally with autoscaling bounded by a budget.

Most sites that think they need horizontal scaling need steps 2 through 4. A well-cached single instance behind a CDN serves a remarkable amount of traffic, and it is far simpler to reason about than a fleet.

The multi-domain question is worth deciding separately and early, because migrating between multisite and separate installs later means exporting content, remapping users, and rewriting URLs across every site at once.

How this fits the rest of the stack

Cache at the edge for global latency, protect the database because it is the real ceiling, and solve uploads before you add a second instance. On the domain question, choose multisite only if the sites genuinely share content or users — otherwise you are accepting a shared failure domain for administrative tidiness. If you are sizing a multi-site WordPress setup and want the sites, database, and bandwidth as separate line items, the RunxBuild hosting calculator lays them out.

Useful related references:

• Is WordPress Multisite One Theme or Multiple? How Themes Actually Work Across a Network
• IPv4 vs IPv6: How They Actually Differ When You Ship Traffic
• Nested Domains: How Deep Subdomains Can Go and What Breaks First
• Custom domains and certificates on RunxBuild

FAQ

What is the biggest factor in scaling WordPress globally?

Edge caching of HTML. Latency between continents is physics — a Sydney-to-Frankfurt round trip costs roughly 250ms before the server does anything — and only serving from a location near the visitor addresses it.

Should I use WordPress Multisite for multiple domains?

Use multisite when the sites genuinely share content or users and one team maintains all of them. Use separate installations when sites need different plugins, different client access, or independent failure domains.

Why do images disappear when I run multiple WordPress instances?

Uploads land on whichever instance handled the request, and other instances have no copy. Solve it with shared persistent storage or by offloading media to object storage before scaling horizontally.

How many database connections does WordPress need?

Roughly one per PHP worker per instance. Twenty instances with fifty workers each will attempt a thousand connections, which most database plans refuse. Check Threads_connected against max_connections before scaling out.

Does autoscaling fix WordPress performance problems?

No. Autoscaling handles traffic variance, not inefficiency. Ten instances pointing at one undersized database multiply the pressure on the same bottleneck. Fix caching and the database first.