WordPress Multisite: When It Helps and When It Hurts

WordPress Multisite turns one WordPress installation into a network of sites that share the same code, the same plugins and the same user accounts. For an organization running thirty similar sites that is a large saving in maintenance. For an agency hosting five unrelated client sites it is a liability that shows up the first time one site needs something the others must not have.

The difference comes down to what is shared and whether you want it shared. Once that is clear, the decision is usually quick.

What a network shares and what stays separate

A network runs from one copy of WordPress core, one plugins folder, one themes folder and one database. Inside that database, each site gets its own set of content tables with a numbered prefix, while users are stored once for the whole network.

• Shared: core files, the installed plugins and themes, the tables wp_users and wp_usermeta, the PHP version, the server and the update schedule.
• Separate per site: posts, pages, media, options, menus and widgets (in tables such as wp_2_posts and wp_2_options), uploads (under wp-content/uploads/sites/2/), the active theme and which plugins are switched on.

Two layers of administration follow from this. A Super Admin installs and updates plugins and themes for the whole network and decides which themes sites may use. A site administrator manages content and users on one site and can activate only what the network makes available. A plugin that is network-activated runs on every site. A user account exists once but has no access to a site until it is given a role there.

Sites can live in subdirectories (example.com/london/), on subdomains (london.example.com) or on their own mapped domains.

Where WordPress Multisite earns its place

Multisite fits when the sites are siblings: same owner, same technical team, same family of themes and plugins, different content and editors.

• Universities and schools. Each faculty, department or research group gets a site with its own editors, while the central web team controls the theme and the plugin list.
• Franchises and multi-location businesses. Every location has the same layout and features and its own address, staff and offers.
• Publishers and media groups running several titles on one editorial platform.
• Companies with regional or brand sites that must stay on the same design system.
• Site-as-a-service products, where customers sign up and receive a site on a fixed feature set.

In each case the benefits are the same. One update covers every site. A new site takes minutes to create. An editor who works on four sites has one login. Nobody can install a plugin that the central team has not vetted.

Where it hurts

The same sharing becomes the problem when sites are not siblings.

Unrelated client sites. All clients sit in one database with one user table. A fatal error in a network-activated plugin takes every site down at once, an intrusion into one site puts the others at risk, and handing a single client their site means extracting it from the network.

Sites that need different plugins or timing. You cannot run one version of a plugin on site A and another on site B, or update one site this week and the rest next month. Every site moves together, so every update has to be tested against all of them.

One heavy site among light ones. A store or a busy membership site shares PHP workers and the database server with everything else, and its peaks slow the whole network.

Sites that are really sections. If the "sites" need to share content, search across each other or show one combined listing, Multisite works against you. Content lives in separate tables, and code has to hop between sites with switch_to_blog() to read it. WordPress's own guide, Before you create a network, says a network may not be the best choice for sites that are strongly interconnected. One site with categories, custom post types and user roles is often the simpler answer.

Check plugin and theme compatibility first

Most popular plugins run on Multisite, but "runs" and "is designed for" are different things. Before committing, check each plugin you depend on for the following:

• Custom tables. A plugin that creates its own tables has to create them for every site, including sites added later. Poorly written ones only do it for the site where they were first activated.
• Settings scope. Some settings belong at network level and some per site. Plugins that only offer per-site settings mean configuring every site by hand.
• Licensing. Commercial plugins may count each site in the network as a separate license.
• Backup, caching and security plugins. These touch the whole installation and need explicit Multisite support.

WooCommerce works on a network, but each site is a separate store with its own products, orders and customers. Test network activation of every plugin on a staging copy, and create a new site afterwards to see whether it is set up correctly.

Setup choices that are hard to undo

Enabling the feature is short. Back up, deactivate all plugins, add one line to wp-config.php and follow the screen under Tools > Network Setup, which gives you the remaining lines for wp-config.php and .htaccess.

define( 'WP_ALLOW_MULTISITE', true );

The lasting decision is subdomains or subdirectories. The official guide to creating a network notes that you can switch later but that it might not be easy. Subdomains normally need wildcard DNS and a certificate that covers them. On an existing site that has published posts more than a month old, the setup screen does not offer subdirectories. Mapped domains are set per site in the network admin and need DNS and a certificate for each domain.

WP-CLI is close to essential for running a network. The --url flag picks the site a command applies to:

wp site list --fields=blog_id,url
wp plugin activate my-plugin --network
wp plugin list --status=active --url=london.example.com

Backups, restores and moving a site out

A full backup of a network is simple: one database and one wp-content folder. Restoring a single site is not, because rolling back the whole database rolls back every other site with it. You need to be able to export and import one site's tables and its uploads folder:

wp db export london.sql --tables=$(wp db tables --scope=blog --url=london.example.com --format=csv)

Practice that restore before you need it. The general rules are in a WordPress backup strategy you can restore from.

Moving a site out of a network into a standalone install is a migration, not an export. The site's tables have to be renamed to the standard prefix, its users pulled out of the shared user tables, and upload paths rewritten. It is routine work for a team that does WordPress migration, and the reverse direction is similar, but plan for it. It is not a button.

Alternatives worth comparing

	Multisite network	Separate installs with a management tool	One site with roles and post types
Updates	Once for all sites	Per site, triggered from one dashboard	Once
User accounts	Shared	Separate	Shared
Different plugins per site	Limited to what is installed network-wide	Free choice	Not applicable
Restore or move one site	Needs table-level work	Simple	Not applicable
A fault in one site	Can affect all	Stays contained	Affects the site

Management tools such as MainWP or ManageWP, or your own WP-CLI scripts, give you bulk updates across separate installs while keeping every site isolated. For unrelated sites that is usually the better trade.

How to decide, and when to ask for a second opinion

Choose Multisite when all of these are true: one organization owns every site, one team maintains them, they use the same plugins and themes, and you expect to keep adding sites. If any one is false, separate installs are safer. If the sites need to share content, look at a single site first.

A network of a handful of brochure sites is something a competent administrator can set up and run. Bring in WordPress developers when the network will carry stores or learning platforms, when custom plugins have to be made network-aware, or when an existing set of sites is being merged into one. Whatever you choose, updates on a network deserve a staging pass every time, which is the main thing a WordPress maintenance plan pays for here.

Frequently asked questions

Is a Multisite network faster than separate sites?

Not by itself. The sites share one server and one database, so they compete for the same resources. It can be cheaper to host, and one well-tuned server is easier to manage than twenty, but a traffic peak on one site is felt by all of them.

Can each site in a network have its own domain?

Yes. WordPress supports mapping a separate domain to a site from the network admin, with no extra plugin for the basic case. Each domain needs DNS pointing at the server and a valid certificate, and login cookies do not carry across different domains.

Can an existing site be converted to Multisite?

Yes. The existing site becomes the first site in the network and keeps its content. Take a full backup first, deactivate plugins during the conversion and check every plugin afterwards. Other existing sites then have to be imported one by one.

Is Multisite a good way to build a multilingual site?

It is one valid approach: one site per language, linked by a plugin built for that purpose. It gives each language its own editors and settings, at the cost of managing several sites. A multilingual plugin on a single site is simpler when the languages mirror each other closely.