Cloning a Site You Own but Cannot Log Into

This is written for people who own the site. You pay the hosting bill, the domain is in your name, or you have inherited the business the site belongs to — and the admin password is gone, or the developer who set it up has moved on. If that does not describe your situation, stop here: hosting-level access to a site you do not own is not a technical problem, it is someone else's property.

With that established, the good news is that hosting access outranks wp-admin. Everything the admin dashboard does, it does by writing files and rows that you can reach directly.

Confirm you actually have the two things you need

A WordPress site is files plus a database. Copying one without the other produces nothing useful.

• File access. SFTP, SSH, or the file manager in cPanel, Plesk or your host's own panel.
• Database access. phpMyAdmin, Adminer, or a MySQL command line over SSH.

The credentials for the database are already on the server — they sit in wp-config.php in the WordPress root, in DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. If you can read that file, you can read the database, and the file itself is worth understanding before you touch anything else.

Try the host's own clone tool first

Before doing any of this manually, look in the hosting panel for staging, clone site or copy to subdomain. Managed WordPress hosts almost all have one, they operate at the account level rather than the WordPress level, and they do not ask for an admin login.

That single button replaces the next four sections. Use it if it exists.

Copy the files

Archive the entire WordPress root — everything from wp-admin and wp-includes through wp-content to wp-config.php and .htaccess. Compress it on the server if you can; downloading tens of thousands of small files over FTP is slow and drops connections.

wp-content is the part that is genuinely irreplaceable: your uploads, themes and plugins. Core files can be replaced from an official release if the transfer damages them.

Export the database

In phpMyAdmin, select the database named in wp-config.php, choose Export, and take a full SQL dump of every table. Over SSH, mysqldump does the same thing more reliably for a large database.

Two things to check on the way out: that the export includes the tables carrying your $table_prefix (it may not be wp_), and that the file is not truncated. A dump cut short by a timeout imports without complaint and leaves you missing content.

Build the clone

1. Create the destination — a subdomain, a staging directory, or a second hosting account. Give it its own empty database and a dedicated database user.
2. Upload and extract the files.
3. Import the SQL dump into the new database.
4. Edit wp-config.php on the copy with the new database name, user and password. This step is the one people forget, and the symptom is an error establishing a database connection.

The clone now exists but still believes it lives at the original URL.

Change the URLs correctly

Every absolute URL stored in the database must be rewritten — in the site options, in post content, in widget and theme settings, and inside page-builder data.

The safe tool is WP-CLI, which understands serialised data:

wp search-replace 'https://oldsite.com' 'https://clone.example.com' --all-tables --dry-run

Run the dry run, read the counts, then run it again without --dry-run. If WP-CLI is not available, use a serialisation-aware search-replace script uploaded to the clone and deleted immediately afterwards. Do not do this with a raw SQL UPDATE across the whole database: serialised PHP arrays record the length of each stored string, and a plain text replacement leaves those lengths wrong. The affected settings then fail to unserialise and revert to defaults, quietly.

As a stopgap to get the clone loading at all, you can override the URLs in wp-config.php with WP_HOME and WP_SITEURL, but that fixes the two options and nothing else.

Get your admin account back

With database access, restoring your own access is straightforward, and there are two supported routes: add a fresh administrator through phpMyAdmin, or reset the existing password. Do this on the clone first — it is the whole point of having a clone — and only then decide whether to repeat it on production.

Finish properly

Log in, flush permalinks by re-saving the permalink settings, clear any caching plugin, and confirm uploads render rather than 404.

Then keep the clone private: block search engines, and put it behind HTTP authentication if the host offers it. A duplicate of your site indexed publicly is a real SEO problem, not a theoretical one.

Finally, treat this as the prompt to fix the underlying gap — take a proper backup on a schedule and store the hosting credentials somewhere that survives a staff change. If the end goal is moving the site rather than duplicating it, continue with migrating to a new host.