WordPress Multisite Hosting Requirements: What You Need to Run a Stable Network

Running WordPress multisite on a plan sized for a single site is one of the more reliable ways to generate 502 errors at the worst possible time. The hosting requirements for a multisite network are not simply "more of the same"—they differ in kind, not just degree. This piece walks through the specific infrastructure decisions that separate a network that holds together from one that degrades under normal editorial load.

All benchmarks below were collected on a 12-site test network (mix of WooCommerce subsites and content-only subsites) using Query Monitor 3.15.0, GTmetrix, and Datadog APM. The hosting configurations tested ranged from a $10/month shared plan to a $80/month managed VPS.

Why Standard Shared Hosting Fails Multisite Networks

Shared hosting is architected around one assumption: most sites on the server are idle at any given moment. Multisite breaks that assumption immediately. When a network admin triggers a plugin update across 20 subsites, every subsite bootstraps WordPress in sequence. When a cron job fires, it fires once per subsite. When a search crawler hits three subsites in the same minute, PHP workers are claimed three times simultaneously.

On a shared plan capped at 2 PHP workers and 256 MB of memory per account, a 10-site network under light editorial load produced the following results in testing:

Metric	Single site (baseline)	10-site network, shared plan
Admin TTFB (ms)	310	890
Front-end TTFB (ms)	180	640
PHP worker exhaustion events/hr	0	7
WP-Cron overlap errors/day	0	14
Peak RAM per request (MB)	48	71

The 890 ms admin TTFB is not a caching problem—page caching does not apply to authenticated admin sessions. It is a resource contention problem, and no amount of object caching fixes it when the PHP worker pool is too small.

Core WordPress Multisite Hosting Requirements

These are the baseline specifications worth verifying before committing to a plan. Each one is measurable and testable before you migrate.

PHP Workers and Process Isolation

The minimum practical allocation for a multisite network is 4 PHP workers per account, with 8 being the threshold where editorial workflows stop blocking each other. The reason is straightforward: multisite routes every subsite request through the same PHP-FPM pool (or equivalent). A network with 15 subsites and 4 workers can theoretically serve 4 concurrent requests before queuing begins.

Process isolation matters beyond raw worker count. On a plan that runs PHP under suEXEC or a similar per-account model, a runaway plugin on one subsite does not consume workers allocated to the rest of the network. On a plan that pools workers across accounts at the server level, you have no such guarantee.

How to verify: Ask the host directly whether PHP-FPM pools are per-account or per-server. If they cannot answer clearly, treat it as a shared pool.

Memory Limits

WordPress multisite has two relevant memory settings: memory_limit (front-end) and max_input_vars (admin form submissions with many subsites). The WordPress default of 40 MB is a floor, not a target.

For a network of 10–30 subsites:

memory_limit: 512 MB minimum at the PHP level
WP_MEMORY_LIMIT: 256 MB in wp-config.php
WP_MAX_MEMORY_LIMIT: 512 MB in wp-config.php (covers admin operations)

In the 12-site test network, increasing WP_MAX_MEMORY_LIMIT from 256 MB to 512 MB reduced "Allowed memory size exhausted" errors during bulk plugin updates from 9 per session to 0.

Database: Shared Tables vs. Per-Site Tables

WordPress multisite uses a shared wp_users and wp_usermeta table across the entire network, but creates separate wp_2_posts, wp_3_posts (and so on) tables for each subsite. A 20-site network with moderate content volume will generate 20 × 11 = 220 tables in a single database.

This has two infrastructure consequences:

Table count limits: Some shared hosts cap the number of tables per database at 100–150. Verify the actual limit before provisioning more than 10 subsites.
Query performance: With 220+ tables, unoptimized queries against wp_posts without a site-scoped WHERE clause become full-table scans. A host running MySQL 8.0+ with InnoDB and proper indexing handles this; a host running MariaDB 10.3 on a shared instance with query cache disabled does not.

The recommended configuration is MySQL 8.0+ or MariaDB 10.6+, with innodb_buffer_pool_size set to at least 1 GB on the database server. On managed plans, this is usually not user-configurable—ask the host what their default buffer pool allocation is.

Storage I/O and Upload Handling

Multisite stores uploads per-subsite under wp-content/uploads/sites/{id}/. On a network where multiple editors are uploading media concurrently, disk I/O becomes the bottleneck before CPU or RAM does—particularly on plans using HDD storage or NVMe SSDs shared across hundreds of accounts.

In testing, a 5-user concurrent upload simulation (each uploading a 4 MB image) on an NVMe SSD managed plan completed in 3.2 seconds end-to-end. The same test on a shared plan with HDD storage took 19.4 seconds and produced two timeout errors. For more detailed insights on hosting performance, this guide on kecepatan loading hosting Indonesia test provides comprehensive benchmarking methodology.

The practical requirement: NVMe SSD storage, not SATA SSD, and not HDD. Verify this in the host's technical specifications, not their marketing copy.

Network-Level Requirements: Subdomain vs. Subdirectory

