WordPress Multisite Hosting: What to Look for in a Host

WordPress Multisite lets you run a network of sites from a single WordPress installation with a shared database, shared user table, and shared plugin and theme directories. It is genuinely powerful for the right use case, but running it successfully depends on specific hosting infrastructure requirements that standard single-site shared hosting often cannot meet. Choosing the wrong host for Multisite creates problems that no plugin or configuration change will fix.

What WordPress Multisite actually is

Enabling Multisite converts a single WordPress installation into a network. Sub-sites are added through the network admin panel and share the same WordPress core files, plugin directory, and theme directory. Each sub-site has its own database tables (prefixed with a unique site ID), its own media uploads directory, and its own activated plugin and theme configuration. A network admin can install plugins and themes that site administrators can optionally activate, or activate them network-wide.

Multisite is appropriate when you are managing multiple related sites that share a plugin and theme stack, a user base, or centralised administration. Common use cases include university networks (each department gets a sub-site with the same branding framework), franchise networks (each location gets a site with shared plugins managed centrally), media publishers (multiple publications under one installation), and agencies running a managed hosting service for clients.

It is not appropriate simply because you want to manage multiple unrelated sites from one place. For that, MainWP or ManageWP manage multiple independent WordPress installations from a single dashboard without the infrastructure complexity of Multisite. Multisite adds complexity, understand the use case before committing to it.

Wildcard subdomain DNS and SSL

