What a multi site website is and when it fits

People search for “multi site website” when they mean three different things. Usually they mean WordPress Multisite, where one installation runs a network of sites. Some of them mean several separate websites run by one person or team. Some are a business with several locations, asking whether each location needs its own site. Each meaning has a different right answer, so work out which one you have before you change anything.

Which kind of multi site website do you actually have?

Here are the three setups side by side.

Setup	What it is	Usually right for
WordPress Multisite network	One install, one database, many sites, managed from Network Admin	Sites that share an owner, a theme, a plugin set and a team
Separate installs, one operator	Each site is its own WordPress install, with updates often handled from a central dashboard	Agencies, freelancers and anyone running unrelated sites
One site, many locations or services	A single WordPress site with a distinct page for each location or service	Most small businesses with several branches or service lines

The rest of this article is mostly about the first setup, because that is where the expensive mistakes happen. If you already know you want a network, our WordPress Multisite installation steps cover the setup in detail. If your sites are separate installs, see how to manage multiple WordPress websites.

What a Multisite network shares and what it keeps separate

A network shares the engine but not the content. WordPress keeps one copy of core, plugins and themes, and one user list. Each site gets its own posts, pages and settings in its own database tables, and its own uploads folder under /wp-content/uploads/sites/, named by site ID.

• Core: one copy. When you update WordPress, every site moves to that version at once.
• Plugins: installed once. A Super Admin can network-activate a plugin so it runs on every site, or a plugin can be activated on individual sites. The code is shared either way.
• Themes: installed once and enabled per site.
• Users: one list for the whole network. A role on one site gives no role on another until someone adds it.
• Content: separate per site. Sites cannot share posts or pages without a plugin or custom code.

This is what makes the decision hard. Shared code helps when the sites are meant to stay the same. Once the sites start to differ, it gets in the way.

When one network is the right call

Multisite fits when the sites are really one operation: one owner, one set of rules, the same theme and plugins, and one team running them. WordPress’s own Before You Create A Network page opens by asking whether you really need a network, and it warns against creating one just to get sites that look different.

Good fits that come up again and again: franchise locations on one template, a school district whose sites share a footer and admins, university departments, and closely related brand sites. Practitioners on X and Reddit sum it up the same way. If each site is basically the same site on the same theme and plugins, a network saves work. If not, it creates work.

Site count matters less than similarity. One wordpress.org moderator suggests separate installs for two to four sites, with Multisite becoming more appealing above that. That is one person’s opinion. Most practitioners decide by asking whether the sites are alike, not by counting them.

Interest is also cooling at the top end. In the State of Enterprise WordPress survey, the share of respondents who rated Multisite capabilities very or quite important fell from 56% in 2023 to 46% in 2024. The sample is small and the question measured importance, not usage, but the trend matches what practitioners are saying.

Why unrelated sites usually belong on separate installs

Every site on a network shares the same code and database, so they also share failures. One vulnerable plugin, one bad update, one weak password on a sub-site admin account or one traffic spike can reach every site. How far it spreads depends on the host. You still can’t fully isolate one site from the rest.

Agencies feel this most. A client wants a plugin nobody else needs, so it goes onto the shared codebase. Another client wants to leave, so you have to extract their site. Plenty of agencies have moved client sites off a single network for these reasons. Some went back to separate installs and some moved to isolated hosting. One Reddit user split off about 15 client sites but kept a network of around 50 nearly identical ones, which is the right pattern.

Leaving a network is harder than joining one. To extract a site you separate its database tables, media, users, URLs and plugin records. One estimate puts the first extraction at four to six hours, and it notes that some hosts charge per site to do it. Changing the network type later is also a migration. WordPress’s Multisite Network Administration page says that switching between subdomains and subdirectories takes more than editing SUBDOMAIN_INSTALL and the rewrite rules. The stored addresses, DNS, virtual hosts, TLS, redirects and cookies all have to change too.

