Clone a WordPress Website in 7 Simple Steps

To clone a WordPress site, you copy two things, its files and its database, to a new location, then update every stored URL so the copy points at its new address. That’s the whole job in one sentence. The seven steps below show how to do it safely, whether you use a migration plugin, your host’s staging tool or the manual route with WP-CLI.

Why you might clone a WordPress site

A clone is an exact working copy of a site: same content, same theme, same plugins, same settings. People make one for three main reasons:

• A staging site. You want to test a big plugin update, a new theme or a redesign without touching the live site. You work on the copy, check it, and only then make the same change on the real thing.
• Moving to a new host. The site stays on the same domain but moves to a different server, perhaps for better speed, support or price.
• A new domain. You’re rebranding, or launching a second site that starts from the first one’s design and setup.

The method is nearly the same in each case. What changes is the last step: a staging copy stays hidden from visitors and search engines, while a host move or domain change ends with pointing real traffic at the new copy.

What a WordPress clone is made of

Every WordPress site has two halves, and a clone needs both.

• The files: WordPress itself, your themes and plugins, and the wp-content/uploads folder with all your images and documents. The wp-config.php file is here too; it tells WordPress which database to use.
• The database: your posts, pages, menus, users, comments, widget and plugin settings and, on a shop, your products and orders.

Copy only the files and you get an empty installation. Copy only the database and you get content with no theme, plugins or images. Most cloning problems come down to one half missing, or to the database still pointing at the old address.

1Back up the original site first

Before you copy anything, take a full backup of the site you’re cloning: files and database, stored somewhere other than the web server. Cloning reads from the original, so in theory it can’t harm it. In practice, people run a search-replace on the wrong database, overwrite the live site while importing, or click “restore” on the wrong tab. A fresh backup turns any of those mistakes into a short delay instead of a disaster.

While you’re there, note a few details you’ll need later: the WordPress and PHP versions, the table prefix in wp-config.php (often wp_, but not always), and the exact site address under Settings → General, including whether it uses https:// and www.

2Choose how to clone your WordPress site

There are three common ways to clone a WordPress site. All of them do the same work under the hood; they differ in how much of it they do for you.

The plugin route

A migration plugin packs your files and database into an archive on the old site, then unpacks it on the new one and updates the URLs for you. A few widely used options on WordPress.org:

• Duplicator builds a “package” (an archive plus an installer script) that you upload to the destination and run in the browser. It has a free version on WordPress.org.
• All-in-One WP Migration exports the site to a single file that you import on a fresh WordPress installation through its import screen. It also has a free version on WordPress.org.
• Sitecarry is a free WordPress.org plugin by Dotance for backing up, cloning and migrating WordPress sites.

Each plugin has its own workflow, and features or limits on archive size can change between versions, so check the plugin’s WordPress.org page before you start. Whichever you pick, install it from the official directory, keep it updated, and delete any archives or installer files it leaves on the server when you’re done. A downloadable backup sitting in a public folder is a gift to anyone who finds it.

The manual route

The manual route means copying the files over SFTP or SSH, exporting the database yourself, editing wp-config.php, and replacing URLs with WP-CLI. It takes longer the first time, but it has no archive size limits and you can see exactly what happens at each stage. Steps 3 to 6 below follow this route, and they’re worth reading even if you use a plugin, because they explain what the plugin is doing for you.

Host staging tools

Many managed WordPress hosts offer a staging feature in their control panel. One click copies the live site to a private staging address, and some can push changes from staging back to live. If you only need a test copy on the same host, this is usually the quickest and safest option. Check your host’s documentation for how it handles the database when you push back, because a push can overwrite orders or form entries that arrived on the live site in the meantime.

3Export the files and the database

For the files, download the whole WordPress folder over SFTP, or compress it on the server first if you have SSH access, which is much faster for big media libraries:

tar -czf site-files.tar.gz -C /path/to/wordpress .

For the database, you have two common choices. In phpMyAdmin, select the site’s database, open the Export tab and download an SQL file. With WP-CLI, run this from the WordPress folder:

wp db export site.sql

On a busy shop, put the site into maintenance mode or pick a quiet time, so no new orders arrive between the export and the switch-over.

4Create the destination

The copy needs somewhere to live. On the new host, staging subdomain or new domain:

1. Create an empty database and a database user with full rights on it. Write down the database name, user, password and host.
2. Make sure the server runs a PHP version your theme and plugins support, ideally the same version as the original.
3. Point the domain or subdomain at the right folder, and switch on an SSL certificate if the host allows it before DNS moves (many hosts offer free Let’s Encrypt certificates once the domain resolves to them).

If you’re using a plugin that imports into an existing site, install a fresh WordPress here instead and then install the plugin.

5Import the files and database

Upload the files to the new folder and unpack them. Then import the database, either through the Import tab in phpMyAdmin or with WP-CLI:

