WordPress Multisite; When Is It Cost-Effective and When Is It a Disaster

Exactly when do you start thinking about WordPress Multisite?

You've built a second site. Or a third. Now, every time you need to update a plugin, you have to log into three separate dashboards, log in three times, and click "Update" three times. One day you ask yourself: "Couldn't a single installation be enough for all of them?"

Don't ask yourself that question. First ask: "Do these sites really need a shared infrastructure?"

WordPress Multisite is a single WordPress core that manages multiple sites with one database and one wp-content folder. It has been officially part of the core since version 3.0 and is activated by adding one line to the wp-config.php file:

define( 'WP_ALLOW_MULTISITE', true );

After this line, you create the network via Tools → Network Setup. That's it. But what does this "that's it" really mean? It means all sites share one core, one database, and most importantly: a shared user table. If one site gets hacked, the rest are at risk at that very moment.

The real advantage: when all sites are truly one

WordPress Multisite was built for one scenario: a network of sites managed by a single team, from one panel, with one set of plugins and themes. You see examples every day: a university where each faculty has a subdomain (math.university.ac.ir, eng.university.ac.ir), or a network of stores from one brand, each serving a different city.

In this case, one core update updates all sites at once. One plugin installation activates for everyone. A user who registers on the math faculty site has the same account on the engineering faculty site. This is real time savings in management, not a marketing claim.

Global user management is also a serious advantage. In separate installations, if you have 20 sites and one administrator needs access to all of them, you have to add them as an admin 20 times. In Multisite, just once. Super Admin roles have influence across the entire network.

This is where they go wrong: thinking Multisite means "multiple sites with one host"

This is the most common misconception. Someone has three independent sites, each with its own domain, its own content, and its own audience. Then they hear that Multisite "reduces hosting costs" and they build a network. Three months later, they want to sell one of the sites or move it to a more powerful server.

That's where things get bitter. Extracting a site from a Multisite network is a manual operation: you have to extract that site's tables from the shared database, rewrite table relationships, separate its files from the shared uploads folder, and then import all of it into a fresh installation. There is no automated tool in the core for this. Third-party plugins usually work for small sites but break down mid-way at larger scales.

The result? Either you leave the site there, or you spend a weekend on manual migration. I've seen this scene many times: a team that bought 20 hours of migration work to save 500,000 tomans a month on hosting.

Backup; where the game changes

Backing up a regular WordPress installation means: a copy of the files + an SQL export of the database. Simple. Restoring is also simple: put the files back, import the SQL, done.

In Multisite, the database is a single entity. Each site's tables have a specific prefix (e.g., wp_2_posts for the site with ID number 2). If you want to restore just one site from the network, you have to find and import that site's tables separately. If you restore the entire network and one of the sites broke between two backups, you have no choice but to roll the whole network back and lose changes from the other sites.

Now imagine you have 15 sites on one network. One of them gets hacked by a weak plugin. To clean the infection, you have to scan the entire database because users and sessions are shared. In a separate installation, you restore that one site from backup and the rest keep working.

Technical note: popular backup plugins like UpdraftPlus don't fully support Multisite in their free version. They have paid versions that back up each site separately, but you need to factor in that cost too. Command-line tools like wp db export via WP-CLI export the entire database, not just one site. For selective backups, you have to write manual queries.

Migration: a chain where you only want one link

Suppose you've built the network and now one of the sites has grown so large that it needs a separate server. This scenario isn't all that rare. Your main site has 100,000 monthly visits, and a secondary site has just reached 500,000 and is slowing down the rest.

Leaving the network, as I said, is manual. But joining the network isn't easy either. If you have an independent site and want to add it to the network, you have to import its content with the WordPress Importer tool. This tool works for text and images, but it doesn't properly transfer plugin settings, custom shortcodes, and complex structures. You're essentially rebuilding the site, not moving it.

Let me give you a practical criterion: if your plan is to move one of the sites to separate infrastructure within the next 12 months, don't build a Multisite now. You'll have paid the cost of building the network and you'll also pay the cost of leaving it. The sum of these two is always greater than the cost of a separate host.

When is a separate installation the right choice?

The short answer: almost always. If your sites have independent domains, separate content teams, or each needs different plugins, a separate installation is the safer option. Hosting costs more, but you won't pay the cost of error management and migration.

A rule of thumb from me: if you have fewer than 5 sites and each has its own domain, don't build a Multisite. At this scale, the time saved on updates (maybe 30 minutes a month) isn't worth the security risk and backup complexity.

If you have many sites but they share a common subdomain and are managed by a single team, Multisite makes sense. In that case, make sure you have a network-level backup strategy and read the WordPress documentation on networking before building.

For independent sites, choosing WordPress hosting with separate management for each site spreads the risk. If one site has a problem, the others aren't affected. This simplicity is worth its money in the long run.

Quick comparison: Multisite vs. separate installations

How do you make the final decision?

Do a simple test. Answer three questions honestly:

1. Do all sites have one management team?
2. Do all of them use the same set of plugins?
3. Is none of them going to be moved to separate infrastructure in the near future?

If you said "yes" to all three, Multisite could be the right choice. If you said "no" to any of them, choose separate installations. It's simple.

And if you're still not sure, start with a test installation. Build a network with two sites, work with it for a month, take backups and restore them. The cost of this experiment is a cheap Linux host, nothing more. After a month, you'll know the answer yourself.

ServerNet's online testing and analysis tools can help you evaluate the performance of your independent sites. If your sites have acceptable speed on their current hosting, there's no technical reason to consolidate them.

Frequently Asked Questions

Does WordPress Multisite hurt SEO?

The Multisite structure itself doesn't harm SEO. Google treats subdomains and subfolders of a single installation like independent sites. The main problem arises when site speed drops due to shared resources, or when one site in the network affects the credibility of the entire domain because of poor content.

Can I convert independent sites to Multisite later?

Yes, but the cost is high. You have to import each site's content into the network with the Import tool and redo plugin settings. This is doable for small sites with simple text content, but for complex sites with custom structures, it's essentially a site rebuild.

Are WordPress plugins compatible with Multisite?

Most popular plugins work with Multisite, but some are designed only for single installations. Plugins that store their data in global tables (like some caching or security plugins) may cause conflicts between sites. Before installing, check the plugin's compatibility page in the WordPress repository.

How is Multisite backup different from regular backup?

In a regular backup, one SQL file covers the entire database. In Multisite, the database includes tables from all sites, and restoring a specific site requires manually extracting that site's tables. Professional backup plugins automate this, but the free versions often don't have such a feature.