Moving a WordPress Site to a New Domain

Changing a domain is one of those jobs that looks like a settings tweak and behaves like surgery. WordPress stores your domain in far more places than the two fields in Settings → General: it lives inside post content, serialized theme options, plugin tables, hardcoded widget links, and sometimes your wp-config.php. Miss one layer and you get mixed-content warnings, images that load from the old domain, or a login redirect loop that locks you out of your own admin.

The good news: a domain move is entirely mechanical. There is no judgment call in the middle of it, just a sequence. Do the steps in order, verify each one, and the whole thing takes an afternoon — most of which is waiting for DNS.

Before You Touch Anything: The Pre-Flight List

Every painful migration story starts with a skipped preparation step. Before the move, do all of these:

• Take a full backup — files and database, stored somewhere that is not the server you are about to change. Verify you can actually open the archive. A backup you have never tested is a hope, not a backup.
• Lower your DNS TTL 24–48 hours in advance. Set the TTL on the relevant records to 300 seconds. This means that when you flip the switch, the internet forgets the old answer in minutes instead of a day.
• Confirm you control both domains and that the new one has (or can get) a valid SSL certificate. Migrating to a domain with no certificate turns a clean move into an emergency.
• Export a crawl of the old site. Run a crawler (Screaming Frog’s free tier handles 500 URLs) or at minimum export your sitemap. You will use this list to verify redirects later.
• Note your search visibility. Screenshot Search Console performance for the old domain so you have a baseline to compare against in a month.

The Two Migration Paths

There are two ways to do this, and the right one depends on whether you are also changing hosts.

Path A: Same server, new domain

If the site stays on the same hosting account, you point the new domain at the existing site, then rewrite the URLs in place. No file copying required. This is the simpler path and the rest of this article mostly assumes it.

Path B: New server and new domain

If you are moving hosts at the same time, clone the site to the new server first (files plus database), get it working on the new domain there, and only then deal with redirects on the old one. Resist the temptation to do both changes as one atomic step — when something breaks, you want to know which change broke it. A useful rule: change one variable at a time, even when it means an extra hour of work.

Step 1: Update the Site URL Properly

WordPress keeps the canonical address in two options: siteurl and home. Change them via WP-CLI if you have shell access:

wp option update home 'https://newdomain.com'
wp option update siteurl 'https://newdomain.com'

If you do not have WP-CLI, update the two fields in Settings → General — but understand that the moment you click save, the admin will redirect to the new domain, which must already resolve. If it does not resolve yet, you have just locked yourself out (recoverable, but annoying). When in doubt, define both values temporarily in wp-config.php instead, because a config file edit is trivially reversible:

define('WP_HOME', 'https://newdomain.com');
define('WP_SITEURL', 'https://newdomain.com');

One warning: values defined in wp-config.php override the database silently. If a previous developer hardcoded them, your Settings screen fields will be greyed out or ignored. Check the config file first, always.

Step 2: Search-and-Replace the Database (the Right Way)

This is the step that separates clean migrations from haunted ones. Your old domain appears throughout the database: in post content, in image URLs, in menu items, and — crucially — inside serialized data. Themes and plugins store settings as PHP serialized strings, which embed the character length of each value. If you replace olddomain.com with mynewdomain.com using a plain SQL query, the lengths no longer match, the serialized data becomes unreadable, and settings quietly vanish. Widgets disappear. Page builder layouts collapse.

So never run a raw UPDATE ... REPLACE() query for this. Use a serialization-aware tool:

• WP-CLI: wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run — run with --dry-run first, read the table-by-table counts, then run it for real without the flag.
• Better Search Replace (plugin) if you have no shell access — it handles serialization correctly and also has a dry-run mode.

Run the replacement in this order to catch protocol and www variants:

1. https://olddomain.com → https://newdomain.com
2. http://olddomain.com → https://newdomain.com
3. //olddomain.com → //newdomain.com (catches protocol-relative URLs)
4. Finally, a bare olddomain.com → newdomain.com pass to catch email addresses in settings, schema markup, and stray references. Review this one’s dry run carefully — you may not want every match (for example, mentions of the old domain in a blog post about the migration).

