When a business runs more than one website, the question almost always comes up. Should we keep them as separate WordPress installations, or merge them into a multisite? The answer is rarely obvious, and the wrong choice can quietly cost a lot in time, flexibility and risk.
We help clients make this decision regularly, so here is how we think about it. No technical deep dive, just the practical reasoning that should sit behind the choice.
What multisite actually is
WordPress multisite is a built in feature that lets several websites run on a single WordPress installation. The sites share the same core files, the same set of installed themes and plugins, and a single database. Each site keeps its own content, its own settings, and can have its own domain or subdomain, but the underlying engine is shared.
That shared foundation is the whole point. It is also the source of every advantage and every drawback that follows.
You can read the official overview in the WordPress Advanced Administration Handbook if you want the technical specifics.
When multisite is the right choice
Multisite tends to make sense when the websites have a lot in common and the organisation behind them is unified.
A network of similar sites under one umbrella is the classic case. Think of a company with regional websites, a university with departmental sites, or a brand running campaign sites that all share the same look and feel. When the sites use the same theme, draw from the same plugin set, and follow the same governance, multisite removes a huge amount of duplicated work. You install a plugin once, you update WordPress once, you maintain one set of security configurations.
Centralised user management is another strong argument. If the same group of editors and administrators need to move between sites, multisite gives them a single login and a single user database. That alone can save real friction in larger organisations.
Cost and resource efficiency matter too. Hosting and licensing tend to be cheaper across a network than across a portfolio of separate installations, and the maintenance overhead is meaningfully lower. For a marketing team or IT function trying to keep many sites in shape, that simplification is often the deciding factor.
When multisite is the wrong choice
Multisite is a poor fit whenever the sites need to be genuinely independent.
If two websites use very different themes, different plugin stacks, or different functionality, the shared environment becomes a constraint rather than a benefit. Every plugin you install affects the whole network. Every update touches every site. If one site needs a specific version of a plugin and another needs a different one, you are stuck.
Security and isolation is the other major concern. All sites in a network share a database and a codebase, which means a vulnerability in one site is, in practice, a vulnerability across all of them. A traffic spike on one site affects performance on the others. A serious security incident can compromise the entire network at once. For sites with different ownership, different sensitivity levels, or different compliance requirements, that shared fate is rarely acceptable.
Plugin compatibility is also a real and often underestimated issue. Not every plugin is built to work in a multisite environment, and some premium plugins charge per subsite rather than per network, which can erase the cost advantage entirely.
Finally, multisite is hard to undo. Once a network is established and content has been built across it, splitting sites back into separate installations is a serious project. The decision should be made with the long term in mind, not the launch.
Questions worth asking before you decide
A few questions usually clarify the picture quickly.
How similar are the sites in terms of design, functionality and audience? The more they overlap, the more multisite makes sense.
Will the same team manage all of them, or do different teams need separate control? Multisite assumes a central administrator, and that is not always realistic.
Are there any compliance, security or data sensitivity concerns that would make a shared environment uncomfortable? If yes, separate installations are usually the safer answer.
Do the sites need to scale independently, or grow together? A network shares resources, which works well for sites with similar traffic patterns and badly for one that might suddenly spike.
How likely is it that the sites will diverge over time? What looks similar today may not stay that way, and migrating out of a multisite later is significantly more work than starting separately from the beginning.
How we approach the decision with clients
We never recommend multisite without seeing the actual sites first. The right answer depends on details that are hard to assess from a brief, things like plugin choices, traffic patterns, ownership structure and how the sites are likely to evolve. What looks like an obvious case for multisite on paper sometimes turns out to be a bad fit in practice, and the other way around.
When the answer is not clear, we usually lean towards separate installations. They cost a little more to maintain, but they preserve flexibility, isolate risk, and leave every option on the table later. Multisite is powerful, but it is also a commitment, and that commitment should be made with full awareness of what it brings and what it takes away.
If you are weighing this decision for your own organisation, we are happy to help you think it through. The earlier the conversation happens, the more options you have.
