Picture a familiar week. The client approves a new header on Tuesday. On Thursday someone pushes it live, and with it goes a plugin update nobody tested, a half-finished pricing table and a database copied from a staging site that had not been refreshed for over a week. The new header looks great. Every contact form entry since the copy was made is gone.
Nobody in that story is careless. The team has a staging site. What it lacks is a staging workflow: a shared, written agreement about what goes onto staging, who looks at it, who says yes, and how the approved change actually reaches the live site. This post is about building that agreement for client sites, so that “it was fine on staging” stops being the start of an awkward call.
Staging is an environment; the workflow is the habit around it
If you need the basics of what a staging copy is and how hosts and plugins create one, our guide to setting up and using a WordPress staging site covers that ground. Here we assume the copy exists and look at the part agencies usually leave to memory.
For an agency, the risk is different from a single site owner’s. You have many client sites, several people touching them, and often an outside developer or partner in the mix. The same person rarely builds, reviews and deploys. Every handover between those people is a place where a change can be misunderstood, skipped or pushed in the wrong state.
A good agency staging workflow answers five questions for every change, before anyone opens a terminal:
- What exactly is changing, and on which site?
- Does this change need staging at all, or is it safe to make live?
- Who checks it on staging, and against what?
- Who on the client side approves it, and in what form?
- How does it move to live, and what is the way back if it goes wrong?
Decide which changes go through staging
Sending everything through staging sounds safe and quickly becomes theatre. People start skipping the step for “tiny” things, and then the rule means nothing. Be explicit instead.
Changes that should always go through staging
- Major plugin or theme updates, and anything touching a page builder or WooCommerce.
- PHP version changes on the hosting account.
- New templates, layout changes across many pages, or a new header and footer.
- Checkout, booking, membership or form logic.
- Replacing one plugin with another that does the same job.
Changes that can usually be made live
- Text edits, new blog posts and image swaps on a single page.
- Adding a new page from an existing template.
- Minor plugin updates on a site where you have a recent backup and a history of clean updates.
Write this list down per client if a site is unusual. A store that takes a large share of its orders on weekends may need staging for things a brochure site would never bother with.
Keep staging close to live, but not too close
A staging copy is only useful if it behaves like the real site. A copy taken months ago, with different plugin versions and a different PHP version, tells you very little. Refresh it from live before any significant piece of work, not after.
At the same time, the copy must not act like the live site in the ways that reach the public. Before you hand a staging URL to anyone, check that:
- Search engines are blocked, ideally with a password on the whole copy. The “Discourage search engines” setting under Settings, Reading in WordPress is a request, not a lock.
- Outgoing email is switched off or caught by a mail-logging tool, so test orders and form submissions do not reach real customers.
- Payment gateways are in test or sandbox mode.
- Scheduled jobs that talk to the outside world, such as subscription renewals, newsletter sends or stock syncs to a marketplace, are paused. Some plugins notice they are running on a copy and hold back; do not rely on that without checking.
- Analytics and ad pixels are removed or disabled, so client reports are not polluted by your team’s clicking.
The approval step clients actually respond to
Most approval problems are not about the client being difficult. They are about the request being vague. “Can you have a look at staging?” invites a quick glance at the homepage on a phone, followed by “looks good” and a complaint a week later about the contact page.
Give the client a short, specific review request. It should include the link and login, the pages to look at, what changed on each, what you need from them, and what happens next. For example:
Sample approval request
Hi Dana, the new booking form is ready to review on the private preview copy of your site. Link and password are below. Please check two pages: Book a Visit (the form itself) and the Thank You page that appears after you submit. Try one test booking with your own email; it will not reach your calendar or send anything to customers. If both pages look right, reply “approved” and we will schedule the change for the live site. If anything needs adjusting, a screenshot with a note is perfect.
Ask for the word “approved”, or something equally unambiguous, in writing. A thumbs-up emoji in a chat thread is easy to misread later. Keep the approval with the ticket or task, so anyone deploying can see it without asking.
Internal review comes first
Never send a client to a staging copy your own team has not checked. Someone other than the person who made the change should click through the affected pages on desktop and mobile, submit any form involved, and compare against the original request. If the work came from an outside developer, this is where your own check sits; we have a separate checklist for reviewing outsourced work before the client sees it.
Deploying: files, database and the part that bites
This is where staging workflows usually fail, and the reason is almost always the database.
WordPress keeps code (core, themes, plugins) in files, and keeps content, settings, users, orders and form entries in the database. While you worked on staging, the live site kept running. People placed orders, left comments, filled in forms and maybe edited a page. If you copy the whole staging database over live, you replace all of that with the older copy.
So decide, per change, what actually needs to move:
| Type of change | What moves to live | Safer approach |
|---|---|---|
| Theme or plugin code, CSS | Files only | Deploy the changed files, or repeat the update on live |
| Plugin update | Files, sometimes a database upgrade routine | Run the same update on live after a fresh backup |
| New page built in a page builder | Content and builder data in the database | Export and import the page, or rebuild it on live |
| Settings changes | Database options | Note each setting and repeat it on live |
| Large redesign | Files and much of the database | Schedule a short content freeze, then push everything |
Many host tools offer to push “everything” or “files only” or selected tables. Use the narrowest option that does the job. For a full push, agree a content freeze with the client: a window when nobody edits the site and, for a store, a quiet time for orders.
When a database does move between staging and live, the URLs inside it need changing, and WordPress stores some data in serialised form. A plain find-and-replace in a text editor can break those values. Use a tool built for it, such as WP-CLI’s search-replace command or a migration plugin that handles serialised data.
Before you deploy
- Confirm the approval is in writing and matches what you are about to push.
- Take a fresh backup of the live site, files and database, and check it finished.
- Note the current plugin and theme versions on live.
- Pick a quiet time for the client’s audience, not just for your team.
- Tell the client when the change is going live.
After you deploy
- Clear every cache layer involved: plugin cache, host cache, any CDN. Stale cache is the usual reason a client says the change “did not go through”; here is how to tell which cache is holding the old version.
- Click through the changed pages logged out, on mobile and desktop.
- Submit a real form or place a low-value test order if checkout was touched, then refund or delete it.
- Check the error log for new warnings.
- Send the client a short note: what went live, what you checked, what to tell you if they notice anything odd.
Plan the way back before you need it
Every deploy should have a rollback plan that someone could follow without the person who made the change. Usually it is simple: restore the backup taken just before the deploy, or roll back a single plugin to the noted version. Write it in the task. If the change involved a full database push, be clear that a rollback will also lose anything that happened on live since, so restoring is a decision, not a reflex.
For routine plugin and core updates across many sites, the same pattern holds at scale: copy, test, approve where needed, update live, verify, keep the rollback ready. That routine is exactly what a tested, behind-the-scenes update service is meant to carry for an agency that does not want to run it in-house.
When an outside team is part of the workflow
If a partner or contractor builds on staging and your team handles client approval, make the handoffs explicit:
- Who creates and refreshes staging. If both sides do it, you will end up with two copies and confusion about which is current.
- Where the “ready for review” signal lives. A status on the task, not a passing message.
- Who has permission to push live. Many agencies keep this for their own team; others let the partner deploy after approval. Either works if it is written down.
- What the partner sends back. A note listing files changed, settings changed, anything that must be repeated on live by hand, and any known issues.
With a large time difference, this structure is what lets work move overnight: the developer finishes on staging and leaves a clear note, your team reviews in the morning and sends the client link, and the deploy happens once approval arrives. Without the note, the morning starts with questions instead of review.
A one-page staging policy you can adapt
- Staging is refreshed from live before every significant change.
- Staging is password-protected, with email, payments and external jobs disabled.
- Every change on staging has a task describing what changed and where.
- An internal reviewer checks the change before the client sees it.
- Client approval is requested with a specific list of pages and recorded in writing.
- Live is backed up immediately before deploy, and the rollback step is written in the task.
- Only the parts that changed are pushed, unless a content freeze has been agreed.
- After deploy, caches are cleared, key pages and forms are tested, and the client is told.
Print it, adjust it to your sites, and make it the default rather than the exception. Our broader guide to how agencies hand WordPress work to an outside team shows where a routine like this fits alongside briefs, access and reporting.
If your team would rather hand the staging, testing and update routine to someone else while you keep the client conversation, that is what our white-label updates work covers, and we are happy to talk through how it would fit your current process.
Next in this series: Who Is Responsible for Client Website Backups?
