On this page
- Which “multi site manager” do you actually mean?
- Why the real decision is shared fate, not a single login
- What Network Admin manages, and what it doesn’t
- Where a Multisite network breaks, layer by layer
- What a dashboard for separate installs manages, and where it breaks
- What changes when an agent does the site work
- Frequently asked questions
Key takeaways
- Multisite puts every site in one database, one file tree and one user table. A bad plugin update or a compromised Super Admin account can reach every site on the network.
- MainWP’s own documentation says its Dashboard was not designed for Multisite networks and that MainWP does not officially support that setup. Dashboards are built for separate installs.
- Unrelated client sites usually belong on separate installs with a central dashboard. Multisite fits related sites under one owner, such as locations, brands or language versions.
- Multisite problems tend to sit in one of four layers: server routing (subsite 404s), plugin activation, mapped domains and cookies (redirect loops), and migrations run without a network-aware search-replace.
- WooCommerce on Multisite gives you separate stores. WooCommerce’s docs say each subsite has its own tables and runs as an independent store.
The second site is easy. By the fifth you are logging into five dashboards, updating the same plugin five times and keeping track of which client is on which PHP version. Then you search for a “WordPress multi site manager” and get two sets of answers that don’t match.
The answers don’t match because the phrase means two different products. One is WordPress Multisite, a feature built into WordPress core. The other is a management dashboard that connects separate WordPress installs to one control screen. They solve different problems, and you can’t swap one for the other. Our broader guide on how to manage multiple WordPress websites covers every setup. This article covers the choice between these two and what each one actually manages day to day.
Which “multi site manager” do you actually mean?
If your sites live in one WordPress installation, you mean Multisite. If each site has its own install, possibly on a different host, you mean a dashboard. The table shows the difference.
| WordPress Multisite | Dashboard over separate installs | |
|---|---|---|
| What it is | One WordPress installation running many subsites | A control site or service connected to each install by a plugin |
| Shared between sites | Core files, plugin and theme code, database, user table | Only the control screen |
| Where you work | Network Admin | The dashboard, plus each site’s own wp-admin |
| What one failure can reach | Potentially the whole network | Usually one site, unless the dashboard itself is compromised |
| Typical fit | Related sites under one owner | Unrelated client sites |
The two don’t stack well. MainWP’s compatibility notes say its Dashboard “was not designed for managing WordPress Multisite networks” and that MainWP does not officially support Multisite setups. Its testing on Multisite is periodic and limited. So if you are building a network and plan to put a dashboard on top of it, check that first.
Why the real decision is shared fate, not a single login
Multisite shares fate by design. Every subsite runs the same plugin code from the same file tree and reads from the same database. That is where the efficiency comes from: one core update, one plugin update and one set of users. It also means one bad update, one compromised Super Admin account or one resource spike can turn into a network-wide event.
Practitioners are careful about the detail here. A broken page on one subsite doesn’t automatically break the others. The risk comes from what the sites depend on together: the shared code, the shared accounts and the shared server. One r/webdev thread made the agency version of the point plainly. A single problem plugin or database change on a network of client sites could hit all the clients at once.
Community advice comes out in the same place almost every time:
- Multisite fits related sites. Think of one business with several locations, one organisation with several brands, or one site in several languages. These sites share an owner, governance, a theme and most of a plugin set.
- Separate installs plus a dashboard fit unrelated clients. Each client gets its own plugins, its own users, its own backups and its own way back if something breaks. You still get central updates and reporting.
- Leaving a network is real work. You can export a subsite that has grown apart from the rest into its own install, but it takes planning. Decide how a site would leave before you add it.
WordPress’s own handbook opens its Multisite preparation page by asking “Do you really need a network?” before it lists any requirements. If the answer is yes, our walkthrough of WordPress Multisite installation covers the setup.
What Network Admin manages, and what it doesn’t
Network Admin is the Multisite manager. A Super Admin works there on sites, network plugins, themes and users. A few of its rules catch people out:
- Plugins are installed for the whole network, then activated per site or for every site. “Network Activate” switches a plugin on everywhere. If you network-activate a plugin for one location’s booking widget, all the other locations get it too.
- Deleting a plugin or theme removes it from the whole network. MainWP’s notes flag this for anyone connecting subsites to a dashboard. A delete that looks like it affects one site affects them all.
- Users are shared, roles are not. An account exists once for the network, and you give it a role on each site separately. Having a network account doesn’t make someone an editor anywhere.
- Site admins can’t manage plugins on their own. If a plugin is available on the network, that doesn’t mean every site admin controls it.
Network Admin also has hard limits, because some of the work happens outside WordPress. WordPress’s handbook says subdomain networks need wildcard DNS and server routing that sends every subdomain to the same install, and that Multisite needs working rewrite rules. No WordPress setting creates a DNS record, a virtual host or a certificate. A very common mistake is to change settings and expect the server to follow.
WooCommerce has its own limit. WooCommerce’s installation docs say each subsite on a network has separate tables and runs as an independent store. Activating WooCommerce for the whole network doesn’t share products, checkout sessions or customer accounts between stores. Some extensions also don’t support network activation, and some paid licences count each subsite as a separate site.
Where a Multisite network breaks, layer by layer
Multisite failures usually fall into one of four layers. The order below is how often each comes up in the support threads and host docs we reviewed. It isn’t a measured frequency. Find the layer that matches your symptom before you try any general “multisite fix”.
| Symptom | Layer | Where to look first |
|---|---|---|
| Main site works, subsites return 404 | DNS and server routing | Wildcard DNS, document root, rewrite rules, Apache AllowOverride |
| “The plugin could not be activated because it triggered a fatal error”, blank screen, missing tables | Plugin activation | PHP error log, the plugin’s Multisite notes, activating per site |
Login loop, “Cookies are blocked or not supported”, ERR_TOO_MANY_REDIRECTS | Mapped domains, HTTPS, cookies | Site Address, home and siteurl, SSL for each domain, host redirect settings |
| “Error establishing a database connection” after a move | Migration | wp_blogs against DOMAIN_CURRENT_SITE, and how the search-replace was run |
Subsite 404s mean routing, not WordPress
WordPress’s network debugging guide says a working main site with child sites that return 404s points to routing or rewrite problems. Check that subdomains reach the same document root, that .htaccess holds the rules Network Setup generated, and that the server reads them. If your host won’t let you turn rewrites on, the handbook’s answer is to contact the host.
Plugin activation fails network-wide but works per site
WordPress.org support threads show plugins that crash on network activation but run fine when activated site by site. They also show plugins that never create their per-site tables. Read the error log before you retry, and check for an updated version. In one 2026 thread, a guestbook plugin’s network activation fatal error was fixed in the next point release.
Mapped domains loop when URLs disagree
A mapped domain has to agree in three places: the Site Address in Network Admin → Sites → Edit, the site’s home and siteurl options, and the server’s redirects and certificate. Host settings can work against you here. Kinsta’s docs warn that its “force all traffic to primary domain” option stops subsites from being reached on a mapped-domain network, and recommend forcing HTTPS on all live domains instead.
Migrations need a network-aware search-replace
WordPress stores full URLs in the database, some of them inside serialized data that breaks under a plain text find-and-replace. WP-CLI’s search-replace handles serialized data, but on a network it only touches every site when you tell it to:
wp search-replace 'https://old.example.com' 'https://new.example.com' --network --dry-runRun it once with --dry-run to see what would change, then run it without the flag. Pantheon’s Multisite docs note that WP-CLI can return “Error: Site not found” when the command runs without the right site context. For a full domain move, our guide to changing a WordPress domain safely covers the order of steps.
What a dashboard for separate installs manages, and where it breaks
A dashboard is a separate control layer. MainWP’s setup is typical: you install the Dashboard on a dedicated, clean WordPress site and a Child plugin on each site you manage. Other services use a hosted console and a connector plugin. In both cases you get bulk updates, backups, uptime checks and client reports, while every site stays its own install.
The trouble people report comes from that extra layer:
- “Up to date” isn’t always true. Users on r/Wordpress report several tools sometimes missing available updates. Check against a site’s own Dashboard → Updates screen now and then.
- Connections fail for reasons your browser can’t see. MainWP points out that the Dashboard reaches each site over a different path from your browser. A site can load fine for you and still not connect. Use HTTPS, confirm the Child plugin is active, and run Test Connection.
- Self-hosted dashboards depend on cron. If the dashboard’s scheduled jobs don’t run reliably, updates and checks quietly stop.
- Bulk actions slow down at scale. Practitioners describe bulk theme updates getting slow at around 100 sites.
- The console is the most valuable target you own. One Reddit user described a compromised management console that spread to the connected sites. Give the dashboard its strongest password, two-factor login and the fewest admins.
The habits matter more than the tool you pick. Update one canary site first, then the rest. Take backups, and make sure you have actually restored from a backup at least once. Give juniors and freelancers the narrowest access that lets them do the job. After an update, load each site’s checkout, contact form or booking page, because a green tick in a dashboard doesn’t show what visitors see. If you sell this as a retainer, write down what it covers. Our explainer on what a care plan should include sets out the usual scope.
What changes when an agent does the site work
Dashboards are good at the same action across many sites: update this plugin everywhere, back up everything tonight. They don’t do the other half of a portfolio, which is the steady stream of small requests that are different on every site. One client needs new opening hours, another wants a redirect fixed, a third has a contact form that stopped sending. Each one is a few minutes of work wrapped in a login, a hunt for the right screen and a check afterwards.
SiteSelf takes that second kind of work. You tell the agent what needs doing in chat or from Telegram. It makes the change on the live site, fetches the changed page to check the result, and reports what changed and what it checked. It joins the stack you already run. Your dashboard, backups and uptime monitoring stay where they are. Our page for agencies handling client site requests shows how this fits a portfolio.
Example request: “On the Harbor Dental site, Saturday hours are now 9 to 1. Update the Contact page and the footer, and tell me if any other page still says closed on Saturdays.”
- What the agent does: Before it changes anything, it says what it is about to change and whether the change can be undone. Then it edits the Contact page, updates the footer, and searches the site’s content for other mentions of Saturday.
- What it checks: It fetches the Contact page and a page that shows the footer, then reports what it found, including any other pages that still mention the old hours. What it did is recorded.
- What access it needs: The SiteSelf Connector plugin from the WordPress.org directory covers content and settings. If the footer text is hard-coded in theme files, the agent needs hosting (SSH) access for that part.
- What it can’t do: If the Contact page is owned by Elementor, Divi or Beaver Builder, the edit is refused when the agent gets to it, and it tells you why. It doesn’t update the clinic’s listings on outside platforms. Third-party systems are read at most. It doesn’t monitor the site afterwards either. Work happens on request.
The point is the cost of coordination. Changing one line of opening hours shouldn’t need a ticket, a login hunt and a reminder to check the page afterwards. If you want to know what this costs across a portfolio, see SiteSelf pricing.