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

by Francis Rozange | Oct 2, 2026 | WordPress

A glowing glass trunk branching into many identical translucent rooms

In the United Kingdom, more than one hundred and forty government blogs run on a single WordPress installation. The Government Digital Service’s blog, the Technology in Government blog, the departments’ blogs: each has its own address, team and posts, but they all share the same core, the same theme and the same plugins. The network has worked this way since 2013.

That is the promise of WordPress Multisite: running dozens, even hundreds of sites as one. Yet the official documentation opens with a warning. For tightly connected sites that share data or users, multisite might not be the best solution.

This guide helps you decide. It explains what a network really is, how to enable one, the choice between subdomains and subdirectories, what is shared, what it costs in performance, backups and migrations, and the alternatives. It ends with a decision grid.

What a multisite network really is

One core, many sites, separate tables

A multisite network is a collection of sites that share the same WordPress core files. Sites have no folder of their own on disk: each has its own media folder, under wp-content/uploads/sites/ followed by its number (the main site keeps wp-content/uploads/), and its own tables in the database.

Each new site gets ten tables: posts, comments, links, options, terms and taxonomies, with their metadata. The first site keeps the usual tables, such as wp_posts; the second uses wp_2_posts, and so on. Other tables stay shared across the whole network: users and their metadata, the list of sites, sign-ups and network settings.

The official documentation describes the typical use: business sites that share some resources, such as the theme or plugins, with different content for different regions. A network can also let visitors create their own site, as on WordPress.com, or keep site creation for the administrator.

The Super Admin, and what site administrators lose

A network adds a role above all the others: the Super Admin. That role installs plugins and themes, updates core, creates sites and manages accounts. The list of Super Admins is stored in a network option, not in the usual roles.

Below the Super Admin, a site’s Administrator loses much of their power. They can neither install a plugin or theme, nor edit the profiles of their site’s users, nor publish unfiltered HTML. By default, they do not even see the plugins menu. Our guide to WordPress user roles and capabilities details these differences.

Enabling a network: the steps

Preparing the ground

The official documentation lists four prerequisites: back up the database and files, check that pretty permalinks work, deactivate all plugins, and, if you plan to give WordPress its own directory, do so before enabling the network. On a live site, try it on a copy first.

The network setup menu only appears after you add one line to wp-config.php, above the comment telling you to stop editing.

define( 'WP_ALLOW_MULTISITE', true );

Creating the network

A new Network Setup screen then appears under Tools. There you choose the URL model, the network title and the administrator’s email address. WordPress then generates two blocks to copy: the constants to add to wp-config.php, including MULTISITE and SUBDOMAIN_INSTALL, and the rewrite rules for the .htaccess file. After logging in again, the network admin menu is available.

The network’s default settings

A new network is cautious by default. Registration is closed, the plugins menu is hidden from site administrators, and a 100 MB per-site upload quota is pre-filled, but it only applies once the Site upload space box is ticked. Some site names are reserved, such as “www”, “admin” or “files”. These settings can be changed on the network settings screen. Opening registration or the plugins menu deserves thought: version 7.0.3 fixed a flaw that affected networks open to registration.

Subdomains or subdirectories: a binding choice

What each model requires

When creating the network, you choose between two URL models: subdomains, such as site1.example.com, or subdirectories, such as example.com/site1. The documentation is clear: it is one or the other, and changing later is not easy.

Subdomains require a bit more server work. Wildcard DNS is only needed if sites are to be created on demand, despite the warning shown by the installer. Over HTTPS, you need a wildcard certificate or one certificate per subdomain; with subdirectories, all sites share the same domain and certificate.

A few restrictions apply. A subdomain network is impossible if the site address contains a path, such as example.com/blog, or uses localhost or an IP address. No network works on a port other than 80 or 443. WordPress generates rewrite rules for Apache and IIS, not for Nginx: on Nginx, the configuration is up to you.

The one-month rule, as the code applies it

