Clone a site safely by copying into an isolated staging target, separating secrets and external integrations, checking every URL and database reference, and only then promoting the tested copy.
Inventory source and destination
Write down the source domain, application version, runtime requirements, database engine, scheduled jobs, upload directories, and external services. Give the destination a temporary host name and an explicit staging label. A site clone should be traceable to its source and should not share an unclear document root with another lander.
Copy data without copying side effects
Copy application files and the database through a method appropriate to the software, then review configuration files before starting the clone. Replace absolute URLs, callback addresses, cookie domains, and upload paths for the staging host. Disable production webhooks, payment callbacks, email delivery, queue workers, and scheduled publishing until the destination has test endpoints. Preserve only the sample records needed to reproduce the issue and remove unnecessary personal data.
Rotate and separate credentials
Do not reuse production API keys, database passwords, signing secrets, or administrator sessions in staging. Create test credentials with the smallest useful scope, store them outside the document root, and rotate them after a clone has been shared. Check analytics and advertising identifiers as well; otherwise a staging visit can pollute production reports or trigger a real campaign.
Check permissions and dependencies
Review file ownership, writable directories, runtime extensions, cron definitions, and cache directories on the destination. Keep uploads and generated files separate from application code. Confirm that the clone uses the intended PHP version and database connection through the hosting interface, without assuming that a source configuration matches every target account.
Compare the clone with the source
Use a short checklist and a representative URL set to compare status codes, page titles, canonical links, forms, assets, and cache headers. Check that scheduled tasks are either disabled or pointed at test services, and record any intentional differences. An audit note with the clone date, source revision, test owner, and open issues makes later cleanup much easier.
Verify before promotion
Test login, forms, redirects, canonical URLs, outbound links, error handling, cache invalidation, and mobile rendering. Compare a representative page with the source and inspect browser developer tools for mixed content or failed requests. Keep the old version available until the new one has passed the agreed checks. The multi-site guide explains when isolation justifies separate accounts; use a support ticket when a cloning question depends on your particular application.