WordPress Multisite vs separate installs: which fits your sites?

Choose WordPress Multisite when one team runs many similar sites that should share the same code, plugins, themes and user accounts, such as university departments, regional offices or a franchise. Choose separate installations when sites have different owners, different plugins, different risk levels or might one day be sold or handed over; WP-CLI aliases let you manage a fleet of separate sites almost as easily.

The official handbook puts it bluntly: if your sites need to be strongly interconnected, share data or share users in complex ways, a network "might not be the best solution". This comparison explains how Multisite really works, where it saves time, where it costs you, and how to set up either option with WP-CLI.

How Multisite works

A Multisite network is one WordPress installation that serves many sites. According to the Advanced Administration Handbook:

• Core files are shared. Every site runs the same WordPress version, updated once.
• Plugins and themes are installed once for the network. Individual sites can activate them, but only a network administrator (the "super admin") can install them.
• Content is separate. Each site gets its own database tables, such as wp_2_posts and wp_2_options, and its own uploads folder under wp-content/uploads/sites/2/.
• Users are shared. There is one user table for the whole network; a person has one account and a role on each site they belong to.
• Addresses are subdomains or paths. A sub-domain install gives site1.example.com; a sub-directory install gives example.com/site1. Since WordPress 4.5, any site can also be mapped to its own domain without a plugin.

Multisite vs separate installs: side by side

When Multisite is the right choice

• Many sites, one owner, one standard. A university with 60 department sites that must use the approved theme and plugin set.
• Sites created on demand. A platform where users or staff spin up new sites from a template, similar to WordPress.com.
• Shared accounts are a feature. Staff who write for several regional sites with one login.
• Central control matters more than flexibility. Site admins cannot install plugins, which is often exactly what IT wants.

When separate installs are better

• Clients or business units own their sites. An agency hosting 30 client sites should not let one client's plugin request, outage or breach affect the other 29.
• Sites differ. A shop, a membership site and a blog need different plugins and different caching.
• Traffic is uneven. One high-traffic site should not slow down the rest.
• Exit options matter. If a brand might be sold or spun off, a standalone site moves with it cleanly.

Option A: Create a network with WP-CLI

The handbook's preparation steps apply whichever tool you use: back up files and database, confirm pretty permalinks work, and deactivate all plugins before converting. Then convert an existing single site:

# Back up first
wp db export before-multisite.sql

# Convert to a sub-directory network (add --subdomains for a domain-based network)
wp core multisite-convert --title="Acme Network"

# Create a site, activate a plugin for every site, add a second super admin
wp site create --slug=london --title="Acme London" --email=london-admin@example.com
wp plugin activate acme-branding --network
wp super-admin add jane

multisite-convert adds the network constants to wp-config.php unless you pass --skip-config. On a sub-directory network the result looks like this:

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

You still need the Multisite rewrite rules in .htaccess or your Nginx configuration; the Network Setup screen in wp-admin prints the exact rules for your installation.

Restrictions to check before you convert

• You cannot create a network if the WordPress address uses a port other than 80 or 443.
• A sub-domain network is not available if WordPress is installed in a path, or if the address is localhost or an IP address.
• A sub-directory network is not offered for an existing site that has been set up for more than a month, because of clashes with existing permalinks.
• On-demand subdomain sites need wildcard DNS; sites you create by hand do not.
• Decide on www or no www before converting; changing it afterwards is harder.

Working with one site in a network

Most WP-CLI commands target a single site with --url. To back up just one site, export only its tables:

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

Remember that users live in the shared tables, so a single-site restore does not bring back user accounts. Copy wp-content/uploads/sites/<id>/ as well.

Option B: Manage separate installs as a fleet

Separate sites do not have to mean separate effort. WP-CLI aliases in a wp-cli.yml file let you run the same command against several installations over SSH, and alias groups combine them:

@client-a:
  ssh: deploy@server1.example.com
  path: /var/www/client-a
@client-b:
  ssh: deploy@server2.example.com
  path: /var/www/client-b
@clients:
  - @client-a
  - @client-b

wp @clients core version
wp @clients plugin list --update=available
wp @client-a plugin update --all

Pair this with a shared base theme or a must-use plugin deployed from Git, and you keep most of Multisite's consistency without coupling the sites' fate.

A quick decision test

Answer these five questions for your group of sites. If you answer "yes" to most of them, Multisite is likely a good fit; if you answer "no" to two or more, separate installs will probably cause fewer problems:

1. Is one team responsible for every site, today and for the foreseeable future?
2. Can every site run the same plugin and theme versions?
3. Would shared user accounts help rather than confuse people?
4. Is a short outage of all sites at once acceptable during an update?
5. Is your host comfortable supporting a Multisite network?

Gotchas

• "Network Activate" is all or nothing. A network-activated plugin runs on every site; test it on a staging network first.
• Super admin is the most powerful account you have. Keep the number of super admins small and protect them with strong, unique passwords and two-factor authentication.
• Search and replace needs --network. When moving a network, URLs live in every site's tables and in wp_blogs and wp_site.
• Mapped domains need certificates. Each mapped domain needs TLS, and if logins fail with cookie errors the handbook suggests setting COOKIE_DOMAIN in wp-config.php.
• Turning Multisite off is not a button. Going back to single sites means migrating each site out.

What to do next

1. List your sites with their owners, plugins, traffic and likely future. Mixed answers point to separate installs.
2. If Multisite still fits, build a staging network and test every plugin you need with network activation.
3. Write down your backup and single-site restore procedure before launch.
4. If you choose separate installs, set up WP-CLI aliases and a shared update routine on day one.