How to Change Your Domain Name Without Losing Your Traffic

Changing your domain name is a two-part job. The mechanical part (pointing DNS, setting redirects, updating your platform) is straightforward and takes an afternoon. The part that decides whether you keep your traffic is everything around it: picking a name worth moving to, mapping every old URL to a new one, and telling Google what happened. This guide covers both, in the order you should actually do them.

First, Which Change Do You Actually Mean?

"Change my domain name" gets used for three different jobs, and they have almost nothing in common. Work out which one you're doing before you touch anything:

• Changing the domain itself. You're rebranding, and oldname.com becomes newname.com. This is a real site migration with genuine SEO risk, and it's what most of this guide is about.
• Changing registrars. You're keeping the same domain but moving it from GoDaddy to Cloudflare (or similar). Nothing about your site changes, no SEO impact, and it's a transfer rather than a migration. See the best domain registrars for where to land.
• Changing what your platform points at. You bought a domain and want to attach it to an existing Wix, Shopify, or WordPress site that's currently on a subdomain. That's a DNS and settings change, not a migration, and the platform sections below cover it.

What Changing Your Domain Actually Costs You

Google's official position is that a 301 redirect passes full ranking signal, and that has been the stated behavior since 2016. In practice, sites that move domains almost always see a temporary dip anyway. The redirects work, but Google has to recrawl and reprocess every URL, and that takes time proportional to how big your site is and how often it gets crawled.

What you should budget for:

• A ranking dip of a few weeks to a few months. Small sites recover fastest because they get fully recrawled sooner. Large sites can take a quarter or more to fully settle.
• Permanent loss of type-in and direct traffic. Anyone who had your old domain memorized or bookmarked reaches you only through the redirect, and only while the redirect exists.
• Backlink decay over time. The links still count through the redirect, but new links now point at the new domain while old ones depend on a redirect you have to keep paying for indefinitely.
• Brand recognition reset. This is the real cost, and it's the one nobody budgets for. If people already know your name, weigh that against whatever the rebrand is solving.

The Migration, Step by Step

1. Secure the new domain before you announce anything

Register it, and register the obvious defensive variants if the budget allows. Don't discuss a shortlist publicly before you own it. If you're still deciding, branded vs keyword domain names covers the tradeoff, and how to choose a domain name for a small business walks through the selection criteria.

2. Map every old URL to a new one

Before you write a single redirect rule, build the map. Export your full URL list from your sitemap, from Search Console's page report, and from your analytics (any URL that earned a visit in the last year). Deduplicate, then assign each one a destination.

If your URL structure isn't changing, this is a single wildcard rule and the map is just verification. If you're restructuring at the same time, do the mapping by hand. Changing domain and URL structure in one move is the riskiest version of this, and if you can split it into two separate moves a few weeks apart, do that instead: it makes diagnosing a problem far easier.

3. Set up 301 redirects

301 (permanent), not 302 (temporary). A 302 tells Google to keep indexing the old URL, which is the opposite of what you want. Redirect at the server or CDN level rather than with a plugin or a meta refresh, and confirm each one returns a single 301 hop with no chain through an intermediate URL. Redirect chains dilute crawl efficiency and are the most common thing that turns a clean migration into a slow one.

Test before you cut over. Point a local hosts file entry at the new server, or stage the redirect rules, and spot-check your top fifty URLs by traffic.

4. Update everything that hardcodes the old domain

• Internal links. Rewrite them to point at the new domain directly. Leaving them to resolve through redirects wastes crawl budget and slows every page load.
• Canonical tags. Every page's canonical should be its new URL. A stale canonical pointing at the old domain will actively fight your migration.
• Sitemaps. Publish a new sitemap with the new URLs. Keep the old sitemap live and reachable for a while so Google recrawls the old URLs and discovers the redirects faster.
• Structured data, Open Graph tags, and RSS feeds. All of these carry absolute URLs.
• Third-party profiles. Google Business Profile, social bios, directory listings, email signatures, app store entries, and any paid campaign destination URLs.
• High-value backlinks. You can't update most of them, but it's worth emailing the top twenty referring sites to ask. A direct link is worth more than a redirected one, and it survives the day you eventually drop the old domain.

