WordPress Multisite Hosting: Requirements That Matter

WordPress multisite hosting runs one WordPress installation that powers multiple sites at once, sharing the same core files, plugins and database while keeping separate content, users and, usually, separate domains. Most standard shared or managed WordPress plans were never built for this. Multisite needs specific server configuration around subdomains, SSL, PHP resources and file limits, and a lot of hosts simply don't mention any of it until your network starts falling over.

What is WordPress multisite hosting?

Multisite is a feature built into WordPress core that lets you run a network of sites from a single dashboard: one codebase, one set of plugin files, one database with prefixed tables for each site. It's not a plugin bolted on top. You either enable it in wp-config.php before setup or you don't have it. The official WordPress network creation guide covers the config side well, but it says almost nothing about what your hosting environment needs to actually cope with a live network under real traffic. That gap is where most multisite installs quietly break.

Hosting-wise, the important distinction is that multisite isn't "regular WordPress hosting but bigger." It changes how the server handles requests, file storage and database queries, and the hosting requirements shift with it, sometimes in ways a generic shared plan can't handle at all.

Who should use multisite, and who should avoid it?

Multisite makes sense if you run a genuine network: a university with departmental sites, a franchise with near-identical branch sites, a publisher running several branded content sites off shared themes and plugins, or an agency managing near-clone sites for similar clients. The common thread is that centralised control and shared code matter more than isolation.

I've had clients come to us convinced multisite was the answer when what they actually needed was a handful of separate WordPress installs on one server, managed through a decent panel. If your sites don't share users, don't share a theme, and don't benefit from one admin logging in once to update everything, multisite just adds complexity for no real gain. One badly behaved plugin or a bloated database on a single site can drag down every other site on the network, because they all share the same resources and the same point of failure.

Agencies juggling dozens of client sites are usually better served by agency hosting with proper site isolation, rather than forcing everything into one multisite network just to get a single login. Isolation means one client's rogue plugin doesn't take down twenty other client sites. The operational math backs this up: one agency's real numbers on managing 50 WordPress installs put annual hosting, maintenance and plugin-license costs at $57,000–$78,000, before counting the 20–40 monthly hours spent on updates and conflicts alone.

What are the core WordPress multisite requirements?

Before you touch a hosting plan, get a few things confirmed on the server side. Wildcard DNS or subdirectory support, depending on your network type. A server configuration that allows the .htaccess or Nginx rewrite rules multisite generates. PHP memory limits high enough for multiple sites querying shared plugin code at once. And enough available worker processes that one busy subsite doesn't starve the rest of the network.

None of this is exotic, but it's exactly the sort of thing budget hosts leave undocumented. If a host's plan page doesn't explicitly mention multisite support, assume it doesn't have it configured properly, and ask before you commit.

Do you need wildcard subdomains or subdirectory mapping?

When you set up a network, WordPress asks you to choose subdomains (site1.example.com) or subdirectories (example.com/site1). Subdomains require wildcard DNS, a DNS record pointing *.example.com at your server, and the hosting environment needs to accept requests for any subdomain without you manually adding each one. Some budget hosts only support a fixed number of subdomains per account, or require you to add each one individually in cPanel, which defeats the point entirely.

Subdirectories are simpler at the DNS level since there's no wildcard needed, but the server still needs rewrite rules configured correctly so WordPress can route /site1/, /site2/ and so on to the right content. Check this before launch, not after. Migrating a live network from one structure to the other is painful.

How do domain mapping and SSL work for mapped domains?

Domain mapping is where multisite hosting gets genuinely tricky. If subsites need to run on entirely separate domains rather than subdomains or subdirectories of the main network, you need the WordPress domain mapping functionality (built into core since WordPress 4.5) plus a hosting environment that can issue SSL certificates for each mapped domain automatically.

This is where a lot of shared and even some managed plans quietly fall short. Free automated SSL via Let's Encrypt handles the primary domain fine, but if the hosting panel isn't configured to auto-provision certificates for additional mapped domains as they're added, you're stuck manually requesting and installing SSL for every single site on the network. On a network with thirty mapped domains, that's not a minor inconvenience, that's someone's entire week. Ask any host directly whether SSL for mapped domains is automated or manual before you sign up.

