A staging site: test WordPress updates before they break things

Short answer: A staging site is a private copy of your website where you try updates, new plugins and design changes before touching the live site. Use your host's built-in staging if it has one; it's usually the simplest and safest. The rule that saves most businesses: push code and design changes (files) to live, but think very carefully before pushing the database, because that can overwrite orders, bookings, form entries and comments that arrived on the live site while you were testing.

Updates break WordPress sites in boring ways: a plugin clashes with the theme, a page builder update shifts layouts, checkout stops talking to the payment gateway. A staging copy lets you find that out on a Tuesday afternoon instead of from a customer on Saturday.

Host staging or a plugin?

If your host offers staging, use it. If not, a plugin works, or your developer can set up a staging copy on a subdomain with a proper copy-and-deploy process.

The workflow, step by step

1. Refresh staging from live

Start each round of changes from a fresh copy of the live site, so you're testing against today's plugins, content and settings, not last spring's.

2. Make the staging site safe

• Keep it private. Password-protect it and stop search engines from indexing it, so Google never shows customers a test copy.
• Stop it emailing customers. A staging copy of a shop or booking site can send real order or reminder emails. Disable outgoing email or route it to a test inbox.
• Switch payments to test mode. Use the gateway's sandbox keys on staging.
• Label it. WordPress has an environment type setting; its developer reference lists the values local, development, staging and production, and says it defaults to production if not set. Some plugins use it to change behaviour on staging, so ask your developer to set it.

3. Make one batch of changes

Update plugins, theme and WordPress core, or build the new page, or install the new feature. Do updates in a sensible order (core, then theme, then plugins) and note what you changed.

4. Test what earns you money

Don't just look at the homepage. Run through:

• [ ] contact and quote forms (do they submit, do notifications arrive in the test inbox?)
• [ ] booking or checkout, end to end, with test payments
• [ ] logged-in areas, memberships or customer accounts
• [ ] the pages that bring the most traffic
• [ ] the mobile menu and layout on a phone
• [ ] anything a plugin you just updated touches

5. Deploy the right thing

Here's where staging goes wrong most often.

Files are your theme, plugins, uploads and code. Pushing them carries over updates and design changes.

The database holds pages and posts, settings, and also everything visitors created: orders, bookings, form entries, new customer accounts, comments. If you push the whole staging database to live, the live database becomes a copy of staging, and anything that arrived on live since you made the copy is gone.

Hosts say this plainly. Kinsta's documentation notes that its push doesn't distinguish between new and old WooCommerce orders; pushing all files and the database overwrites live exactly as staging is. Its suggested workarounds are pushing only files, selectively pushing database tables while excluding WooCommerce tables, or syncing the live database to staging first. SiteGround's guide says a Full Deploy replaces both the files and the database of the live site, and offers a Custom Deploy for partial pushes.

So:

• Plugin, theme and core updates: often simplest to repeat the same updates on live once staging proves they're safe, or push files only.
• Design or layout changes built in the editor: these live in the database. On a site with ongoing orders or form entries, either push only the specific tables or pages your host or tooling allows, or rebuild the change on live from your tested notes during a quiet hour.
• Brochure sites with no user-generated data: a full push is usually fine if nobody changed live content in the meantime.

6. Back up, push, check

Take a fresh backup of live immediately before pushing. After the push, clear caches (plugin, host and CDN), then repeat the key tests on live.

What never to push blindly

• The whole database of a shop, booking site or membership site
• Staging's email settings and payment test keys
• Staging's "discourage search engines" setting
• Password protection settings meant only for staging
• Hard-coded staging URLs in theme files or plugin settings (Kinsta notes these need manual updating even when its search-and-replace runs)

How often to use it

For most small business sites, a monthly update round through staging works well, plus any time you add a plugin, change the theme or rebuild a key page. Urgent security updates may need to go to live faster; take a backup first and test right after.

FAQ

Does staging slow down my live site?

A host's staging environment usually runs separately. A plugin making a copy inside the same hosting account can use resources while copying, so do it outside busy hours.

Can I edit content on live while staging is in use?

Yes, but keep a list. Any live edits will be overwritten if you later push the staging database.

Is a staging site the same as a backup?

No. A backup restores the site after something goes wrong. Staging is for finding problems before they reach visitors. You want both.

Do I need staging for a small brochure site?

It helps, but a recent backup and a quick test after updates may be enough for a simple site with no forms or shop. Once money or bookings flow through the site, staging earns its keep.

If you'd like a staging setup that never overwrites a live order again, tell us where your site is hosted.

Sources

• https://kinsta.com/docs/wordpress-hosting/wordpress-push-environments/
• https://www.siteground.com/tutorials/staging/deploy
• https://developer.wordpress.org/reference/functions/wp_get_environment_type/