To clone a WordPress site, copy its files and database to a separate destination, then update settings and test the copy. You can use a migration plugin such as Duplicator to package and deploy the site, or use a host’s staging tools if they handle the setup for you. The steps below follow Duplicator’s package-and-installer workflow; menu labels and options can vary by plugin version and hosting setup.
What a WordPress clone includes
A clone is a working copy of the site’s WordPress files and database installed at a separate location. That location might be a staging address, another domain, a different directory, or a new host. Duplicator describes its plugin as a way to move sites, create backups, or clone a site for staging (WordPress.org: Duplicator).
A file-only copy is not enough: WordPress also needs the database that stores posts, settings, user accounts, and other content. If the clone uses a different domain or path, the relevant URLs must be updated too.
Before you begin
- Make a fresh backup. Confirm that you can access the source site and have a recoverable backup before changing either installation.
- Choose and prepare the destination. For a new host or domain, arrange hosting access, an empty destination directory, a database, and a database user. The classic Duplicator workflow asks for destination database connection details (Duplicator Classic Installation guide).
- Protect any existing destination. If the destination already contains a site, back it up before replacing it. Deployment may overwrite destination files or data.
- Check access and capacity. You may need the WordPress administrator account, hosting file access such as FTP or a file manager, and database credentials. For a large site, confirm that the host can handle the archive upload and extraction.
How to clone a WordPress site in 7 steps
1. Back up the source and confirm access
Create a current backup of the source site and verify that you can reach its WordPress dashboard and hosting account. Keep the backup separate from the destination you plan to overwrite, so it remains available if deployment fails.
2. Prepare the destination
Create or select the target location: a staging site, a directory on the same host, or a site on a new host or domain. For the classic Duplicator method, the target should have an empty directory and a database with a user that has permission to use it. Record the database name, username, password, and host value supplied by your hosting provider.
3. Build the clone package
In the source site, use Duplicator to create a package. It bundles the WordPress files and database into an archive and provides an installer file. The exact dashboard labels can differ between versions; follow the plugin’s current package-building prompts. Duplicator’s installation documentation describes the classic migration as a package-and-installer deployment (Duplicator Classic Installation guide).
4. Transfer the package
Upload both the archive and the installer file to the prepared destination directory using FTP or your host’s file manager. Make sure they are in the directory where the clone should run, rather than in a nested folder by mistake.
5. Run the installer
Open the installer at the destination using the URL and filename provided by the plugin, then follow its validation and deployment prompts. Enter the destination database details when requested. Read any warnings before proceeding, especially if the installer reports a database or file conflict. The installer imports the database and deploys the site files; do not treat a successful upload alone as a completed clone.
Rank #3
6. Update URLs and environment settings
When the clone uses a different domain or path, make sure WordPress points to the new location and that stored references to the old address are replaced appropriately. WordPress identifies siteurl and home in the wp_options table as key URL settings (WordPress Developer Handbook: wp-config.php; WordPress Developer Handbook: wp-config.php API). A migration tool can handle URL replacement as part of deployment; avoid manually changing serialized database values with a plain text search-and-replace, which can damage stored data.
7. Test the clone and remove installer files
Visit the destination and check that the dashboard and front end work. Test representative pages, images, links, forms, plugins, and theme behavior; confirm SSL if the destination uses HTTPS. Once deployment is verified, remove the installer and archive files from the server. Leaving migration files in a public directory is unnecessary and can expose sensitive site data.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choosing a cloning method
Duplicator’s package-and-installer approach suits a move to a new host or domain and can also be used to create a staging copy. WP STAGING is another option when the main goal is creating a test copy or staging site; its WordPress.org listing describes cloning for testing, development, or as a safety net (WordPress.org: WP STAGING). Managed hosting may offer staging creation and migration support, reducing the need to configure the destination yourself.
| Option | Useful when | Destination setup and access |
|---|---|---|
| Duplicator package and installer | You want to deploy a package to staging, another domain, or a new host. | The classic workflow requires a destination directory and database details; transfer uses FTP or a host file manager. |
| WP STAGING | Your priority is making a separate copy for testing or development. | Exact access requirements and transfer capabilities depend on the plugin version and workflow; check its current documentation before choosing it for a host-to-host move. |
| Managed-host staging or migration | You want the host to provide destination setup or migration assistance. | Available tools and support depend on the host and hosting plan; confirm whether it supports the domain, site size, and workflow you need. |
Before committing to any method, check its current support for large packages, URL replacement, multisite, backups, rollback, and the destination you intend to use. These capabilities can vary by plugin version, plan, and host.
Quick Recap
If the clone does not work
- Installer cannot connect to the database: Recheck the database name, username, password, host, and user permissions with your hosting provider.
- The old site appears at the new address: Check the WordPress
homeandsiteurlvalues and whether migration URL replacement completed. - Pages load but images or links fail: Inspect media URLs and internal links for references to the source domain, then correct them using a migration-safe replacement method.
- The installer reports file or database conflicts: Stop before overwriting anything you need. Preserve the destination backup, confirm you are in the intended directory and database, then resolve the conflict or choose a clean destination.
- The site works but behaves differently: Test plugins, forms, theme features, and HTTPS individually; differences in server configuration or SSL setup can affect the copy.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
