WordPress Multisite: What It Is and When to Use It 2026

Running five WordPress sites means five dashboards, five rounds of plugin updates and five logins to forget.

WordPress Multisite runs them all from one WordPress install, with one plugin folder and one database. Use it for a network of similar sites you control, like school blogs or regional company sites. For client sites you might hand back, keep separate installs.

We built a three-site test network to see what it really shares. One broken plugin took down all three.

What is WordPress Multisite, in plain English?

WordPress Multisite is a built-in WordPress feature that lets one installation run many separate websites. It’s free, it ships with every copy of WordPress, and it’s switched off until you turn it on.

Think of one apartment building instead of five houses. Every flat has its own furniture and front door. The plumbing and the roof are shared, and one manager holds the master key.

In WordPress, that manager is the Super Admin. They get a new dashboard called Network Admin. From there they create sites, install plugins and themes, and decide what each site may use. Each site still has its own admin, with fewer powers.

So what sits in each flat, and what’s shared? Most explainers skip that part, so we built a network and looked.

How we tested it (and what we didn’t)

We installed WordPress 7.1.4 on a Linux test server running PHP 8.4 and MariaDB 11.4. Then we turned it into a three-site network: the main site, /shop/ and /docs/.

The conversion ran through WP-CLI, which calls the same core functions as the Network Setup screen. We also rendered that screen to copy its exact instructions. Then we read the database, poked at permissions and broke things on purpose.

We didn’t test a subdomain network, mapping real domains with SSL, Nginx rules or performance under load. Where we cover those, it’s from WordPress’s own Advanced Administration Handbook, not our lab.

What’s shared across the network, and what each site keeps

Code and people are shared. Content and settings are not. Here’s what our test network actually stored where:

The table count climbs fast. Our single site started with 12 tables. After conversion and two new sites, it had 38. A 100-site network carries over a thousand, which MySQL handles fine but a database tool makes painful to browse.

Users surprise most people. A login created on one site is a login on the whole network. That’s handy for a school where every student blogs. It’s a problem when two clients should never share a user list.

Subdirectory, subdomain or a domain of its own?

Every network picks one address style at setup: subdirectories (example.com/shop), or subdomains (shop.example.com). Either way, any site can later show on its own domain.

• Subdirectories need nothing extra from DNS. They’re the easier start, and they keep everything under one domain name.
• Subdomains need a DNS record for each site, or a wildcard record if you let people create sites on demand. You’ll also want a wildcard SSL certificate so every subdomain gets HTTPS.
• Domain mapping has been built into WordPress since version 4.5. Point the domain at your server, give it an SSL certificate, then change the site’s address in Network Admin under Sites. No plugin needed.

WordPress doesn’t always let you choose. Two rules caught us in the lab:

• Older sites must use subdomains. Once we backdated the Hello world post by a couple of months, WordPress removed the subdirectory option. Its reasoning: an established site’s posts could clash with new site paths.
• Localhost can’t use subdomains. On a local test machine, subdirectories are the only choice.

There’s one more quirk. In a subdirectory network, the main site’s posts get /blog/ in their address. We set our main site to Post name permalinks and WordPress saved them as /blog/%postname%/, so Hello world moved to /blog/hello-world/. The subsites kept clean addresses like /shop/hello-world/.

Common mistake: Turning an established blog into a subdirectory network and expecting its URLs to stay put. Check the main site’s permalinks straight after conversion, and add redirects if they changed.

When should you use WordPress Multisite?

Use it when your sites look alike, share a plugin list and will always be run by your team. Skip it when each site has a different owner or toolkit.

Good fits: a university giving each department a blog, a franchise with a site per city, or a publisher’s language editions. Each has one owner and one plugin list across many near-identical sites.

Bad fits: unrelated client sites, a store sitting next to a simple blog, or any site you might sell. Our lab showed why.

One bad plugin takes down every site

We wrote a tiny plugin with a deliberate fatal error. Activated on /shop/ only, it broke /shop/ and the other two sites carried on. Network-activated, it broke all three at once, main site included.

That’s the whole trade-off in one test. One update reaches every site. So does one bad update.

Site admins lose powers they’d have on their own install

We made a user the administrator of /shop/ and checked what they could do. They couldn’t install plugins or themes, or even activate a plugin the Super Admin had installed. The Plugins menu doesn’t appear for them by default.

They also lost unfiltered HTML. This admin saved a post with an iframe and a script tag, and WordPress stripped both. The same iframe saved by the Super Admin survived. If your site admins paste embed codes from map or booking tools, that will bite.

