WordPress Multisite sounds like a dream when you first hear about it. One installation, one set of plugins, one place to update everything, and as many sites as you like running on top. For agencies, universities and franchise businesses, it can genuinely be the right tool.
I’ve also been brought in to untangle Multisite networks that should never have been built. Sites that had nothing in common were bundled together because it seemed convenient at the time. Years later, one of them needed a plugin the others couldn’t tolerate, or a client wanted to move their site to a different host, and suddenly the convenience turned into a long and expensive extraction project.
Multisite isn’t good or bad. It’s a specific architecture with specific trade-offs. This guide is meant to help you make that decision with your eyes open.
What Multisite actually is
A normal WordPress installation runs one site. Multisite turns one installation into a network of sites that share the same WordPress core files, the same plugins and themes folder, and the same database, with separate tables for each site’s content.
A few key ideas:
- Super Admin. A new role above Administrator that controls the whole network: which plugins and themes are available, which sites exist, and network settings.
- Network-activated plugins. Plugins can be activated for every site at once, or made available for individual site admins to activate.
- Shared users. There’s one users table for the whole network. A person can have different roles on different sites, but it’s the same account.
- Subdomains or subdirectories. Sites can live at site1.example.com or example.com/site1. Domain mapping lets each site use its own domain as well.
Enabling it starts with one line in wp-config.php:
After that, WordPress walks you through the network setup under Tools and gives you more configuration lines to add. The setup itself is easy. Living with the decision is what needs thought.
When Multisite is a great fit
Multisite shines when the sites in the network are genuinely related and benefit from being managed as a group.
Organisations with many similar sites
Universities with department sites, franchises with location sites, and media companies with regional editions are classic examples. The sites share a brand, a theme and a set of approved features. Central control is a feature, not a limitation.
Sites that share users
If the same people need to log in across many sites, a shared user base saves real effort. A staff member who writes for five regional blogs only needs one account.
Platforms that create sites on demand
Some products let customers spin up their own site, such as a school platform giving each class a site, or a SaaS product built on WordPress. Multisite handles this neatly, because creating a new site is a single database operation rather than a whole new installation.
Strict control over plugins and themes
In a network, individual site admins can’t install plugins. Only the Super Admin can. For organisations that want to prevent random plugins from appearing, that’s a big advantage.
When Multisite will hurt you
Here’s where most of the problems come from.
Unrelated client sites
The most common mistake I see is an agency or freelancer putting all their client sites into one network to save on hosting and updates. On day one it feels efficient. Then:
- One client needs a plugin that conflicts with another client’s site.
- One site gets heavy traffic and slows down every other site on the network.
- A security issue on one site puts all the others at risk, because they share files and a database.
- A client leaves and wants their site moved, and you discover how fiddly it is to extract one site from a network.
If the sites belong to different businesses with different needs, separate installations are almost always better. Tools for managing many separate sites from one dashboard have become very good, so you don’t need Multisite to update everything in one place.
Plugin compatibility
Most popular plugins work on Multisite, but not all of them, and “works” can mean different things. Some plugins store settings network-wide when you expected them per site. Some licence per site and get expensive across a big network. Some simply aren’t tested on Multisite at all. Before committing, check that every plugin you rely on officially supports it.
Everything updates together
Shared core and plugins mean that when you update a plugin, it updates for every site that uses it. That’s the selling point, but it’s also a risk. One bad update can break fifty sites at once. Good staging and testing processes are even more important on a network.
Backups and restores are harder
Backing up the whole network is straightforward. Restoring a single site from last Tuesday without touching the others is not. Many backup tools handle it poorly or not at all. Think about how you’ll recover one site before you need to.
Hosting limitations
Some hosts don’t support Multisite, or only support it on higher plans. Domain mapping and SSL for many custom domains can add complexity, though modern hosting has made this much easier than it used to be.
Questions to ask before deciding
I run through these with clients considering a network:
- Do all the sites belong to the same organisation?
- Will they use mostly the same theme and plugins?
- Do the same people need to log in across them?
- Is it acceptable for an update to apply to every site at once?
- Is it unlikely that any one site will need to leave the network?
- Are all critical plugins confirmed compatible with Multisite?
If most answers are yes, Multisite is worth considering. If several are no, separate sites will probably serve you better.
Practical tips if you do go ahead
Choose subdomains or subdirectories carefully
This choice is hard to change later. Subdirectories are simpler for SSL and keep everything under one domain, which some people prefer for SEO. Subdomains feel more separate and suit sites with distinct identities. If most sites will use their own domains through mapping, the choice matters less.
Lock down plugin management
Decide which plugins are network-activated, which are optional, and who gets to request new ones. Without a clear process, the network slowly fills with plugins nobody remembers installing.
Plan your performance setup
A busy network needs good caching and a persistent object cache such as Redis. Because all sites share one database, a slow query on one site can affect others. Monitor database performance across the network, not just page speed on the main site.
Use WP-CLI
WP-CLI is extremely useful on networks. You can run commands against a specific site with the url parameter, or loop through every site:
Have an exit plan
Even if you don’t expect any site to leave, know how you’d do it. Test extracting one site to a standalone installation on staging. It’s much better to learn the process calmly than during a client handover.
Alternatives worth considering
If the main reason you’re looking at Multisite is to manage updates across many sites, look at management tools instead. Several services let you update, back up and monitor dozens of separate WordPress sites from one dashboard, without tying them together technically.
If the goal is sharing content between sites, you can use the REST API or syndication plugins to push posts from one site to others. That gives you shared content without shared infrastructure.
Frequently asked questions
Is Multisite bad for SEO?
No. Search engines see each site as a normal website. What matters is good content, proper structure and correct technical setup on each site. The subdomain versus subdirectory choice can influence how sites are perceived as related, but it isn’t a ranking penalty either way.
Can I convert an existing site to Multisite?
Yes. Your existing site becomes the main site of the new network. Take a full backup first and test on staging, because permalinks and some plugin settings can be affected.
Can I move a site out of Multisite later?
Yes, but it takes work. You need to export that site’s content and tables, move its uploads, and convert user data into a standalone installation. Migration plugins can help, but plan for some manual cleanup.
Does each site need its own SSL certificate?
Each domain needs to be covered by a certificate. With subdirectories, one certificate covers everything. With subdomains, a wildcard certificate is the usual choice. Mapped custom domains each need coverage, which most modern hosts handle automatically.
Final word
Multisite is a powerful tool for organisations that really are one entity running many related sites. It’s a poor shortcut for managing unrelated sites that happen to share a developer. Be honest about which situation you’re in. If you’re unsure, start with separate installations. It’s much easier to combine sites later than to pull them apart.
