In this article9 sections
Most WordPress outages start with an update that looked harmless. A plugin changes its database tables, a theme drops a function a page depends on, or a new PHP requirement breaks a checkout. A staging site is a copy of the live site where you test those changes first. It costs a little time to set up and saves the much larger cost of a broken homepage on a Monday morning. This guide shows how to create a staging copy, how to keep it from affecting the live site, how to test updates, and how to push the tested changes back to production safely.
SiteHarbour’s WordPress hosting plans include one-click staging and cloning, so the copy is made for you. The steps below explain what the staging tool does and what to check, so you can use it with confidence and know how to do it by hand if you need to.
Why a staging copy is not optional
An update is a change to live code and live data at the same moment. A staging copy separates the two. You can break staging, learn why, and fix it, while visitors keep using the live site. The rule is simple: every plugin, theme or PHP update goes to staging first, and reaches live only after it passes the checks in Step 4.
Step 1: Create the staging copy
In your WordPress hosting dashboard, choose the site and select Staging, then Create staging site. The copy includes the files and the database, so it matches the live site on the day you make it. Expected: a separate address for the staging site, usually on a subdomain, that you can open in a browser.
If you copy the site by hand, copy the files with SFTP or File Manager, export the database from phpMyAdmin, and import it into a new database. Then update the site address in the database, because the copy still points to the live domain.
Step 2: Stop the copy from affecting the live site
A staging site must not send email, post to social media, or index in search engines. Set these before you log in to the copy:
- Block search engines. In Settings > Reading, tick Discourage search engines from indexing this site. Staging copies that get indexed create duplicate content problems.
- Stop email. Use a plugin that disables outgoing mail on staging, or the staging tool’s built-in mail block. A test order must not email a real customer.
- Disable payments in test mode. Switch the payment gateway to its sandbox mode, and check that no live keys remain in the settings.
- Remove scheduled tasks. A staging copy that runs the live site’s cron jobs can publish or email content twice. Check the scheduled tasks in Tools > Site Health and disable any that touch live services.
Step 3: Test the update on staging
Update one thing at a time: first the plugins, then the theme, then the PHP version, and never all three together. This way a failure points to one cause. Update, then check:
- The home page, a post, the archive pages and the search results load without errors.
- The login, the admin dashboard and any form or checkout work end to end.
- The browser console shows no new JavaScript errors.
- Tools > Site Health shows no critical issues.
For a store or membership site, place a test order and log in as a customer. Those flows break more often than the public pages do.
Step 4: Check the errors you would not see by eye
Turn on the debug log on staging only, in wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);After the test, read wp-content/debug.log. A notice that repeats on every page can cause slow pages and filled logs on live. Fix it before the change goes live. Turn debugging off on staging when you finish.
Step 5: Push the tested changes to live
Once staging passes, repeat the same change on the live site, at a quiet time. Keep a fresh backup first, as described in how to back up and restore a cPanel account. Make the change, then check the live site with the same list as Step 3.
Do not copy the staging database over the live one. The staging database holds test orders, test users and the disabled settings. Push code and plugin versions, not data. If the staging tool offers a “push to live” option, check exactly what it copies before you confirm.
Step 6: Keep the copy current
A staging copy from six months ago tests the wrong site. Refresh it before each batch of updates by cloning the live site again, then repeat the tests. Delete staging copies you no longer use, because they take space and can be found by people who should not see them.
Common mistakes
- Testing on a copy that is out of date. Refresh the copy before testing.
- Letting staging send email. A test order that emails a customer is a real incident.
- Updating everything at once. When something breaks, you cannot tell which change caused it.
- Pushing the staging database to live. You overwrite real orders and users.
- Skipping the search engine block. Staging pages in search results compete with the live ones.
Frequently asked questions
Do I need staging for a small blog?
A blog with no sales still needs a way to recover from a bad update. A recent backup is the minimum. Staging becomes essential once you take payments, rely on forms or have many visitors.
How long does a staging copy take to make?
Most small sites take a few minutes. Large sites with big media libraries take longer, because the copy includes every uploaded file.
Can staging test a PHP upgrade?
Yes, if the staging copy can run the new PHP version. Change the version on staging first, then test every plugin under that version before you change live.
Should the staging site have its own login?
Yes, or at least a different password from live. A staging site with the same passwords is a second entry point for an attacker.
A staging copy turns updates from a gamble into a test. Block search engines and email on the copy, update one change at a time, read the debug log, then repeat the tested change on live with a fresh backup. Keep the copy fresh, and never push its database over the live one. For the errors that show up after an update, read how to fix the WordPress white screen of death.