What WordPress Multisite Is (and Isn’t)
WordPress Multisite lets you run multiple WordPress sites from a single installation — one codebase, one database, shared plugins and themes, individual site admin areas. It’s used by academy trusts running school websites, agencies managing client portfolios, media publishers running regional editions, and franchise businesses with per-location sites.
It is not the same as running multiple WordPress installs on the same hosting account. Multisite is a single WordPress installation serving multiple sites from a shared database. This architecture is both its advantage and its most significant hosting challenge.
The Database Problem
In a standard single-site WordPress installation, the database contains a defined set of tables — wp_posts, wp_options, wp_users, and so on. In a Multisite network, each subsite gets its own set of tables within the same database — wp_2_posts, wp_3_posts, wp_2_options, and so on. A network with 20 sites has roughly 20× the number of tables of a single installation.
This isn’t just a storage issue. Every query hits the same database server. A traffic spike on one subsite — a school website on results day, a client’s product launch — creates database load that affects every other site on the network. On shared hosting, where the database server is also shared with other customers, this compounds further.
Managed hosting with adequate dedicated RAM and NVMe storage is not optional for a Multisite network above trivial scale. It’s the difference between a network that runs and one that doesn’t.
PHP Workers and Multisite
Standard single-site WordPress allocates PHP workers per site. In Multisite, all subsites share the same PHP worker pool. If your network has 8 PHP workers and three subsites receive concurrent traffic, those workers are divided between them.
The practical implication: a Multisite network needs more PHP workers than an equivalent number of independent single sites. The Scale plan (16 PHP workers) and Elite plan (32 PHP workers) are both appropriate for Multisite networks depending on subsite count and traffic patterns.
Staging for Multisite
Staging a Multisite network is more complex than staging a single site. You need to stage the entire network — not just one subsite — to test changes that affect the shared codebase, shared plugins, or network-wide settings.
WP Pro Host staging creates a full copy of your production environment. For Multisite, this means a copy of the entire network database, all subsites, and the shared plugin/theme directory. Changes to core, network-activated plugins, and theme files can be tested on staging before touching the live network.
SSL on Multisite
Multisite with subdomain configuration (site1.yourdomain.com, site2.yourdomain.com) needs a wildcard SSL certificate. Multisite with subdirectory configuration (yourdomain.com/site1) uses the root domain SSL. Domain mapping — where each subsite has its own custom domain — requires individual SSL certificates per domain.
WP Pro Host provisions SSL on all configured domains. For domain-mapped Multisite networks, add each domain to your account and SSL is handled automatically.
When Multisite Makes Sense
Multisite is the right choice when: you need centralised management of multiple related sites, you want to share plugins and themes without separate licence purchases, you’re running an academy trust or franchise network with a common design system, or you’re an agency managing a client’s portfolio of related brands.
It’s not the right choice when sites are completely unrelated, when you need complete isolation between sites (a compromise on one affects all), or when individual site owners need to manage their own hosting accounts.
Hosting Requirements Summary
A Multisite network above 5 subsites or with meaningful traffic needs: dedicated PHP workers not shared with other customers, fast NVMe database storage, Redis object caching to reduce repeated database queries, adequate RAM for WordPress to hold network configuration in memory, and staging that covers the full network, not individual subsites.
These requirements point to Scale or Elite plans rather than Launch or Grow — not because of storage, but because of PHP worker count and RAM allocation.
Frequently Asked Questions
What is WordPress Multisite and when should I use it?
WordPress Multisite allows running multiple WordPress sites from a single installation — sharing core files, plugins, and themes with separate databases for content. It is appropriate when: managing multiple sites with identical plugin stacks (reduces update overhead), running a network of related sites with shared branding or authentication, building a SaaS platform where each customer gets their own WordPress subsite, or managing educational platforms with multiple department sites. It is not appropriate for managing unrelated client sites (separate installs with isolated containers are better), sites requiring different plugin stacks, or high-traffic sites where shared database creates performance bottlenecks.
What are the performance implications of WordPress Multisite hosting?
Multisite performance considerations: all subsites share a single database server, so high query load from one subsite affects others (no per-site performance isolation), the main site’s wp_options table grows with network-wide settings, WordPress loads network-aware code on every request adding overhead compared to single-site installs, and caching must cover the full network rather than per-site. On managed hosting with adequate resources (Redis, NVMe, sufficient PHP workers), a Multisite network of 5-20 subsites with moderate traffic performs well. Networks above 20 sites or with high-traffic individual subsites require Scale or Elite plan resources.
Can all WooCommerce plugins run on WordPress Multisite?
Not all WooCommerce extensions are Multisite-compatible. The main WooCommerce plugin supports Multisite, but many extensions have limitations: WooCommerce Subscriptions has Multisite constraints, some marketplace and membership plugins require per-site licensing even on a network, and custom table-based plugins frequently have Multisite incompatibilities. Audit all required extensions for Multisite support before committing to the architecture. Extensions that work perfectly on single installs may behave unexpectedly in Multisite due to network-wide settings conflicts or per-site database table assumptions.
How does SSL work on a WordPress Multisite network?
SSL on Multisite depends on your configuration: subdomain Multisite (site1.yourdomain.com) requires a wildcard SSL certificate (*.yourdomain.com) to cover all subsites, subdirectory Multisite (yourdomain.com/site1) uses the same SSL certificate as the main domain, and domain-mapped Multisite (where each subsite has its own domain) requires a separate SSL certificate per domain. On WP Pro Host, Let’s Encrypt certificates are provisioned automatically including wildcard certificates for subdomain Multisite networks. Domain-mapped Multisite requires adding each mapped domain to your hosting account for SSL to be provisioned.
What are the alternatives to WordPress Multisite for managing multiple sites?
Alternatives to Multisite for managing multiple WordPress sites: separate installs on an agency hosting plan (10-30 sites on Scale/Elite plans with container isolation), MainWP or ManageWP for centralised management of separate installs (plugin updates, backups, monitoring from one dashboard), WP Remote or similar SaaS management platforms, or a custom deployment pipeline using WP-CLI scripts. For agencies managing client sites, separate isolated installs are generally preferable to Multisite — each client has full isolation, can have different plugin stacks, and problems on one site cannot affect others. The management overhead of separate installs is handled by centralised management tools.