Duplicating a WordPress site safely

The safest way to duplicate a WordPress site is with staging tools if you only need a working copy to test on, or a dedicated migration plugin if you need a real standalone copy at a new location. A raw file copy plus database export works too, but only if you handle serialized data correctly, most manual clones break because of that one detail.

"Duplicate" can mean two different things: a temporary sandbox copy of a live site, or a permanent second site (new domain, subdomain, or separate hosting account). The right method depends on which one you actually need.

Option 1: staging, for temporary copies

If you're duplicating a site to test something, a plugin update, a theme switch, custom code, you don't need a real duplicate. You need a staging copy. See using WordPress staging for the full workflow: clone to a private non-public location, make changes, test, then push the verified changes back to live.

Staging is not what you want if the goal is a second, independently running site. It's built to be temporary and eventually merged back or discarded.

Option 2: migration plugin, for a real second site

When you need an actual standalone copy, same site, new domain or new location, a migration plugin handles the file copy, database export, and URL rewriting in one pass. This is the same problem as moving a site, so the tools overlap:

• All-in-One WP Migration: exports the full site (files, database, plugins, themes) as a single archive, then imports it at the destination. Free tier caps import size; extensions remove the cap.
• Duplicator: builds an installer package plus an archive. Good when the destination is a fresh WordPress install you're pointing at your export.

Either way, the plugin rewrites URLs in the database as part of the import, so you land on the new domain without a broken site. That's the main advantage over a manual copy.

Option 3: manual clone, and the serialized-data trap

A manual duplicate is two steps: copy the files (wp-content, wp-config.php, core files) to the new location, then export and import the database. It works, but the database export is where manual clones usually go wrong.

WordPress stores some settings as serialized PHP data, strings with an embedded length count, like a:2:{s:3:"url";s:19:"https://old.com/x";}. Widget settings, some theme options, and various plugin configs use this format. If you open the SQL export in a text editor and do a plain find-and-replace on the domain, you change the string length but not the length count embedded in it. WordPress can no longer parse the value, and that setting silently breaks, missing widgets, blank theme options, plugin settings reverting to defaults.

This is the exact problem changing your WordPress site's domain covers in detail, since a manual clone to a new domain is really a domain change plus a copy. The fix is the same: use a tool that understands serialized data instead of a raw text replace.

Doing it safely

1. Copy the files to the new location (via FTP, or the Files tile in the portal if both sites are on the same hosting account).
2. Export the database from the source site.
3. Create a new, empty database at the destination and import the export.
4. Update wp-config.php at the destination with the new database name, user, and password.
5. Install the Better Search Replace plugin (or run wp search-replace if you have shell access) on the new site and replace the old domain with the new one across all tables. Run it as a dry run first, then for real.
6. Log in to wp-admin at the new site and confirm Settings → General shows the correct URLs.

Skip the raw SQL text editor entirely. Either a search-replace tool or wp search-replace handles serialized strings correctly by recalculating the length prefixes, a plain text editor or basic SQL REPLACE() does not.

If you're duplicating for multiple sites on one account

If the end goal is running several independent WordPress sites under one hosting account rather than one duplicate, skip the clone entirely and use the install wizard per site instead. See multiple WordPress sites on one hosting account, each gets its own directory, database, and admin from a clean install, which sidesteps the serialized-data issue altogether since there's nothing to duplicate.

Before you clone anything

Take a fresh backup of the source site first, regardless of which method you use. See backing up your WordPress site. If a migration plugin or manual export goes wrong partway through, you want a clean point to restart from rather than a half-migrated source site.

When to contact support

If a database import fails, the new site won't load after a search-replace, or you're not sure whether serialized data broke something, open a ticket from Support → New ticket in the portal. Live chat works too for faster back-and-forth. A real person can check server-side logs and database state that you can't see from wp-admin alone.