How to Clone a WordPress Site Without a Plugin, in 30 Seconds of Clicks

Published September 6, 2026

Every guide to duplicating a WordPress site starts by telling you to install a plugin. That advice was written for shared hosting where you have no other option, and on a site of any size it is the slowest and most fragile route available.

There is a better one, and if your host offers it you already have it. This article is about what copying a WordPress site actually involves, why the plugin route struggles with it, and how to do it in about thirty seconds of your own time.

Your part

About 30 seconds of clicks

The server’s part

Usually a minute or two

Files through your browser

None

Effect on the original

None — it is only read

Why the Plugin Route Struggles

A migration or duplicator plugin has to do everything from inside PHP, inside a web request, which is a bad place to copy a few gigabytes from. Four things go wrong, in roughly this order as the site grows:

• The archive build times out. Zipping the site is PHP work, and PHP has a maximum execution time. Good plugins get around this by chunking the job across many requests, which works — until one of the chunks lands on a slow moment and the whole run has to start again.
• Memory. Serialising a large database inside PHP costs memory that your plan does not have spare, and the failure often is not an error message. It is a white page, a half-written archive, or an export that looks complete and is not.
• The file goes through your laptop. The classic route is: the server makes a 400 MB archive, you download it over your home connection, then upload it to the destination. That is two transfers of the same bytes across the slowest link in the chain, to move a file between two directories that may be on the same disk.
• Then it has to rewrite every address inside the database, which is the part that quietly breaks things. More on that below, because it is the interesting bit.

None of this makes those plugins bad. On hosting with no server-side copy, they are the only answer and they are impressively good at a hard job. But if the copy can be made on the server, none of the four problems exists: no archive, no PHP time limit, no browser, and the files never leave the machine.

What Copying a WordPress Site Really Involves

Worth knowing even if a button does it for you, because it tells you what can go wrong. A WordPress site is three things, and a copy is not complete until all three have moved:

1. The files

   WordPress core, your theme, your plugins and — nearly always the largest part — the uploads directory. On the server this is a straight file copy. Done properly it also excludes the junk: cache directories, and the backup archives that backup plugins leave inside the site, which is how people end up with a copy twice the size of the original.

2. The database

   Every post, page, comment, user, setting and plugin option. Copied schema and all, into a new database with its own name and its own credentials — which then have to be written into the new site’s wp-config.php, or the copy quietly runs against the original’s database. That is a genuinely dangerous failure: you edit the copy and the live site changes.

3. Every address stored inside the database

   This is where copies go wrong, and it is the next section.

The Four Shapes of a URL, and Why a SQL Find-and-Replace Breaks Sites

WordPress stores its own address in the database — not just once in the settings, but scattered through post content, menus, widget configurations, page-builder layouts and plugin options. A copy that does not rewrite all of them is a site that loads and then sends every visitor back to the original.

The obvious approach is to open the database dump in a text editor and replace oldsite.com with newsite.com. Do not do this. It will appear to work and it will break your widgets, your page-builder layouts and any plugin that stores structured settings.

The reason is serialization. WordPress stores structured data as strings that carry their own length, like this:

s:19:"https://oldsite.com";

That 19 is the number of characters PHP expects to find. Replace the domain with a longer or shorter one and the string is now 19 characters according to the label and 21 in reality. PHP refuses to unserialize it, the plugin gets false instead of its settings, and your widget area is empty for no visible reason. Nothing errors. It just silently forgets.

Doing it properly means walking the serialized structures and rewriting the values with their length prefixes recalculated — which is what WP-CLI’s search-replace does, and what any competent server-side copy uses. And it means covering four shapes of the same address, because a WordPress database holds all four:

Miss the third and your page builder’s background images vanish. Miss the fourth and any block storing its settings as JSON keeps pointing at the old site. This is the difference between a copy that works and a copy that mostly works, and it is why “I’ll just do a find and replace” is the single most common way a duplicated WordPress site ends up subtly wrong.

Doing It From the Panel

On HostCrafter this is a button, and everything above happens on the server without a file passing through your browser.

1. Open the site’s row and choose Clone

   In Websites, click the row of the site you want to copy — the row expands and every action is labelled.

   

2. Choose where the copy goes

   Domains already parked on your account with nothing on them are offered first, and using one of those costs no extra website slot. A domain that is new to the account takes a slot.

   

3. Leave it running

   Typically a minute or two, longer for a site with a large uploads directory. The original is only read from — nothing about it changes, and it stays online throughout.

The click-by-click version, with every dialog and the five things to check afterwards, is in the knowledge base: how to clone a WordPress site in one click.

What a Clone Cannot Bring With It

A copy is a copy of your site. It is not a copy of the world your site lives in, and these are the things that catch people out:

• Licences tied to a domain. Premium themes and plugins — page builders, form plugins, WP Rocket — are usually licensed per site. The copy will run; it will not update itself, and some will not activate their features at all until they are licensed.
• Anything keyed to the domain at a third party. Analytics, Search Console, ad network approvals, reCAPTCHA keys, payment gateway webhooks. All of them point at the old hostname.
• Email. Mailboxes belong to the domain, not the site. A cloned site sending mail from a new domain has new deliverability to earn — new SPF, DKIM and DMARC records, and no sending reputation.
• Search engine identity. The copy is a different site to Google. If the two are publicly reachable with the same content, that is duplicate content competing with itself — keep the copy out of search until you have decided which one is the real one.
• Scheduled jobs mid-flight. A copy inherits every scheduled task in the database, so a newsletter plugin can cheerfully send from both sites. Check that before you leave it running.

Clone, Staging or Migration?

Three different tools that all copy a site, and picking the wrong one wastes an afternoon.

The short version: if the change is meant to end up on the original site, you want staging, not a clone. Cloning is for when you want two sites at the end.