WordPress Multisite Explained

The one-line version: multisite is a single WordPress installation — one core, one wp-content, one wp-config.php — serving many sites that share a users table and each get their own set of content tables. Enabling it changes the administration model far more than it changes the code.

Get the decision right first. Migrating a network apart later is significantly harder than joining separate sites together.

What is shared and what is not

Each site gets its own numbered tables — wp_2_posts, wp_2_options and so on — while wp_users and wp_usermeta stay single. That is the whole design. One person, one account, different capabilities on different sites.

The consequence people underestimate: a plugin is installed once, for everyone. There is no per-site plugin directory. A network of forty sites where each wants a different SEO plugin is a network fighting its own architecture.

Subdomain or subdirectory

You pick one at creation, and it is written into wp-config.php:

• Subdirectories — example.com/marketing/. No DNS work. Fine for departmental or language sites. Note that site slugs then compete with the top-level URL space of the main site.
• Subdomains — marketing.example.com. Needs a wildcard A record (*.example.com) and a wildcard TLS certificate. Better when sites should read as distinct properties.

Either way you can map real domains onto individual sites; that is built into core now and does not need a plugin. What you cannot do is flip between the two models afterwards without rewriting URLs throughout every site's tables and issuing redirects for everything already indexed.

Enabling the network

On a healthy single site, with a current backup and preferably on a staging copy first:

1. Deactivate all plugins.
2. Add the constant to wp-config.php, above the "stop editing" line:

define('WP_ALLOW_MULTISITE', true);

3. Go to Tools → Network Setup, choose subdomains or subdirectories, and submit.
4. Paste the two blocks WordPress gives you — one into wp-config.php, one into .htaccess — exactly as shown. On Nginx there is no .htaccess; the equivalent rewrite belongs in the server configuration.
5. Log in again. Sessions are invalidated by the change.

With WP-CLI the same thing is one command:

wp core multisite-convert --subdomains

If pretty URLs break afterwards, the pasted rewrite block is the first suspect — WordPress permalinks not working covers the rest of that diagnosis.

What changes for administrators

A new role sits above everything: super admin. Only super admins can install plugins and themes, create and delete sites, edit users globally, and change network settings. Site administrators inside the network lose those abilities entirely, including the plugin and theme installers.

That restriction is the main reason to choose multisite, and the main reason to avoid it:

• It is a feature when a central team maintains the platform and individual sites should not be able to install arbitrary code.
• It is a problem when each site has a genuinely independent owner who expects to run their own site.

Roles within each site work as they always do; the per-site assignment is what changes. WordPress user roles explained covers the capability model that multisite layers on top of.

When multisite is the right answer

Use it when the sites are genuinely one system:

• a university or company with departmental sites on one brand;
• a language or regional network built from the same templates;
• a product that provisions sites for customers programmatically;
• anything where one team patches everything and wants to patch it once.

When separate installs are better

Choose separate installs when:

• the sites belong to unrelated clients, especially if any might be sold or handed over;
• each site needs different plugins for the same job;
• the sites have very different traffic profiles, and one busy store should not affect the others;
• you need per-site backup and restore that does not involve extracting one site's tables from a shared dump;
• nobody on the team has run a network before and there is no operational reason to start.

"It is cheaper to update one install" is a weaker argument than it looks. Managed updates across separate installs are a solved problem, and the operational cost of multisite lands elsewhere — in migrations, backups and plugin compatibility.

Operational realities

• Backups are network-wide. Restoring one site out of a multisite dump means extracting that site's tables and its uploads folder by hand.
• Migration is harder in both directions. Moving a site out of a network requires exporting its tables, renumbering them and rewriting URLs.
• Not every plugin is network-aware. Some store data in a way that leaks across sites, some have no network settings screen at all. Test before committing, and read how to fix plugin conflicts before assuming multisite itself is at fault.
• Uploads add a directory layer (wp-content/uploads/sites/2/). Anything with a hardcoded upload path breaks.
• One PHP configuration serves everyone. A memory limit that suits the busiest site applies to all of them — see how to increase the WordPress memory limit.
• Caching is per site but purging often is not. Verify that a purge on one site does not flush the entire network on every save.

Verify a new network

Create a second site, then check the boring things in order: it loads over HTTPS on its own hostname, the admin is reachable, media uploads land in the right subfolder, pretty permalinks resolve on both sites, a user added to one site has no access to the other, and the main site is unchanged. Confirm all of that on staging before pointing real traffic at a network you converted this morning.