Cloning a WordPress Site – Dev, Staging, and Production

Cloning a WordPress site means making a complete copy somewhere else. Reasons include: creating staging to test changes, moving to a new hosting provider, building a local development copy, spinning up a new site that starts as a copy of an existing one. The mechanics are similar across all cases — copy files, copy database, fix URLs. This guide covers the plugin and manual methods.

Three components to clone

• WordPress files — everything under public_html (or wherever WP lives). Themes, plugins, uploads, core files.
• Database — all of WordPress’s content lives here.
• URL references — site URL hardcoded in many database tables. Must update to match new location.

Miss any of these and the clone won’t work properly.

Method 1: All-in-One WP Migration plugin

Best for: most users, sites under 512MB (free tier limit).

Source site

1. Install plugin “All-in-One WP Migration.”
2. Tools → Export → Export to → File.
3. Wait for export. Download the .wpress file.

Destination site

1. Install fresh WordPress at destination.
2. Install All-in-One WP Migration plugin.
3. Tools → Import → File → upload .wpress file.
4. Wait. Plugin replaces everything — files, database, URLs.
5. Re-save permalinks (Settings → Permalinks → Save).

Free tier limit 512MB. For larger sites, premium addon or another method.

Method 2: Duplicator

Best for: larger sites, more control.

Source site

1. Install plugin “Duplicator.”
2. Duplicator → Packages → Create New.
3. Plugin scans site, gives warnings about large files.
4. Build package. Wait — large sites take minutes.
5. Download two files: archive.zip and installer.php.

Destination site

1. Create empty database in cPanel MySQL.
2. Upload archive.zip and installer.php to destination’s public_html (or relevant directory).
3. Visit https://destination.com/installer.php.
4. Wizard walks through: extract archive, install database, replace URLs.
5. Delete installer files after completion.

Duplicator handles URL replacement automatically. More robust for complex sites.

Method 3: Manual via cPanel

Best for: full control, very large sites, when plugins fail.

Step 1: Copy files

Source server, cPanel → File Manager → public_html → select all → Compress → ZIP.

Download the ZIP to your computer. For large sites, FTP/SFTP is more reliable than browser download.

Step 2: Copy database

cPanel → phpMyAdmin → select WordPress database → Export → Quick → SQL → Go. Downloads .sql file.

Step 3: Upload to destination

1. Upload ZIP to destination’s public_html via File Manager.
2. Extract there. Move files up if needed.
3. Create new database at destination cPanel.
4. phpMyAdmin → select new database → Import → upload .sql file.

Step 4: Update wp-config.php

Edit wp-config.php with new database credentials:

define('DB_NAME', 'new_database_name');
define('DB_USER', 'new_database_user');
define('DB_PASSWORD', 'new_password');
define('DB_HOST', 'localhost');

Step 5: Fix URLs

Site references old URL throughout database. Must update.

Easy way: install plugin “Better Search Replace” on destination. Run:

• Search: https://olddomain.com
• Replace: https://newdomain.com
• Select all tables.
• Uncheck “dry run.”
• Execute.

Run again with HTTP variant if site was on HTTP before. Run again for protocol-relative URLs (//olddomain.com).

Critical: DO NOT do this with simple SQL find/replace. WordPress serializes some data; raw SQL replace breaks serialized strings. Better Search Replace handles serialization correctly.

Step 6: Re-save permalinks

Settings → Permalinks → Save Changes. Regenerates .htaccess.

Method 4: WP-CLI

Best for: developers with SSH access.

# On source
wp db export source.sql

# Copy source.sql + files to destination

# On destination
wp db import source.sql
wp search-replace 'olddomain.com' 'newdomain.com' --all-tables
wp cache flush
wp rewrite flush --hard

Fastest method when SSH and WP-CLI are available.

Special considerations

Same server, different domain

For staging on same hosting account: create subdomain (staging.yourdomain.com), point document root to its own folder, clone there. Staging guide.

Local development copy

Tools like Local by Flywheel or LocalWP import .wpress files directly. Easiest path from production to local.

Large site uploads (1GB+)

Browser upload often fails. Use SFTP or extract directly on server via SSH:

cd /home/user/public_html
unzip site-backup.zip

WooCommerce clones

Same process but extra care:

• Set staging WooCommerce to test mode for payment gateways.
• Delete real customer orders from staging if it’s not the same business.
• Sanitize email recipients so staging doesn’t email real customers.

Stripping staging of production data

Staging often shouldn’t have real customer data. After cloning:

• Disable email notifications: plugin “WP Disable Emails.”
• Add password protection: cPanel → Directory Privacy.
• Add noindex robots tag: Settings → Reading → Discourage search engines.
• For commerce: clear orders, customer accounts (or anonymize).

Pushing staging changes back to production

Trickier than initial clone — production has live data you don’t want to overwrite.

• Code only changes (theme, plugins): Copy specific files from staging to production. Don’t touch database.
• Content additions (new pages): Use WordPress Export (Tools → Export) on staging, Import on production.
• Full sync: Sometimes easiest to do work directly on production (with backup), or use specialized plugins like WP Stagecoach / WP Sync DB.

Common issues

“Cloned site loads home but other pages 404.” Permalinks. Re-save Settings → Permalinks.

“Cloned site shows old domain in URL bar after click.” URL replacement incomplete. Run Better Search Replace again, including https/http variations.

“Some pages have broken images / shortcodes.” Image URLs in content or widget data didn’t get replaced. Run Better Search Replace on all tables.

“White screen after migration.” PHP version mismatch between source and destination. Match versions or update wp-config to debug.

“Plugin migration says file too large.” Increase upload_max_filesize and post_max_size in PHP. PHP settings guide. Or use manual method.

Common questions

“Is cloning my site the same as backing it up?” Similar mechanics but different goals. Backup is for restoring this site here. Cloning is for running a copy somewhere else.

“Will SEO be affected by cloning?” Only if duplicate content goes public. Always set staging to noindex.

“How long does cloning take?” Small site under 100MB — 5-15 minutes total. Large WooCommerce site 1GB+ — possibly 1-2 hours.

“Can I clone to a subdirectory of same domain?” Yes — yourdomain.com/staging/. Works the same but URLs include /staging/.

“Does cloning work between cPanel and DirectAdmin?” Yes — WordPress doesn’t care about control panel. Mechanics differ slightly but principles identical.

What’s next

• Staging site setup: WordPress staging.
• Migration to iWebVault: WordPress migration.
• Backup best practices: JetBackup.

Cloning is one of those tasks that feels intimidating until you’ve done it twice. All-in-One WP Migration handles 80% of cases; Duplicator covers another 15%; manual SSH+phpMyAdmin handles the rest. Pick the method matching site size and your comfort level, and the worst that happens is you restore from backup and try again.