The practical rule: if you might want separate sites later, start with separate sites. You can get the single-dashboard convenience with a management tool across isolated installs. Our explainer on what a multi site manager manages covers that choice. If you’d rather not handle the routine client requests yourself, SiteSelf for agencies handles the work on each connected site when you ask for it in chat.

Backups are the other hidden cost. In one wordpress.org thread about an 18-site network, a backup plugin’s free version could back up sub-sites manually, but it needed the paid version for scheduled backups and for the main site, and it could not back up the whole network as one package. Before you consolidate, test whether you can restore one site without touching the others. The usual steps to restore a WordPress site gain an extra step on a network: making sure you import only that site’s tables.

WooCommerce stores on a network do not share anything

Owners often expect one network to mean one catalogue. It doesn’t. WooCommerce’s installation docs say each sub-site stores its data in separate tables and runs on its own. Network activation does not share product databases, checkout sessions or user accounts. A customer who buys from two of your stores has two order histories.

Shared stock needs an extension, such as WooCommerce’s Central Stock or a sync plugin. For two related product lines, the usual advice on r/woocommerce is one store with categories and landing pages.

Does a business with several locations need several sites?

Usually not. Advice in small-business and marketing communities favours one site with a distinct page for each location or service. Separate sites duplicate the maintenance, make it harder to compare conversions, and split your search authority across several domains.

The location pages have to differ in more than the name. A page that is a clone of another with only the city swapped won’t do you any favours. Give each one real local content: staff, hours, the area served and reviews. Keep each one consistent with that location’s business profile.

What breaks after setup, and the order to check it

Most broken networks are infrastructure problems: DNS, the web server, certificates or cookies. A mapped domain only works when three layers agree: DNS and the host, the Site Address in WordPress, and SSL. Check them in this order.

1. DNS and host routing. Sub-sites on a subdomain network that return “Not Found” almost always come down to a missing wildcard DNS record, or a wildcard document root that doesn’t point at the WordPress directory. Creating an empty folder for each subdomain makes this worse. DNS changes can take up to 24 hours to propagate.
2. The Site Address. In Network Admin, go to Sites, then Edit, and set the Site Address (URL) to the full mapped URL, including https://. WordPress has supported this natively since version 4.5, according to the domain mapping handbook, so you don’t need an old mapping plugin.
3. SSL for every domain. The primary domain’s certificate does not cover mapped domains. A host rule that forces all traffic to the primary domain makes every mapped site unreachable.
4. Cookies. Only check these if login loops or “Cookies are blocked” errors remain on mapped domains. The handbook’s fix goes in wp-config.php after the network setup lines.
5. Rewrite rules. Replace the old WordPress rules with the exact ones that Network Setup generates, and back up the file first. On Apache, confirm that mod_rewrite is on and that AllowOverride permits .htaccess.

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

That line fixes one login problem. It does nothing for DNS, SSL or routing.

After a migration, “Error establishing a database connection” can mean more than bad credentials. On a network it can also mean the requested domain is missing from wp_blogs. A common cause is a search-replace that only reached one site. WP-CLI’s search-replace works on the current site unless you add --network. Our guide to changing a WordPress domain safely covers the network case.

Plugins are the other common source of trouble. WP Activity Log 5.3.4 was reported to make a network’s main site show the wrong content, and the developer shipped a redirects fix in 5.3.4.1. Gwolle-Gb 5.1.0 failed to network-activate with a fatal error, and the person who reported it said 5.1.1 worked. Test on staging or on one sub-site before you network-activate anything.

When to stop and get help

Stop if you are editing server configuration on a host you don’t control, if the main site is now broken as well, or if you are about to run SQL from the handbook’s debugging page on a production database. Those examples cover specific cases and can do damage if copied blindly. Ask your host whether your plan supports Multisite before you start. Many setup problems on shared hosting turn out to be host limits.