WordPress Multisite: When to Use It, When to Avoid It and the Alternatives

WordPress Multisite lets you run many websites from a single WordPress installation. The official documentation describes a multisite network as "a collection of sites that all share the same WordPress installation core files." One set of core files, one set of plugins and themes, one database and one place to update, serving anything from two sites to thousands.

That shared foundation is both the appeal and the risk. Multisite is excellent when sites are similar and centrally managed, such as a university's department sites, a franchise network or a publisher with regional editions. It is a poor fit when sites have different owners, different plugin needs or very different traffic, because everything shares the same code, the same database server and the same update schedule.

Multisite is built into WordPress core. You turn it on with a setting in wp-config.php, choose sub-domain or sub-directory addresses, and can map each site to its own domain without a plugin.

This guide explains how a network works, when to use it, when to avoid it, how domains, plugins, themes and users behave, and what alternatives exist.

How a multisite network works

• One codebase. WordPress core, plugins and themes are installed once and shared by every site.
• One database, separate tables. Each site gets its own set of content tables (posts, options and so on), while users and network settings live in shared tables.
• Shared users. According to the official administration docs, users are created in common tables but must be assigned a role on a site before they can access it. One login can work across many sites.
• A Super Admin. The network has a Network Admin dashboard. The Super Admin manages sites, users, plugins, themes and network settings. Each site has its own Administrators, Editors and other roles.
• Separate uploads. Each site keeps its media in its own folder.

Sub-domains vs sub-directories

When you create a network, you choose how site addresses work:

• Sub-domains: site1.example.com, site2.example.com. Creating sites on demand requires wildcard sub-domains on your DNS and server. You cannot choose this mode if WordPress is installed in a path, or on localhost or an IP address.
• Sub-directories: example.com/site1/, example.com/site2/. The official docs note that you cannot choose this mode if your existing WordPress install has been set up for more than a month, because of conflicts with existing permalinks.

Either way, individual sites can later be mapped to completely separate domains.

When multisite makes sense

• Many similar sites with one owner: schools and departments, franchise locations, regional or language editions, brand microsites.
• Central control is a feature: one team decides which plugins and themes are allowed and keeps everything updated together.
• Shared users: staff need access to several sites with one account.
• Site creation at scale: new sites need to be launched quickly from a standard setup, sometimes by users themselves.
• One subdirectory per language: some multilingual setups use one site per language. Others use a single site with a translation plugin; both approaches work.

When to avoid multisite

The official documentation puts it plainly: if your sites are strongly interconnected, share data or share users in complex ways, multisite might not be the best solution. In practice, also avoid it when:

• Sites have different owners or clients. Separating one site out later is a migration project, and billing, access and responsibility get tangled.
• Sites need very different plugins. Every plugin installed is available to the whole network, and some plugins are not multisite-compatible or are licensed per site.
• One site has very different traffic. A busy store and a quiet brochure site sharing one server and database means the store's load affects every site.
• You need different update timing. Updating a plugin updates it for every site at once.
• Your host does not support it well. Some hosts limit or charge extra for multisite, and some backup and security tools work only at the network level.

The shared-risk point matters for security too. A vulnerable plugin, a compromised Super Admin account or a database problem affects the whole network at once.

Domain mapping

Since WordPress 4.5, domain mapping is native, so a network site can use its own domain (brand-one.com, brand-two.com) instead of a sub-domain or sub-directory. Per the official domain mapping documentation, the main steps are:

1. Point each domain's DNS at your server.
2. Install SSL for the primary domain and use SNI certificates for the other domains. Many hosts handle this automatically.
3. In Network Admin, edit the site and change its Site Address (URL) to the mapped domain.
4. If logins fail with a cookie error, the docs suggest setting COOKIE_DOMAIN in wp-config.php.

Older guides that recommend a domain-mapping plugin predate 4.5. Check that any SEO settings, sitemaps and redirects reflect the final domain.

Managing plugins and themes in a network

As the multisite administration documentation states, site admins cannot install new themes or plugins. That is good for control, but it means every request for a new plugin goes through the network team.

Before adding any plugin, check that it supports multisite. Look for notes in its documentation about network activation, per-site settings and licensing. Our post on building multisite plugins explains what developers need to handle.

Setting up a network

The official steps for creating a network, in short:

1. Back up the site and deactivate all plugins.
2. Add define( 'WP_ALLOW_MULTISITE', true ); to wp-config.php.
3. Go to Tools > Network Setup, choose sub-domains or sub-directories, and set the network title and admin email.
4. Copy the generated lines into wp-config.php and .htaccess (or your server config) as instructed.
5. Log in again, then reactivate plugins, network-wide or per site as appropriate.

Test this on staging first. See our staging guide. Turning an existing busy site into a network is easier to get wrong than starting fresh.

Operating a network day to day

• Backups: back up the whole network (files plus the full database). Restoring a single site from a network backup is harder, so check that your backup tool supports it. See our backups guide.
• Updates: one update covers every site, so test on a staging copy of the network first. Our updates guide covers the routine.
• Performance: a large network needs good hosting, object caching and database attention. WordPress raises PHP memory to 64MB by default for multisite, compared with 40MB for a single site, and large networks often need more.
• Roles: keep the number of Super Admins small. A Super Admin can change any site on the network.
• Moving a site out: exporting one site to its own install is possible but requires migrating its tables, users and uploads. Plan for it if a site might leave later.

Alternatives to multisite

Multisite is not the only way to manage many sites.

• Separate installs with a management dashboard. Tools such as MainWP (a self-hosted dashboard; its child plugin has 700,000+ active installs on WordPress.org as of October 2026) or ManageWP (its Worker plugin has 1+ million) let you update, back up and monitor many independent sites from one place. Each site keeps its own plugins, database and update schedule.
• Managed hosting with multi-site accounts. Many hosts let you run many separate installs under one account, with staging and backups per site.
• A single site with sections or languages. If "sites" are really sections of one brand, one install with categories, custom post types or a translation plugin may be simpler.
• Headless or decoupled setups. Large organizations sometimes use WordPress as a shared content source feeding several front ends. See our guide to using WordPress as a headless CMS.

To try multisite without risk, WordPress Playground can start a disposable multisite network in your browser.

Conclusion

WordPress Multisite is a strong choice when one organization runs many similar sites and wants central control over code, users and updates. It is a poor fit for unrelated sites, sites with different owners, or sites with very different needs, because everything shares the same codebase, database and risks. Domain mapping is built in, but plugin compatibility, backups and future site separation need planning. Explore more in our WordPress hub, and if you are weighing a network build, eSEOspace's WordPress development team can help scope it.

Frequently asked questions