Should You Use WordPress Multisite? Scenarios and Trade-offs

Multisite allows a single WordPress installation to manage multiple sites, which sounds convenient. However, it introduces strong coupling—all sites share the same database and codebase, meaning an issue in one site can potentially affect all of them.

Whether to use it depends on whether these sites truly need to be bound together.

What is Multisite?

Suitable Scenarios

• Highly related sites: Branches of the same organization, chain stores, or multi-language versions
• Unified user system required: Single sign-on across multiple sites
• Unified plugins and themes: One update applies to all sites
• Large number of sites (more than a dozen), where managing them independently is too costly

Unsuitable Scenarios

• Independent sites (different clients, different businesses) → Should be installed separately
• Each site requires different plugin combinations, which may conflict
• One site has significantly higher traffic or importance than others → Coupling becomes a risk
• You might want to sell or migrate a specific site independently in the future

Placing sites for different clients within a single Multisite network is the most common misuse. It may seem convenient, but if one site is compromised, all are affected, and individual sites cannot be migrated out easily.

How to Enable

// wp-config.php (before /* That's all */) 
define('WP_ALLOW_MULTISITE', true);

Then go to the admin dashboard under Tools > Network Setup, choose subdomain or subdirectory mode, and follow the instructions to add configuration.

// Append to wp-config.php as guided
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);            // true=subdomain, false=subdirectory
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

# Subdomain mode requires wildcard DNS resolution + nginx wildcard server
server_name example.com *.example.com;

# Subdomain mode requires wildcard DNS resolution
dig +short anything.example.com A    # Should resolve correctly

Trade-off Comparison

Two Operational Challenges in Practice

① Coarse Recovery Granularity

In Multisite, all sub-sites share the same database (table prefixes include the site ID). Restoring the entire database will affect all sites, making it impossible to roll back just one.

# Sub-site tables are distinguished by prefix
mysql -e "SHOW TABLES LIKE 'wp_2_%';" dbname   # Tables for Site ID 2

② Plugin Compatibility

Some plugins behave abnormally or explicitly do not support Multisite. Confirm compatibility with critical plugins before enabling.

Decision Tree

Should you use Multisite?
├─ Are the sites related (same organization/business)?
│  └─ No (different clients/businesses) → Install separately
├─ Do you need a unified user system?
│  └─ Yes → Lean towards Multisite
├─ Will you need to migrate a specific site independently later?
│  └─ Yes → Install separately (migration is difficult in Multisite)
├─ Is there a particularly important site?
│  └─ Yes → Install separately (avoid coupling risks)
├─ Do critical plugins support Multisite?
│  └─ No → Install separately
└─ Many sites (10+) that are highly homogeneous
   └─ Multisite is more suitable

Scenario Simulation: One Sub-site Fails, Affecting All

Phenomenon: Multiple sub-sites run under a Multisite architecture.
After one sub-site is compromised, other previously normal sub-sites start experiencing issues.

1. First, analyze why the impact scope is so large → Multisite shares a single database.
   Once a sub-site gains write permissions, its reach extends beyond its own data.
2. Confirm if it’s a batch failure → Check each sub-site individually,
   recording the extent of impact for each. This step determines whether to stop the bleeding globally or handle them one by one.
3. Stop the bleeding globally first → Suspend external services or switch to read-only temporarily to prevent further spread.
4. Identify the difficulty of recovery → To roll back a single sub-site,
   you need to extract its corresponding tables from the full database backup and handle associations with the main site.
5. Realize this is something you can do but shouldn’t do often → The complexity of single-site recovery
   is much higher than in standalone installations; this is an inherent cost of the Multisite architecture.
6. Re-evaluate architectural suitability → These sub-sites belong to different entities,
   so they were never suitable for the same Multisite network.

# See how many sub-sites are in this Multisite network
wp site list --fields=blog_id,url,public --allow-root

# Source of single-site recovery difficulty: each sub-site has a set of numbered tables
wp db query "SHOW TABLES LIKE 'wp_%_posts'" --allow-root

# After stopping the bleed, check visibility one by one
for u in $(wp site list --field=url --allow-root); do
  printf '%-32s ' "$u"
  curl -sS -o /dev/null -w '%{http_code}n' "$u"
done

Root Cause: Multisite shares a database with weak isolation.
The impact of one sub-site being breached is at the database level, while recovering a single site is very cumbersome.

Two key points to remember:

• If sites belong to different entities, they should not be placed in the same Multisite network.
  This is the hardest rule for selection, regardless of convenience.
• When evaluating Multisite, focus on two aspects: fault impact scope and ability to recover a single site independently.
  These determine the cost during incidents, while daily management convenience is secondary.

Multisite vs. Standalone Installation: Operational Comparison

The most critical rows in this table are “Fault Isolation” and “Single-Site Recovery”.
Multisite shares one database; if one sub-site is breached, the theoretical impact scope is the entire database.
During backup recovery, extracting and rolling back a single sub-site is far more complex than in standalone installations.
These two points determine: As long as sites belong to different entities or clients, they should not be placed in the same Multisite network.

# Multisite related: Confirm network config and sub-site type (subdirectory/subdomain)
wp site list --field=url --allow-root
wp site list --fields=blog_id,url,public --allow-root

# Source of single-site recovery difficulty: Check how many sites' data are mixed in tables
wp db query "SELECT blog_id, COUNT(*) c FROM wp_2_posts GROUP BY blog_id" --allow-root 2>/dev/null
wp db query "SHOW TABLES LIKE 'wp_%_posts'" --allow-root

The last command clearly shows the actual structure of Multisite:
Each sub-site has its own set of tables, with numbered prefixes.
Understanding this explains why single-site recovery is difficult—you must extract a specific set of tables from the full database backup
and handle user table associations with the main site. It’s something you can do, but shouldn’t do frequently.

8 Common Pitfalls

1. Putting different clients’ sites together: Risks and responsibilities cannot be isolated.
2. Not confirming plugin compatibility: Critical functions may malfunction.
3. Assuming you can migrate sub-sites independently: Migration is troublesome in Multisite.
4. Not configuring wildcard DNS for subdomain mode: New sub-sites will be inaccessible.
5. Ignoring backup granularity: Unable to restore just one site.
6. Large sites slowing down small ones: Shared resources.
7. Wanting to revert after enabling: Splitting is much harder than installing separately initially.
8. Improper sub-site permission configuration: Administrators may see all sites.

Real Customer Feedback (From Cloud Market Reviews and Inquiries)

The following excerpts are taken from real buyer reviews and inquiries for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and peers, provided for reference only, not fictional tickets):

10***09 2024-03-18 5.0 Convenient and stable | Clean interface | Complete after-sales service (User did not fill in review content)