WordPress Multisite: When One Network Beats Separate Sites

WordPress multisite is a built-in feature that runs many sites from one WordPress installation. Those sites share one codebase, one database and one pool of users. The distinction that matters is whether your sites truly belong together. Multisite suits campus departments or franchise branches. If you manage unrelated client sites, separate installs with a shared management layer will usually serve you better, and they cause far less pain when one site needs to leave.

TL;DR:

WordPress multisite runs many sites from one install, with one codebase, one database, one user table and one Super Admin.

You choose subdomains or subdirectories when you set up the network, and that choice is hard to reverse later.

Multisite fits sites that share an owner, a theme and a user base, such as universities, franchises and multilingual brands.

For unrelated client sites, separate installs are safer because one bad plugin can't take down every site at once and any site can leave cleanly.

You can manage many sites with AI either way, since the work runs through each site's REST API rather than the network itself.

PRESSHAND

Running separate sites instead of multisite?

PressHand connects Claude or ChatGPT to every WordPress site you own, so you can manage separate installs from one place.

Visit →

How WordPress Multisite Actually Works Under the Hood
Subdomains or Subdirectories: The Choice You Make Once
What Multisite Does Well, and Who Should Use It
Where Multisite Hurts: Shared Failure, Hosting and the Exit Problem
WordPress Multisite vs. Separate Installs, Side by Side
Managing Many Sites With AI, With or Without a Network
Get Plain-English Control of Every Site You Run, for One Payment
Frequently Asked Questions
Sources

How WordPress Multisite Actually Works Under the Hood

Multisite has been part of WordPress core since version 3.0. That release folded the separate WordPress MU project into the main software. You turn it on by adding define( 'WP_ALLOW_MULTISITE', true ); to wp-config.php. A new Network Setup screen then appears under Tools. The WordPress Advanced Administration handbook walks through the full process. It takes about ten minutes on a host that supports it.

After setup, you have one installation hosting many sites. Here is what they share and what stays separate:

One codebase. Every site runs the same WordPress core files. When you update core, every site on the network updates in the same moment.
One database, with tables split per site. The main site keeps the usual wp_posts and wp_options tables. Site two gets wp_2_posts, wp_2_options and its own full set. Network-wide tables such as wp_blogs and wp_sitemeta hold the whole network together.
One user table. There is a single wp_users table for the entire network. A person has one account, and you grant them a role on each site separately.
One Super Admin. This role sits above every site's Administrator. Only a Super Admin can install plugins and themes. Ordinary site admins can only activate what the Super Admin has allowed.
Separate media folders. Each site's uploads go into their own folder, such as wp-content/uploads/sites/2/. The files stay apart even though the code is shared.

One wp_users table serves every site on a multisite network. A person who registers on site 14 already has an account everywhere else.

That shared user table is the feature people most often underestimate. It is a convenience when the same editors work across a dozen sites. It is a liability when those sites belong to clients who have never met each other.

Subdomains or Subdirectories: The Choice You Make Once

During setup, WordPress asks how the network's site addresses should look. You choose between two options:

Subdomains. Sites live at addresses like london.example.com. You need wildcard DNS and usually a wildcard SSL certificate, so check that your host supports both before you begin.
Subdirectories. Sites live at addresses like example.com/london/. There is no DNS work involved, but the subsite paths can clash with the main site's existing pages and permalinks.

WordPress itself steers this choice. If your existing install is more than a month old, the setup screen won't offer subdirectories. The handbook explains that existing permalinks could collide with the new site paths.

If your WordPress install is more than a month old, network setup will not offer subdirectories. You get subdomains, or you start fresh.

You can also point a fully separate domain at a subsite, such as london-bakery.com instead of london.example.com. WordPress has supported this domain mapping natively since version 4.5, so you no longer need a plugin for it. Your host still has to route the domain to the network, and you still need an SSL certificate for each mapped domain.

My recommendation is to use subdirectories for a brand with sections, and subdomains or mapped domains for sites that each need their own identity. Either way, decide before you launch. Switching later is a migration project.

What Multisite Does Well, and Who Should Use It

Multisite works best when the sites have one owner, a common design and a shared group of staff. In that situation, the shared parts save you a lot of work:

Universities and large organizations. Each department gets a site, IT controls which plugins exist, and staff log in with one account.
Franchises and branch networks. Thirty locations can run the same theme, each with its own address, menu and opening hours. Head office pushes a design change to all thirty at once.
Multilingual brands. One subsite per language is a common, clean pattern. It keeps the translations separate while the codebase stays shared.
Site-as-a-service products. If you sell people a site on your own platform, multisite gives you sign-up, provisioning and central control without building any of it yourself.

In all four cases, central control is the point of the setup. The Super Admin deciding which plugins exist is a feature, not a restriction.

Pro Tip: On a fresh network, the maximum upload size under Network Admin → Settings defaults to 1,500 KB. That is smaller than an ordinary phone photo, and site admins can't change it themselves. Raise it on day one, before your editors start reporting "failed uploads" that are really a settings problem.

Where Multisite Hurts: Shared Failure, Hosting and the Exit Problem

The drawbacks of multisite come from the same shared setup that makes it useful. Before you commit, it's worth knowing what each one costs you.

One bad update takes down everything

A network-activated plugin runs on every site. If one plugin update throws a fatal error, every site on the network can fail together. On separate installs, the same bad update breaks one site, and you fix it while the others keep running.

