Clone And Stage WordPress With wp-toolkit¶

Use this page to create a WordPress clone for testing changes before touching the live site.

When To Clone¶

Clone before:

• Major WordPress core updates.
• WooCommerce, page-builder, membership, booking, or form plugin updates.
• PHP version changes.
• Theme swaps.
• Large imports.
• Design or content rebuilds.

Create A Clone¶

1. Log in to cPanel.
2. Open wp-toolkit.
3. Expand the source site.
4. Choose Clone or the available staging/copy option.
5. Select a destination domain, subdomain, or folder.
6. Confirm the destination is not an active site you need to preserve.
7. Create the clone.
8. Test the cloned site.

Use a subdomain or clearly named folder, such as staging.example.com or example.com/staging, so the clone is not confused with production.

WP-CLI Equivalent: Clone Manually¶

WP-CLI can handle the database side of a manual clone. File copying and database creation still need normal SSH or cPanel work.

From the production document root:

wp db export ~/production-before-clone.sql
wp db export ~/staging-clone.sql

After copying the WordPress files to the staging folder and updating wp-config.php to use the staging database, import the copied database from the staging document root:

wp db import ~/staging-clone.sql
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid
wp option update home 'https://staging.example.com'
wp option update siteurl 'https://staging.example.com'

Use exact URLs. If production uses www, a subfolder, or a different scheme, match that value exactly in the search-replace command.

Keep The Clone Away From Customers¶

After cloning:

• Disable production payment capture.
• Avoid sending test email to real customers.
• Do not let search engines index the staging copy.
• Confirm contact forms and automations are not sending unwanted messages.
• Clearly label the clone in wp-toolkit if the interface allows it.

Copying Changes Back¶

Copying a clone back to production is riskier than creating the clone. It can overwrite content created after the clone was made.

Be careful with:

• WooCommerce orders.
• Form entries.
• Membership signups.
• Comments.
• Bookings.
• New media uploads.
• User accounts.

For many sites, the safer approach is to repeat the tested changes manually on the live site instead of pushing a full clone over production.

Before Replacing Live¶

Confirm:

1. The live site has a fresh backup.
2. The staging copy is current enough to use.
3. Dynamic data created on live will not be lost.
4. Forms, checkout, login, and admin have been tested.
5. DNS and SSL are still correct for the production domain.

Review general staging guidance