WordPress Multisite: When It Helps and When It Hurts

Comparison: multisite vs separate installs

Dimension	Multisite	Separate installs	Best fit
Updates	One core, one theme/plugin set	Per site	Multisite: franchise, campus, internal microsites
Ownership	Shared users, network admins	Independent admins	Separate: agencies, resale, SaaS tenants
Plugins	Network-activated or per-site opt-in	Free choice	Separate: conflicting plugin needs
Backups	Shared tables, per-site content split	Self-contained	Separate: compliance, per-client export
Hosting	One stack, shared resources	Isolated stacks	Separate: noisy neighbors, custom PHP
Migration	Complex table remapping	Standard export/import	Separate: handoffs, divestitures

Choose multisite for controlled fleets you operate forever. Choose separate installs when any site may leave, need distinct plugins, or require isolated backups. If you are unsure, separate installs are the safer default in 2026.

Where it fits

Multisite fits organizations running dozens to thousands of low-variance sites: university department pages, restaurant chains, internal campaign microsites, and membership chapters sharing one login. In these cases you want one WordPress core at version 6.8 (current stable as of early 2026), one set of must-use plugins in wp-content/mu-plugins/, and one security patch cycle. It does not fit agencies building client sites, because you cannot cleanly hand off a subsite without exporting content and losing network-level settings.

To enable it, add to wp-config.php above the /* That's all, stop editing! */ line:

define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Then replace the single-site .htaccess rules with the network rules WordPress gives you in Tools → Network Setup. Verify with wp site list via WP-CLI 2.11 and by visiting /wp-admin/network/. Pitfall: enabling multisite on an existing site older than a few weeks can leave serialized URLs broken; roll back by restoring the pre-change database dump and removing the defines. If you host on constrained infrastructure, review our guide on Choosing WordPress Hosting: Shared, VPS or Cloud in 2026 before committing to a network, because one network shares one PHP worker pool.

Plugin and theme compatibility

Multisite changes how plugins load. Plugins can be network-activated to run on every site, or activated per site. Themes must be network-enabled in Network Admin → Themes before any subsite can use them. Many plugins are not multisite-aware: they assume a single options table, write to wp_options instead of wp_2_options, or skip switch_to_blog() when reading cross-site data.

How to test compatibility

1. Install the plugin on a staging network clone, not production.
2. Network-activate it and load three subsites plus network admin.
3. Check wp-content/db.php conflicts and review debug.log for switch_to_blog misuse.
4. Run each site’s critical path (form submit, checkout, cache purge).
5. Confirm the plugin stores data per site with wp site list --field=url plus a database query for its tables.

Common pitfall: a plugin creating one shared table without blog IDs leaks data between sites. Roll back by deactivating network-wide, dropping the plugin’s tables per prefix, and restoring from backup. Verify by querying SHOW TABLES LIKE 'wp_%' and confirming per-site prefixes exist. For teams standardizing delivery, our Custom WordPress Development engagements include a compatibility matrix per network.

Backup and migration complexity

A multisite database has shared tables (wp_users, wp_usermeta, wp_blogs, wp_site) and per-site tables (wp_2_posts, wp_2_options, and so on). A full backup must capture the whole database plus wp-content/uploads/sites/2/ directories. Restoring one site means importing its tables and remapping IDs, not just dropping files.

Step by step: per-site export

1. Use wp db export network.sql for a full dump before touching anything.
2. Identify the site ID with wp site list.
3. Export only that site’s tables with wp db export site2.sql --tables=$(wp db tables --blog_id=2 --format=csv).
4. Copy wp-content/uploads/sites/2/ to the target.
5. On the destination single install, import and run wp search-replace '//subsite.network.com' '//newsite.com' --all-tables.
6. Verify permalinks, media URLs, and user roles load correctly.

Pitfall: restoring a full network dump over a live network duplicates users and breaks wp_blogs paths. Always restore to a staging host first; see Setting Up a WordPress Staging Environment Safely for isolation patterns. Verify by diffing wp site list counts and loading each site’s media library. If you need a recovery path after a bad migration, the process in Choosing a Vendor for WordPress Site Hacked Recovery in 2026 applies to corrupted restores too.

Splitting back into separate sites

Divesting a subsite into a standalone WordPress install is the exit strategy you must plan before enabling multisite. It is doable but manual, because there is no core one-click export that preserves users, settings, and media paths cleanly.

Process: extract one subsite

1. Put the network in maintenance mode and take a full wp db export.
2. Export the subsite content with wp export --dir=/tmp/ --blog_id=2.
3. Copy wp-content/uploads/sites/2/ into the new install’s wp-content/uploads/.
4. Install a fresh WordPress 6.8 single site on the target host.
5. Import the WXR with wp import /tmp/site2.xml --authors=create.
6. Run wp search-replace for old URLs, then delete the subsite from the network with wp site delete 2.

Pitfall: skipping the search-replace leaves broken featured images and serialized widget data pointing at the old path. Roll back by keeping the network dump for 30 days and restoring the subsite with wp site create --slug=subsite plus re-import. Verify by crawling the new site for 404s and confirming wp_options has the new siteurl and home. More migration patterns are in the technical articles index.

Action checklist

• Decide fleet vs handoff: choose multisite only for permanent, uniform fleets.
• Test every plugin on a staging network before network activation.
• Back up the full database plus uploads/sites/ and verify a restore.
• Document the per-site export process before you need it.
• Rehearse one subsite extraction to a standalone install.

Ready to audit your network or plan an exit? Talk to our engineers at Custom WordPress Development for a multisite review.

References & further reading

• WordPress Developer Documentation
• WordPress Theme Handbook
• WordPress Plugin Handbook