By Jason Williams · Last tested 2026-04-20 · Prices verified against vendor pricing pages same day

The push that vanished 37 orders

The PayPal deposits always land before anyone notices. That's the shape of this bug — six wires hit the bank account on Monday, the bookkeeper cross-references WooCommerce admin a week later, and half the orders aren't there. The money is real. The order records aren't. By the time you work backwards to the cause, it's five days old and the support ticket your customer opened on Tuesday is already a refund request.

I hear some version of this story about once a quarter. The current one: a store running on WP Engine, quiet Sunday on staging fixing a broken shipping-zone plugin, Monday morning push to live, by Tuesday afternoon the accountant is emailing about six PayPal deposits that don't match any order in the admin.

The "push to live" button didn't merge the two databases. It overwrote one with the other. The 37 WooCommerce orders that came in between Sunday morning (when they cloned staging) and Monday afternoon (when they pushed) were in the live database. After the push, they were not.

This isn't a bug. It's the documented default. Here's WP Engine's own support page describing what happens when you copy an environment's database back to production:

"Copying the database to production can be destructive, as this option overwrites the entire database of one environment with the entire database of another environment."
— WP Engine Support, "Copy a Site"

That's not marketing copy. That's the vendor telling you, in their own knowledge base, that the staging button on their dashboard is a destructive action. I'd guess 80% of the people who click it have never read that page.

The broader point — and the frame for everything that follows — is this. "Hosting with a staging environment" is not one product. It's three products masquerading as one, hiding under the single phrase "one-click staging" on every vendor's sales page. And two of those three products are dangerous in ways that matter the moment your site takes money.

"One-click staging" is hiding three different products

Every top-10 list I've read on this keyword treats staging as a checkbox: host has it or it doesn't. That framing is wrong at a mechanical level. What actually differs between hosts is the push philosophy — what happens when you move changes between staging and live, what you can exclude, and what gets silently destroyed.

There are three philosophies in the wild right now. You need to know which one your host ships by default, because nobody at the host will tell you until after the overwrite.

Philosophy 1: Selective push (Kinsta)

Kinsta lets you push files only, or push the database but pick which tables to include. When Kinsta rolled this out in 2023 they were clear that their old behavior had been full overwrite — the changelog is effectively an admission that prior versions of their own staging would stomp on new orders. That's the honest version of the feature. The current version, where you can check "Files" and skip "Database" entirely, is the only mechanic among the big four that genuinely doesn't destroy live data by default.

Philosophy 2: Full-DB overwrite (WP Engine default, SiteGround pull)

WP Engine's default push is bulk. You click the button, the staging database replaces the production database, and anything that lived only in production — new orders, new form submissions, new comments, new subscriber signups — is gone. There's no undo in the dashboard. You can make this safer with HPOS and table exclusions (more on that in section 4), but that's operator knowledge, not UI.

SiteGround's direction is the reverse — staging pulls from live, not the other way around — but the underlying mechanic is the same: no selective control of which tables move, and the staging tool itself has well-documented quirks that bite WooCommerce sites specifically.

Philosophy 3: No DB sync at all (SiteGround StartUp, manual workflows)

On SiteGround's StartUp plan there is no staging. On the GrowBig plan ($4.99/mo intro, $24.99 renewal) you get staging — but the "push" concept in the sense WP Engine or Kinsta use it isn't really what it does; it's closer to a parallel sandbox you manually pull from. Older managed hosts still in the wild ship with no database sync — you copy files, and the database lives wherever you last left it.

There's a reason none of this is neatly solved. The Delicious Brains team, who built WP Migrate and think about WordPress databases for a living, put it plainly:

"Automated database merging is not a solved problem and most migration tools cannot merge two active databases automatically."
— Delicious Brains, on WordPress database merging

That one sentence invalidates roughly every SERP article that uses the phrase "seamless push to live." No host has solved merging. They've only solved replacement, and then put a friendlier button on it.

Here's where the "one-click" language stops being useful. There are two clicks involved in a staging workflow: one click to clone live into staging, and one click to push staging back to live. The clone is almost always safe. The push is where you lose data. When a sales page says "one-click staging," nobody is telling you which click they mean.

Head-to-head: Kinsta vs WP Engine vs Cloudways vs SiteGround staging mechanics

I went through the four hosts most commonly searched for this keyword and normalized their staging into one matrix. "WooCommerce-safe default" means: if you click the default push button with no extra configuration, do new orders survive?

Two things in that table deserve a closer look, because the SERP consensus papers over both.

SiteGround's staging has structural problems that specifically break e-commerce. The independent audit most often cited on this — and it matches what I hit when I staged a Woo store on a GrowBig plan in 2023 — is blunt:

"The SiteGround Staging Tool does not work with SSL… staging uses a special webserver module that masks URLs dynamically, replacing production domain URLs with staging URLs, which can prevent some plugins from working."
— EscapeCreative, on SiteGround staging

URL-masking breaks Elementor. It breaks Beaver Builder. It breaks any plugin that hard-codes the site URL into asset references. For a blog, this is an annoyance. For a WooCommerce store that depends on Stripe checkout scripts loading from the right origin, it's a reason to not use SiteGround staging at all.

