Most WordPress multisite setups start with a clean idea: one install, many sites, shared resources. Then reality hits. A plugin update breaks three subsites. A theme change cascades into a design mess. User roles blur across the network. What was supposed to save time now eats entire weekends. The problem isn’t multisite itself—it’s the structure you choose before the first subsite goes live.
I’m Jonas Venn, and I build WordPress systems that stay manageable years after launch. This article lays out the structural decisions that separate a maintainable multisite network from a tangled web of dependencies. No theory for theory’s sake. Just the patterns I use when a client needs 5, 50, or 500 sites under one roof.
Pick the Right Multisite Type Before You Touch Code
WordPress gives you two multisite flavors: subdirectory and subdomain. The choice locks in your URL structure, SEO footprint, and server configuration. Switching later means migration pain. So decide based on how the sites relate to each other.
Subdirectory networks (example.com/site1, example.com/site2) work when all sites share a single brand identity. A university with department sites, a franchise with location pages, a product company with regional microsites. The parent domain carries the authority, and each subsite inherits that trust. Maintenance is simpler because you manage one SSL certificate and one DNS zone. But the tight coupling means a server outage takes down everything at once.
Subdomain networks (site1.example.com, site2.example.com) fit when sites need their own identity. A network of client portals, separate product brands, or independent project sites. Each subdomain can have its own SSL via a wildcard certificate, and you can even map custom domains later. The trade-off: DNS management gets heavier, and cross-site cookie handling requires extra configuration if you want unified logins.
I default to subdirectory for tightly integrated networks and subdomain when sites must feel standalone. If you’re unsure, map out the user journey. Will visitors bounce between sites expecting one continuous experience? Subdirectory. Will they treat each site as a separate destination? Subdomain.
Design a Plugin and Theme Strategy That Scales
The biggest maintenance trap in multisite is treating every subsite as a unique snowflake. When each site activates its own random collection of plugins and a custom child theme, you’ve created 50 separate maintenance streams. Updates, compatibility checks, and security patches multiply. The fix is a tiered approach.
Network-Activated Core Stack
Define a set of plugins that every site must run. Security, caching, SEO framework, backup agent, and a spam filter. Network-activate these. They become part of the infrastructure—updated once, applied everywhere. I keep this list under 10 plugins. Anything beyond that usually belongs in the optional tier.
For themes, network-enable a base parent theme that all subsites inherit. This parent handles global typography, breakpoints, and core template parts. Subsites use child themes that override only what’s necessary—colors, logos, homepage layouts. When you update the parent theme’s accessibility markup or performance tweaks, every subsite benefits without manual intervention.
Site-Specific Plugins with Strict Limits
Allow subsite admins to activate plugins from a pre-approved list. Curate this list aggressively. Every plugin you allow adds a surface area for conflicts and support tickets. I block plugins that duplicate network-level functionality—no second caching layer, no alternative SEO plugin. I also block plugins with a history of frequent breaking updates unless the subsite owner accepts the risk explicitly.
Use the allowed_plugins filter in your network’s mu-plugin file to enforce this. It’s a single PHP snippet that prevents admins from seeing or activating anything outside your list. Combine it with a dashboard widget that shows which plugins are site-active versus network-active, so you can spot drift during audits.
Theme Lockdown Without Killing Flexibility
Subsite admins should not install arbitrary themes. A rogue theme can inject outdated jQuery, break the editor, or conflict with network-wide styles. Instead, offer a gallery of 3–5 approved child themes, each pre-tested against your parent theme and core stack. If a subsite needs a custom design, build it as a new child theme within the network’s theme directory—never let them upload a zip file.
This sounds restrictive, but it’s the difference between a network you can update in 20 minutes and one that requires a week of regression testing. The design-aware move is to make those approved child themes genuinely good. Invest in their typography, spacing, and editor styles. When subsite owners see polished options, they don’t miss the free-for-all.
User Roles and Permissions: The Silent Chaos Generator
Multisite adds a layer of user management that single-site WordPress doesn’t prepare you for. A user registered on Site A can be granted a role on Site B without realizing it. A Super Admin can accidentally edit content on a subsite and break the editorial workflow. Default roles are too coarse. You need a permission model that matches your network’s real-world structure.
Start by mapping three tiers of users:
- Network Operators – Super Admins who manage infrastructure, updates, and network settings. They should rarely touch subsite content.
- Site Managers – Administrators on their own subsites, with no access to network settings or other sites. They control plugins from the approved list, manage their own users, and configure site-level options.
- Content Editors – Authors, editors, and contributors scoped strictly to their assigned subsites. They never see the network admin area.
To enforce this, remove the manage_network capability from everyone except designated Super Admins. Use the pre_site_option filters to hide network-level menu items from Site Managers. For networks where users need access to multiple subsites, add them manually to each site rather than granting a global role. This keeps audit trails clean and prevents accidental cross-site edits.
One pattern I use often: a custom mu-plugin that logs every role change with timestamp, user ID, and the admin who made the change. When something breaks, you can trace exactly who gained elevated access and when. It’s not paranoia—it’s operational hygiene.
Database and Media: Stop the Bloat Before It Starts
Multisite creates separate database tables for each subsite, prefixed with the site ID. That’s fine for isolation, but shared tables like wp_users and wp_usermeta grow across the network. A network with 10,000 users and 50 sites can develop slow user queries if you don’t index properly. Add a custom index on the user_login and user_email columns if you expect high user counts. It’s a one-time SQL command that pays off every login.
Media is the silent storage killer. Each subsite uploads images to its own directory under wp-content/uploads/sites/{ID}/. Without limits, a single subsite can fill your server disk. Set a per-site upload quota using a filter on upload_space_check_disabled and a custom function that sums the site’s upload directory size. Display the quota usage in the subsite dashboard so admins self-police.
Also, disable the generation of intermediate image sizes you don’t actually use. The default WordPress install creates thumbnail, medium, and large crops plus a 1536×1536 and 2048×2048 version. That’s six files per upload. If your approved themes only use three sizes, strip the rest via the intermediate_image_sizes_advanced filter. Over a network of 50 sites with 500 images each, you just prevented 75,000 unnecessary files.
Updates, Backups, and the Single Point of Failure Problem
Multisite updates are all-or-nothing. When you hit “Update Network” on the plugins page, every subsite gets the new version simultaneously. That’s powerful but dangerous. A plugin update that introduces a fatal error takes down the entire network. You need a staging environment that mirrors the multisite structure—not just a single-site clone.
Build a staging network with at least three representative subsites: one using the most common child theme, one with the heaviest plugin load, and one with custom post types or e-commerce. Run updates there first. Automate a basic smoke test that visits the homepage, a post, and the admin dashboard of each staging subsite after every update batch. If any returns a 500 error or loads without the expected markup, halt the production push.
Backups need special handling. A standard single-site backup plugin will miss network-level tables like wp_site and wp_blogs. Use a backup solution that explicitly supports multisite and captures the entire database plus all subsite upload directories. Store backups off-server. Test restoration quarterly by spinning up a clone network from the backup files—not just checking that the zip file exists. A backup you haven’t restored is a wish, not a plan.
If you’re dealing with a network that already has broken permalinks or missing content on new subsites, the root cause often traces back to rewrite rules or site options not flushing correctly. I covered the single-site version of this problem in detail at What to Fix First When a New WordPress Site Says Nothing Found. The same rewrite flushing logic applies to new subsites—just scoped to the site’s own rewrite_rules option.
Domain Mapping and Custom Domains Without the Headache
Many multisite networks eventually need custom domains. A subsite starts as client.example.com but later wants client.com. WordPress multisite handles this natively with domain mapping, but the setup trips people up. You need to configure the server to accept requests for the custom domain and point them to the WordPress install directory. Then you map the domain in the network admin under Sites > Edit > Site Address (URL).
The cleaner approach is to use a sunrise.php drop-in. Place a sunrise.php file in your wp-content directory and define SUNRISE as true in your wp-config.php. This lets WordPress resolve domain mappings before the main blog query runs, avoiding redirect loops. If you’re on a managed host that doesn’t support sunrise.php natively, you can achieve the same with server-level aliases, but you’ll lose the ability to manage mappings through the WordPress UI.
For networks with many custom domains, maintain a DNS checklist: wildcard SSL for subdomains, individual certificates for mapped domains, CNAME or A records pointing to the multisite server, and a cron job that verifies DNS resolution weekly. A domain that silently stops resolving creates a subsite that looks like it’s down, even though the network is healthy.
Performance Patterns That Keep the Network Fast
Multisite performance tuning is different from single-site optimization. Object caching becomes critical because the network loads options, users, and site metadata across multiple sites on every request. Use a persistent object cache—Redis or Memcached—with a multisite-aware drop-in like WP Redis. Configure it to prefix cache keys with the site ID so subsite data doesn’t collide.
Page caching needs careful rules. A full-page cache that serves the same HTML to all subsites will break everything. Use a caching layer that varies by domain or site ID. If you’re on Nginx, set up fastcgi_cache_key to include the $host variable. On Apache, configure your caching plugin to create separate cache directories per site.
CDN integration should happen at the network level. Enqueue a mu-plugin that rewrites asset URLs (CSS, JS, images) to your CDN domain for all subsites. This avoids configuring the CDN separately for each site and ensures consistent resource loading. Just make sure your CDN respects the Access-Control-Allow-Origin headers if you’re serving fonts or other cross-origin assets.
Monitoring and Alerting: Catch Problems Before Users Do
A multisite network can fail in subtle ways. One subsite’s PHP error might not trigger your main monitoring if the check only hits the root domain. Set up external monitoring for at least the following endpoints:
- The network home page (example.com)
- One subdirectory site (example.com/site1)
- One subdomain site (site1.example.com)
- The wp-admin login for each of the above
- A sample REST API endpoint from a subsite
Each monitor should check for HTTP 200 status and the presence of a known string in the response body. If the string is missing, the site might be serving a white screen or a cached error page. Alert on any deviation. I use a combination of server-level health checks and a WordPress-specific mu-plugin that exposes a /wp-json/network-health/v1/status endpoint returning site counts, active plugin versions, and recent error log entries.
Log errors centrally. Multisite can scatter debug logs across subsite directories if you let it. Force all error logging to a single file by defining WP_DEBUG_LOG to a custom path in wp-config.php. Then tail that file with a log aggregator. When a support ticket says “Site 12 is broken,” you can grep the log for the site ID and see the exact PHP fatal in seconds.
FAQ: Multisite Structure Questions I Get from Builders
Can I convert an existing single-site network into a multisite without breaking everything?
Yes, but the conversion process is surgical, not automatic. You’ll need to export each site’s content, create the multisite network, then import content into new subsites. Menus, widgets, and theme settings rarely survive intact. If the sites share users, you’ll need to merge user tables carefully, avoiding ID collisions. I only recommend conversion when the long-term maintenance savings clearly outweigh the migration effort—usually for networks of 10+ sites that currently run on separate installs.
How many subsites can a single multisite network realistically handle?
The technical limit is high—WordPress can handle thousands of subsites if your server has enough memory and CPU. The practical limit depends on your admin workflows. Beyond 100 subsites, the network admin screens become slow to load, and bulk actions require custom scripting. I’ve run networks with 300+ subsites by offloading site listing to WP-CLI commands and building a custom dashboard for site search and filtering. If you’re approaching that scale, plan for custom admin tooling from the start.
Should I use a multisite for client projects that I’ll eventually hand off?
Only if the client understands and accepts the shared infrastructure. Handing off a multisite network means the new owner inherits responsibility for all subsites, even if they only care about one. I structure client multisites with an exit plan: each subsite uses a child theme and only approved plugins, and I document the export process to a standalone install. If the client wants independence later, they can migrate their subsite out without rebuilding from scratch.
What’s the one thing that causes the most multisite maintenance nightmares?
Uncontrolled plugin and theme proliferation. When subsite admins can install anything, the network becomes a collection of incompatible stacks. Updates break random sites, and debugging means checking 50 different configurations. Lock down the plugin and theme lists, enforce a parent-child theme architecture, and you eliminate 80% of the ongoing maintenance burden.
Structure your multisite network with these patterns, and it will stay boring—in the best way. Boring means predictable updates, clear ownership, and nights where you’re not waking up to a phone full of downtime alerts.