Most staging disasters we get called in to fix don’t happen while testing. They happen at the moment someone clicks “push to live” and three days of WooCommerce orders quietly disappear.
A staging site is a private copy of your website where you can try things out. Same theme, same plugins, same content, usually on an address like staging.yourbusiness.com.au. You make changes there, check them, and only then apply them to the real site. Simple idea. The hard part is the last step, and that’s what most of this article is about.
When a staging site is worth the bother
You don’t need staging to fix a typo or swap a photo. Do that on the live site and move on.
You do want staging for:
- Plugin or theme updates on a site that makes money. A WooCommerce store, a booking site, anything where an hour of broken checkout costs real dollars.
- Major version jumps. A big Elementor release, a PHP upgrade, WooCommerce moving up a major version.
- Redesigning a section. Rebuilding the homepage or services pages over a week or two while the old ones stay up.
- Adding something with moving parts. A new form plugin, a membership system, a payment gateway, a booking tool.
- Anything you’d be nervous explaining if it went wrong. That’s a decent test on its own.
On a five-page brochure site with no store and no bookings, a good backup taken before you start is often enough. Staging earns its keep when the site is changing while you work on it.
The problem: your live site keeps changing
This is what trips people up. A WordPress site isn’t just files. Everything that matters (pages, orders, customers, form entries, bookings, settings) lives in one database.
Say you copy your shop to staging on Monday. You spend the week rebuilding the product pages. Meanwhile the live shop takes 40 orders, a dozen customers create accounts, and your contact form collects enquiries.
On Friday you push staging to live. If the push replaces the whole database, the live site now matches Monday’s copy plus your design changes. Those 40 orders, the new accounts and the enquiries are gone. The money is still in Stripe or PayPal, but WordPress has no record of what to ship or who to call back.
This is the single most common way staging goes wrong, and it’s why “just push it live” is the wrong default for any site that takes orders or entries.
What’s safe to push and what isn’t
Think of your site in two halves: the parts you changed on staging, and the parts your customers changed on live.
| What it is | Where it lives | Safe to push from staging? |
|---|---|---|
| Theme and plugin files | Files | Yes |
| Uploaded images and PDFs | Files (uploads folder) | Usually, if you merge rather than replace |
| Elementor templates, pages and posts | Database | Only if nobody edited them on live in the meantime |
| Plugin and site settings | Database | Usually, check each one |
| Orders, customers, subscriptions | Database | No |
| Form entries, bookings, comments | Database | No |
| User accounts and passwords | Database | No |
The rule we work to: files can travel from staging to live, customer data never travels in that direction.
How we push changes without losing anything
There are three approaches, from safest to riskiest.
1. Rebuild the change on live
For small to medium changes, this is often the best answer. Use staging to work out exactly what needs doing (which plugin breaks, which setting fixes it, what the new section looks like), then repeat those steps on the live site during a quiet hour. Elementor makes this easier than it sounds, because you can export a finished template or section from staging and import it on live. We explain why we build that way in why we build every WordPress site in Elementor.
It feels slower. It’s the method least likely to lose anything.
2. Selective push
Better staging tools let you choose what to push: files only, or specific database tables. Push the theme, plugins and uploads, plus the tables holding your pages and settings, and leave the orders, customers and form entries alone.
This needs someone who knows which tables hold what, which is a good reason to get WordPress support for the first one. WooCommerce in particular now stores orders in their own tables rather than with posts on many sites, so the old rules of thumb don’t always hold. Many hosts include staging with selective push in their control panel. Plugins such as WP Staging do it from inside WordPress, though check which features are in the free version and which are paid before you rely on them.
3. Full push with a freeze
For a big rebuild, you can put the live site into maintenance mode, take fresh copies of any new orders and entries, push everything, then bring the site back. This works if you can actually stop trading for an hour, say at 9pm on a Tuesday. It doesn’t work for a shop that sells overnight.
Staging mistakes that cause real problems
Staging emails customers. Your staging copy includes every customer’s email address. If someone tests checkout or a plugin sends a reminder, real customers get real emails from a fake site. Turn off outgoing email on staging, or route it to a test inbox. If you’re not sure how your site sends mail in the first place, why emails from your WordPress site go missing covers it.
Staging takes real payments. Put every payment gateway into test or sandbox mode on staging. Disable scheduled tasks that charge subscriptions.
Google indexes staging. A public staging site with no password can end up in search results competing with your real site. Password-protect it and tick “Discourage search engines” under Settings > Reading. Then make very sure that box isn’t still ticked when anything is pushed back to live.
Staging goes stale. A staging copy from four months ago isn’t a test of anything. Refresh it from live before each round of work.
Nobody remembers it exists. Old staging sites still run old plugins, and outdated plugins are how sites get hacked. Delete staging when you’re finished, or keep it updated.
One question before you start
Ask yourself one question: will anything on the live site change while I work? If the answer is no, take a backup and work on live. If the answer is yes, set up staging, lock down its email and payments, and decide how you’ll get changes back before you start, not after.
Staging, backups and safe updates are part of how we look after the sites on our hosting and care plans. If your current setup doesn’t give you a staging copy or a clear answer on who owns what, our website ownership page explains the alternative.