WordPress Multisite alternative: when one shared install becomes everyone’s problem

By the We.Inc editorial team · Updated · Editorial policy

WordPress Multisite is a clever answer to a real need: dozens of sites, one installation, one place to update. It suits teams with WordPress developers on staff. It suits much less well a central team that has no developers and sites owned by people who just want to change their opening hours. This page explains how Multisite actually works, the signs your network has outgrown it, and what moving the small sites to a white-label builder looks like.

TL;DR

How Multisite really works

The WordPress developer documentation describes a network plainly: "A multisite network is a collection of sites that all share the same WordPress installation core files." Each site gets its own database tables and its own uploads folder, but they are virtual sites inside one install, not separate installations.

Three consequences follow, all from the official documentation on creating a network:

  1. Plugins and themes are shared. In the docs' words, each site "can activate both, but install neither." Whoever runs the network decides the menu; site owners pick from it.
  2. You choose subdomains or subdirectories once. "You must choose one or the other", and changing later "might not be easy".
  3. Custom domains per site are a separate step, covered in its own domain-mapping documentation.

This is a good design for a newsroom with twenty section sites, a university web team with developers, or an agency that has standardised on one theme and owns every site. The problems start when the network grows in a direction the design did not expect.

Seven signs the network has outgrown it

Score your network honestly. Three or more usually means the maintenance has become the job.

SignWhy it hurts in Multisite
A plugin update broke sites you did not know used itShared plugins mean one update reaches every site that activated it
Site owners ask for a plugin "just for them"Adding it to the network adds it to everyone's menu and everyone's risk
Nobody on the team writes PHP any moreThe network was built by a developer who has since left
You need one site on a different host or setupSites cannot be split out without an export and rebuild
Owners want to change layouts, not just textTheme options are limited to what the shared theme allows
Restoring one site from backup is an ordealBackups are usually of the whole network database
You have sites nobody can name an owner forMultisite has no native idea of a site owner beyond user roles

None of these is a WordPress bug. They are the cost of sharing one install, and they grow with the number of sites and owners.

The other model: each owner gets a site, you set the rules

A white-label builder separates the two jobs Multisite fuses together. Your central team sets the brand and the rules. Each site owner, whether a department, a chapter, a franchisee or a paying client, gets their own site inside a portal under your name. Nobody shares a plugin list, because there are no plugins to install; features like a blog, store, forms and SEO settings are part of the builder and you switch them on or off per owner.

Client register listing demo site owners with tags, status and a search across names, emails, sites, notes and tags

*The register of site owners. In Multisite this list lives in someone's spreadsheet; here it is the list of accounts.*

One client opened, showing their sites, plan, site limit, permission switches, notes, tags, and pause or remove

*One owner's settings: how many sites they may have, which features are on, and whether publishing waits for approval.*

The builder itself is the other half. Owners describe the site they need and the AI builds it, then they edit visually. A department web editor who would never touch a WordPress theme file can change a layout safely.

Builder panels menu listing Code, Cloud, Blog, SEO, Store, Domain, Analytics, Speed and Security

*Features live in the builder's panels, not in plugins you have to vet and update across a network.*

What you give up by leaving Multisite

Be clear about this before a migration:

A migration plan that does not take the network down

Move the long tail first, the flagship last (or never).

PhaseActionExit test
0Export the list of network sites with last-modified date and active pluginsYou know which sites are idle and which depend on plugins
1Retire sites with no owner and no edits in a year, with sign-offFewer sites to move
2Set brand defaults and approval rules in We.IncA new owner starts locked down sensibly
3Pilot five small sites, rebuilt from their current contentEach owner has published a change unaided
4Move remaining small sites in batches; map domains as each is approvedOld network sites redirect to the new ones
5Leave plugin-dependent and flagship sites on WordPressThe network is smaller and easier to maintain

Redirect every old URL to its new home when a site moves; search engines treat a moved page with a proper redirect very differently from a page that disappears.

Domain panel in a client's editor inviting them to connect a domain they own

*Connecting a domain from inside the site's editor, when you allow that owner to do it.*

Accountability you do not have to build

Multisite tracks who edited a post. It does not, out of the box, give the central team a log of who changed which owner's permissions or approved which launch. We.Inc keeps an audit log of organisation actions: clients invited or removed, limits and switches changed, approvals, team changes. It is an account-level record, not a revision history of every paragraph.

Audit log listing two events from editing a client, with time, action and user columns

*The audit log after editing one client's settings in the demo brand.*

And because every site's code can be downloaded or synced to GitHub, leaving We.Inc later does not mean starting again, which is the question procurement should ask any platform. Our vendor exit plan lists the clauses.

The honest summary

If you have WordPress developers, a handful of sites and plugins you depend on, Multisite is a good tool and you should keep it. If you have many small sites, owners who are not technical and a central team that spends its week on updates, moving those sites to a builder with owner-level rules is usually less work. Our broader white-label builder vs enterprise CMS guide covers the same decision for Drupal and commercial platforms.

Book a demo with your network's site list and we will sort it into "move", "keep" and "retire" with you.

Sources

Last checked 2026-10-25.

Book a demo. Pricing is tailored to your volume and setup, and you get your exact price on the call. 0% transaction fee.

Frequently asked questions

Can site owners in WordPress Multisite install their own plugins?

No. According to the WordPress documentation, each site in a network can activate plugins and themes but cannot install them; installation happens at network level.

Do I have to move every Multisite site to We.Inc?

No. The usual pattern is to move the many small sites and keep plugin-dependent or flagship sites on WordPress.

Can We.Inc import a WordPress site automatically?

We do not claim an automatic importer. Small sites are rebuilt by the AI from a description and the existing content, which for most department or client sites is quicker than porting a theme.

Is there a shared-content hub like Multisite plugins offer?

No. There is no tool to publish one item to many sites at once. Keep syndicated content on the system that does it today.

Keep reading

More in White Label

We.Inc is an AI-powered website builder you can resell under your own brand. Launch a branded client dashboard, bill on Stripe Connect, and deliver AI-generated websites in minutes. White-label pricing is tailored to your volume and setup: book a 30-minute demo for a quote.

Product

Who It's For

Features

Resources

Company

View Sitemap