WordPress Multisite: When It Helps and When It Hurts

• One WordPress core installation and one plugins and themes directory. Updates apply to every site at once.
• One database, with a set of tables per site plus shared tables for users and network settings.
• One user table. A user account exists across the network, with a role per site.
• One uploads directory, partitioned per site.
• One server, one PHP configuration, one set of resources.
• What each site keeps its own: content, settings, active plugins and theme, and menus.

• Many sites that are genuinely similar — a chain's branch sites, a university's department sites, a franchise network — where consistency is the point.
• One team maintaining all of them, so a single update round covering everything is a benefit rather than a coordination problem.
• Sites that should share users, so someone logs in once and has access to several.
• A platform where people create their own sites, which is what multisite was originally built for.
• A design system rolled out identically across sites, where you want a theme change to reach all of them at once.

• One site with several sections. Sections are pages and post types, not sites.
• Sites belonging to different clients or different organisations. Shared fate across unrelated businesses is a difficult conversation when one of them takes the network down.
• Sites with genuinely different requirements, where site A needs a plugin that conflicts with site B's.
• A multilingual site. Multisite can do it, and dedicated multilingual plugins do it better — translation linking, language switching and hreflang are all more awkward across separate sites.
• One site that's just large. Multisite doesn't help with size.
• A staging environment. Staging is a separate installation, not a site in a network.

This is the consideration that decides most of these cases, and it's underweighted because it only bites occasionally.

One plugin update breaks something, and it breaks across every site. One site gets compromised, and the attacker has filesystem access to all of them. One site gets a traffic spike, and every site slows down. One database problem takes the whole network offline.

For a chain of branch sites run by one team, that's acceptable — they were going to share a fate anyway. For six unrelated clients on one network, it means one client's problem becomes everyone's outage, and you explaining why.

• Only a network administrator can install plugins and themes. Site administrators can activate what's available, which is a feature for governance and a constraint for autonomy.
• Some plugins aren't multisite-aware. They assume one site and behave oddly — settings leaking between sites is the classic symptom. Check compatibility before committing.
• Backups and restores are harder. Restoring one site from a network backup means extracting its tables, not restoring the database.
• Migrating a site out of a network later is real work: extracting its tables, remapping IDs, splitting the uploads, and untangling shared users.
• Domain mapping — each site on its own domain rather than a subdirectory or subdomain — is built in now but still needs configuring.
• Debugging is harder, because a problem on one site may be caused by something in a shared layer.

A network's sites are neighbours competing for the same PHP workers, the same database connections and the same memory. That is fine until one of them is not like the others.

• A single busy site can starve the rest. Monitor load per site, not just for the network as a whole, or you will see the symptom without the cause.
• Shared tables grow with the whole network. The users table in particular can get large on a network where every site has its own audience.
• Object caching matters more than on a single site, because more work is repeated across sites — and make sure the cache is keyed per site, or one site will serve another's data.
• Network-activated plugins run on every request on every site. One heavy plugin activated network-wide is a tax multiplied by the number of sites.
• Page caching works normally per site, but purging needs to understand the network so a change on one site does not clear the whole thing.

Before enabling multisite, check whether one of these fits better.

• Separate installations sharing a Git repository for the theme and plugins. You get consistency in code with independence in operation, at the cost of running updates per site. For a handful of sites this is usually the better trade.
• One site with custom post types, if what you actually have is one site with different kinds of content.
• A multilingual plugin, for translations.
• A shared component library or design system, if what you want is visual consistency rather than shared infrastructure.
• Separate sites with a single sign-on layer, if the driver is shared user accounts specifically.

• Plan the URL structure before enabling it. Subdirectory versus subdomain is decided at setup and awkward to change afterwards.
• Keep the network-activated plugin list minimal. Anything network-activated runs on every site.
• Establish who is a network administrator and keep the list very short. It's the most privileged role in the installation.
• Test plugin updates on a staging network, not on one site of the live one.
• Provision more server resources than a single site would need, and monitor per-site load so one site's traffic doesn't quietly starve the others.
• Document the setup. Multisite networks outlive the people who configured them, and the configuration is not self-explanatory.

Ask two questions. Are these genuinely separate sites, or sections of one? And would the people running them accept that a problem on any one of them can affect all of them?

Two yeses means multisite is probably right. A no to either means separate installations, or one site, will serve you better — and both are much easier to change your mind about later.