Network upkeep, without taking every site down
Maintaining a WordPress Multisite Network Safely
Perform a WordPress multisite update without taking every site on the network down at once. One core update reaches all of them simultaneously, which is what makes the staging step non-optional here. The checklist below covers network release order, per-site plugin conflicts, and backing up a shared database where one table set holds every site on the network.
WordPress multisite maintenance differs from single-site maintenance in one way that matters: core, plugin and theme updates are network-wide and land on every site at once. Stage the release against a clone of the whole network, test the heaviest subsite first, and keep per-site table exports alongside the full database dump.
Tick what you already do
- The failure modes on multisite are shared, and a single-subsite copy exercises none of them
- The network-active list is what decides release order; without it the update goes out blind
- Restoring one subsite from a full dump rolls every other site back to the same moment
- Mapped domains fail one at a time and get reported by visitors, days late
- A rollback that cannot restore the configuration is not a rollback
- A clean run on the quietest subsite proves nothing about memory limits, slow queries or layout
- Super admin is the highest privilege on the install and reaches every site at once
- One content-heavy subsite exhausts the limit while the rest stay fine
- A persistent cache keeps serving the old schema and the network half works
- A rollback nobody wrote down is a rollback nobody performs at three in the morning
Tick the tasks you already run. Where you stand, what the gaps cost and which ones matter appear here.
How often each task is actually due
| Task | Interval | Why that interval |
|---|---|---|
| Network core update | Within 72 hours of a security release | One release reaches every subsite, so a delay multiplies the exposure by the site count |
| Network-active plugin updates | Weekly, staged | A single bad plugin takes down every site on the network simultaneously |
| Per-site plugin updates | Monthly | Failures stay contained to one subsite |
| Full network backup | Daily | Shared tables make a partial restore impractical without one |
| Per-site table export | Weekly | The only realistic way to restore one subsite without touching the rest |
| Domain mapping and certificate check | Monthly | Certificates expire per domain, not per network |
| Super admin audit | Quarterly | Super admin is the highest privilege the install has |
| Dormant subsite review | Quarterly | An unused subsite still runs live plugin code |
One install, every site, one update
A multisite network is a single WordPress install serving many sites from one file system and one database. That is the whole of its appeal and the whole of its risk. Ten sites patch in the time one takes. Ten sites also break in the time one takes.
On a single site, a bad update is an incident. On a network of forty, the same bad update is forty incidents that arrive together, and the phone calls arrive together too. The staging step is not a best practice here; it is the only thing standing between a routine release and a network-wide outage.
The shared database is the hard part
Every subsite gets its own numbered table set — wp_2_posts, wp_3_posts — while users, site metadata and network options live in shared tables. A backup that captures the whole database restores every subsite to the same moment, which is exactly wrong when one subsite needs rolling back and thirty-nine do not.
The answer is two backups running at different granularities: a full nightly dump for disaster recovery, and a weekly per-site export for the far more common case of one site needing to go back a few days. The second one is the one that gets skipped, and it is the one that gets used.
Test the heaviest site, not the easiest
The instinct is to check the update on a small subsite, see a working page, and promote. That test passes on almost anything. The subsite that finds problems is the one with the most posts, the most plugins and the most custom code — it is the one that hits the memory limit, the query timeout and the slow migration.
Run the release against that site, with the object cache warm and cold, before the network sees it.
Where a network quietly rots
Two things decay on multisite without anyone noticing. Domain mapping breaks after core updates and certificate renewals, and because each mapped domain is checked by its own visitors rather than by you, the report arrives days late. Dormant subsites are the other: a site nobody has opened in two years still executes every plugin it has activated, and an abandoned plugin on a forgotten subsite is an entry route into the whole network.
A quarterly inventory closes both. List every subsite, its last edit, its mapped domain and its active plugins, and archive what nobody uses. The network is only as secure as its least-visited site.
A network multiplies every measurement problem across every site on it, so the two things worth centralising first are uptime monitoring and field performance data. Both are on the WordPress maintenance guides.
The procedure, step by step
- Clone the whole network, not one siteA single-subsite copy tests nothing that matters here. The failure modes are shared: a database schema change, a network-activated plugin, a drop-in. Clone the full multisite install, including wp-content/uploads/sites and the complete table set.
- Inventory what is network-activeRun wp plugin list --network on the clone. A network-active plugin is the one that takes everything down together, and it is the list that decides your release order. Per-site plugins are a separate, lower-risk batch.
- Take per-site exports as well as the dumpA full dump restores the whole network to one point in time. When one subsite breaks a week later, that dump costs every other site a week of data. wp db export --tables with the subsite prefix gives you the granular restore.
- Update on staging in release orderCore first, then network-active plugins one at a time, then themes, then per-site plugins. One at a time is slower and it is the only order that tells you which change broke something.
- Test the heaviest subsite firstThe subsite with the most content, the most plugins and the most traffic surfaces the memory limit, the query timeout and the layout regression. A clean run on the quietest subsite proves nothing.
- Promote, then flush the object cachewp core update-db --network runs the schema migration across every site. A persistent object cache holds the old schema until it is flushed, and the symptom is a network that half works.
- Verify every mapped domainDomain mapping breaks quietly. Check each mapped domain resolves, serves its own certificate, and canonicalises to itself rather than to the network's primary domain.
- Record the rollback pointNote the database snapshot, the file snapshot and the time. A rollback nobody wrote down is a rollback nobody performs at three in the morning.
Tools worth using, and what each misses
| Tool | What it does well | What it misses |
|---|---|---|
| WP-CLI | Network-wide operations from one command: wp site list, wp plugin update --network, wp core update-db --network | No visual regression check — it reports success on a page that renders broken |
| A staging clone on the same host | Reproduces the PHP version, memory limit and database engine that actually matter | Cloning a large multisite is slow, so it gets skipped under pressure |
| Query Monitor | Names the slow query and the plugin that fired it, per subsite | Admin-only, and it changes the performance profile while it runs |
| Object cache drop-ins (Redis, Memcached) | Removes most of multisite's query overhead | Holds stale schema and options through an update until flushed |
| Multisite-aware backup plugins | Understands the shared table set | Most restore the whole network, not one subsite |
When it needs handing over
wordpress update serviceHand over WordPress updates and stop choosing between an unpatched site and a broken one. Core, plugins and themes are applied to a staging copy every…
More guides
Questions people ask before calling
Can I update one subsite without touching the others?
Plugins and themes activated per site, yes. Core, no — there is one WordPress install behind the whole network and a core update applies to all of it at once. That is the defining constraint of multisite maintenance.
How do I restore a single subsite?
From a per-site table export plus that site's uploads directory. Restoring from a full network dump rolls back every other site to the same moment, which is why the per-site export is on the weekly list rather than the optional one.
Why does one subsite run out of memory when the others are fine?
Memory is consumed per request, and the request is served by whichever subsite is loaded. A content-heavy subsite with thirty plugins hits the limit that a brochure subsite never approaches on the same install.
Is multisite worth it for five client sites?
Rarely. Multisite pays off when the sites are genuinely a network — shared users, shared theme, central control. Five unrelated client sites get all the coupling and none of the benefit, and one bad update takes down five clients instead of one.
What breaks most often after a network update?
Domain mapping and permalinks, in that order. Both fail silently on subsites nobody checks, which is the argument for a mapped-domain sweep after every release rather than a spot check.