Multisite or Separate WordPress Installs? A Decision Framework for Agencies

The short answer, before the framework, is this. You should use WordPress multisite only when the sites genuinely belong together as one network, sharing a codebase, a theme and plugin set, usually a team of administrators, and a single owner who controls all of them. A university with forty department sites, a retail chain with a page per location, a multi-language brand under one roof, a product that spins up a site per customer. Those are networks. For anything else, and that includes the most common case an agency faces, which is several unrelated client sites that simply happen to be built by the same shop, you should use separate installs.

The reason the answer needs a framework rather than a rule is that multisite makes a specific trade. It buys you shared maintenance, where one core update and one round of plugin updates cover every site at once, and it pays for that with reduced per-site flexibility and, more importantly, a lock-in problem that most agencies do not see until it is too late. Extracting a single site out of a multisite network later is hard, hands-on work, not a button. If you put sites into a network that should have been separate, undoing it is one of the more expensive mistakes you can make in WordPress. So the question is not which option is better. It is which trade is right for the specific sites in front of you, and the rest of this article is the five questions we use to decide that correctly.

What multisite actually is, in plain terms

It helps to be precise about what you are turning on, because a lot of bad multisite decisions come from a fuzzy mental model of it. Multisite is a feature built into WordPress core. You enable it by adding a couple of constants to wp-config.php and some rewrite rules, and a single WordPress install becomes a network capable of running many sites.

Underneath, there is one set of core files on disk, one wp-content directory, and one shared set of plugin and theme files. There is one database, but each site in the network gets its own set of content tables, while the users table is shared across the whole network. Sites can live on subdomains or in subdirectories, and that choice is fixed early and awkward to change afterwards. A new role appears above Administrator, the Super Admin, who controls which plugins and themes exist on the network. Individual site administrators lose the ability to install plugins or themes themselves. They can only use what the Super Admin has made available.

That last point matters more than it sounds. The defining characteristic of multisite is centralisation. One codebase, one update cycle, one point of control. Everything good about multisite and everything painful about it flows from that single fact.

Question one: do the sites share a codebase and theme?

The first question is whether every site in the proposed network will run the same theme and broadly the same set of plugins. This is the question multisite was built to answer well. If you have twenty sites that are all variations on one design, the same theme with different content and branding, drawing on the same plugin stack, then the shared codebase is a genuine and ongoing saving. You update once and twenty sites are current. You ship a theme improvement once and it appears everywhere. The maintenance maths is firmly in multisite's favour.

If, on the other hand, the sites need genuinely different themes and divergent plugin sets, the shared codebase stops being a saving and becomes a constraint. Every plugin lives on the network whether a given site uses it or not, and a theme change for one site is a change every site administrator can potentially see. When sites want to be different from one another, multisite spends its effort fighting that difference. Separate installs let each site be exactly what it needs to be, with no negotiation. So if the honest answer to this question is that the sites are meaningfully different builds, you have already found a strong reason to keep them apart.

Question two: do the sites share a user base?

The second question is about people. Will the same humans administer, edit, or contribute across multiple sites in the network? Multisite shares one users table across every site, which means a person logs in once and can be granted a role on as many sites as needed. For a franchise where regional managers move between location sites, or a campus where staff contribute to several department sites, that single sign-on is a real convenience and a genuine reason to choose multisite.

If each site has its own separate, unrelated set of users with no overlap, that shared table becomes a liability rather than a feature. Every user in the network technically exists across the whole network, which complicates permissions, complicates a clean view of who has access to what, and complicates the day you need to remove someone. Separate installs keep each site's user data fully isolated, which is simpler to reason about and simpler to audit. When the people behind the sites have nothing to do with each other, that isolation is worth keeping.

Question three: is there per-site billing or separate ownership?

The third question is commercial, and for agencies it is often the decisive one. Ask who owns and who pays for each site. If a single organisation owns every site in the network and pays for the whole thing as one system, multisite fits the ownership model cleanly. The network has one owner, and the technical structure matches the business structure.

