Yes, and technically it is not difficult. You transfer the files, the database, and the configuration, and tools automate most of the work. The catch is that copying files is half the task. The other half is deciding whether you are moving the site or duplicating it, because those two scenarios have opposite requirements. A move needs 301 redirects and a change of address in Search Console. A duplicate needs the reverse: indexation blocked, so the copy does not start competing with the original.
First decide: are you moving or duplicating?
These two get confused more than anything else in this area, and the cost of confusing them is high.
Moving is a permanent change of address. A rebrand, a new domain, a brand consolidation. The old address falls out of use, and everything it has earned in search has to be passed to the new one.
Duplicating means creating a copy for development purposes: a staging environment, a pre-production version, a copy for a rebuild. The original stays and keeps working.
The requirements point in opposite directions:
| Moving | Duplicating | |
|---|---|---|
| 301 redirects | required, URL by URL | must not be set |
| Indexation of the copy | wanted | blocked |
| Search Console | submit a change of address | separate property or none |
| Old domain | kept and redirecting | untouched |
The most expensive common mistake is leaving a staging copy open to crawlers. The search engine then indexes two identical versions of the site, and it does happen that the copy at staging.example.com is the one left in the results. Recovering from that takes weeks.
How to copy the site technically
The simplest route is a migration plugin. You install the tool on the source site, build a package containing the files and database, then restore it at the destination. Duplicator, All-in-One WP Migration, and UpdraftPlus all handle this, though free versions cap package size.
On larger and more complex sites, plugins fail because the package does not fit within script execution limits. The standard then is WP-CLI: export the database, move the files over SSH, and replace URLs with wp search-replace.
The manual route means exporting the database through phpMyAdmin, moving files over FTP, importing the database, updating wp-config.php, and replacing URLs in the database. If the goal is running several sites rather than moving one, see can multiple WordPress sites use the same database? instead.
Many hosting providers offer their own migration tools, which are useful particularly when moving within the same infrastructure.
| Method | Suited to | Skill level |
|---|---|---|
| Migration plugin | sites up to a few GB | basic |
| Hosting tools | moves within one provider | basic |
| WP-CLI | large and complex sites | advanced |
| Manual | full control over the process | advanced |
Replacing URLs in the database
The database stores URLs in several places, and all of them need updating.
The starting point is siteurl and home in wp_options. That is only the beginning. URLs also sit inside post content, widget settings, theme configuration, and plugin settings.
Serialised data needs particular care. A plain text replacement breaks its structure, because the serialised format encodes the length of every string. Tools such as wp search-replace or Search Replace DB recalculate those lengths automatically and keep the data consistent.
A separate trap: URLs hard-coded in files rather than the database. Stylesheets with absolute paths to fonts or images, theme configuration, scripts. A database replacement will not touch those, so files need a separate pass.
Back up the database before every operation and test the replacement on staging before touching production. The same discipline applies when changing a WordPress theme without losing content.
When moving: what determines whether visibility survives
This is the part most often skipped, and the part that decides whether traffic survives the domain change.
301 redirects, URL by URL. Not the whole old domain redirected to the new homepage, which destroys everything the individual pages had earned. Every old URL has to reach its counterpart. Start by exporting the URL list from the old sitemap and build a one-to-one map.
Keep the old domain. Redirects need to work for at least a year, and in practice are worth keeping permanently. Letting the domain lapse a year after migration means losing every external link still pointing at it.
The change of address tool in Google Search Console. The new domain has to be added as a separate property. Submitting a change of address speeds up how the search engine processes the move. The new sitemap needs submitting too.
Update external references. Social profiles, the business listing in search, industry directories, email signatures, campaign tracking. For the most important link sources, an email asking for an update is worth the effort.
Ranking fluctuation is normal. A correctly executed domain change usually produces a temporary drop in visibility lasting a few weeks to a few months. Say so before the migration rather than explaining it afterwards.
When duplicating: how not to damage the original
Block indexation on the copy. The visibility setting in WordPress, a robots.txt rule, and protection at server level. WordPress settings alone are not always enough, which is why password protection at server level is the safer option.
Do not set redirects from the old domain. The original is meant to keep working.
Disconnect production integrations. A copy with a live mailing list, a payment gateway in production mode, or a connected CRM can send emails to real customers or create test orders in a real system. That is the most expensive version of this mistake.
Exclude the copy from analytics. Otherwise test data distorts production reporting.
What breaks most often after a migration
Broken links and missing images. Usually the result of an incomplete URL replacement or an incomplete file transfer.
The SSL certificate. A new domain needs a new certificate. Mixed content, meaning assets loaded over HTTP on an HTTPS page, blocks some browser functionality.
Plugin licences tied to a domain. Premium plugins with domain-locked licences need deactivating on the old domain and activating on the new one. Without that they stop receiving updates, which is a security problem rather than an inconvenience.
External services with domain allowlists. Payment gateways, OAuth redirect URIs, webhook endpoints, domain-restricted API keys, CDN configuration, form tools. Each needs a separate pass, and on shops this is usually the longest list.
Email and DNS records. Changing the domain also changes email addresses. MX, SPF, DKIM, and DMARC records need configuring on the new domain, or messages land in spam.
Database character encoding. Shows up as garbled non-English characters. It comes from a mismatch between source and destination encoding.
Scheduled tasks and authentication keys. Check cron jobs after the migration, and regenerate the salt keys in wp-config.php if the copy was shared outside the team.
How long does it take?
A simple site with modest content moves in fifteen to thirty minutes with an automated tool. A large shop can take several hours, and with a big media library and a long integration list, several days.
Duration depends on file and database size, hosting performance, the method chosen, and the scope of post-migration testing.
The technical transfer is the shortest part, though. On a domain move, the surrounding work, meaning redirect mapping, Search Console configuration, and working through the integration list, usually takes longer than copying the site.
Schedule the migration for a low-traffic window, with time for testing and a rollback plan ready.
When to bring in help
On a simple informational site, migration is an administrative task. On a site that carries revenue, the outcome is decided by redirect mapping and the integration list, and a mistake at that stage shows up in revenue rather than in logs.
External support is worth considering where a site has e-commerce, custom integrations, multiple languages, or an established search position whose loss costs more than the migration itself.
FAQ: copy a WordPress site to another domain
Does changing domain damage SEO?
With 301 redirects done properly and a change of address submitted in Search Console, equity transfers to the new domain. A temporary fluctuation lasting a few weeks to a few months is normal.
How long should redirects from the old domain stay up?
A year at minimum, and in practice permanently. Removing them means losing every external link still pointing at the old address.
Is redirecting the old domain to the new homepage enough?
No. That destroys what the individual pages had earned. Every old URL should reach its counterpart.
How do I keep a staging copy out of the index?
The WordPress visibility setting, a robots.txt rule, and password protection at server level. The last of those is the most reliable.ervices ensure expert handling of intricate configurations, custom code, and specialised integrations whilst minimising risks and downtime.