Step 3: Sweep the Places Search-Replace Misses

The database replacement covers most references. The few that remain cause most of the post-migration bug reports:

• wp-config.php — hardcoded WP_HOME/WP_SITEURL, cookie domain constants, or multisite DOMAIN_CURRENT_SITE.
• Theme files — a previous developer may have hardcoded absolute URLs in header.php or the customizer CSS.
• CDN configuration — if you serve assets from a CDN pull zone pointed at the old origin, update the origin.
• Caching plugins — purge everything, then check whether the plugin stores the domain in its settings (several do).
• External services — payment gateway webhook URLs, email service domains, OAuth redirect URIs, analytics property settings, uptime monitors.
• Licensed plugins — many license activations are domain-bound. Expect to re-activate two or three licenses.

Step 4: Redirect the Old Domain, Permanently and Precisely

This is the step that protects your SEO, and it has one non-negotiable requirement: every old URL must 301-redirect to its exact equivalent on the new domain, not to the new homepage. A blanket redirect-everything-to-the-homepage move is treated by search engines as a soft signal that the old pages are gone, and their accumulated authority evaporates instead of transferring.

Because the URL paths are identical (you changed the domain, not the structure), a single pattern rule handles it. On Apache, in the old domain’s .htaccess:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?olddomain\.com$ [NC]
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]

On Nginx, a dedicated server block with return 301 https://newdomain.com$request_uri; does the same. If the old domain sits behind Cloudflare, a single Bulk Redirect or Redirect Rule can do it without any origin server at all — useful if you plan to cancel the old hosting.

Two details people miss:

• Keep the old domain’s SSL certificate alive. A redirect from an https URL only works if the old domain can still complete a TLS handshake. An expired certificate on the old domain means every historical https link now shows a browser security error instead of redirecting.
• Keep the redirects running for at least a year, ideally as long as you own the domain. Search engines typically consolidate signals within a few months, but human links in emails, PDFs, and bookmarks live forever. The cost of keeping a domain registration and a redirect rule is roughly the price of two coffees a year.

Step 5: Tell Google, Explicitly

Search Console has a purpose-built tool for exactly this scenario, and skipping it slows down the transfer of rankings noticeably:

1. Verify the new domain as a property in Search Console (use the Domain property type, verified via DNS TXT record).
2. In the old property, open Settings → Change of Address, and point it at the new property. This requires the 301 redirects from Step 4 to already be live — Google checks a sample.
3. Submit the new sitemap under the new property.
4. Update the property in Google Analytics and any ads platforms.

Expect rankings to wobble for two to six weeks even when everything is done correctly. A temporary dip in organic traffic during the consolidation window is normal; a sustained steep drop after two months means a redirect problem worth investigating.

Step 6: Verify Like You Mean It

Now the crawl export from your pre-flight list earns its keep. Verification is a checklist, not a vibe:

• Redirect check: take 20–30 URLs from the old crawl (mix of posts, pages, images, and category archives) and confirm each returns a single 301 hop to the matching new URL. Chains of redirects (old http → old https → new) work but leak signal; flatten them if you can.
• Mixed content check: open the new site with browser dev tools on the Console tab. Any warning mentioning the old domain means the search-replace missed something.
• Forms and email: submit the contact form, complete a test checkout if you sell anything, and confirm transactional emails still send. Email is domain-sensitive — if your from-address changed, you need SPF, DKIM, and DMARC records on the new domain before those emails will reliably land in inboxes.
• Login and cookies: log out fully and log back in. Cookie-domain mismatches show up here as instant logouts or infinite redirect loops.
• Crawl the new site and compare page counts against the old crawl. A meaningful difference in indexable URLs means something got lost.

A Realistic Timeline

The Short Version

A clean domain move is: backup, serialized-safe search-replace, sweep the hardcoded corners, exact-match 301s with a live certificate on the old domain, tell Search Console, then verify against a pre-migration crawl. None of it is difficult; all of it is unforgiving of shortcuts. Schedule it for a quiet morning, work the list top to bottom, and the most dramatic thing about your migration will be how little anyone notices it happened.

Photo: SHVETS production on Pexels