To clone a WordPress site, you copy two things, the files and the database, into a new location, then tell the copy its new address. The easiest route is your host’s staging button, which does all of it in one click on Hostinger, SiteGround, Kinsta, WP Engine, Flywheel and most managed hosts. Second easiest is a plugin such as Duplicator or UpdraftClone, which packages the site into an archive you install elsewhere. The manual method (export files by FTP, export the database, import both, search-and-replace the URL) is what those tools automate, and it is worth knowing for the day a plugin fails. All three are below, plus the mistakes that make a clone leak into Google or overwrite the live site.
Why clone a WordPress site?
| Reason | What the clone is for | Where it should live |
|---|---|---|
| Staging | Test plugin and core updates before they hit the live site | A staging subdomain on the same host, blocked from search engines |
| Redesign | Rebuild the site with the new theme while the old one keeps running | Staging, then pushed live or migrated with redirects |
| Migration | Move to a new host or a new domain | The new server; see the domain change guide for the redirect side |
| Local development | Work offline with full control | Local by Flywheel, DevKinsta or a similar local environment |
| Template | Reuse one build as the starting point for another client | A fresh install from the archive, then find-and-replace the content |
The first row is the one every business site should have. Updates on staging first is most of what WordPress maintenance means in practice.
Method 1: clone with your host’s staging tool
- Log in to the hosting panel (hPanel, Site Tools, MyKinsta, the WP Engine User Portal).
- Open the site, find Staging and click Create staging (names vary). The host copies files and database to a subdomain such as
staging.yoursite.comand rewrites the URLs. - Log in to the staging site with the same credentials and work there.
- When finished, use Push to live (or Deploy) and choose whether to push files, database, or both. Pushing the database overwrites live orders, comments and form entries created since the clone, so on a shop push files only and repeat content changes by hand.
Most hosts set the staging copy to discourage search engines, and some password-protect it; that is the step people forget on the manual route.
Method 2: clone with a plugin
- Duplicator (free): Duplicator, Backups (Packages in older versions), Create New, Build. Download the archive and the installer.php, upload both to the new location, open
newsite.com/installer.php, enter the new database details, and the installer unpacks the site and replaces URLs. Free version handles most sites under a few hundred MB. - UpdraftClone: from the UpdraftPlus plugin, creates a temporary clone on UpdraftPlus servers with a token, useful for a quick test without touching your host. UpdraftPlus’s clone guide covers the tokens and limits.
- All-in-One WP Migration: export to a single file, install the plugin on a fresh WordPress at the destination, import. Free version has an upload size limit that many sites exceed.
- WP Migrate: the developer’s choice for pushing and pulling databases between environments, paid.
Every plugin route starts with a working backup; where WordPress backups are stored explains where to find the one your host already makes.
Method 3: clone manually
- Copy the files. Download the whole WordPress folder by FTP or the host’s file manager (wp-admin, wp-includes, wp-content, and the root files including
.htaccessandwp-config.php). Uploads folders are the slow part; a host’s file manager zip is faster than FTP. - Export the database. phpMyAdmin, select the database, Export, Quick, SQL. Or over SSH:
wp db export. - Create the destination. A new database and user at the new host, and upload the files to the new folder.
- Edit wp-config.php in the copy with the new database name, user, password and host.
- Import the database into the new one via phpMyAdmin Import, or
wp db import file.sql. - Replace the URL. Over SSH:
wp search-replace 'https://oldsite.com' 'https://staging.oldsite.com' --all-tables. Without SSH, the Better Search Replace plugin does the same from the dashboard. Plain find-and-replace in the SQL file breaks serialised data; use one of these. - Flush permalinks (Settings, Permalinks, Save) and log in to check pages, images and forms.
The WordPress.org migration handbook covers the same steps with the edge cases (multisite, changing table prefixes, moving between directories).
What must you do to every clone?
- Block search engines. Settings, Reading, tick Discourage search engines, and ideally password-protect the folder at the host. An indexed staging site creates duplicate content that competes with the live one.
- Disable emails and payments. A cloned shop with live payment keys can charge real cards; a cloned site with a mail plugin can send real customers test emails. Switch WooCommerce to test mode and disable mail on the clone.
- Stop scheduled tasks that post, sync or notify (newsletters, social auto-posting, backup uploads to the same bucket).
- Label it. A different admin colour scheme (Users, Profile) so nobody edits staging thinking it is live, which happens more than anyone admits.
- Delete it when done, or keep it patched; an abandoned clone is an unpatched WordPress install on your domain, which is how sites get hacked through a door nobody remembered.
Clone, staging, backup, migration: which word means what?
| Term | Meaning |
|---|---|
| Backup | A stored copy for restoring the same site; not running |
| Clone | A running copy of the site at another address |
| Staging | A clone used for testing, usually on a subdomain, hidden from search |
| Migration | Moving the site so the clone becomes the live site and the original is retired, with redirects if the address changed |
A migration is a clone plus redirects plus DNS, and the redirect part is what changing a WordPress domain is about. Staging is the routine version and the one I set up on every WordPress build before handover, because a client with a staging button stops being afraid of the update screen.
Frequently asked questions
Use your host’s staging tool if it has one, or a plugin such as Duplicator to package files and database into an archive you install at the new location. Manually, copy the files by FTP, export and import the database, edit wp-config.php, and search-and-replace the old URL.
Yes. Duplicator’s free version and the manual FTP and phpMyAdmin method cost nothing, and many hosts include one-click staging in their plans. UpdraftClone is paid per clone.
Create the subdomain and a new database at your host, copy the files into the subdomain folder, import the database, update wp-config.php, and run a search-and-replace from the old URL to the subdomain URL. Then set the copy to discourage search engines.
Only if Google indexes the copy. Keep the clone hidden and it has no effect; if a staging site does get indexed, add noindex and request removal in Search Console.
Cloning makes a second running copy; migrating moves the site so the copy becomes the live one, with DNS changes and redirects if the domain changed. Every migration starts with a clone.
Yes, but put the clone’s payment gateways in test mode, disable order emails, and never push the staging database back over the live one, or you overwrite real orders placed since the clone was made.
