Website Migration SEO Checklist: Keep Your Traffic

In June, Google added one line to its site move guide: on a domain change, use the Change of Address tool for every subdomain variant of the old domain, www and non-www included.

It’s a small edit. But details like that decide whether a move goes smoothly or costs you a month of traffic.

The short version: list every old URL, give each one a new home, redirect it in one hop, and change as little else as you can. Then watch Search Console for weeks.

Can a checklist promise zero loss? No. Google itself says rankings move while it recrawls, but a checklist stops the losses that come from mistakes.

First, what kind of move is it?

The risk grows with how many URLs change, and with what else changes alongside them. Here’s a rough guide:

Move	What changes	Risk
Hosting or CDN	Servers and DNS; URLs stay the same	Lower, if DNS and HTTPS work on day one
HTTP to HTTPS	Every URL’s protocol	Medium
Redesign	Templates and layout	Low if URLs and content stay put, high if they don’t
New platform (WordPress to Shopify, for example)	Templates, URLs, metadata controls	Medium to high
New URL structure	Paths and folders	High
New domain	Every URL	High
Merging two sites	Two sets of URLs into one	High

One rule from Google covers most of it: change only one thing at a time.

Move to a new domain and redesign in the same week, and you can’t tell which one hurt you.

The 9 checks at a glance

#	Check	When	About
1	Take a baseline	Weeks before	1 hour
2	List every old URL	Weeks before	2 hours
3	Map each old URL to a new one	Weeks before	Depends on size
4	Build on staging, back up, plan a rollback	Before launch	Days
5	Set up Search Console, analytics and DNS	Days before	1 hour
6	Switch on redirects and test every one	Launch day	1 to 3 hours
7	Remove staging blocks and check the new pages	Launch day	1 hour
8	Tell Google, and everyone else	Launch day	1 hour
9	Watch the numbers, keep the redirects	Months after	15 min a week

Before the move

1. Take a baseline

You can’t judge a migration if you don’t have a “before”. Save these, with the date range written on each:

Search Console Performance by page and by query
analytics landing pages and conversions for organic visitors
a full crawl of the current site (titles, canonicals, status codes), the same one a technical SEO audit starts with
your most linked pages, from Search Console’s Links report or a backlink tool

Note anything seasonal you’d expect. A December drop on a gift shop isn’t a migration problem.

Check it: one dated folder holds all four exports.

2. List every old URL

Your sitemap is a start. Google also points to server logs or analytics for the URLs that get traffic, and to the pages other sites link to.

Pull from every source you have:

XML sitemaps
a crawl of the live site
an export from your CMS
Search Console’s top pages over the last year
analytics landing pages
your most linked URLs from a backlink tool
images and PDFs that people link to directly

Merge them, and you’ll remove a lot of duplicates. The URL nobody remembered is the one with the backlinks.

Check it: one deduplicated list, each URL tagged with where it came from.

3. Map each old URL to a new one

Every old URL gets one of three answers:

It stays the same.
It redirects to the closest matching new page.
It’s gone for good, with no replacement, and returns a 404 or 410.

Don’t send a pile of old URLs to the homepage. Google says that “might be treated as a soft 404”, and it confuses people too.

Merged content is the exception: if three old posts became one guide, all three can redirect to that guide.

Check it: no blank cells in the destination column, and the homepage only appears where the old URL was the homepage.

4. Build on staging, back up, plan a rollback

Build the new site where Google can’t see it yet: behind a password, so a forgotten setting can’t leak it into the index. Then compare it with the old one, template by template.

Check that titles, headings and main content match on your important pages. Then test what earns you money: forms, logins, checkout, email sign-ups.

Before launch day:

take a full backup of the old site and confirm someone can restore it
freeze content changes, or log them, so the map doesn’t go stale
write down what would make you roll back (sitewide errors, checkout failing, redirects broken) and who decides

Check it: a crawl of staging matches your baseline on titles and canonicals for every important template, and a test order or form goes through.

5. Set up Search Console, analytics and DNS

Add and verify the new site in Search Console before launch. For a domain move, make sure every variant of the old domain is verified too, because Change of Address needs them.

Put your analytics tag on the new templates and check that it fires for you.

