The right place to test a plugin update, a new theme or a redesign is a copy of the site that nobody else can see. Plesk's WordPress Toolkit makes that copy in a click and, more usefully, copies changes back the other way when you are done. Here is the workflow we use for every client site.
Create the staging site
- In Plesk, open WordPress and find the site's card.
- Click Clone.
- Choose Create subdomain and enter
staging— you getstaging.example.com. (Or pick an existing empty domain.) - Leave Database name as generated. Click Start.
Two minutes later you have a full copy, with its own database, its own URL, and search engines told to stay away (Toolkit sets Discourage search engines on the clone). Password-protect it too, so the copy is never mistaken for the live site: Password-protected Directories on the subdomain, or the Toolkit's Maintenance mode with a password.
Test on staging
Do the risky thing there: update the plugins, switch the theme, edit functions.php, try the new page builder. Check the pages that matter — home, a product, checkout, the contact form — in a real browser. If it breaks, delete the clone and make a new one; nothing was at risk.
Toolkit's Smart Update automates the most common case: it clones, applies pending updates to the clone, compares screenshots of key pages before and after, and only updates live if nothing visibly changed. Turn it on under the card's Updates settings for sites where you would otherwise skip updates out of caution.
Sync back to live
Click Sync on the staging card (or Copy Data in older Toolkit versions) and choose:
- Files — which directories: everything, or just themes/plugins, or a custom list.
- Database — all tables, or only tables you select, or new tables only.
This choice is the whole skill of staging. Two rules:
Code goes down, content stays up. Themes and plugins you changed on staging should be synced to live. Content — posts, orders, comments, users, form entries — has changed on live while you were working, and syncing the database from staging would overwrite it. For a design or plugin change, sync files only.
Database sync is for a full rebuild. If you rebuilt the whole site on staging over weeks, put live into maintenance mode, sync both files and database, and accept that anything created on live in the last minutes is lost. For a WooCommerce store, that means picking a quiet hour and telling the team. If you must merge — new pages from staging plus new orders from live — sync only the specific tables (wp_posts, wp_postmeta for pages; leave wp_woocommerce_* and wp_users alone), then check.
Before any sync, Toolkit offers to back up the target. Say yes; the backup is one click away if the result is wrong.
Refresh staging from live
The other direction — copy live back to staging so you are testing against current content — is the same Sync on the live card pointed at staging, all files and database. Do this before each round of testing; a stale staging site produces false confidence.
Search engines and staging
Toolkit sets the WordPress "discourage indexing" flag, but a link to staging.example.com found somewhere can still get it crawled. The password protection above prevents that entirely, and a Disallow: / in the subdomain's robots.txt is a cheap extra. When you delete the staging site, also remove the subdomain's DNS record so the URL stops resolving.
Without Toolkit
On a server without Plesk, the same workflow is: copy the files, dump and import the database with the URL replaced (wp search-replace https://example.com https://staging.example.com with WP-CLI, which handles serialised data correctly), and reverse it to go live. It works, but the file-only versus database-only choice has to be done by hand each time, which is exactly where mistakes happen.
Every VPSPioneer shared and reseller plan includes WordPress Toolkit with clone, sync and Smart Updates; on a managed VPS we set up the staging subdomain for each site at handover.