wp db import site.sql

Now open wp-config.php on the new copy and update the database details to match what you created in step 4:

define( 'DB_NAME', 'new_database' );
define( 'DB_USER', 'new_user' );
define( 'DB_PASSWORD', 'new_password' );
define( 'DB_HOST', 'localhost' );

$table_prefix = 'wp_'; // must match the prefix in the imported tables

The $table_prefix must match the tables you just imported. If it doesn’t, WordPress can’t find your content and shows the installation screen instead. DB_HOST is often localhost, but some hosts use a separate server name, so check their panel.

6Search and replace the old URLs

This is the step that makes or breaks a clone. WordPress stores full URLs in the database: the site address, links inside posts, image paths, menu items and many plugin settings. Until you change them, the copy keeps sending visitors (and you) back to the old site.

The catch is serialized data. Many settings are saved as PHP serialized strings, which record the length of every text value. Swap old-site.com for new-site.co.uk with a plain SQL REPLACE or a text editor and those lengths no longer match, so WordPress silently throws the setting away. Widgets disappear, page builder layouts break and theme options reset.

WP-CLI’s wp search-replace command understands serialized data and fixes the lengths as it goes. Always do a dry run first:

wp search-replace 'https://old-site.com' 'https://new-site.co.uk' --all-tables --skip-columns=guid --dry-run

Read the report, check that the numbers look sensible, then run it again without --dry-run. A few tips:

• Include the protocol (https://) so you don’t accidentally change email addresses or unrelated text.
• If the old site was reached both with and without www, or over http:// as well, run a replacement for each variation.
• --skip-columns=guid leaves post GUIDs alone, which the WordPress documentation advises for live sites because feed readers use them as permanent IDs.

The official wp search-replace reference lists every option, and WordPress’s own guide to moving WordPress covers the wider process. If you can’t use WP-CLI, use a tool that is built to handle serialized data rather than editing the SQL file by hand.

7Test the clone, then switch DNS and SSL

Log in to the copy and work through it as a visitor would, before anyone else sees it:

• Open the home page, a few posts and pages, and any page built with a page builder.
• Check that images load from the new address, not the old one.
• Submit a test form, and on a shop, run a test order through checkout.
• Look under Tools → Site Health for errors such as a missing PHP extension.
• Clear every cache: plugin, server and CDN. A stale cache can make a working clone look broken. Our guide on how to clear WordPress cache walks through the usual places.

For a staging copy, you’re done: keep it private. For a host move or new domain, one more stage remains. Lower your DNS records’ TTL a day ahead if you can, then point the domain’s A record (or nameservers) at the new host. Once DNS has moved, confirm the SSL certificate is active and that Settings → General shows https:// for both addresses. For a new domain, set up 301 redirects from the old domain’s URLs to the matching new ones, so visitors and search engines follow you.

Common mistakes when you clone a WordPress site

Most broken clones fail in the same few ways. Check for these before you call the job finished.

Mixed content warnings

The page loads over https://, but some images, scripts or stylesheets still load over http://. Browsers block or flag that, and the padlock disappears. It usually means the search-replace missed the http:// version of the old address, or a URL is hard-coded in a theme file or custom CSS. MDN’s page on mixed content explains what browsers do with it. Your browser’s developer console lists each offending address.

Every page except the home page returns a 404

This is almost always permalinks. On Apache, the .htaccess file holding WordPress’s rewrite rules may not have been copied, because files starting with a dot are hidden by many FTP clients. Go to Settings → Permalinks and click Save Changes without changing anything; that regenerates the rules. With WP-CLI, wp rewrite flush --hard does the same. On Nginx, the rewrite rules live in the server configuration instead, so ask your host.

Search engines still blocked, or a staging site in Google

Staging copies should have Settings → Reading → Discourage search engines from indexing this site ticked, and ideally password protection too. The mistake is carrying that setting across to the new live site, which quietly tells search engines to stay away. After a move, check that box is unticked on the live site, and ticked on any staging copy.

Emails and scheduled tasks firing from the copy

A full clone also copies your scheduled tasks, so a staging site can send real order emails, newsletters or reminders to customers. On staging, turn off outgoing email or use a mail-logging plugin, and pause anything that talks to a payment gateway or external service in live mode.

Leftover archives and installer files

Backup archives, SQL dumps and installer scripts left in the web root can be downloaded by anyone who guesses the name. Delete them from both servers once the clone works. Our WordPress security tricks cover more habits worth checking on a freshly moved site.

The bottom line

To clone a WordPress site safely, back it up, copy both the files and the database, point wp-config.php at the new database, replace the old URLs with a tool that understands serialized data, and test everything before DNS moves. A host staging tool or a migration plugin does most of this for you; the manual route with WP-CLI gives you full control. Either way, the clone is only finished when the mixed content, permalinks and search engine setting have been checked.

Frequently asked questions