Moving hosts? Google suggests lowering your DNS records’ TTL beforehand, so the switch spreads faster.

Check it: you own both old and new properties in Search Console with the same Google account, and a test visit shows up in analytics.

Launch day

6. Switch on redirects and test every one

Use server-side permanent redirects (301 or 308). Google says to use JavaScript redirects only as a last resort.

Each old URL should land on its new page in one hop. Google says long redirect chains have “a negative effect on crawling”.

Your visitors feel every extra hop too.

Leave the old site crawlable, and don’t block it. Google has to fetch the old URLs to see the redirects, so a robots.txt block on the old domain hides your whole move from it.

On a domain change, test the homepage redirect too. Googlebot now must be able to follow redirects from your home page to find your favicon.

Check it: run your whole old-URL list through Screaming Frog in list mode with redirects followed. Every URL should reach its mapped page in one hop with a 200, and retired ones should return the 404 or 410 you planned.

7. Remove staging blocks and check the new pages

This is where most disasters happen. Google’s hosting guide puts it first on launch day: “Remove any temporary blocks to crawling.”

Check, on the live site:

robots.txt no longer says Disallow: /
no noindex in meta robots or the X-Robots-Tag header
the staging password is off
canonical tags point to the new URLs, not the old ones or staging
hreflang annotations, if you use them, point to the new URLs

Check it: run 10 key new URLs through URL Inspection’s live test. Each should be crawlable, indexable and canonical to itself.

8. Tell Google, and everyone else

Submit the new sitemap in Search Console. Google says you can remove the old one after that.

Moving to a new domain? Use the Change of Address tool in the old property’s settings, for every variant of the old domain.

It’s meant for domain moves only, so you don’t need it for HTTPS, www or path changes. The tool runs for 180 days.

If you uploaded a disavow file for the old site, upload it again on the new property.

Then update what lives outside your site:

Google Business Profile and social profiles
ad landing pages and email templates
payment, form and login callback URLs
the backlinks that actually send traffic: ask those sites to update the link
directory listings and profiles you set up yourself (our link hub lists the common ones)

Check it: the new sitemap reads successfully in Search Console, and your Change of Address request appears for each old variant.

After the move

9. Watch the numbers, keep the redirects

On launch day, check for errors every hour or two: 404s and 5xx in your logs, forms, checkout.

For the first two weeks, open Search Console daily. Watch Page indexing, Crawl stats, and traffic moving from the old site to the new one.

Then compare weekly against your baseline. For a medium-sized site, Google says “it can take a few weeks or more” before new URLs replace old ones.

Keep the redirects for as long as you can, “generally at least 1 year” in Google’s words.

And keep paying for the old domain for at least a year too, Google says, so nobody else can buy it.

Check it: auto-renew is on for the old domain, the redirect rules are written down somewhere the next developer will find them, and your weekly comparison sheet exists.

What’s overrated

A goal of zero 404s. A page that’s gone with no replacement should return 404. The ones to fix are URLs that should have moved and didn’t.
Moving and redesigning together to save time. You save a week and lose the ability to tell what went wrong.
Panic in week one. Rankings move during a migration. Judge it on weeks of data.

Why it matters

A migration is the one time you can lose years of SEO work in an afternoon. It happens.

Nearly every avoidable loss comes from two mistakes: an old URL with no redirect, or a staging block that went live.

So where should your hours go? Checks 2, 3 and 7.

A complete URL list, a map with an answer on every line, and five minutes reading robots.txt on launch day are worth more than any tool you could buy for the job.

And keep the old domain. It’s cheap to renew, and you don’t want a stranger owning it while your backlinks still point there.

Common Questions

How long does it take to recover traffic after a website migration?

Weeks, usually. Google says medium-sized sites can take a few weeks or more before new URLs replace old ones in search results, and larger sites take longer. A move with missing redirects or a leftover noindex can take much longer to recover.

How long should I keep 301 redirects after a site migration?

At least a year. Google’s site move guide says to keep redirects as long as possible, generally at least one year, and its Change of Address help recommends paying for the old domain for at least a year too.

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

Avoid it if you can. Google’s site move guide says to change one thing at a time. Doing a domain change and a redesign together also leaves you unable to tell which of the two caused a traffic drop.