How to clone WordPress sites

Decide whether the clone will use a new domain, subdomain, server, or local development URL. Put the target into maintenance mode if visitors or customers could reach it while you work. For WooCommerce, pause order processing or clone from a staging copy so new orders are not missed.

Record the source URL, database name, database user, table prefix, PHP version, and any special server settings. A clone is a full copy, not a WordPress export: the database and the wp-content files both matter.

Back up the entire WordPress directory, including wp-content/uploads, themes, plugins, and any custom files, then export the complete WordPress database. WordPress documents both the files and database as necessary parts of a move.

Keep the backup outside the hosting account and do not delete the source until the clone has been checked. If the source is busy, take the database export and file copy as close together as possible to reduce the chance of mismatched content.

Create the target database and database user, then grant that user access. Upload the copied WordPress files to the target document root and import the database through the host’s database tool or command line.

Do not assume the table prefix is wp_; retain the prefix used in the exported database. If the target server uses different database credentials, edit the copied wp-config.php so its database name, user, password, host, and table prefix match the target.

When the target uses a different domain or path, replace the old site URL throughout the database. Use a serialization-aware method rather than a basic SQL REPLACE(): WordPress settings, widgets, theme options, and page-builder data can contain PHP-serialized values whose stored lengths must be updated.

With WP-CLI, run a dry run first, then use wp search-replace 'https://old.example' 'https://new.example' --skip-columns=guid from the target site directory. WP-CLI handles serialized data and provides a dry-run option; multisite installations need the appropriate network option.

Check that the target’s home and siteurl values point to the new address. WordPress identifies these values as part of the move, and they can be updated in the database or with WP-CLI if the dashboard is inaccessible.

Log in, visit Settings → Permalinks, and save the settings once to refresh rewrite rules. Clear WordPress, plugin, server, and CDN caches. If the site shows blank pages, redirect loops, missing images, or a three-slash URL such as https:///, check the URL replacement and database connection before changing files at random.

Check the homepage, several posts and pages, media files, forms, user login, search, menus, scheduled tasks, and any integration that sends email or uses an API. For WooCommerce, inspect products, checkout, payment settings, webhooks, and order emails before making the copy public.

Confirm that the clone cannot accidentally send production emails, process real payments, or connect to production services. Keep the source backup until the target has passed these checks. For a one-off clone, this manual route is usually sufficient; the main drawbacks are the file transfer, database import, URL replacement, and troubleshooting all being your responsibility.

For the fast route, use MainWP Clone when you manage several WordPress sites or regularly replicate a working setup. It is designed to clone a full site, including themes, plugins, settings, content, and media, from a MainWP-managed workflow, with backup and activity-log features for the process.

Install and activate it on the relevant WordPress sites, connect the source and target through MainWP, and follow its clone workflow. Still verify the target URL, database access, cache, email, payments, and external integrations after the copy. A cloning plugin removes much of the repetitive work, but it does not remove the need to check a live clone before handing it over.