Does a staging environment slow down my live site?

No. The test copy runs on the same hosting account, but since only you visit it, the load it creates is low. Cloning and copying data cause brief disk and CPU usage; on large sites, it's enough to schedule these operations for low-traffic hours.

Do I need a separate domain or hosting plan for staging?

No. The test copy runs under your existing domain, on a subdomain such as staging.yourdomain.com, in the same hosting plan. The copy takes up as much disk space in your plan as your site does; deleting it after testing frees that space again.

What do I do if a change I pushed live causes problems?

If you used WP Toolkit, you can return the live site to its previous state with the restore point created before the copy. Only one restore point is kept per WordPress installation, and each new copy overwrites the previous one. If you need to go back further, restore a backup from Plesk's Backup Manager.

What's the difference between staging and a backup?

A backup is a stored copy of your site at a point in the past, used to go back when something goes wrong. Staging is a working copy that lets you try a change before it goes live. For a safe update, use both: back up first, then test on staging.

How Do I Test a New Feature Without Breaking My Live Site? (Staging Guide)

October 17, 2026 · 6 min read

A plugin update, a new payment method or a theme change looks like a small job on paper, but tried on a live site it can end in a blank white screen or a broken cart page. For an online store, that means lost sales. The solution is to try changes first on an exact copy of the site that visitors don't see: a staging environment. In this guide we explain why and how to set up a staging environment, both with WP Toolkit for WordPress and by hand for other sites, step by step.

The 4 Parts of a Staging Environment

A staging site is a copy of your live site running at a separate address. A properly set up test environment has these four parts:

A copy of the files: The site's code, theme, plugins and images.
A separate database: The test copy works with its own copy of the database. If its configuration file points to the live database, every change you make while testing is written to the live site.
A separate address: Usually a subdomain such as staging.yourdomain.com.
Restricted access: Password protection and search engine indexing turned off. Otherwise search engines may index two sites with identical content, or your customers may place orders on the test site.

Common Mistakes When Setting Up Staging by Hand

You can set up a staging environment manually: create a subdomain, copy the files, export the database and import it into a new one, then update the configuration file. Depending on the size of the site, these steps take a long time, and each one is a separate point of failure:

The connection details in wp-config.php or .env aren't changed, so the test copy writes to the live database.
The WordPress site URL is replaced in bulk with SQL, which corrupts serialized data. The right tool is the wp search-replace command (WP-CLI), which handles serialized data correctly.
The test copy sends order and notification emails to customers, or runs the payment provider in live mode.
Once testing is done, it's unclear which files and tables should be moved to the live site.

Comparing Ways to Set Up Staging

Method	Setup	Moving to live	What to watch out for
Manual copy (subdomain + database copy)	Files, database and configuration are copied separately	Changed files and tables are moved one by one	The configuration file must not point to the live database
Local development environment (on your own computer)	A web server and database are installed on your computer	Files and database are uploaded to the server again	PHP version and server settings may differ from production
Separate Git branch	The `staging` branch is deployed to a subdomain, the main branch to the live site	Merge the branch and push	Database changes need separate handling (e.g. migrations)
WP Toolkit cloning (zuwinasa cloud WordPress Hosting)	Clone copies files, database and settings to a subdomain	Copy Data moves files, the database or selected tables, with a restore point first	WordPress sites only

Setting Up Staging and Going Live with WP Toolkit in 5 Steps

1. Back Up the Live Site

Before anything else, make a full backup of the files and database with Plesk's Backup Manager. The restore point created in a later step makes things easier, but it doesn't replace a backup.

2. Clone the Site

In Plesk, open WordPress and click Clone on the live site's card.
Keep Create subdomain as the target; WP Toolkit suggests the staging prefix by default, which you can change.
Edit the database name if needed and start cloning. WP Toolkit copies the files, the database and the WordPress settings, and adjusts the site URL to the new subdomain.

3. Close the Test Copy to the Outside World

On the copy's card, turn off Search engine indexing and turn on Password protection.
On an online store, switch payment methods to test (sandbox) mode and turn off emails to customers.
If there are scheduled tasks such as subscription renewals or stock syncing, disable them on the test copy; otherwise the same job may run twice.

4. Try the Change on the Test Copy

Update the plugin, change the theme or install the new feature. Then go through the paths that earn money and bring in contacts one by one: product page, cart, checkout, account registration, contact form and mobile view. If something breaks, the live site isn't affected; you can delete the copy and clone again.

5. Move the Changes to the Live Site

On the test copy's card, click Copy Data and select the live site as the target.
Choose what to copy: Files Only, Database Only or Files and Database. For the database, instead of all tables you can also choose new tables only or selected tables.
Leave Create a restore point checked; if something goes wrong, you can return the live site to its state before the copy in a single step.
During copying, the live site briefly goes into maintenance mode, so do it at a time of low traffic.

Note: On an online store, don't copy the database from staging to live with all tables. Orders placed, accounts created and reviews written on the live site after the test copy was made would be overwritten by the older data from the test copy. For theme and plugin changes, copy only the files; for tables created by a new plugin, copy only the new tables.

For Sites Not Built on WordPress

If you use Laravel, custom PHP or other e-commerce software, you can prepare a staging environment in Plesk in three steps: copy the files to a subdomain with Website Copying, create a full copy of the database with Copy under Databases, and point the connection in your configuration file (e.g. .env) to that copy. If you manage your code with Git, the Developer Hosting plans let you deploy the staging branch to a subdomain and the main branch to the live site; we explained how to connect Git in Plesk in our Node.js deployment guide.

For WordPress sites, cloning, data copying and Smart Updates are included in all zuwinasa cloud WordPress Hosting plans. Smart Updates tries plugin and theme updates on a copy of the site before applying them to the live site; if it detects broken layout or code, it doesn't apply the update to production. If you want a daily automatic backup of your live site, you can add our website backup service.