WordPress refuses to create a subdirectory network on an existing site in one specific case: if the posts table holds any published entry, whether a post, a page or another content type, dated more than a month ago. The reason is the risk of collisions between existing post addresses and those of future sites. A constant, ALLOW_SUBDIRECTORY_INSTALL, lets you lift this restriction knowingly.

On a subdirectory network, the main site also gets a /blog/ prefix in its post addresses, for the same reason. Static pages do not: a page and a future site with the same name would therefore collide.

Changing your mind later

Since September 2026, the official documentation spells it out: changing the SUBDOMAIN_INSTALL constant and the rewrite rules migrates neither existing site addresses, nor DNS, nor certificates, nor redirects, nor cookies. It is a full migration.

WordCamp.org did it in 2020. The network of WordPress conference sites used addresses such as 2020.torino.wordcamp.org. Joost de Valk and Jono Alderson had reported that some of these sites were not even indexed because, in their view, Google treated each subdomain as a separate site. The team moved to torino.wordcamp.org/2020, while staying on multisite. To our knowledge, no figures on the SEO effect have been published since.

Going back from a network to a single site is even trickier. The host Pantheon calls the choice between single site and multisite permanent, and does not support switching back.

Custom domains: native mapping

Since WordPress 4.5, giving a network site its own domain no longer requires a plugin. Point the domain at the server, install a certificate for that domain, then change the site’s address in the network admin, on the Sites screen. It works with both URL models.

If logins misbehave on a mapped domain, the documentation gives one line to add to the configuration file.

define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

The sunrise.php file, long essential, is now only needed for advanced cases, for example WPML serving each language on its own domain within a network. One documentation page still suggests a mapping plugin: it has simply fallen behind the others.

Shared users, plugins and themes

A single user directory

All network accounts live in the same tables. An account only gets into a site if it is given a role there, but once logged in on one site, it is logged in on every site of the same domain. Roles are stored site by site, under a numbered key such as wp_2_capabilities.

Deleting an account calls for care. With WP-CLI, wp user delete only removes the account from the current site; you need the --network option to delete it from the network, after reassigning its content. WordPress 7.1 even introduced a regression that emptied the reassignment menu in the network admin when the site’s members were not members of the main site: content could then be deleted without warning, until the 7.1.1 fix on September 17, 2026.

WordPress 7.0 also changed spam handling: marking an account as spam no longer automatically marks its sites. A filter restores the old behavior.

Plugins: per site or network-wide

Plugins are installed once, from the network admin. They can then be activated site by site, or for the whole network; in that case, no site administrator can deactivate them. Must-use plugins, placed in mu-plugins, load everywhere.

A plugin can require network-wide activation with the Network: true header. That header matters: version 7.1.1 fixed a flaw that let a site administrator network-activate a network-only plugin. In August, 7.0.3 had already fixed a privilege escalation that let a registered user create a site.

Not every plugin works on multisite, and the official directory has no field to say so. You have to read each plugin’s FAQ, or ask its author.

Themes: one codebase for all, styles per site

Themes are installed for the whole network, then enabled for all sites or site by site. Editing a theme’s code changes it for every site using it; styles set in the Site Editor stay specific to each site.

On licensing, caution is in order. As WP Engine points out, many premium plugins and themes count each subsite as an activation. A network of fifty sites can therefore use up fifty activations.

A ring of light opening a long corridor of identical glass doors

The GOV.UK case: a government network since 2013

The UK government’s blogging platform is one of the few multisite networks whose story is documented from 2013 to 2020, by its owner, the Government Digital Service, and by its supplier, the agency dxw, which built and hosts it. It shows both when multisite makes sense and what it costs.

Why a network rather than separate blogs

In September 2013, the Government Digital Service introduced the platform, launched that spring with a first blog on the history of government. Not every government organization was as well set up to blog, and sharing that capability brought clear economic benefits. The platform was then free for any public body that met a few criteria, set out in May 2013: post regularly, offer distinct and unique content, follow the style guide.