Fresh networks also set tight upload limits: 1,500 KB per file and 100 MB of storage per site. You can raise both in Network Settings, but nobody warns your editors first.

Moving one site out is the hard part

Exporting a single site is easy. Our export of /shop/ took under a second: a 13 KB file with its posts, pages and two authors.

It skipped plugin settings, theme options, passwords and the uploads folder. A clean exit means moving the wp_2_ tables, the uploads/sites/2 folder and the users into a fresh install. Plan that before a client asks for their site back.

Our take: Multisite is a management tool, not a hosting plan. No shared owner and plugin list? Separate installs on one hosting account are simpler and safer.

How to enable WordPress Multisite, step by step

Enabling it takes six steps and two file edits. A fresh install needs about ten minutes. On a live site, pick a quiet hour and take a backup first.

Skipping step 1 on a live site is the mistake people regret. A WordPress backup plugin copies the files and database in one go. Then step 3 is a single line:

/* Multisite */
define( 'WP_ALLOW_MULTISITE', true );

Step 5 adds these lines to wp-config.php. This is what our lab generated for a subdirectory network. Your screen will fill in your own domain:

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 );

On Apache or LiteSpeed, these rules replace the usual WordPress block in .htaccess. Nginx needs equivalent rules in its server config. Not sure which you run? Ask your host.

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Comfortable in a terminal? WP-CLI does the database work and the wp-config edit in one command. Our conversion took 0.6 seconds. Each new site took about the same.

$ wp core multisite-convert --title="My Network"
Set up multisite database tables.
Added multisite constants to 'wp-config.php'.
Success: Network installed. Don't forget to set up rewrite rules (and a .htaccess file, if using Apache).

$ wp site create --slug=shop --title="Shop"
Success: Site 2 created: http://example.com/shop/

You still add the rewrite rules yourself. WordPress’s own Create a Network guide covers unusual setups, like WordPress running from its own folder. Starting from scratch? Our guide to installing WordPress step by step gets you to a clean single site first.

Will your hosting plan run a network?

Most WordPress hosts allow Multisite, but not all. Check three things before you switch it on.

• Is it allowed? Hostinger says all its managed WordPress plans support Multisite. Pressable supports both subdirectory and subdomain networks. WordPress.com doesn’t support Multisite, so each site there needs its own plan.
• Can you add DNS records and SSL? Subdomain and mapped-domain networks need DNS records and certificates for each address. Subdirectory networks don’t.
• Are backups and restores per account or per site? Most host backups restore the whole account. On a network, that rolls back every site to fix one.

Every site shares one server’s memory and PHP workers, so a busy site slows its neighbours. Our managed vs shared WordPress hosting comparison shows when a managed plan earns its price. Our Hostinger review covers how 20 of Lokesh’s sites run there.

Want full control? On a virtual private server you set wildcard DNS, upload limits and caching yourself. A small DigitalOcean Droplet is enough to test a network, if you’re happy patching the server too.

Not sure yet? Spin up a throwaway copy with one of our WordPress sandbox tools and try Multisite there before you touch a live site.

Our verdict: who should use Multisite?

Multisite pays off for one owner running many similar sites. For everyone else, separate installs win.

• Schools, universities and companies: use it. One Super Admin, one approved plugin list and shared logins match how these places already work.
• Publishers with regional or language sites: use it, because one theme update reaches every edition. Map each site to its own domain if readers expect one.
• Agencies and freelancers: skip it for client work. A client leaving means unpicking tables, users and uploads, and one client’s bad plugin can break every other client’s site.
• Bloggers with two or three unrelated sites: skip it. Separate installs on one hosting account cost the same and keep each site independent.
• Developers building a sites-on-demand platform: use it with subdomains, wildcard DNS and a host that lets you control the server.

Warning: Treat every network-wide plugin update as a change to every site at once. Test it on a staging copy first. Keep a WordPress security plugin active network-wide too, because a hacked site shares its database with the rest.

Frequently asked questions

The bottom line

WordPress Multisite fits one team running many look-alike sites. You get one Network Admin, one plugin list and one update for everything. For client sites or unrelated projects, separate WordPress installs are simpler to back up, move and keep apart.

Whichever you pick, remember the lab result: a network shares its failures as well as its updates.

Next step: add the WP_ALLOW_MULTISITE line to a throwaway copy and see if Network Admin fits the way you work.