If the sites have different owners, separate invoices, or any possibility of being handed over to a client to run themselves, multisite works against you. You cannot cleanly give one client their site when that site lives inside a network you also use for other clients. There is no tidy boundary to hand over. Billing each site separately for hosting becomes an accounting exercise rather than a clean line item. We have watched agencies build a multisite network purely to save on hosting costs across a dozen client sites, and then spend far more than they saved when one client wanted to leave, or move their site to their own hosting, or simply own their own thing. Separate ownership is one of the clearest signals that you want separate installs.

Question four: are the required plugins compatible with multisite?

The fourth question is a practical audit, and skipping it causes some of the nastiest surprises. Not every WordPress plugin behaves well on multisite. Many plugins are written with a single site in mind. Some store data in ways that assume one site, some behave unpredictably when network activated, and some categories of plugin, particularly ecommerce, membership, learning management, and booking systems, are either explicitly unsupported on multisite or licensed in a way that does not cover a network without paying considerably more.

So before you commit a project to multisite, list every plugin the sites genuinely need and check each one against multisite directly, in the plugin's own documentation and licensing terms. If a must-have plugin does not support multisite cleanly, or supports it only on a tier the budget cannot reach, that single fact can rule the whole approach out. It is far cheaper to discover this during planning than after the network is built and a key plugin will not run.

Question five: how hard will it be to migrate a site out later?

The fifth question is the one agencies most often forget, and it is the most important. Look honestly at each site and ask whether there is any realistic future in which it needs to leave the network. Could it be sold? Could it be spun off into its own business? Could it grow large enough to need its own dedicated hosting away from its neighbours? Could a client one day insist on owning and controlling it themselves?

If the answer to any of those is a plausible yes, weight it heavily, because extraction is the single most expensive thing multisite makes you pay for. There is no clean one-click way to lift one subsite out of a network and stand it up as an independent install. The real process means exporting that site's specific database tables, rewriting table prefixes, untangling its rows out of the shared users table, moving its uploads from the network's per-site upload folder, rebuilding a standalone configuration and database, and then fixing every internal URL that was stored with the old structure. Tools exist to help, but it remains a project measured in hours of careful, error-prone work, not a button you press. If you can foresee a site needing to leave, the kindest thing you can do for your future self is to never put it in the network at all.

The lock-in pain, stated plainly

It is worth pausing on that lock-in, because it is the thing that turns a convenient decision into a regretted one. When multisite is the right choice, you never feel the lock-in, because no site ever needs to leave. The network is the system, and it stays the system. When multisite is the wrong choice, the lock-in is the entire bill coming due at once.

The pain is not theoretical and it is not rare. It usually arrives as a perfectly reasonable request. A client wants to take their site in-house. A site has been sold. One site has outgrown the shared environment and is now slowing down its neighbours. In a world of separate installs, every one of those is a routine migration. Inside a multisite network, each one becomes a delicate extraction, and the agency either absorbs that cost or has an uncomfortable conversation about billing for it. Multisite does not make sites harder to maintain. It makes them harder to separate. If separation is ever on the table, that is the cost you are signing up for.

Making the call before you write any code

Putting the five questions together, the pattern is clear. Multisite suits a network that is genuinely one system, with one owner, a shared build, a shared team, and sites that are variations on a single theme. Separate installs suit sites that are independent things, even when the same agency builds and maintains all of them. Being built by one agency is not a network purpose. Being run by one organisation as a single system is.

This is the view we take at WitsCode. The multisite-versus-separate decision is not a hosting preference to settle later. It is an architecture decision, and it is one of the few in WordPress that is genuinely expensive to reverse, so we make it deliberately during discovery, before any code is written. We walk through these five questions with the client, weigh the lock-in against the maintenance saving honestly, and choose the structure that fits the next five years of the business rather than the convenience of the first month. If you are weighing multisite for your own project or your client base and want that call made carefully, with the build to back it up, that is exactly the kind of decision we are built to get right.