WordPress Multisite is one of those features people either love or never touch. It saves time on the right job and creates pain on the wrong one. After running both models for client portfolios, here is when each actually wins.
When multisite wins
- Many similar sites with shared management. A university with 80 department sites. A franchise with 200 location pages. A media group with 12 brand sites that all share the same plugin stack. Updating once and propagating is the whole point.
- Centralised user management. One user account with different roles on different sites is genuinely useful when content teams overlap.
- Shared media library when the assets logically belong to one organisation.
- Tightly controlled plugin set. The super-admin enforces what is allowed; site admins cannot install rogue plugins. This is a feature for IT teams.
When separate installs win
- Sites with different stacks. One needs WooCommerce, another needs LearnDash, another is a simple brochure. Multisite forces you to share more than you want.
- Sites that need different update cadences. Some clients want every WordPress update yesterday; others wait six months. Multisite’s “update everything together” is hostile to that.
- Sites with very different traffic profiles. One viral site can bring down the entire multisite network. Separation isolates the blast radius.
- Sites you might sell or hand off. Migrating one site out of a multisite is painful. Separate installs are portable.
The honest gotchas of multisite
- Plugin compatibility is worse. Some plugins simply do not work on multisite. The list shrinks every year but still exists.
- Hosting choice narrows. Many cheaper managed hosts do not support multisite or charge a premium for it.
- Backups are all-or-nothing for the network. Per-site restore is rarely as clean as you want.
- Subdomain vs subdirectory is a one-way decision. Pick wrong and migration is a project.
The honest gotcha of separate installs
Tooling burden. Running 30 separate WordPress installs requires the kind of automation we covered in our 50-sites article. Without it, the “freedom” of separate installs becomes “30 things to remember to update”.
The shorthand
If the sites should be managed together because they share an organisation, a stack, and a release cycle: multisite. If the sites only happen to be managed by the same agency but are otherwise independent: separate installs. The wrong choice is fixable but expensive — make it deliberately on the first build.