How to Change Domains or Platforms Without Losing Search Traffic

You keep search visibility through a domain or platform change by mapping every existing URL to its closest new equivalent, redirecting each one with a permanent 301, keeping page content and titles substantially intact through the move, and telling Google about the change in Search Console. Most traffic losses after a migration are not caused by the new site being worse—they are caused by old URLs that were never redirected anywhere.

A migration is one of the few website projects with genuine downside risk. A mediocre redesign wastes money; a botched migration can remove a business from search results it spent years earning. The work is entirely manageable, but it is unforgiving of shortcuts, and it has to be planned before the new site is built rather than discovered on launch day.

Know which kind of migration you are doing

“Migration” covers several different projects with different risk levels. Being precise here determines how much of the checklist applies.

Where you have the choice, avoid the last row. Changing domain and platform in the same launch means that if traffic drops, you cannot tell which change caused it. Sequencing them—platform first, domain a month later, or the reverse—costs a little more time and makes problems diagnosable.

Before the move: build the inventory

Nearly every serious migration failure traces back to a missing inventory. You cannot redirect URLs you never wrote down, and the pages most likely to be forgotten are old ones that quietly still earn traffic.

• Export every known URL. Combine your XML sitemap, a crawl of the current site, the Pages report in Google Search Console, and your analytics. Each source catches URLs the others miss.
• Include URLs that are not in your sitemap. Old blog posts, PDFs, images that earn search traffic, and legacy pages from a previous site are the usual casualties.
• Record current performance. Before launch, save clicks, impressions, and average position by page for the last twelve months, plus your top landing pages. Without this baseline you will be arguing from memory when someone asks whether traffic dropped.
• Note existing external links. Pages other sites link to are the most costly to break, because that link value flows through the redirect or is lost.
• Check current indexing. Fix indexing problems before the move rather than migrating them into the new site.

Build the redirect map

The redirect map is the deliverable that determines whether the migration succeeds. It is a simple two-column list: every old URL, and the single new URL that best replaces it.

• Use 301 (permanent) redirects. A 301 signals a permanent move and is how search engines transfer signals to the new address. Temporary 302s tell Google to keep the old URL indexed, which is the opposite of the goal.
• Map to the closest equivalent, not the homepage. Dumping every retired page onto the homepage is the single most common mistake. Google treats redirects to an irrelevant page as soft 404s, and any value the old page held is lost.
• Redirect one hop. Old URL straight to final new URL. Chains of redirects through two or three intermediate addresses slow crawling and lose value at each hop.
• Do not forget the variants. HTTP to HTTPS, www to non-www, trailing slashes, and uppercase variants all need to resolve to one canonical address.
• Handle genuinely retired pages honestly. If a page has no equivalent and no traffic, letting it return 404 is acceptable and cleaner than a misleading redirect.

Google’s documentation on site moves with URL changes is the primary reference for this process and is worth reading in full before a domain change.

Keep the content recognizable through the move

A migration and a rewrite are two separate projects. If a page moves to a new URL and its title, headings, and body text are rewritten at the same time, you have changed both the address and the thing at the address—and you have removed your own ability to tell which change moved the rankings.

Where a redesign genuinely requires new content, migrate first and revise afterward where you can. If they must happen together, keep page titles, primary headings, and the substance of the content close to the original on your highest-traffic pages, and treat lower-traffic pages as the place to experiment.

Launch day

Do the launch when you can watch it, not late on a Friday. Work through this immediately after the new site goes live:

• Remove the staging blocks. A noindex tag or a robots.txt disallow left over from development will deindex the entire new site. Check this first, then check it again.
• Spot-check redirects. Test your top twenty URLs by traffic and confirm each returns a 301 to the right destination in one hop.
• Verify canonicals. Every page should declare an absolute canonical URL on the new domain, never the old one.
• Confirm HTTPS everywhere. Valid certificate, no mixed content, and HTTP redirecting to HTTPS.
• Submit the new sitemap in Search Console, listing only live canonical URLs on the new domain.
• Use the Change of Address tool if the domain changed. Both properties must be verified in Search Console for this to work.
• Keep the old domain’s Search Console property. You will need it to monitor how the old URLs are being processed.
• Check analytics is actually recording. Tracking code is routinely lost in a platform change, and you will not notice until you need the data.
• Test the contact form. Forms break in migrations more often than anything else, and a silent form means lost inquiries with no error message.

What to expect afterward

Some fluctuation is normal. Google has to recrawl the old URLs, process the redirects, and update its index, and that takes time proportional to the size of the site. A period of unstable rankings after a large migration is expected, not evidence of failure.

What is not normal is a sustained drop with no recovery. Watch these signals over the first several weeks:

• Crawl and indexing reports on the new property—new URLs should be getting indexed steadily.
• 404 errors on both properties, which reveal URLs the redirect map missed. This is the most productive report to check, and missed URLs are usually easy to fix once identified.
• Clicks and impressions compared against the baseline you saved, page by page rather than in aggregate.
• Server errors and response times on the new host under real traffic.

Keep the redirects in place permanently, or at minimum for a year. Old links on other sites, in directories, and in printed material keep sending people to the old addresses long after search engines have caught up. Retiring redirects early quietly breaks those paths.

The mistakes that cause most losses

• Launching with no redirect map and building one after traffic drops.
• Redirecting everything to the homepage.
• A leftover noindex from staging.
• Changing domain, platform, and all content simultaneously.
• Letting the old domain’s registration lapse.
• No performance baseline, so nobody can tell what was lost.

If traffic does fall, resist the urge to make sweeping changes in the first week. Work the 404 report, confirm the redirects behave correctly, and check that indexing is progressing. The diagnostic sequence in why a business is not showing up on Google applies directly to post-migration troubleshooting.

Next step

If a move is coming, build the URL inventory and redirect map before the new site is designed—it is far cheaper as a planning input than as a launch-week emergency. Budget the migration work explicitly rather than assuming it is included; the website cost guide covers how scope like this affects a quote, and signs a website needs a redesign can help confirm the move is worth doing at all. To have the redirect planning handled as part of a rebuild, start a project inquiry describing the current site and where it is going.