The shared platform served a precise goal: an experience consistent with the rest of GOV.UK. All the blogs share the GOV.UK look and the same email subscription system. About a dozen blogs were already live in early September 2013, each on a subdomain of blog.gov.uk.

What sharing cost

Joining the network has a price. In January 2014, when the Government Digital Service’s own blog moved onto it, the team warned that most comments from the previous few weeks would not be carried over, and that the update emails sent to subscribers would change.

Account security became one of the priorities. In 2015, dxw and the digital service built a two-factor authentication plugin for the whole platform, with an SMS fallback, because not every civil servant had a smartphone. By the end of 2016, the network counted more than one hundred blogs and two thousand users.

A security audit then revealed a large number of inactive accounts, and users who had left their government roles. dxw built tools to deactivate those accounts and mark as inactive those that no longer logged in. The question the audit raised sums up multisite: how to run a shared platform securely when publishing is delegated to dozens of teams.

What it delivered

The flip side is a decisive advantage: every fix benefits every blog at once. The 2015 two-factor authentication was built once, then rolled out to users across the whole platform. In 2020, after an accessibility audit, dxw spent four weeks fixing the non-compliant elements of the blogging platform and of the government campaigns platform. The platform then had one million monthly active users.

Closing a blog does not mean deleting it. In October 2018, the Digital Marketplace blog announced its closure, its news moving to the main blog. All its content stayed online for reference, and can still be read today.

At the time of writing, the blog.gov.uk homepage lists one hundred and forty-three blogs, image addresses follow the pattern specific to multisite, and new posts appeared there on the very day we checked, October 1, 2026.

What to take away

The GOV.UK case ticks every box of a good multisite use: many small sites, one brand, one template, shared rules and a central team that maintains everything. Conversely, it shows that the shared user directory becomes the main security workload, and that joining the network has a cost. Keep in mind that dxw, a paid supplier, is describing its own work here, and that no cost figures have been published.

Performance and database

Counting tables and host limits

The math is simple: a thousand sites mean ten thousand core tables, before any plugin. Plugins that create their own tables usually create them for every site: WooCommerce declares several dozen. A network of stores therefore multiplies tables very quickly.

Hosts set limits accordingly. WP Engine caps the number of subsites by plan and the number of tables at one hundred thousand per environment, explaining that too many tables cause scaling problems and lengthen maintenance reboots.

Object cache: what is shared, what is per site

With a persistent object cache, some data groups are shared by the whole network, such as users, network options and the list of sites; the others are separated per site. Another practical point: flushing the cache with WP-CLI usually flushes it for every site. Our guide to Redis object caching covers how to set it up.

Very large networks

WordPress itself considers a network “large” beyond ten thousand sites or ten thousand users: some admin screens then behave differently. At the extreme, WordPress.com spreads millions of tables across thousands of databases with the HyperDB plugin, according to the plugin’s documentation, where this sentence has not changed since at least 2011. At those scales, splitting the database becomes a project in its own right.

Backups and migrations: where multisite makes you pay

Moving the whole network

Moving a network on the same domain means copying the files and the database, as for a single site. Changing domain is trickier: the database holds many references to the server address, in each site’s tables as well as the network’s. With the --network option, WP-CLI covers the tables of every site. The official example below is limited to the options tables, wp_blogs and wp_site; drop those names to cover content as well.

wp search-replace --url=example.com example.com example.test 'wp_*options' wp_blogs wp_site --network

To prepare the switchover itself, our guide to migrating a WordPress site without downtime still applies.

Extracting a single site

Taking a site out of a network is manual work. WP-CLI can export just its tables.

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

But users are not in those tables, media sit in a numbered folder, network-activated plugins and must-use plugins do not appear in the export, and the table prefix has to be renamed. A practitioner who extracted a site in 2022 describes receiving an export, probably made with a backup plugin, that was missing more than five gigabytes of media.

What backup plugins do