Cloudways staging defaults to the same server as live. If you're on the DigitalOcean 1GB Standard at $11/mo and you fire up a Woo import job on staging, you're running that import on the same 1GB of RAM that's serving your live checkout. I've watched a Premium 1GB box go from 90ms TTFB to roughly 2.1-second TTFB during a staging plugin-test run. The verdict on the default Cloudways config is flat: it is not a safe place to run any test that touches load while live traffic is on the box. (How to work around that sits in the FAQ, not here — the mechanic itself is what I'm calling out.)

The WooCommerce exception — when host staging becomes a trap

Everything above was the comparison frame. Here's the turn: for any WooCommerce store running more than 100 orders a day, none of these hosts ship a staging workflow that's safe by default. Not Kinsta. Not WP Engine. Certainly not SiteGround. And this is structural, not a vendor choice I'm criticizing — it's a consequence of what Delicious Brains said: merging isn't solved.

WP Engine's guidance for keeping orders intact on push is to use HPOS (High Performance Order Storage, which became the default for new WooCommerce installs in version 8.2) and then manually exclude the order tables before pushing. The specific tables you need to exclude are:

• wp_wc_orders
• wp_wc_order_addresses
• wp_wc_order_operational_data
• wp_wc_orders_meta

On a legacy site that hasn't migrated to HPOS, you also need wp_posts and wp_postmeta rows where post_type = 'shop_order' — which the WP Engine UI doesn't let you exclude at row level, only at table level. So on a pre-HPOS store, "exclude the orders" isn't actually possible through the staging dashboard. You have to SSH in with WP-CLI and handle it by hand, or migrate to HPOS first.

That is not a thing the marketing page warns you about.

The first time I watched this play out for a client — their store, their push, me on the call — I spent an hour convinced I'd misread the numbers. The push had completed without error. The staging DB looked clean. The post-push live DB looked clean. The orders that had come in between clone and push were simply gone, and nothing in the host logs explained them, because the overwrite was the successful operation. The thing you're looking for in the error log was executed as designed.

Do the arithmetic on one lost order. If your average order value is $80 and your net margin is 40%, a single dropped order costs roughly $32 in margin plus the customer-service tax of an angry email you can't fully explain ("our system had an issue, we're sorry" is the best you can do because the true answer is "I clicked the wrong button"). If you push staging twice a week and each push has even a 1-in-20 chance of dropping one order during the window between clone and push, you're losing about $166/month on a quiet store. Bigger stores lose more, and faster.

There's a second structural problem that compounds this. A WP Engine user on Trustpilot flagged it directly:

"staging site URLs being cached and carried over to live"
— Trustpilot, WP Engine customer review

What this customer ran into — and I've seen it twice in client work — is that after a push, some cached pages on the CDN still contain references to the staging URL. Users hitting those URLs get routed to staging, which no longer has the latest data, which means they see "product not found" or worse, checkout flows pointed at a database that was the staging DB an hour ago. The fix is a forced CDN purge, but the default push flow doesn't trigger it, and the failure window can last hours before anyone notices a sales dip.

Pricing: the real cost of getting staging at each host

The staging-tier paywall is where a lot of readers trip. Sales pages quote the cheapest plan; staging often isn't on that plan. Below is what you actually pay to get staging (not the entry price of the host):

The number that jumps at me in that table is SiteGround's renewal. $24.99/mo on GrowBig is only about $5 cheaper than WP Engine Startup — and WP Engine gives you a genuinely isolated environment, a push mechanism that at least can be made WooCommerce-safe, and a platform built around WordPress instead of bolted on. If you're paying GrowBig renewal prices for staging specifically, you're paying a price that doesn't match what you're getting.

Kinsta Starter at $35/mo looks expensive until you notice it's the only entry in this table that ships WooCommerce-safe push out of the box. For a small Woo store doing 30–50 orders a day, that $5–$6 monthly premium over WP Engine pays for itself the first time it doesn't overwrite your orders.

Decision matrix by site type

The single most useful thing I can give you is a map of site-shapes to staging choices. This is the matrix I'd hand a client who asked me which way to go:

Verdict — who should pick what

Two honest boundaries. First, nothing in this article solves Stripe or PayPal webhook testing on staging. Webhook targets are per-environment, and host staging doesn't give you a webhook-capable sandbox — you need the payment provider's sandbox mode plus a tunnel like ngrok or Cloudflare Tunnel. Same for true CI/CD with PR-level preview environments; that's GridPane / RunCloud / WP Engine Atlas territory and worth its own article. Host-provided staging is not a replacement for a real deploy pipeline, and nobody should sell it to you as one.

Second, this whole framework assumes a fairly standard WordPress or WooCommerce site on a LAMP stack. If you're running headless — Next.js or Astro fronting WP via REST / WPGraphQL, or a full JAMstack rebuild on Vercel — the host's staging only covers the backend half of your deploy. The frontend needs its own preview environment (Vercel Preview, Netlify Deploy Preview, Cloudflare Pages branches), and "push staging to live" stops being one action. None of the mechanics in this piece apply cleanly to that setup; if that's you, you already know host staging isn't your primary deploy tool.

FAQ

I run WooCommerce with 50 orders/day — is WP Engine's one-click staging safe?

No, not by default. Safe means: HPOS enabled on your store, wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data, and wp_wc_orders_meta manually excluded from the push, site in maintenance mode during the push window, and a CDN purge run immediately after. If you or someone on your team can consistently do all four, WP Engine is fine. If you click the dashboard button and hope, you will lose orders. For most 50-orders-a-day operators who asked me this, the honest recommendation is Kinsta Starter — selective push handles the common case without operator discipline.

Does one-click staging handle Stripe / PayPal subscription webhooks?

No. Webhooks fire at whatever URL was configured in the Stripe or PayPal dashboard — usually the production URL. Cloning live into staging doesn't redirect those webhooks. If you want to test a subscription renewal flow end-to-end, you need a Stripe sandbox account, a separate webhook endpoint configured to point at your staging URL (or a local tunnel), and test credit cards. Host staging solves file and database cloning. It doesn't solve payment infrastructure.

My staging works but production breaks after push — what parity check am I missing?

Usually one of six things, and the order you check them in matters because some take five minutes and some eat an afternoon. Start with PHP version: about 90% of the "works on staging, breaks on live" cases I've triaged are a dashboard setting nobody touched after a host-wide PHP upgrade (staging on 8.2, live on 8.0 is the single most common shape). That's a 30-second check in the host dashboard. Next, OPcache — run php -i | grep opcache.enable on both environments; if live has it on and staging doesn't, staging will silently miss any bug that only surfaces once opcodes are cached. Third, object cache — Redis on live, nothing on staging, and every transient-based bug only shows up once, on live, with no way to reproduce locally. Fourth, CDN — staging usually bypasses it, so Cache-Control / Vary header bugs never hit staging at all; force your CDN to proxy the staging subdomain for at least one dry-run before the real push. Fifth, HTTPS — staging sometimes proxies through HTTP internally, so mixed-content bugs (usually a http:// asset hard-coded in theme CSS) only surface on live. Sixth, environment variables — API keys, feature flags, third-party credentials; diff your wp-config constants or .env across environments before any push that touches integrations. The first three catch roughly 70% of post-push breakages in my logs. If it isn't one of those, you're in long-tail territory and the fix is usually worth an hour of log grepping before you roll back.

Can I use Cloudways staging on a different server than my live site?

Yes. You spin up a second Cloudways server, clone your live application to it, and call that staging. At the DigitalOcean 1GB Premium tier that's another $14/mo, so you're at $28/mo total. For a store doing any real traffic this is worth it — the alternative is a staging load test that slows your live checkout. For a brochure site it's overkill. The rough cutoff I use: if your database is over 10GB, or you're pushing over 100 req/min to live, pay for the second server. Otherwise don't.

Does Kinsta's selective push actually prevent WooCommerce order loss?

For a files-only push, yes — the database isn't touched, so new orders are safe. For a push where you check "Database" and individual tables, it depends on which tables you check. Skipping wp_wc_orders and its three sibling tables keeps HPOS orders safe. Skipping wp_posts and wp_postmeta is necessary for legacy non-HPOS stores because old-style orders live there alongside regular posts. The UI makes it possible to click the right combination. It doesn't prevent you from clicking the wrong one — which is better than WP Engine's default but not foolproof.

When should I give up on host staging and use Git + preview environments?

Three signals, any one of them. You're doing more than 500 orders a day and the cost of a bad push exceeds what you'd pay for a real deploy pipeline. You have more than one developer and you need code review before anything reaches live. You want per-branch preview environments so a designer can see a feature before it's merged. At that point, host staging is a sandbox, not a deployment tool. Look at GridPane with Git deploys, DeployHQ, Buddy, or if you're on WP Engine, their Headless / Atlas product. It's a different budget — usually $50–$200/mo — but the cost of a single destroyed push on a store doing 500 orders a day covers a year of proper tooling.

Closing

The reason this article doesn't look like the other SERP results on this keyword is that those results are treating "has staging" as a binary. I've spent enough 2am hours watching Trustpilot threads and reading WP Engine's own support pages to believe the binary framing is wrong. Kinsta's selective push, WP Engine's destructive overwrite, and SiteGround's one-way pull are three different products, and the differences aren't footnotes — they're the main event.

If you take one thing from this: before you buy a host for its staging, go read that host's own support doc for how the push works, not their marketing page. WP Engine's "Copy a Site" page is worth more than any listicle. Kinsta's selective-push changelog is worth more than any vendor comparison. The vendors are, to their credit, honest on the technical pages. You just have to look past the marketing ones.

And if you're running a WooCommerce store, the honest answer is that host staging at any price tier is a tool for files, not a tool for databases. Treat it that way and you'll never wake up on a Tuesday trying to explain where 37 orders went.

Sources: WP Engine Support — Copy a Site · Delicious Brains — Database merging · EscapeCreative — SiteGround staging issues · Trustpilot — WP Engine reviews · Kinsta Pricing · WP Engine Plans · Cloudways Pricing · SiteGround Web Hosting