New Customers: 50% OFF Your First Month on All VPS Servers & Web Hosting Plans!

Using a staging site safely

A staging site lets you test WordPress updates, plugins and theme changes safely before deploying to your live site. This guide explains what a staging copy includes, which data syncs back to live, and the risks of editing both copies at once.

Sarah FrankiewizcPanel, WordPress, migrations and backups 10 min read Updated 23 Sep 2026

Using a staging site safely

This picks up from a working WordPress site on Hostworld cPanel hosting and that you can log in to cPanel. If your site is elsewhere, adjust the steps to your control panel or move first.

Test changes without risking your live site by using a staging site. A staging site is a working copy where you try updates, new plugins and theme changes, then deploy to production when you are happy. On Hostworld shared, reseller and WordPress hosting you do this in cPanel using WordPress Toolkit or Softaculous.

Before you start

  • Where this lives: Staging for Hostworld shared, reseller and WordPress hosting is managed in cPanel. We provide both WordPress Toolkit and Softaculous there. WordPress Toolkit is the supported way to clone and sync WordPress in cPanel. cPanel’s docs point to the WP Toolkit feature behaviour described by Plesk.
  • What a staging copy contains: Both tools create a separate set of files and a separate database. This protects your live database while you test.
  • The big risk: Copying a staging database over a live site overwrites live data created since you cloned, such as orders, customers, comments and form entries. WooCommerce can store orders in custom HPOS tables from 8.2 onwards. Excluding only wp_posts and wp_postmeta will not protect orders if HPOS is enabled. Data loss here is permanent without a backup.
  • Softaculous warning: The “push full database” option in Push to Live deletes the live database before importing the staging database. On an active site this wipes live data. Use it only during a planned content freeze or on sites without changing data.
  • WP Toolkit caution: In Copy Data, the “Remove missing files” option deletes files on live that do not exist on staging. This can remove media uploaded on live during your testing period. Leave it off unless you intend a hard reset.
  • Versions matter: When copying with WP Toolkit, if live is on an older WordPress version than staging, WP Toolkit upgrades live first. If staging is older than live, the copy is aborted. Plan the push window and update order to avoid surprises.
  • Maintenance window: WP Toolkit places the target in maintenance mode for the copy. Expect a brief maintenance period. Plan for a quiet time.
  • Keep staging private: Staging should not be indexed by search engines or seen by customers. In WordPress, enable “Discourage search engines from indexing this site”. You can also add HTTP Basic Auth at the web server level so the staging URL requires a password.
  • Avoid surprise emails: When testing orders or sign-ups on staging, disable transactional emails. WooCommerce recommends turning off emails during testing to avoid sending test messages to customers.
  • There is no two-way sync: Staging and live do not auto-synchronise. If you want staging to reflect current live data before pushing, copy the live data to staging first, then continue.
  • Undo options: WP Toolkit offers a restore point before copying data. Softaculous creates a backup automatically before each Push to Live. These are your rollbacks if something is wrong.
  • Need help: If anything here is unclear for your site, open a support ticket and we will take a look.

Step 1: Decide your staging address and keep it private

What you are doing: Choose where the staging copy will live and set privacy controls so it is not crawled or visited by the public.

  1. Decide on a subdomain such as staging.example.com. WordPress Toolkit defaults to a “staging” prefix. Softaculous lets you choose a domain and optional subdirectory.
  2. Make sure the target path is empty. Both tools warn if you are about to overwrite files at the target. Do not place staging where something else lives unless you intend to replace it.
  3. In the staging WordPress admin, go to Settings and enable “Discourage search engines from indexing this site”. This is a signal, not a guarantee. Add HTTP Basic Auth if the content is sensitive so a password is required to view any page.
  4. If you will test orders or contact forms, disable outgoing emails in the application while testing.

Undo: If you created staging in the wrong place, remove that staging instance from the same tool you used to create it, then re-create it at the correct subdomain.

Step 2: Create staging in cPanel with WordPress Toolkit

What you are doing: Clone your live WordPress into a new location with its own database using WordPress Toolkit for cPanel.

  1. Log in to cPanel and open WordPress Toolkit. Find your live installation in the list.
  2. Use Clone. Choose the target domain or subdomain and, if needed, a subdirectory. WordPress Toolkit will create a new database for the clone.
  3. Read the warning about overwriting data at the target. Confirm only if the target path is empty or disposable.
  4. Wait for the clone to complete. You will now have separate live and staging entries in WP Toolkit.