What PHP, memory and object caching does a network actually need?

Multisite runs every subsite through the same PHP processes and the same memory pool. A plugin that's fine on a single small site can behave very differently once it's being loaded across fifty subsites simultaneously, particularly if it hooks into every page load. Practically, that means you want a plan with generous PHP memory limits and enough concurrent PHP workers that traffic to one busy subsite doesn't queue up requests to every other site on the network.

Object caching (Redis or Memcached) stops being optional once you're running a real network. Shared queries, especially anything touching the wp_users or wp_options tables across sites, get hit constantly, and without persistent object caching the database ends up repeating the same work on every page load across every subsite. This is one of the clearest differences between a proper managed WordPress hosting plan and a generic shared plan that happens to support WordPress: managed hosts generally build object caching in by default, shared hosts generally don't.

Why do shared hosting inode and process limits break multisite networks?

This is the part almost nobody warns you about, and it's the reason I've seen more multisite networks collapse from hosting limits than from anything to do with WordPress itself. Shared hosting plans cap the number of inodes (files and folders) your account can hold and the number of simultaneous processes your account can run. A multisite network with active plugins across dozens of subsites, each generating cache files, uploaded media and log entries, chews through inode limits far faster than a single WordPress install ever would.

Once you hit the inode cap, your host typically won't warn you gracefully. Sites just start failing to save uploads, plugins fail to update, backups fail silently. Process limits cause the more visible failure: too many subsites getting hit at once and the shared account simply runs out of allowed concurrent processes, so visitors start seeing intermittent 500 errors that seem to come from nowhere. This is exactly the trap covered in Shared Hosting Math: Why Most Hosts Lose Money on $3/Month Plans. Low-cost shared plans are built around the assumption of light, individual, isolated sites, and a multisite network is the opposite of that assumption.

How do managed WordPress hosts price multisite?

Pricing for multisite hosting rarely matches the advertised entry price on a host's plan page, and this is where the pattern in The Real Economics Behind Your $5/Month Hosting Plan applies directly. Most managed WordPress hosts price multisite based on total visits or PHP workers across the whole network rather than per subsite, which sounds reasonable until a fifteen-subsite network with modest traffic on each site racks up combined numbers fast enough to bump you into an enterprise tier.

Some hosts charge multisite as a fixed add-on to an existing plan. Others require you to be on their agency or business tier before multisite is even supported. A few genuinely don't support it at all regardless of what plan you buy, and they won't tell you until the support tickets start piling up. Before committing, get a straight answer on whether pricing scales per subsite, per combined visit count, or stays flat regardless of network size, and check that support explicitly confirms multisite compatibility rather than assuming standard WordPress hosting covers it.

Frequently asked questions

Can I convert an existing WordPress site into a multisite network later?

Technically yes. WordPress supports converting a single install into the primary site of a network, but it's a manual process involving wp-config changes, database table restructuring and often plugin compatibility checks. It's far easier to plan for multisite from the start than to retrofit it onto a busy live site.

Do all plugins and themes work on multisite?

No. Some plugins are built specifically for multisite (network activation, per-site settings), others work fine as-is, and a meaningful number simply were never tested against a network environment and will misbehave, particularly anything that assumes a single set of site options or a single uploads directory.

How are backups handled across a multisite network?

Because all subsites share one database, a full backup covers the entire network at once rather than individual sites. That's efficient for a total network backup but makes restoring a single subsite without affecting the others considerably harder. Ask any host directly whether their backup tool supports per-site restoration on multisite, because plenty of "automatic daily backups" only restore the whole network as one unit.

Is multisite good for an agency managing many client sites?

Usually not, unless the client sites are genuinely near-identical and benefit from shared plugin management. Most agencies get better results, and fewer support headaches, from properly isolated hosting per client rather than bundling everything into one shared network where a single site's problem can affect them all.