Almost everything written about WordPress staging assumes you have one site. At one site, staging is simple: copy live to staging, make changes, push back, done. The push-to-live button works because there is only one thing to reconcile and you were the only person touching it.
At a hundred sites, none of that holds. This is what breaks, and what to do instead.
Why One-Site Advice Breaks At Scale
Three things change.
You are no longer the only one editing. While you work on staging, the client publishes a post, a customer places an order, and a form collects twenty entries. The live site has moved on. Push staging over it and all of that is gone.
Sites drift apart. A hundred sites accumulate a hundred sets of plugin versions, PHP settings and custom code. A workflow that assumes they are identical will be wrong most of the time.
The volume makes manual impossible. Any process needing fifteen minutes of human attention per site is twenty-five hours a month before you have fixed anything.
The Database Merge Problem
This is the heart of it, and it is worth being blunt: there is no general solution to merging two WordPress databases. Not a hard problem, an unsolved one.
The reason is that WordPress stores content, configuration and state in the same tables, with integer primary keys assigned in sequence. Two environments both writing to wp_posts will both allocate ID 4821 to different things. When you try to merge, there is no reliable way to know that staging's 4821 is a page you built and live's 4821 is an order somebody placed.
Some tools reconcile specific cases. Nothing reconciles the general one, and any tool claiming to is making assumptions you should read carefully before trusting.
The Rule That Fixes It
Because you cannot merge databases, you stop trying. Instead:
Code moves up. Content moves down. They never cross.
Which in practice means:
- Code (themes, plugins, custom functionality) is built in staging and deployed to live. It lives in version control, not in a database, so deploying it is a file operation and carries no data risk.
- Content and data (posts, orders, users, settings) are authoritative on live and are copied down to staging when you need a realistic environment. Never the other way.
- Configuration that must change with a release is handled by a migration script that runs once against live, not by copying a database over.
Once that rule is in place, most of the terror goes out of deployment, because no deployment can destroy client data. It also means staging can be refreshed from live whenever you like, which is what keeps it useful.
Managed Hosting solutions for WordPress backed by Speed, Security and Scalability
Talk To Sales →Three Environments, Not Two
Agencies that run only live and staging end up using staging for two incompatible jobs: building things, and showing clients things. Those need different stability.
| Environment | Who touches it | Refreshed from live | Purpose |
|---|---|---|---|
| Local | Developers | On demand | Building. Broken most of the time, which is fine |
| Staging | Team and client | Before each review | Approval. Must always be presentable |
| Live | Nobody, directly | n/a | The real thing. Changes arrive by deployment only |
The rule that makes this work is the last one. Once you accept that nobody edits code on live, the whole workflow becomes predictable, and wp-config.php can be set per environment using the constants documented in the WordPress configuration reference.
Keep staging out of Google
Every staging site needs HTTP authentication and a noindex header. Not one or the other. Search engines find staging sites through links, and a client's half-finished copy competing with their real site in search results is a genuinely difficult conversation.
Testing Updates Across 100 Sites
The single most valuable thing staging does at this scale is stop one bad plugin release breaking your entire book on the same afternoon.
The workflow that holds up:
- Pick a canary set. Five or six sites that between them cover your common stacks: one WooCommerce, one membership, one heavy page builder, one minimal, one on the oldest PHP you still support.
- Update the canaries first. On staging, then on their live sites if they pass.
- Wait a day. Most bad releases surface within hours, and waiting costs you nothing.
- Roll out in batches of ten or twenty, not all at once.
- Keep the rollback ready. A backup taken immediately before, per site, that you have actually tested restoring.
WP-CLI is what makes this practical: it can check, update and roll back plugins across many sites from one command, which is the difference between a workflow and a wish. Our WordPress maintenance checklist covers what else belongs in the same pass.
Who Approves What
Process failures at this scale are usually human, not technical. Two decisions worth making explicitly:
What needs client sign-off? Security patches should not wait for an email reply. Design changes should never go live without one. Write the boundary down, because the default is that everything waits for approval and nothing gets patched.
Who can deploy? At a hundred sites, "anyone who has the password" is not an answer. One named person per release, and a record of what changed.
What To Automate First
In order of return, assuming limited time:
- Backups, verified. Not "backups exist" but "we have restored one this month". An untested backup is a belief, not a plan.
- Refreshing staging from live. If this takes a developer twenty minutes, staging will be stale, and stale staging gets ignored.
- Update checks. A daily report of what needs updating across every site, rather than logging into each one.
- Uptime and error monitoring. You want to hear it from a monitor, not a client.
- Deployment. Last, because it is the largest job and the previous four remove more risk per hour spent.
If your agency hosting platform provides staging, backups and one-command site copies, most of this is configuration rather than engineering, which is the argument for agency-focused hosting over assembling it yourself. Once the workflow exists, moving a portfolio becomes routine rather than an event.
Refreshing Staging Without Breaking It
A staging environment is only useful if it resembles live. Left alone for a month it becomes a museum, and nobody trusts a test that passed on stale data.
Refreshing means copying live down, and the step that catches people is the URLs. WordPress stores absolute URLs throughout the database, including inside serialised PHP arrays used by page builders and theme options. A naive find-and-replace corrupts those arrays, because changing the text without changing the recorded string length makes them unreadable.
The fix is a search-replace that understands serialisation. WP-CLI's search-replace command does this correctly, and running it with --dry-run first tells you how many rows will change before anything does.
A refresh worth automating looks like: copy the database, copy uploads, run search-replace for the domain, disable outbound email, disable payment gateways, add HTTP authentication, and set a noindex header. The last four are what stop a staging refresh emailing your client's customers.
The things that must never run on staging
- Outbound email. A staging site with a live mail configuration will send order confirmations, password resets and newsletters to real customers.
- Payment gateways in live mode. Switch to test keys during the refresh, not afterwards.
- Scheduled tasks that talk to third parties. Stock syncs, CRM pushes and webhooks will happily fire from staging.
- Analytics. Otherwise your client's numbers include your testing.
Every one of these is a real incident that has happened to somebody. Bake the list into the refresh script rather than remembering it.
Configuration Per Environment
The cleanest way to keep these differences straight is to stop treating them as a checklist and start treating them as configuration. WordPress supports an environment type constant, and plugins and themes can branch on it.
Set WP_ENVIRONMENT_TYPE to production, staging or local in each environment's wp-config.php, and the site can decide for itself whether to send email or load live payment keys. The configuration reference covers the constant and the related debug settings.
The benefit at a hundred sites is that a refresh cannot forget a step, because the step is not a step. It is a value in a file that travels with the environment.
What The Tooling Actually Buys You
| Approach | Good for | Where it struggles |
|---|---|---|
| Host-provided staging | One-click copies, no setup, per-site | Push-to-live usually still cannot merge databases |
| WP-CLI scripts | Bulk operations across every site at once | You maintain the scripts |
| Git-based deployment | Code with a history and a rollback | Does nothing for content or uploads |
| Local environments | Fast iteration, offline work | Cannot be shown to a client |
Most agencies at this size end up with all four, and that is the correct answer rather than a failure to choose. They solve different problems.
The Honest Limit
Staging catches the failures that are visible on a page. It does not catch load-related problems, because your staging environment does not have your live traffic. It does not catch anything that depends on real payment or real third-party data. And it will not catch a plugin conflict that only appears with a specific piece of client content you did not copy down.
Which is why the canary approach in the previous section matters more than the staging environment itself. Staging tells you whether something is obviously broken. A small live rollout tells you whether it is actually broken. You want both, and if you can only have one, take the second.