How to change your WordPress domain without losing SEO

01Why a domain change is the riskiest move you can make

A theme switch keeps your URLs and changes the markup. A domain change does the opposite — it keeps your content and changes every single URL. That is a much bigger deal to Google, because the address is how it found, indexed, and ranked every page you have.

Think about what Google has stored: thousands of URLs on the old domain, each tied to a ranking, a click history, and whatever link equity points at it. Move the site and every one of those addresses returns nothing unless you tell Google exactly where it went.

Done right, a domain change is routine and rankings carry over within weeks. Done wrong, it's the fastest way to vaporize an organic-traffic business overnight. The difference is almost entirely in the redirects — which is why most of this guide is about getting them right.

What actually changes when you move domains

• Every URL — your homepage, every post, every page, every category and tag archive now lives at a new address. The old ones must point to the new ones or they 404.
• Internal links — links inside your content, menus, and widgets still point at the old domain until you rewrite them, creating redirect chains or dead links.
• Canonical tags — self-referencing canonicals baked into pages will keep naming the old domain unless they're updated, which confuses indexing.
• Sitemaps and feeds — your XML sitemap and RSS feed list old-domain URLs that Google will keep trying to crawl.
• Backlinks — every external link earned by the old domain now points at a URL that only resolves if your redirects are in place.
• Email, analytics, and verification — Search Console properties, analytics filters, and any hard-coded domain references all need the new address.

None of that is visible by glancing at the new site. It can look perfect while half your indexed URLs quietly 404 and your link equity drains. That gap between "looks done" and "is done" is exactly what the checklist below closes.

02The pre-move checklist you can't skip

Before you change a single setting, capture what your site looks like today. A domain change is reversible only if you know precisely what you started with — and your old URL list is the literal blueprint for the redirects you're about to build.

Do all of this on the old domain while it's still live and indexed, and save every output somewhere you can reopen weeks later when something looks off.

Capture these before you touch anything

• A full backup — files and database together, taken right before the move and tested by restoring it once on staging. An untested backup is a hope, not a safety net.
• A complete crawl — run a crawler (Screaming Frog or similar) and export every URL with its status code, title, and word count. This is your master list of what must redirect.
• Your Search Console URL list — export indexed pages and top landing pages so you have a dated record of every URL Google currently ranks.
• Baseline rankings — export top queries, clicks, impressions, and average position from Search Console as your before-and-after benchmark.
• Your internal link map — the crawl already has this; note where internal links point so you know what to rewrite to the new domain.
• A speed baseline — run PageSpeed Insights on a few key pages and save the numbers, so a slow new host doesn't get blamed on the move (or vice versa).

The crawl is the centerpiece. Every URL in that export needs a destination on the new domain, and the cleanest destination is almost always the same path. The list you build now becomes the redirect map you verify after the move.

03Making the move: two ways to get there

There are two technical routes to a new domain, and which one you take depends on whether you're keeping the same hosting or moving servers at the same time. Both end in the same place — the same WordPress install answering to a new address.

Option A — same server, just rename the address

If the site stays on the same host and you only want a new domain, the change is mostly a settings update. Point the new domain's DNS at your server, add it in your hosting panel, then update WordPress Address (URL) and Site Address (URL) under Settings → General to the new domain.

Because changing those two settings can lock you out if DNS isn't ready, many people set them via wp-config.php (WP_HOME and WP_SITEURL) or WP-CLI instead, where it's safer to undo. After the switch, run a search-and-replace across the database to fix old-domain URLs stored inside post content, options, and widgets.

Option B — migrate files and database to the new domain

If you're also changing servers, copy the files and export the database, import them on the new host under the new domain, then run a database search-and-replace to swap every instance of the old domain for the new one. A migration plugin (or your host's migration tool) handles most of this and does the URL replacement for you.

Whichever route you take, do it on staging first. A staging clone on the new domain lets you confirm the site renders, the database replace was clean, and nothing still references the old address before any visitor or crawler arrives. Cloudways gives you one-click staging for exactly this kind of dry run.

One non-negotiable: keep the old domain's hosting and DNS live. The whole redirect strategy depends on the old domain still being able to receive requests and pass them along — if you let it expire or unpoint it, every redirect breaks and the equity is gone.

04The critical part: redirect every old URL, path for path

This is the section that decides whether your rankings survive. Every URL on the old domain must return a 301 (permanent) redirect to its exact equivalent on the new domain — same path, same slug. A 301 tells Google the page moved for good and passes its ranking signals to the new address.

The right pattern is one-to-one and path-preserving: olddomain.com/best-fast-themes/ redirects to newdomain.com/best-fast-themes/, not to newdomain.com/. A single wildcard rule at the server can do this for the whole site at once, which is both the easiest and the safest approach.

The mistake that kills rankings

Redirecting every old URL to the new homepage is the single most damaging error in a domain move. Google treats a mass redirect to one page as a "soft 404" — the old page's signals don't transfer, the ranking is lost, and the visitor who clicked a deep result lands on a homepage with no idea where their page went.

This is the same rule we hold ourselves to when we consolidate or move our own domains: a redirect points to the closest real equivalent of the page that moved, never a catch-all to the root. Path-preserving redirects are the only kind that carry rankings across.

How to implement it

