WordPress Multisite lets you create multiple WordPress websites that all use the same set of themes and plugins.
It might appear to be a great way to make maintaining multiple sites more efficient, as you can update the WordPress core, themes, and plugins once, and they are updated for all sites.
But in practice, the hidden downsides of Multisite can outweigh the benefits in many situations, and the use cases are more limited than they might appear.
The Benefits of WordPress Multisite
The main benefits of WordPress Multisite are reducing maintenance time and having a common codebase for multiple sites.
If there is a WordPress core, plugin, or theme update, you update it once and it’s updated for all sites in the network.
In some situations, this can be very beneficial. But, let’s look at some of the hidden downsides.
The Downsides of Multisite
There are some serious downsides to using WordPress Multisite that might not be immediately apparent.
1. Database Size
If your sites are huge, and this is often the case in e-commerce sites, then you’re multiplying the size of your database by the number of sites in the Multisite network. This can slow down the performance of ALL of the sites in the network.
I would never put two WordPress sites with huge databases on the same Multisite network. Since the database on e-commerce sites can get really huge, I would avoid putting any e-commerce sites on Multisite.
In my experience, WP Multisite database tables tend to crash more often than stand-alone WP databases (I explain more below). A crash on one site can bring the whole network down if it happens in one of the shared tables.
2. Increased Security Risk
If one of your sites is subjected to a DDoS attack or hack, all sites in the network can be affected. Someone can take down your entire WordPress network by attacking one site in the network. Basically, your attack surface area is multiplied by the number of sites you have in the network.
3. Plugin Incompatibility
Not all plugins work on WordPress Multisite. And, not all plugins work the same way on Multisite. Wtih some, you activate them in the parent site, and in others, you activate them in the individual child sites. In general, most plugins are used a lot less on Multisite, so the plugin developers are not likely to test them as thoroughly for Multisite. Bug fixes might come slower as well.
Some plugins require you to purchase the paid pro version for Multisite compatibility.
4. Plugin Creep
Let’s say you have a Multisite network of sites that are not sufficiently different from each other, or that have different owners with different demands that require different plugins. One site requires this plugin, another site requires another. If you have more than just a few sites, you’ll soon find your network with a bloated mess of plugins. Sure, you can activate them per-site, but they all take up database and disk space even when deactivated.
5. Difficulty in De-Coupling
Someday you may want to migrate one of your child sites out of your Multisite network and it can be tricky. There are now some plugins that do this, including:
- Duplicator Pro (paid version)
- All-in-One WP Migration with Multisite Extension (expensive!)
- Prime Mover WordPress plugin
However, these don’t migrate Multisites as reliably as tools for regular WordPress do. For example, Prime Mover didn’t correctly migrate some custom post types in one of my client’s Multisite networks. All-in-One did migrate those custom posts, but failed to migrate member images in the Ultimate Member plugin (probably because Ultimate Member was storing them in a weird location). In short, Multisite has quirks that plugins might not handle correctly.
Here are some articles I found on how to migrate a child site out of a Multisite manually:
This is not something I would recommend for casual WordPress users.
6. Difficulty in Backing Up and Pushing to Staging
Many of the tools for backing up and copying sites don’t work out of the box with Multisite. WP DB Migrate Pro does have a Multisite Tools Addon but it requires purchase. Overall, the migration process is longer and more involved with Multisite. Since the databases and media libraries are larger, backup scripts are more likely to time out, potentially turning a one-click process into a multi-hour ordeal.
If you do need to make a backup of a Multisite network, I recommend the Duplicator Pro plugin:
This is an affiliate link
Disclosure: Some of the links on this page are affiliate links. This means if you click on the link and purchase the item, I will receive an affiliate commission at no extra cost to you. I test or research each service before endorsing it. I own this site and the opinions expressed here are mine.
7. Greater Developer Expertise Needed
WordPress Multisite requires more expertise in development and maintenance. That means you’ll have a smaller pool of WordPress developers to choose from if you have problems and you might have to pay more.
As a developer myself, it means I have to spend more time figuring out how to do things that I could do much quicker on a regular WordPress install.
Basically, WP Multisite makes some of the easy tasks like updating plugins easier, but makes the hard tasks (like debugging problems or migrating) even harder. Not a good tradeoff in most cases!
8. Shared Users
I have one client that has a Multisite network of WordPress membership sites, each with different admins who manage their sub-sites’ users.
But, when a local admin deletes a user locally, that user still exists in the Multisite database, and they can’t re-use that email address. So, I have to go in as the Super Admin and delete the user globally.
Say you want to get rid of a child site and all of its users. If you delete the child site and its users, the users are still in the master database. I don’t know of an easy way to delete them.
This also makes it harder to deal with privacy issues. If someone wants their info deleted, you have to remember to delete them in the child site and in the master site.
9. Database Fragility
I’ve personally found Multisites to be more “fragile” with respect to database corruption. Two Multisites I manage have had repeated corruption of the wp_sitemeta and/or wp_options tables bringing down some or all of the sites in the network. In most cases, repairing them phpMyAdmin fixes the problem, but in one case I had to restore from backup
I’ve never had tables get corrupted in regular WordPress sites.
10. Putting All of Your Eggs in One Basket
In general, I don’t like putting all of my eggs in one basket. If a plugin update has a problem, or if you introduce a fatal bug in a theme update, it will affect all of my sites that use that plugin or theme. It’s bad enough to bring one site down with a bad update, but it would be horrible to bring ALL of my sites down. I don’t like having sites chained to each other unless the benefits outweigh the costs.
Yes, I know you’re supposed to test plugin updates on a staging site. But many people don’t. If you’re one of those folks who just pushes the Update button when a new plugin is available, I really wouldn’t recommend Multisite!
Why the Benefits May Not Be As Great As Expected
The big benefit of Multisite, easier site administration, might be insignificant if you have unique sub-sites. That’s because, if your sub-sites are all different from each other, then the main time-sink in the update process is not pressing the “Update” button. It is testing to make sure the update didn’t break one of the sites.
Using Multisite doesn’t excuse you from having to test each of your sub-sites individually (unless your sub-sites are truly very similar to each other). So there are diminishing returns if your sub-sites are unique.
And as I’ve stated, Multisite can complicate some of the more intensive WordPress tasks such as moving sites. In my opinion, Multisite often makes the easy stuff easier (i.e., clicking the “update” button) and the hard stuff harder (almost everything else) in WordPress. That’s not a great tradeoff.
When I Definitely Would Not Use Multisite
Here are some specific cases where I would not use Multisite:
- E-commerce sites
- Membership sites
- Sites that don’t share themes
- Sites that require individual theme customization
- Sites that have different “owners” who might want their own customizations in the future
- Any site with a huge database
- Sites that require high security, or sites likely to be attacked (i.e., religious, political, celebrity sites)
- Sites that might need to be split off into separate sites in the future
- Any mission-critical sites where bringing down the entire network would be disastrous
- Sites where fastest load time is needed
What to Use Instead
There are many WordPress administration services out there such as ManageWP that let you manage multiple stand-alone sites similar to how you manage a Multisite network without the downsides of Multisite. These allow you to do updates across many sites at the same time, if that is what you want to do.
When I Would Recommend WordPress Multisite
It may sound like I hate Multisite, but there are actually some situations in which the benefits outweigh the disadvantages.
1. Lots of Nearly Identical Sites
Let’s say you own a franchise where each of the franchise owners needs to have a simple website with a common theme. And, let’s say customizing individual themes is prohibited in the contract. This might be a good candidate for Multisite.
2. You Want to Use Different Themes In Different Parts of Your Site
Say your site has a main section and a blog section, and you want to use different themes for those sections. Multisite could be a good candidate for that application if the sections share a lot of plugins and users. I have used Multisite in this situation effectively.
3. Your Web Host Doesn’t Allow WP Installs in Subdirectory
This is actually where I do use Multisite. My web host does not allow the installation of WordPress in subdirectories. So, pretty much the only solution is to use Multisite if you want a “different” WP install in a subdirectory.
What do you think of Multisite? I’m sure I missed some cases where it is beneficial. Please comment below! – Brian