WP Toolkit staging lets you clone your live WordPress site to a subdomain so you can test changes safely. It copies the files and database, rewrites URLs for the staging hostname, and leaves production running as usual. You can break the clone on purpose; that is the point of having a separate copy.
How a staging clone works
In cPanel, open WP Toolkit on the WordPress account and choose the staging or clone option for your site. Toolkit creates a new document root, copies plugins, themes, and content as they exist at that moment, and adjusts the site URL for the staging hostname. Production keeps serving visitors while you work on the copy.
Protect the staging subdomain with Directory Privacy so random visitors and crawlers cannot reach it. A robots noindex tag helps, but a password is stronger. Public staging without a password can expose checkout pages, customer data, and unpublished posts, and search engines may index paths like /staging/cart.
What to push back to production
When your changes look good, push only what you need. For a theme or CSS update, push files. Push the database only when you fully understand that production writes since the clone will be lost. WooCommerce orders, form entries, bookings, and comments are writes. A theme file change is not.
If production took orders or other data after you cloned, a full database push from staging erases that activity. Prefer pushing theme or plugin files, then redo settings by hand on production. When you are unsure, push files only and leave the live database alone.
Traps to avoid
Do not clone over production just to experiment. That replaces the live site with a stale copy. Staging is the environment meant for testing; JetBackup remains your undo if something goes wrong on the live account. Staging is a working copy, not a backup. Keep regular backups in place.
Before you push, confirm the staging URL is password-protected and production is untouched. In Toolkit’s push UI, choose files only unless you have a clear, written reason to include the database. After a files-only push, purge LiteSpeed Cache on production so you are not looking at old HTML and thinking the push failed.
Toolkit’s clone step already rewrote URLs for the staging hostname. If a plugin stored the production URL in its own tables, that data still needs a careful pass. That is another reason not to push the database blindly. After any push, open the live checkout and confirm a recent order still appears. If it is missing, restore from backup rather than pushing again to “fix” it.
Tagged
Was this article helpful?
Be the first to rate this article.