• Server-level wildcard (best) — add one rule that forwards every old-domain path to the same path on the new domain, e.g. an Apache RewriteRule or an Nginx return 301. One rule covers the whole site and is fastest for crawlers.
• Host or CDN redirect — many hosts and Cloudflare let you add a domain-level forwarding rule that preserves the path; this keeps the logic off WordPress entirely.
• Redirect plugin (fallback) — a plugin like Redirection can map old to new, but it loads WordPress on every hit, which is slower and depends on the old install staying up.
• Keep them permanent — leave the 301s in place for at least a year, ideally indefinitely, so old backlinks and stragglers in the index keep flowing to the new URLs.

After you set the rule, spot-check it. Run your saved crawl list against the live redirects and confirm each old URL returns a single 301 straight to its matching new URL — no chains, no loops, no 404s, no landing on the homepage.

05Update internal links, sitemaps, and canonicals

Redirects catch external traffic and old backlinks, but your own site shouldn't lean on them. Every internal reference to the old domain should be rewritten to the new one so links resolve directly, with no redirect hop in between.

The database search-and-replace you ran during the move handles most of this — it rewrites links embedded in post content, menus, and widget settings. The job here is to verify it worked and clean up what it missed.

• Internal links — re-crawl the new site and look for any link still pointing at the old domain; these create needless redirect hops and should resolve directly to the new URL.
• Canonical tags — confirm every page's canonical names the new domain. A canonical still pointing at the old address tells Google the old URL is authoritative, undoing the move.
• XML sitemap — regenerate it so it lists only new-domain URLs, then it's ready to submit to Search Console.
• RSS feed — confirm the feed now serves new-domain URLs so subscribers and aggregators pick up the change.
• Hard-coded references — check theme files, custom HTML widgets, and any settings for the old domain typed in by hand, which a database replace can miss.

The goal is a site where the only place the old domain appears is the redirect rule itself. Everything a crawler reads on the new site should already speak in new-domain URLs.

06Tell Google with the Change of Address tool

Once redirects are live and internal links are clean, formally notify Google. The Change of Address tool in Search Console tells Google your site moved and asks it to transfer the old domain's signals to the new one faster than it would on its own.

There's a setup order that trips people up. You need both domains verified as separate properties in Search Console, and the redirects must already be live, before the tool will accept the request — it checks that the old domain genuinely 301s to the new one.

• Verify the new domain as its own property in Search Console if you haven't already.
• Confirm the homepage redirect — Change of Address requires the old domain's homepage to 301 to the new domain's homepage, not to a subpage. (Hard-won lesson: it rejects a 301 to a subpage.)
• Submit Change of Address from the old domain's property settings, choosing the new domain as the destination.
• Submit the new sitemap in the new property so Google has a fresh map of new-domain URLs to crawl.
• Keep both properties open for monitoring — you'll watch the old one drain and the new one fill over the following weeks.

The tool is a strong hint, not an instant switch. Google still re-crawls and re-indexes at its own pace, which is the whole reason the redirects have to stand on their own without it.

07Monitor after the move

A domain change isn't finished at launch — it's finished when the new domain has absorbed the old one's rankings and you've confirmed nothing leaked. The first few weeks are when you catch problems while they're still cheap to fix.

• Watch both properties in Search Console — impressions and clicks should fall on the old domain and rise on the new one in roughly mirrored curves.
• Check coverage for 404s on the new property and the old one; any spike means a redirect is missing or wrong, and your crawl list tells you which URL.
• Re-crawl the new site and diff it against your pre-move baseline — same titles, same word counts, every URL returning 200.
• Confirm redirects still resolve as single 301s; chains and loops creep in when plugins or caching layers stack rules.
• Track rankings against the baseline for two to four weeks so you can tell a normal re-indexing wobble from a real drop.
• Leave the old domain and its redirects live for the long haul — turning them off later re-breaks every old backlink.

A clean move shows a brief, shallow dip as Google re-indexes, then recovery to the prior level. If positions don't come back after a few weeks, the cause is almost always a redirect problem — and your saved URL list is exactly the diff that points to it.

08FAQ

Will I lose my Google rankings if I change my domain?

Not if you redirect correctly. The rankings transfer when every old URL 301-redirects to its exact equivalent on the new domain and you submit a Change of Address in Search Console. You typically see a short dip during re-indexing, then recovery within a few weeks. Rankings are lost when redirects are missing, point to the homepage, or the old domain is taken offline.

Why can't I just redirect everything to the new homepage?

Because Google treats a mass redirect to one page as a soft 404 and doesn't transfer the old page's ranking signals. A deep page that ranked for a specific query needs to redirect to its matching deep page on the new domain, path for path. Redirecting it to the homepage throws away both the ranking and the visitor's intent.

How long should I keep the 301 redirects in place?

Indefinitely is safest; a year is the practical minimum. Backlinks on the old domain, bookmarks, and stragglers in Google's index keep sending traffic through those redirects long after the move. As long as the old domain stays registered and pointed at the redirect rule, keeping them costs nothing and protects your earned equity.

Do I need to keep the old domain registered?

Yes. The old domain has to stay registered and live so it can keep serving the 301 redirects. If you let it expire, every redirect breaks at once — old backlinks die, indexed URLs 404, and the link equity you moved over is lost. Treat the old domain's renewal as part of the cost of the move.

Should I change my domain and redesign at the same time?

Avoid it. Bundling a domain change with a theme switch or URL-structure change makes it impossible to tell which change caused a ranking move if something goes wrong. Move the domain first, confirm rankings hold, then make other changes one at a time. One variable per migration is how you stay diagnosable.

This is general, experience-based guidance from running a theme shop and moving our own sites, not financial or professional advice for your specific situation. When a site's traffic is business-critical, that's the signal to test the move on staging first and keep a tested backup ready before you flip DNS.