Staging an ordinary website is straightforward: copy it, change it, copy it back. A store breaks that pattern, because the live database does not sit still while you work.
Why the usual approach destroys data
The moment the copy is taken, the live store carries on: orders arrive, stock counts change, customers register, coupons are used.
The staging copy receives none of that. Push its database back and you replace the real order history with a stale one. Every order, registration and stock change since the copy is gone, and there is no undo.
The customers still paid. The payment provider still has the records. Your store does not.
The rule
Files move from staging to live. The database only ever moves from live to staging.
Themes, plugins and custom code are files, and pushing them back is exactly what staging exists for.
Settings, page content and product edits live in the database. Those must be repeated by hand on the live store, which is tedious and is the price of not overwriting orders.
Keep a written list as you work on staging: every setting you changed, so the live repetition is a checklist rather than an attempt to remember.
Three things to disable on the copy, immediately
Outgoing email. A staging copy carries every real customer address. A test order, a bulk action, or a plugin doing its job can send genuine-looking mail to real people from a site that is not your store.
Disable mail at the application level, and preferably at the server level for that account too.
Payment gateways in live mode. A staging store configured with live credentials can take a real payment. Switch every gateway to test mode before doing anything else. Configuring payment gateways goes into it.
Search engine indexing. Otherwise your staging copy competes with your real store in search results, and customers occasionally land on it and order from it.
Discourage indexing in the settings, and password-protect the whole thing, which handles all three risks at once by keeping the public out entirely. Password protecting a directory explains it, and robots.txt walks through why blocking alone is not enough.
Customer data on the copy
A staging store contains real names, addresses and order histories, usually on a less-guarded copy that more people have access to.
If the work does not need real customer data, remove it after copying, or take a copy with orders and customers excluded. That reduces both the privacy exposure and the size of the copy.
Keep the copy short-lived
The longer staging exists, the further it drifts, and the more settings differ in ways nobody recorded.
Take a fresh copy for each piece of work rather than maintaining a permanent parallel store. A copy that is three months old is not a useful test of anything, because it no longer resembles the live store.
Before pushing files back
Take a full backup of live, taken now rather than last night. The difference is today's orders, which is exactly what you would regret losing. Backing up a store taking live orders goes into doing it consistently.
Then push at the quietest hour, and immediately place a test order on live to confirm the checkout still works end to end. A theme change that breaks checkout is silent otherwise; the site looks fine and the orders stop.
What staging is genuinely for
Plugin and theme updates, PHP version changes, and anything touching the checkout. These are the changes that break stores, and they are exactly the ones a copy tests well.
What it tests badly is anything depending on live data volume or real payment behaviour; a checkout that works on staging with test payments can still fail against the real gateway. Updating WooCommerce safely goes into the sequence around a live update.
Keep a written record of what changed
Because the database cannot be pushed back, every setting adjusted on staging has to be repeated by hand on the live store. That repetition is only reliable if it is written down as you go.
Keep a running list while working: which screen, which setting, old value and new. Not a description of the goal. The actual values, because the person repeating them may be you a week later.
The settings most often forgotten are the ones changed early and casually: a tax rate, a shipping threshold, an email template, a payment option toggled while testing something else.
Where the list gets long, that is itself a signal that the work belongs in code or configuration rather than in the database, so that it can move with the files.
Comparing the two before pushing
A copy that has diverged in ways nobody recorded is the usual reason a push goes wrong.
cd ~/public_html && find wp-content/themes wp-content/plugins -type f -newer wp-config.php | head -40 diff -rq ~/dev/wp-content/themes ~/public_html/wp-content/themes | head -30
The first lists files changed on live since the copy was taken, which is what a push would overwrite. The second shows what actually differs between the two trees.
Reading that list before pushing is what catches the case where somebody edited the live theme directly while the staging work was in progress. Overwriting that edit is silent and is discovered when the thing it fixed breaks again.
Copying back the other way
Refreshing staging from live is the safe direction and still deserves care.
Take a fresh database copy, restore it into the staging database, then re-apply the staging-specific settings: the site address, mail disabled, gateways in test mode, indexing discouraged.
Those four are undone by every refresh, because they live in the database that was just replaced. A refresh that skips them produces a staging store that is live in every respect except its address, which is the arrangement that sends real email to real customers.
Scripting the refresh so those settings are reapplied automatically is worth the hour it takes. Making a development copy of a site explains the steps to automate.
Removing the copy properly
A staging store that is finished with should be removed rather than left.
It holds real customer data, it consumes the account's disk and file count, and it is a second copy of the site with weaker attention paid to it, frequently on an older set of plugins, which is a genuine exposure.
Remove the files, drop the database, and remove the subdomain. Leaving the subdomain pointing at an empty directory is untidy; leaving it pointing at an outdated copy of the store is a risk. Store security best practices walks through why an unmaintained copy matters.