Full multisite support is often a paid option. UpdraftPlus reserves it for its premium version, Duplicator for its Pro version, All-in-One WP Migration for a dedicated extension that can also extract a single subsite. Jetpack VaultPress Backup does not support multisite. Our comparison of WordPress backup plugins gives the details.

Multisite and multilingual

A network lets you dedicate one site to each language. That is the approach of MultilingualPress, which only works on multisite, from 149 euros per year for two languages as of October 2026, and of the free Multisite Language Switcher plugin. Each site can then have its own content, plugins and team.

This model makes sense when languages are run by separate teams, with different content or constraints. When a single team publishes the same content in each language, a plugin such as Polylang or WPML in a single site is much simpler. Our comparison of WordPress multilingual plugins tells the story of a Swiss international news service that chose the network route.

The alternatives

The official documentation suggests the first one itself: if you only want a different look per section or distinct access levels, a single site with a plugin is enough.

The second is to keep separate installations and run them from a shared dashboard. MainWP, self-hosted, is free in its basic version, with a Pro plan at $199 per year as of October 2026. ManageWP offers its core features for free, with paid add-ons per site. Each site then keeps its own plugins, PHP version and update schedule, and can be handed over or moved without surgery.

Finally, some hosts offer their own fleet management tools. Pantheon, for example, does not support an agency hosting several clients on one multisite installation: it steers the agency toward a Custom Upstream, a shared codebase from which each client gets its own site.

The decision grid

Multisite is a good fit when most of these conditions are true:

Many sites share the same theme family and the same set of plugins.
One central team handles updates, security and accounts, and site owners only publish.
You need to create new sites quickly from the same base.
Single sign-on across sites is a benefit, not a risk.
Your host supports multisite, and you control DNS and certificates for the chosen model.

Avoid it if any of these situations applies:

Sites belong to different clients or need different plugins, PHP versions or schedules.
Separate development teams must not see each other’s code.
A site will one day have to be moved, sold or handed over to someone else.
A key plugin is not compatible, or is licensed per subsite.
You only want a different look or different access per section.

Need	Single site	Multisite	Separate installs and dashboard
Shared accounts	Yes, one site	Yes, with single sign-on	No
Shared updates	Not applicable	Once for all	Batched from the dashboard
Per-site plugins	Not applicable	Limited to the network catalog	Complete
Backing up or moving one site	Simple	Manual, often paid	Simple
Hosting	Standard	Compatible plan, table limits	Standard, per site
Costs to watch	Low	Per-subsite licenses	Multiplied hosting

Frequently asked questions

Can you go back from a network to a single site?

Not with a setting. You have to extract sites one by one, with their tables, media and accounts, or start from a fresh install and import the content. Some hosts, such as Pantheon, do not support switching back.

Do you need wildcard DNS?

Only for a subdomain network where sites are created on demand. If the administrator creates each site, subdomains declared one by one are enough.

Does WooCommerce work on multisite?

Yes, store by store: each site has its own tables, settings and orders. Some payment plugins require one account per site, such as WooPayments, which cannot serve several addresses with a single account.

Is multisite faster than separate sites?

No neutral measurement shows it either way. What is documented: the number of tables, host limits and the shared object cache. A poorly sized network can slow all its sites down at once.

How do you back up a single site in the network?

With WP-CLI, list its own tables with wp db tables --scope=blog, export them with wp db export, and copy its media folder. With a plugin, check that per-subsite backup is included in your plan: free versions rarely include it.

Conclusion

Multisite is a pooling tool. It excels when many sites look alike and a single team governs them, like the UK government’s blogs. It becomes a trap when sites diverge, change hands or depend on plugins that handle it poorly.

Ask yourself one question before turning it on: will these sites still belong together in five years? If the answer is yes, the network will save you time with every update. If it is uncertain, separate installations run from a dashboard will keep every door open.

Sources

LaFactory designs, builds and maintains WordPress and WooCommerce sites, and develops its own plugins. Talk to us about your WordPress project.

Francis Rozange

Former section editor at Libération, he runs LaFactory, an international web agency since 1996.