Subdomain-based Multisite, the most common configuration, where sub-sites run as site1.yourdomain.com and site2.yourdomain.com, requires wildcard DNS. A wildcard DNS record (*.yourdomain.com pointing to your server's IP) routes all subdomain requests to your server, which WordPress Multisite then uses to identify which sub-site to serve. Without wildcard DNS, new sub-sites are inaccessible until a specific DNS record is manually added for each one.

Not all shared hosts support wildcard DNS configuration, it must be enabled at the nameserver level. Confirm with your host before starting Multisite setup, not after. In cPanel, you can add a wildcard DNS record under Zone Editor: add an A record for *.yourdomain.com pointing to your server's IP. Some cPanel configurations restrict this to hosting accounts that manage their own nameservers.

Wildcard SSL is the corresponding certificate requirement. A standard domain-validated certificate covers your root domain and typically one or a few specified subdomains. To secure an arbitrary number of sub-sites in a Multisite network, you need a wildcard certificate, *.yourdomain.com, which covers all first-level subdomains. Most cPanel hosts can issue wildcard certificates via Let's Encrypt through the SSL/TLS section. Some shared hosting plans restrict wildcard certificate issuance; verify this explicitly before proceeding.

Subdirectory Multisite, where sub-sites run as yourdomain.com/site1/, does not require wildcard DNS or wildcard SSL. It works with a standard domain certificate and standard DNS. The tradeoff is that the subdirectory structure is less clean for branding purposes and cannot be used if the WordPress installation was in use as a single site for more than one month before Multisite was enabled. Subdirectory Multisite is simpler from a hosting requirements standpoint but less flexible for sites that need independent-looking URLs per sub-site.

PHP memory and execution limits

WordPress Multisite loads more PHP code per request than a single-site installation. The network bootstrap, blog lookup, and shared plugin and theme codebase all consume memory before the sub-site's specific code runs. The WordPress minimum PHP memory recommendation for single sites is 64MB. For Multisite, the practical minimum is 256MB per PHP process, with 512MB or more appropriate for networks with more than a handful of active sub-sites or any complex plugins active network-wide.

Many shared hosts default to 128MB or 256MB PHP memory limits. While you can set define('WP_MEMORY_LIMIT', '512M'); in wp-config.php, this directive cannot exceed the limit the hosting server permits. If the server's PHP memory limit is 256MB, your wp-config.php directive can request 512MB but will be capped at 256MB. Confirm the effective PHP memory limit the host will allow, not the default, but the maximum they permit, before assuming your wp-config.php setting will take effect.

Similarly, PHP max execution time matters more for Multisite than single-site installs. Complex plugin operations, bulk post processing, WooCommerce order imports, plugin updates across a large network, can exceed the default 30-second limit on Multisite networks. A host that allows 120–300 seconds via cPanel's PHP settings is preferable for any Multisite installation running complex operations.

Database architecture and performance at scale

Multisite creates additional database tables for each sub-site added to the network. A fresh WordPress installation creates 12 tables. Each sub-site added to a Multisite network adds approximately 10 additional tables (posts, postmeta, terms, term_taxonomy, term_relationships, options, comments, commentmeta, links, and term_taxonomy counts). A network with 20 sub-sites has around 210 WordPress database tables. With 100 sub-sites, over 1,000 tables.

The database lookup overhead for identifying the correct site tables on each request increases as the network grows, particularly for the wp_blogs and wp_site network tables which are queried on every request. Shared hosting database servers under load from hundreds of accounts will feel this pressure earlier than dedicated database infrastructure with properly tuned MySQL or MariaDB settings.

For larger Multisite networks, a VPS or dedicated server with a properly configured database is not optional, it is a requirement. Key database settings that matter: innodb_buffer_pool_size (how much RAM MySQL uses for caching, set to 50-70% of available RAM on a dedicated database server), max_connections (should match your PHP-FPM worker count), and query caching configuration. These are configurable on a VPS but not on shared hosting.

Object caching is particularly valuable for Multisite. Redis or Memcached stores the results of frequently repeated database queries in memory, eliminating repeated round-trips to the database for the same data. The Redis Object Cache plugin for WordPress with a properly configured Redis server on the same host can reduce database query count per page load by 50% or more on a Multisite network. This requires Redis to be available on the server, most shared hosts do not offer it, but VPS plans typically can install it freely.

Which hosting types work best for Multisite

VPS hosting is the most reliable environment for serious Multisite deployments. You have full server access to configure wildcard DNS, set PHP memory limits without restriction, install Redis, tune MySQL, and configure the web server's URL routing for Multisite's subdomain rewriting. LiteSpeed on a VPS handles Multisite subdomain routing natively with the correct .htaccess configuration and provides server-level caching per sub-site through LiteSpeed Cache, the plugin handles Multisite networks correctly and caches each sub-site's pages independently.

Reseller hosting is a good option for agencies managing Multisite networks for multiple clients. The resource allocation model, separate cPanel accounts with defined disk, bandwidth, and process limits, fits the use case of running several Multisite networks under one billing account. The cPanel reseller interface provides the DNS and SSL tools needed without requiring root server access for each operation.

Managed WordPress hosting varies significantly in Multisite support. WP Engine and Kinsta explicitly support Multisite and have tested infrastructure for it. Both provide environment-level configurations that accommodate Multisite's memory and DNS requirements. Other managed WordPress hosts, including some well-regarded ones, silently block Multisite, limit networks to a small number of sub-sites, or require a plan upgrade to enable it. Always confirm Multisite support explicitly with a managed WordPress host before migrating or building on their platform. Ask specifically: wildcard subdomain DNS support, wildcard SSL, and the PHP memory limit ceiling. A vague "yes we support WordPress Multisite" without specifics on those three points is not sufficient confirmation.

Domain mapping for Multisite

Subdomain Multisite routes sub-sites to subdomains of the main domain by default. For networks where sub-sites need their own independent domain names, client1.com pointing to one sub-site, client2.com pointing to another, domain mapping is required. WordPress supports this natively since version 4.5 via the Site Address setting per sub-site in the network admin.

Each mapped domain requires its own DNS A record pointing to the server IP, and its own SSL certificate. For a small number of mapped domains, cPanel's Let's Encrypt integration handles SSL certificate issuance per domain. For large numbers of mapped domains, more than 20 or 30, automating certificate issuance via Certbot or a Cloudflare proxy becomes necessary. Cloudflare's proxy with a wildcard certificate on the Cloudflare side simplifies this considerably: all mapped domains point to Cloudflare, which handles SSL termination, and Cloudflare routes requests back to your server over a single origin certificate.