5. Tell Google with Change of Address

Verify both the old and the new domain as properties in Google Search Console, then run the Change of Address tool from the old property. This is the explicit signal that a site move happened, and it measurably speeds up reprocessing compared to letting Google infer it from redirects alone.

The tool expects the redirects to already be live and the content to be substantially the same on both sides. If you rewrote your content at the same time as the move, Google has to re-evaluate the pages on their merits, and the Change of Address signal carries less weight. That's another argument for doing one thing at a time.

6. Move email separately

Web traffic and email are different DNS records and different failure modes. Your MX records, SPF, DKIM, and DMARC all live on the domain, and none of them redirect. Set up the new domain's mail first, run both in parallel with the old addresses forwarding, and only then start telling people to use the new ones. Silent email loss during a rebrand is common and often goes unnoticed for weeks.

7. Keep the old domain alive

Keep renewing it, and keep the redirects running, for a minimum of one year. Google's own guidance is at least a year, but if the old domain has meaningful backlinks the honest answer is indefinitely: it costs about ten dollars a year to keep the equity flowing, and letting it drop hands your backlink profile to whoever registers it next. Domains with real link histories get bought precisely because someone let them expire.

Platform-Specific Notes

WordPress

Update Settings → General (both WordPress Address and Site Address), unless those are pinned in wp-config.php, in which case change them there. Then run a database search and replace for the old domain, because post content, widgets, and serialized options are full of absolute URLs. Use WP-CLI's search-replace rather than a raw SQL query: it handles serialized data correctly, and a plain SQL replace will corrupt it.

Shopify

Add the new domain in your store's domain settings and set it as primary. Shopify redirects the old primary domain automatically as long as you leave it connected to the store, so do not remove it. That automatic redirect is why the most common Shopify migration mistake is disconnecting the old domain immediately after the switch.

Squarespace and Wix

Both work the same way: connect the new domain, set it primary, and leave the old one attached so the built-in redirect keeps working. Neither gives you fine-grained control over redirect rules, so if your URL structure is also changing, use their URL redirect settings to add the page-level mappings by hand.

Google Workspace

Add the new domain to your Workspace account, then add new addresses as aliases on the existing accounts before switching the primary domain. Aliases mean nothing is in flight when the cutover happens. Changing the primary domain on the account is a separate step from adding the domain, and doing it too early is what causes mail to bounce mid-move.

How Long Recovery Takes

For a site under a few hundred pages with healthy crawl frequency, expect most rankings to reappear on the new domain within two to four weeks, and full stabilization within about three months. Larger sites take longer purely because recrawling takes longer. If you're still meaningfully down after three months, the cause is usually a technical fault rather than the move itself: check for redirect chains, stale canonicals, a stray noindex, or a robots.txt on the new domain that's blocking crawl.

Watch the old property and the new property side by side in Search Console. You want to see impressions falling on one and rising on the other in roughly matching shapes. If the old is falling and the new isn't rising, something is broken in the redirect layer.

Mistakes That Actually Cost Rankings

• Redirecting everything to the homepage. The most damaging and the most common. Map page to page.
• Using 302s. Temporary redirects keep the old URLs indexed and hold the new ones back.
• Letting the old domain expire. Every backlink you ever earned dies with it.
• Changing domain and content at the same time. If rankings drop you won't know which change did it.
• Forgetting the www and non-www variants. Both need to redirect, on both protocols.
• Skipping Change of Address. It's free and it demonstrably speeds up reprocessing.
• No SSL certificate on the new domain before cutover. A certificate error on day one costs you more traffic than the migration will.

The mechanics of changing a domain name are genuinely easy. The discipline is in the sequencing: own the new name before you tell anyone, map every URL before you write a redirect, move one variable at a time, and never let the old domain lapse. Do those four things and the traffic follows you across.