WordPress multisite lets you run dozens—or hundreds—of sites from a single installation. One database, one set of core files, one admin login that controls everything. It’s how WordPress.com hosts millions of blogs, and it’s available in every self-hosted WordPress install.
But the network admin dashboard isn’t just a beefed-up version of the regular WordPress admin. It works differently, exposes different controls, and introduces failure modes you won’t encounter on a single site. If you’re running multiple content sites, client projects, or testing environments, understanding what network admin actually does will save you hours of troubleshooting.
What network admin controls (and what it doesn’t)
When you enable multisite, WordPress splits its admin interface into two layers. Each site still has its own dashboard where editors manage posts, pages, and basic settings. The network admin sits above that, accessible only to super admins, and controls infrastructure shared across all sites.
From the network admin dashboard, you can:
- Add, delete, archive, or mark sites as spam
- Install plugins and themes once, then enable them selectively per site
- Create new users with network-wide access or restrict them to specific sites
- Configure domain mapping, so different sites answer to different domains
- Set upload limits, storage quotas, and permitted file types globally
You cannot directly edit another site’s content from network admin. To publish a post on Site B, you still need to switch to Site B’s dashboard. Network admin is about infrastructure and permissions, not day-to-day content operations.
Plugin and theme activation works in two steps
On a single WordPress site, you install a plugin and activate it. Done. On multisite, installation and activation are separate, and both require network admin access.
First, you network-install the plugin—uploading it or pulling it from the repository. At this stage, it’s dormant. No site can use it yet. Then you either network-activate it (turning it on for every site instantly) or enable it per-site, letting individual site admins activate it themselves.
This two-step design prevents rogue site admins from installing code network-wide. It also means you can test a plugin on one site before rolling it out. But it introduces a common mistake: activating a plugin on one site, seeing it work, then wondering why it’s missing on Site #7. You have to check both the network plugins page and each site’s plugins page to know what’s actually running.
Themes work the same way. Network-enable a theme, and it appears in every site’s theme picker. If you don’t enable it, site admins won’t see it at all—even though the files are physically installed.
When multisite makes sense (and when it’s overkill)
Multisite shines when you’re running multiple sites that share the same plugin stack, user base, or design system. Examples:
- A media company publishing five topical sites under different domains
- An agency managing client sites from one hosting account
- A solo operator running separate content brands that share backend infrastructure
- A staging/production split where both environments live in one installation
Multisite is not a good fit if your sites need fundamentally different plugins, have separate user bases with no shared logins, or require independent backups and update schedules. In those cases, separate WordPress installs—each with its own database and admin—are simpler to manage and easier to migrate or sell later.
Multisite also complicates hosting. Not every managed WordPress host supports it. Those that do often charge more, because resource limits (disk, CPU, database queries) now apply to the entire network rather than one site. If Site #3 gets traffic-spiked and maxes out your database connection pool, every site in the network slows down.
The non-obvious tip: use subdirectory mode unless you control DNS
When you set up multisite, WordPress asks whether new sites should use subdomains (site2.example.com) or subdirectories (example.com/site2). Both work, but subdirectories are far easier to manage unless you already have wildcard DNS and SSL configured.
Subdomain mode requires a wildcard DNS A record pointing *.example.com to your server, plus a wildcard SSL certificate (or a host that auto-provisions Let’s Encrypt certs per subdomain). If you don’t control DNS—say, you’re on a shared host or using a domain registrar with limited DNS editors—subdomain mode breaks. New sites won’t resolve, and you’ll chase certificate errors for hours.
Subdirectory mode just works. No DNS changes, no SSL gymnastics. The tradeoff: URLs look less independent. But if you’re running a network for operational efficiency rather than separate brand identity, subdirectories save you a week of troubleshooting.
WordPress multisite isn’t a feature most operators need. But if you’re managing more than three sites with overlapping workflows, it’s worth the learning curve—just expect to spend a day reading documentation before your first network goes live.
Got a question about WordPress infrastructure or any other online-business tool? Reply to this email—I answer every one, and reader questions often become future articles.