WP Toolkit for cPanel uses the same feature set documented in the WP Toolkit user guide. The Clone action makes a complete copy and sets the configuration for the new database.

Undo: To discard this staging site, return to WordPress Toolkit and remove the staging installation. Do not remove the live installation by mistake. Check the URL before you click delete.

Step 3: Create staging in cPanel with Softaculous

What you are doing: Use Softaculous to create a staging copy with its own database.

  1. In cPanel open Softaculous, then go to All Installations.
  2. Find your live WordPress entry and click Stage.
  3. Choose the target domain and optional subdirectory. Enter a new database name for staging. Softaculous creates a separate database.
  4. Start the staging process. Softaculous emails the details to your account address when it is done.

Undo: If you staged the wrong site or location, go back to Softaculous, find the staging instance in All Installations and remove it. Leave the live installation intact.

Step 4: Prepare staging for safe testing

What you are doing: Make staging reflect current live content where needed, then lock it down for testing.

  1. If your site changes daily and you want staging to reflect the current live data before you begin, use WP Toolkit’s Copy Data to copy data from live to staging first. Copy only what you need. There is no automatic two-way sync.
  2. Turn on “Discourage search engines” in the staging WordPress Settings. Add HTTP Basic Auth if the content is confidential. This prevents search engines and the public from accessing staging.
  3. Disable outgoing emails in your application settings if you plan to place test orders or send forms.
  4. Note the WordPress versions shown in WP Toolkit for both live and staging. If they differ, plan for the WP Toolkit behaviour during push: it upgrades the target if the target is older, or aborts if the source is older.

Undo: If you copied the wrong data to staging, repeat the copy from live to staging and select the correct items. You are working in the staging area, so this does not affect the live site.

Step 5: Test your changes on staging

What you are doing: Apply and verify the changes you intend to deploy.

  1. Update plugins and themes, change settings, and add or edit code on staging until you are satisfied.
  2. For WooCommerce, run test orders on staging while emails are disabled. Confirm checkout, taxes, shipping and confirmations behave as expected.
  3. Keep a short list of what you changed so you can choose the correct push options later.

Undo: If a change fails on staging, back it out on staging and re-test. Nothing you do here touches live until you decide to push.

Step 6: Push changes live with WordPress Toolkit

What you are doing: Use WP Toolkit’s Copy Data from staging to live, choosing what to copy and protecting live content.

  1. In cPanel open WordPress Toolkit. Select your staging installation and choose Copy Data.
  2. Select the live site as the target. WP Toolkit offers a restore point. Take it. The target is placed in maintenance mode during the copy.
  3. Choose what to copy:
    • Files only: Copies code and media files. This is the safest choice for active sites. It does not touch the live database.
    • Database only: Copies database changes. When you choose this, you can select All tables, New tables only, or Selected tables.
    • Files and Database: Copies both.
  4. If you copy the database, use Selected tables for fine control. WP Toolkit can exclude common content tables and has a preset that keeps posts and users by excluding _posts, _postmeta, _users, _usermeta.
  5. If your store uses WooCommerce HPOS, also exclude the HPOS order tables such as wc_orders and related tables. Excluding only posts and postmeta will not protect orders when HPOS is enabled.
  6. Leave Remove missing files unchecked unless you intend a hard reset. Enabling it deletes files on live that do not exist on staging, which can remove new uploads on live.
  7. Review the WordPress version note. If live is older than staging, WP Toolkit upgrades live first. If staging is older than live, the push is aborted. Align versions if needed, then repeat.
  8. Start the copy. When it completes, take the target out of maintenance mode if needed and test the live site.

Recommended approach for active sites: Push Files only. Do not push the database unless you have a content freeze or you have selected only safe tables. WooCommerce’s own guidance is “code goes up, content goes down”.

Undo: If the result is wrong, use the restore point WP Toolkit created to roll back the live site. You will find restore points in the WP Toolkit interface for that installation. Restore, then re-check your selections and try again during the next window.

Step 7: Push changes live with Softaculous