Plugin compatibility is not a given

Most popular plugins work on multisite. Some only partly support it, though, and they may store settings per site where you expected network-wide, or the other way around. Check each plugin's documentation for "multisite" or "network activation" before you depend on it.

Hosting gets narrower and sometimes pricier

Some hosts don't support multisite at all. Others only offer it on higher plans. Subdomain networks also need wildcard DNS and SSL, which not every budget host provides.

Leaving is harder than joining

Moving a subsite out to a standalone install is the step most guides skip. You need to export its tables, rename their prefixes, separate its users from the shared table and rewrite its upload paths. Tools exist for this, but each move is a careful job. On separate installs, a site leaving is just a normal migration.

Backups are all or nothing by default

Many backup setups capture the whole network as one database. Restoring a single subsite to yesterday's version, without rolling back the other forty, takes either a specialized tool or patient work in SQL.

WordPress Multisite vs. Separate Installs, Side by Side

Factor	WordPress multisite	Separate installs
Core and plugin updates	Once, for every site at the same moment	Per site, or batched through a management tool
A broken plugin update	Can take down every site	Breaks one site
User accounts	One shared table across all sites	Separate on each site
Who installs plugins	Super Admin only	Each site's administrator
Hosting requirements	Needs multisite support, plus wildcard DNS for subdomains	Any WordPress host
Moving one site to another host	Multi-step extraction	Standard migration
Restoring one site from backup	Awkward without specialist tools	Straightforward
Giving a client full control	Hard without making them Super Admin	Hand over the admin login
Best for	One owner, shared design and staff	Unrelated sites or client work

If you're a freelancer or agency running sites for different clients, read the last three rows twice. Clients leave, clients want admin access, and clients sometimes need their site restored to last Tuesday. Multisite makes all three harder. For client work, I'd choose separate installs every time and solve the "too many dashboards" problem another way.

Managing Many Sites With AI, With or Without a Network

People often reach for multisite to cut down on dashboards. AI assistants now solve that problem without tying your sites together.

The approach relies on the Model Context Protocol, an open standard that Anthropic introduced in November 2024. It lets an assistant such as Claude or ChatGPT call outside tools. A WordPress MCP client uses that connection to talk to each site through the WordPress REST API. The client logs in to each site with an Application Password, a feature added to core in WordPress 5.6 and described in the Make WordPress Core integration guide. If you haven't created one yet, our guide to setting up WordPress Application Passwords covers the steps and the usual login failures.

This makes the network question mostly irrelevant for daily admin work:

Separate installs. You connect each site once. You can then ask, "Fix the meta descriptions on the last five posts on the bakery site," and the assistant works on that site only.
Multisite. Each subsite still has its own REST API endpoint at its own address, so you connect subsites one by one in the same way. Network-level actions, like creating new subsites or network-activating plugins, stay with the Super Admin.

You get one place to give instructions without sharing a database, a user table or a single point of failure. The choice of assistant matters less than you might expect, but the two do behave differently with long editing sessions. We compare them in ChatGPT vs Claude for running a WordPress site.

Pro Tip: Don't connect the AI with your own Administrator account. On each site, create a dedicated user for the assistant with the Editor role, and give that user its own Application Password. If something goes wrong, you can revoke one password on one site, and the assistant can never install a plugin it shouldn't.

Get Plain-English Control of Every Site You Run, for One Payment

If you run separate installs for clients, or you want to keep your multisite network to the sites that truly belong together, PressHand gives you the single control point that tempted you toward multisite in the first place. It runs on your own machine or server and connects Claude or ChatGPT to every WordPress site you own. From there, it handles 83 jobs: posts, pages, images, menus, plugins, CSS and comments. It also scores live pages for SEO out of 100 and works with Yoast, Rank Math, All in One SEO and SEOPress.

The license costs $97, paid once, and covers every site you own with no per-site fees. The Agency license costs $197 and adds rebrand and resell rights. Both include three months of ReplaStats analytics, plus its WordPress plugin to keep. Here is the caveat: the assistant can only do what its WordPress user is allowed to do. It also isn't a replacement for a Super Admin's network-level controls, so check the spec sheet, ours included, before you count on it for network-wide work. Updates after the first 12 months are optional at $49 a year.

Frequently Asked Questions

Is WordPress multisite free?

Yes. Multisite is part of WordPress core, and you enable it by adding one line to wp-config.php and following the Network Setup screen. The costs show up in hosting instead, because some hosts only support multisite on higher plans or don't support it at all.

Can I convert an existing WordPress site into a multisite network?

Yes, and the existing site becomes the main site of the network. If the install is more than a month old, WordPress will only offer subdomain addresses for new sites, because subdirectory paths could clash with the existing permalinks.

Should an agency put all its client sites on one multisite network?

Usually not. A single broken plugin update can take down every client's site at once, and all the clients share one user table. Moving a client off the network later also takes careful extraction work. Separate installs with a central management tool are safer for unrelated client sites.

Can different sites on a multisite network use different plugins?

Partly. Only the Super Admin can install plugins, but site admins can activate or deactivate the plugins the Super Admin has made available. Any plugin that is network-activated runs on every site, and individual sites cannot turn it off.

Can AI tools manage subsites on a multisite network?

Yes, for most content and settings work. Each subsite has its own REST API endpoint, so an AI client connects to it the same way it connects to a standalone site, using an Application Password. Network-level actions such as creating subsites still need the Super Admin.