Manage a WordPress Multisite network from one dashboard

WordPress Multisite is the underrated power feature of the platform. One install, one filesystem, one wp-admin you can master once — and then dozens of independent sub-blogs that share themes, plugins, users, and your operational discipline. The catch: every "manage many WordPress sites" tool on the market treats your network the same way it treats two unrelated standalone sites. You end up with a blog-by-blog matrix in your dashboard, even though under the hood it's one filesystem and one update operation.

That's the gap we just closed. As of today, Manage GPL pairs a whole multisite network with one token, surfaces every sub-blog under a single row in your dashboard, and lets you target installs and SSO at either the network as a whole or any specific blog. The whole network counts as one site against your plan limit — even on the Free plan, even if you have 50 blogs in the network. No upsell, no special tier, no surcharge per sub-blog.

Why multisite is hard for most management tools

WordPress Multisite has two characteristics that fight a naive "treat each blog as a site" model:

• One shared filesystem. Plugins and themes live in wp-content/plugins and wp-content/themes for the entire network. There's no such thing as installing a plugin "on blog 3" — you install it on the install, then activate it where you want.
• Per-blog activation state. The actual active set lives per blog (wp_options.active_plugins) plus a network-wide set (wp_sitemeta.active_sitewide_plugins). The same plugin file can be active on three blogs and inactive on two more.

If you treat each sub-blog as an independent "site" in your management dashboard, both of those break in unhelpful ways. You'd see the same plugin listed N times — once per sub-blog — even though there's only one copy on disk. Updating it from each row would be a no-op after the first one (the file is already on the new version) but you'd waste API calls trying. And pairing each blog separately would mean N copies of your authentication token sitting on the same install, with no one source of truth for "what's connected to my dashboard."

The right model is one row per network, with the sub-blogs surfaced as picker options where they actually matter — installs (because you need to choose where to activate) and SSO (because you need to land in a specific blog's admin).

How the new multisite support works

The connector plugin you already use on standalone sites — Manage GPL Connect — is now multisite-aware in version 1.23.0. When it boots on a multisite install, it reports back a small overlay alongside the usual inventory:

{
  "multisite": true,
  "is_network_activated": true,
  "network_home_url": "https://network.example.com",
  "current_blog_id": 1,
  "blogs": [
    { "blog_id": 1, "url": "https://network.example.com",       "name": "Main" },
    { "blog_id": 2, "url": "https://blog-a.network.example.com", "name": "Blog A" },
    { "blog_id": 3, "url": "https://blog-b.network.example.com", "name": "Blog B" }
  ],
  "network_active_plugins": ["managegpl-connect/managegpl-connect.php", ...]
}

Manage GPL takes that payload and materialises one parent row for the network, plus one child row per sub-blog (skipping blog 1, which IS the parent at the URL level). Children inherit the parent's HMAC credentials — they don't re-pair, they don't have their own token. The parent is the credential-holder; everything signs as the parent.

What you do (the short version)

1. Install Manage GPL Connect on the network via Network Admin → Plugins → Add New → Upload plugin.
2. Click Network Activate (not the per-blog Activate link).
3. Open Network Admin → Settings → Manage GPL Connect and copy the token.
4. In Manage GPL, paste the URL + token. Done.

If you accidentally per-blog-activate the connector instead of network-activating, the pair attempt is rejected with a clear error: "This is a WordPress Multisite network, but Manage GPL Connect is activated per-blog instead of network-wide. Go to the network admin → Plugins, click \"Network Activate\" on Manage GPL Connect, then try adding this site again." We deliberately gate this at pair time rather than letting you silently end up with a half-broken state.

Installs with a target-blog picker

Open the Add plugin modal on a network's page and a new selector appears next to the Activate after install checkbox. Three choices:

• Main blog only — plugin installed on the filesystem (visible to all blogs) and activated on blog 1. Other blogs see it in their Plugins → Installed list and can activate themselves.
• All blogs (network activate) — the plugin is activated network-wide via wp_sitemeta. Every sub-blog runs it automatically.
• On Blog A / Blog B / … — activated on that single sub-blog only. Useful for blog-specific functionality (a per-blog contact form, a per-blog booking widget).

The connector handles the switch_to_blog() dance behind the scenes — you don't see it. From your dashboard you just pick a target and the activation lands where you said.

SSO into any sub-blog

The WP Admin button on a network's page is now a dropdown. The default click drops you on the network admin (where you'd normally land); the dropdown lists every sub-blog with its name and URL — pick one and you SSO straight into that blog's admin. Same one-click experience as a standalone site, just multiplied by however many blogs you have.

Updates: filesystem-wide, as it should be

WordPress Multisite shares one plugins/themes folder across every sub-blog, so an update lands on the filesystem once and every blog sees the new code immediately. Manage GPL respects that: clicking Update on the network row runs the upgrade once, the new version is pushed once, and you don't get billed for "10 updates" because there's no such thing as updating one blog. Activation state is preserved across upgrades — a network-active plugin stays network-active, a per-blog active plugin stays active on that blog.

What counts against your plan

One network = one slot. A 50-blog network on the Free plan is one of your five free sites. We don't count sub-blogs separately, we don't gate multisite behind a paid tier, and we don't have a "multisite surcharge." This is the right model: the work we do per-network is mostly the same regardless of sub-blog count, the API surface is the same, and charging per-blog would punish exactly the users who get the most architectural value out of multisite.

What we left out (and might add)

• Per-blog uptime monitoring. Uptime is per-host, and a multisite network is one host — one ping covers everyone. We're not splitting monitoring per-blog because the underlying signal isn't different.
• Split per-blog history. Activity log entries record the blog ID where the action happened, but the history page itself shows the network-wide combined view today. We'll surface a per-blog filter in the next polish pass.
• Per-blog whitelabel. Whitelabel is per-network because the connector plugin file is per-network. If you need different agency branding for two specific clients on the same multisite, that's a configuration that doesn't really exist at the WordPress level either.

Try it

If you already run a multisite network, add it to your dashboard. The pair flow is identical to a standalone site — paste URL + token, hit submit. The network and its sub-blogs appear in seconds.

If you don't have an account yet, sign up free — five sites (or five networks, with as many sub-blogs as you want), no card required.

Full guide with edge-cases and troubleshooting: Manage a WordPress Multisite network.