I’ve moved a handful of WordPress sites to new domains at this point, and the failure mode I see most often isn’t some SEO mystery — it’s someone skipping a mechanical step and being surprised when things break. This is mostly plumbing work: database updates, server redirects, a few settings changes. Get the plumbing right and the rankings mostly take care of themselves over time.

Step 1: update the database, don’t just change siteurl in wp-config

WordPress stores your domain in two settings — siteurl and home — but your domain is also buried inside “serialized” PHP data scattered across post content, widget settings, theme mods, and plugin options. Serialized data is just a way PHP packs structured information (like an array) into a single text string for storage, and part of how it does that is by recording the exact character-length of each string right before it.

Here’s the trap: if you do a plain find-and-replace on that string with a SQL query, you change the text but not the length number sitting next to it. PHP sees a mismatched length and just refuses to unserialize the whole thing — your widget settings or theme options can silently break.

This is exactly the problem WP-CLI’s search-replace command was built to handle correctly — it walks through serialized data and updates those length numbers for you automatically. WP-CLI is a command-line tool for managing WordPress, and this is one of its most useful features. I always run it as a dry run first, meaning it reports what it would change without actually touching anything:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run --all-tables

Check that the count of replacements looks sane, then run it for real:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables

The --all-tables flag matters if you’re on a host that prefixes multiple sites’ tables under one database, or if you have custom tables outside the standard WordPress set that also reference the old URL.

If you’re setting up a staging copy of your site to test any of this safely before touching the live domain, I’ve written a separate walkthrough on building a WordPress staging site on shared hosting, which runs into this exact same serialized-data search-replace problem.

Step 2: 301 redirect the old domain at the server level

This is the step people skip because it requires keeping the old domain and hosting active for a while, which costs a bit more money. But it’s non-negotiable if you want to preserve the SEO value your old links have built up, sometimes called “link equity.”

A redirect built into WordPress itself only works while WordPress is still running on that domain — and it won’t be, once you’ve pointed the old domain’s DNS elsewhere. So this redirect needs to live in a file called .htaccess on the old domain’s server, ahead of WordPress’s own rules. Here’s a rule that catches both the plain and “www” version of the old domain and forwards everything to the new one:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.old-domain\.com$
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

The $1 at the end preserves the full path, so old-domain.com/blog/some-post/ redirects to new-domain.com/blog/some-post/ rather than dumping everyone on the new homepage. That path preservation is what actually carries your rankings across. Google is re-crawling individual URLs, not just your domain as a whole, and a 301 redirect that lands on the matching page tells Google unambiguously: this page moved here, transfer its signals to the new one.

Keep this redirect live for as long as you reasonably can. I generally plan on at least six to twelve months, since some crawlers and old backlinks take a long time to get re-processed.

Step 3: file a Change of Address in Google Search Console

Search Console is Google’s free tool for site owners to monitor how their site is indexed. You’ll need both the old and new domain verified as properties in it first. Once both are verified, go to the old domain’s property, find Change of Address in settings, and point it at the new domain.

This is Google’s explicit signal that the whole site moved, on top of whatever the 301 redirects are already telling it. In my experience it noticeably speeds up how quickly the new domain’s URLs start showing up in place of the old ones in search results. It’s the same tool I’d point you to if you were also cleaning up which archive pages Google is indexing — Search Console is worth getting comfortable with generally, not just for migrations.

Step 4: update internal links, don’t rely purely on redirects

The search-replace in step 1 already fixes internal links stored in post content and most plugin settings, since those are just URLs sitting in the database. But check for hardcoded absolute URLs in three other places: your theme’s template files, any custom code in your functions file, and menu items — especially if your menu was built with full URLs rather than relative paths.

Every internal link that still points at the old domain is one more unnecessary redirect hop for both users and crawlers. It’s not fatal. But it’s worth cleaning up rather than leaning on the redirect forever.

What to actually expect afterward

Some ranking fluctuation in the weeks after a domain migration is normal. Google has to recrawl and reprocess every URL on the new domain, and rankings on a handful of terms will bounce around while that settles, even when everything above was done correctly. I don’t treat a dip in the first couple of weeks as evidence something went wrong — I treat it as evidence the migration is being processed.

Frequently Asked Questions About Domain Migrations

How long will it take for my rankings to fully recover on the new domain?

There’s no fixed timeline, but most well-executed migrations settle within a few weeks to a couple of months as Google recrawls and re-indexes the new URLs. Some fluctuation during that window is completely normal and not a sign of a problem. What you’re watching for is a dip that never recovers, which usually points at a mistake somewhere in the redirect setup rather than normal reprocessing.

Do I really need to keep the old domain and hosting active?

Yes, for at least six to twelve months if you can manage it. The 301 redirects that preserve your rankings only work while the old domain is still live and pointed at a server that can serve those redirects — the moment it goes dark, every old backlink and bookmark just leads to a dead page instead of your new site.

Can I do this migration myself without a developer?

The WP-CLI and Search Console steps are approachable if you’re comfortable following instructions carefully, but the .htaccess redirect step involves editing server configuration, and a mistake there can take your whole site offline. If you’re not confident editing server files, this is the one piece I’d hand to a developer even if you do the rest yourself.

What happens if I forget to set up the redirect and just switch domains?

You lose most of the accumulated ranking value from your old domain’s backlinks, and visitors following old links or bookmarks just hit a dead end. The new domain effectively has to build its authority up from something closer to scratch. This is the single most damaging mistake I see in domain migrations, and it’s also the easiest one to avoid.

Will my site look broken to visitors during the migration?

It shouldn’t, if you do the database update and redirect in the right order and test on a staging copy first. The main visible risk is broken images or links if the search-replace step is skipped or done incorrectly, which is exactly why testing on a staging site before touching the live domain is worth the extra time.

What I do watch closely in the weeks after a migration is Search Console’s coverage report, specifically for spikes in “Not found (404)” or “Redirect error.” Normal reprocessing noise looks like gradual re-indexing; those two error types point at an actual mistake in the redirect rules instead.