The reflex and the reality
"We have several websites, so we should use multisite." It is a natural thought and it is usually wrong. WordPress multisite, one installation running a network of sites sharing code and users, solves a specific problem: many sites that are genuinely the same kind of thing, managed centrally. Applied to sites that merely happen to belong to the same owner, it adds coupling and removes flexibility.
Here is where it wins, where it loses, and what to check before choosing it.
Where multisite wins
Many near-identical sites. A franchise with forty locations, each with its own site on the same theme with the same plugins and different content. A university with departmental sites. A property group with a site per development. One theme update, one plugin update, one security patch, applied to all. Without multisite this is forty updates and forty things to forget.
Central user management. Staff who need access to several sites log in once. Head office administers all sites from one dashboard. A departing employee is removed in one place.
Sites spun up by non-developers. A new location opens; the network admin creates its site from a template in five minutes, without a developer or a new hosting account.
Shared content or data across sites. With a little code, a network can share a taxonomy, a media library or a post type across sites, which separate installs cannot do without syncing.
A single hosting bill and a single stack to secure. For an organisation with a small technical team, one thing to monitor and back up beats forty.
If your situation has at least three of those, multisite is probably right.
Where it loses
Sites that are actually different. A company's main marketing site, its store, its careers site and its blog are four different kinds of site with different themes, plugins, performance profiles and editing teams. Putting them in one network couples them for no gain: a WooCommerce update for the store affects the marketing site's stack; a heavy plugin the blog needs is loaded on the store.
Plugins that do not support it. Many do; some do not, or do so badly. Licensing for premium plugins across a network is often per-site anyway. Check every plugin on the list.
Separate ownership or separate futures. If one of the sites might be sold, spun out, handed to a different agency or moved to different hosting, extracting it from a network is a migration project. Separate installs are already separate.
Different hosting needs. The store needs a large plan with an object cache; the brochure sites need nothing. In a network they all sit on the store's plan.
Blast radius. A compromise or a bad update on one site is a compromise or a bad update on all of them, because they share code and a database.
Domain mapping and SSL complexity. Each site on its own domain works and is standard now, but certificates, DNS and redirects for forty domains on one install are a real operational load.
Developer familiarity. Fewer developers have run a network. Debugging network-level problems (switch_to_blog, network-activated plugins, shared tables) is a specialist skill.
The costs people forget
- Database growth. Each site adds its own set of tables. A network of a hundred sites has thousands of tables in one database. Backups, migrations and hosting limits all feel it.
- Media. Uploads are per site and can be large in aggregate; offloading to object storage becomes necessary sooner.
- Search and caching. Page caches and object caches need network-aware configuration. Some plugins get it wrong.
- Testing. A theme change needs checking on representative sites, not one.
- The network admin. Someone has to be it. It is a role.
Alternatives to consider first
Separate installs with shared deployment. A single Git repository containing the theme and site plugin, deployed to each site's hosting by a pipeline. Updates are one commit, deployed everywhere. Sites stay independent. This is the answer for a handful of related-but-different sites and it is what we recommend most often.
A managed host's multi-site tooling. Kinsta, WP Engine and others let you manage many separate installs from one panel, with bulk updates and shared backups policy, without network coupling.
One site with multiple sections. Locations as a post type on one site, with their own pages, rather than a site each. For franchises where each location needs a page rather than a site, this is simpler than multisite and better for SEO.
A headless front end with WordPress as one of several content sources, for the multi-channel case.
Deciding
Ask four questions:
- Are the sites the same kind of thing, on the same theme and plugin set?
- Will they always be owned and hosted together?
- Does someone need to create new ones regularly without a developer?
- Is central user management a real requirement?
Four yeses: multisite. Two or fewer: separate installs with shared deployment. In between: talk it through with someone who has run both.
Where this sits
We have built networks for franchises and property groups where they were the right call, and we have unpicked networks that were built because someone had several sites. The architecture conversation is part of scoping any multi-site WordPress project, and the shared-deployment alternative is usually the answer we reach.