What you are doing: Use Softaculous Push to Live to deploy staging back to production.

  1. In cPanel open Softaculous and go to All Installations. Find the staging instance and click Push to Live.
  2. Choose Default or Customize. In both modes you can decide whether to overwrite files and whether to push the database.
  3. Do not select “push full database” on active sites. Softaculous documents this as a destructive action. It erases the live database and imports the staging database. Use it only if you have a content freeze or the site has no changing data.
  4. Confirm and start the push. Softaculous automatically creates a backup before it runs.

Undo: If you need to roll back, go to Softaculous Backups and restore the backup that was taken right before the push. Test live again.

Step 8: Avoid the trap of editing both copies

What you are doing: Protect live, time-sensitive content and use a clean sync workflow.

  • There is no automatic two-way sync between staging and live. If you edit both, you must decide which changes win. Pushing a staging database to live will overwrite live data created since you cloned.
  • Safe workflow when live keeps changing:
    1. Do your work on staging.
    2. Right before the deployment window, copy content-only from live down to staging so staging reflects the latest orders, users and posts. Use WP Toolkit Copy Data from live to staging and choose Selected tables. Include WooCommerce HPOS tables if HPOS is enabled.
    3. Re-check your changes on staging quickly.
    4. Push Files only from staging to live. Leave the live database untouched.
  • If you must push database changes: Plan a short content freeze, tell your team not to create or edit content during that period, and use WP Toolkit’s Selected tables to exclude anything that changes on live, including HPOS order tables.
  • If things go wrong: Use the WP Toolkit restore point or the Softaculous auto-backup to revert. If you overwrote live orders without a backup, those transactions cannot be reconstructed by the tools.

Step 9: Clean up and keep staging tidy

What you are doing: Reduce confusion and risk once you are finished.

  • Keep staging non-indexed and password-protected at all times.
  • Delete old staging copies you no longer need from WordPress Toolkit or Softaculous so you do not push from the wrong one by mistake.
  • Document your chosen push options for your next change window.

Undo: If you deleted the wrong staging, recreate it from live and repeat your testing steps. This does not affect the live site unless you push again.

What next

If you host WordPress with us you already have WordPress Toolkit and Softaculous in cPanel. If you need more room to experiment, consider a separate environment. Start with our WordPress hosting, or step up to a VPS if you want full server control.

  • Looking to run isolated tests on your own server resources later on. See our UK VPS.
  • If you need to learn more about server administration first, browse our VPS guides.
  • If you want hands-on help setting this up in your cPanel account, open a support ticket and tell us the domain and which tool you prefer.

Next step in the playbook: schedule your change window, then deploy using WordPress Toolkit’s Copy Data with Files only for active sites, or Selected tables if you have to include database changes.

Common questions

Do I need a staging site for a small brochure site?

If your site rarely changes and you are only updating one well-supported plugin, you may decide you do not need staging. For anything that touches themes, multiple plugins, WooCommerce, or custom code, use staging. It gives you a rollback and a safe place to test.

Is staging included on Hostworld shared, reseller and WordPress hosting?

Yes. In cPanel you have WordPress Toolkit and Softaculous. Both can create a staging copy and push changes back to production.

How long will my site be in maintenance during a push?

WP Toolkit places the target into maintenance mode during the copy to prevent a partial state. The time depends on the size of your site and what you copy. Plan the push for a quiet period. Softaculous does not state a maintenance mode, but any file and database operations can still cause a brief interruption.

How do I avoid losing WooCommerce orders when I deploy?

Follow the “code goes up, content goes down” rule. Push files only. If you must push database changes, use WP Toolkit’s Selected tables and exclude live content tables. If WooCommerce HPOS is enabled, exclude HPOS order tables such as wc_orders and related tables as well as posts and users. Never use Softaculous “push full database” on an active store without a content freeze and a tested backup.

What happens if I edited both live and staging?

There is no automatic two-way sync. Decide which changes win. The safest pattern is to pull the latest content from live down to staging right before deployment, re-test, then push files only to live. If you accidentally overwrote live content, restore from the WP Toolkit restore point or the Softaculous backup taken before the push.

Will search engines find my staging site?

They can if you do nothing. Turn on “Discourage search engines” in WordPress on staging and add HTTP Basic Auth so a password is required. This keeps it out of the index and away from public view.

Where do I get help if I am unsure which tables to exclude?

Tell us which plugins you use and whether WooCommerce HPOS is enabled. We will advise on a safe selection for your push. Open a support ticket and include the domain and a brief summary of your change.