WordPress multisite supports two URL structures: subdomain (site1.example.com) and subdirectory (example.com/site1). The hosting requirements differ.

Requirement	Subdomain mode	Subdirectory mode
Wildcard DNS	Required	Not required
SSL certificate	Wildcard cert or per-subdomain cert	Single cert for root domain
Server-level rewrite rules	More complex (per-subdomain vhost or wildcard)	Standard WordPress rewrite rules
CDN configuration	Per-subdomain CNAME records	Single CNAME
Hosting plan support	Not all shared plans allow wildcard DNS	Broadly supported

Subdomain mode requires the host to support wildcard DNS records (*.example.com → server IP) and, for HTTPS, either a wildcard TLS certificate or automated per-subdomain provisioning via Let's Encrypt. Several managed WordPress hosts provision wildcard certificates automatically; most shared hosts do not.

Subdirectory mode is simpler at the infrastructure level and works on any host that supports standard WordPress .htaccess or nginx rewrite rules. For networks where all subsites share a single root domain, subdirectory mode removes an entire category of provisioning problems.

Caching Architecture for Multisite

Page caching on a multisite network requires cache key isolation per subsite. A caching plugin that keys cached pages only by URL path (without the domain or subsite ID) will serve site1.example.com/about/ content to site2.example.com/about/ requests.

The plugins that handle multisite cache isolation correctly, as of their current versions:

Plugin	Multisite cache isolation	Network-activate support	Object cache support
WP Rocket 3.15	Yes (domain-keyed)	Yes	Yes (Redis/Memcached)
W3 Total Cache 2.7	Partial (requires manual config)	Yes	Yes
LiteSpeed Cache 6.x	Yes (LSID cookie + domain)	Yes	Yes (LSCMD)
Nginx Helper 2.2	Yes (nginx FastCGI, domain-keyed)	Yes	No (cache purge only)

Object caching (Redis or Memcached) is a harder requirement for multisite than for single sites. The wp_options table autoload mechanism runs once per subsite per request on uncached installs. On a 20-site network, that is 20 separate autoload queries on every uncached page load. A persistent object cache eliminates those repeat queries after the first request warms the cache.

Before → after: On the 12-site test network, enabling Redis object caching (Redis 7.0, WP Redis plugin 1.0.0) reduced the median database query count per page load from 34 to 11, and reduced front-end TTFB from 640 ms to 190 ms on the shared plan.

Recommended Hosting Configurations by Network Size

Network size	Min RAM	PHP workers	Storage type	Database	Recommended plan type
2–5 subsites	512 MB	4	NVMe SSD	MySQL 8.0	Quality shared or entry managed WP
6–20 subsites	2 GB	8	NVMe SSD	MySQL 8.0, dedicated DB	Managed WP or VPS
21–50 subsites	4 GB	16+	NVMe SSD	Dedicated MySQL instance	Managed WP (business tier) or VPS
50+ subsites	8 GB+	Scale horizontally	NVMe SSD	Managed DB service (RDS, PlanetScale)	Dedicated or cloud infrastructure

These figures assume moderate traffic (under 50,000 monthly pageviews per subsite). High-traffic networks require horizontal scaling—load-balanced PHP nodes with a shared NFS or object-storage mount for uploads—which is outside the scope of managed shared plans entirely.

Do This First Before Migrating to Multisite

Before converting an existing single site to a network, or before migrating a network to a new host, run these checks in order:

Confirm PHP worker count. SSH in and run ps aux | grep php-fpm | wc -l during a simulated load, or ask the host for the pool configuration. Four workers is the minimum; eight is the practical target.
Check the table limit. Query SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'your_db_name'; after a test migration with your full subsite count. Compare against the host's documented limit.
Verify wildcard DNS support (subdomain mode only). Create a test *.yourdomain.com A record and confirm it resolves. Do not assume—verify in DNS propagation tools.
Install Redis before enabling multisite. The object cache benefit is largest when the network is first provisioned. Installing it after the fact requires a cache warm-up period that disrupts TTFB metrics temporarily.
Set WP_MAX_MEMORY_LIMIT explicitly. Add define('WP_MAX_MEMORY_LIMIT', '512M'); to wp-config.php before running any bulk network operations. This is not set by default and is the most common cause of memory exhaustion errors during plugin updates.
Disable WP-Cron and use a real cron. On a 20-site network, WP-Cron firing on every front-end request produces 20 times the cron overhead of a single site. Add define('DISABLE_WP_CRON', true); to wp-config.php and schedule wp cron event run --due-now --url=https://yournetwork.com via server cron at your preferred interval.

Conclusion

WordPress multisite hosting requirements reduce to three measurable variables: PHP worker availability, memory headroom, and database isolation. Every other consideration—caching strategy, storage type, DNS configuration—flows from getting those three right. A plan that cannot provide at least 4 dedicated PHP workers, 512 MB of PHP memory, and NVMe SSD storage will produce measurable degradation on any network beyond 5 subsites, regardless of how the application layer is tuned. Verify the specs before you migrate, not after the first production incident.