Guides

A Site Migration SEO Checklist That Protects Your Traffic

A site migration SEO checklist is the ordered set of tasks that keeps your organic traffic intact when you change your domain, your URL structure, your platform, or your site's design. The risk in any migration is not the new site. It is the gap between how search engines understood the old URLs and how they read the new ones.

Get the sequence right and a migration is nearly invisible to search engines. Get it wrong and you can lose rankings that took months or years to earn, often without an obvious cause. This checklist walks the three phases that matter: what to do before launch, what to verify on launch day, and what to watch in the weeks after.

What counts as a site migration

Migration is a broad word in SEO. It covers any change that alters the URLs search engines have indexed or the way they crawl them. Several distinct project types all qualify, and each one carries the same core risk to your existing organic traffic.

Domain changes, including a rebrand or a move to a new company name.

A switch from HTTP to HTTPS, or from www to non-www.

Replatforming, such as moving from one CMS to another where the URL patterns change.

A redesign that restructures navigation, consolidates pages, or renames URL paths.

Merging several sites into one, or splitting one site into several.

If none of your URLs change and nothing about crawling changes, you are running a redesign, not a migration. The moment a URL moves, you are migrating, and this checklist applies.

Before launch: map everything you have today

The pre-launch phase is where migrations are won or lost. You cannot protect rankings for pages you have not accounted for, so the first job is a complete inventory of what exists today.

Baseline the current site

Crawl the live site and export every indexable URL, not only the pages in your main navigation.

Pull your highest-traffic landing pages from analytics and Search Console so you know which URLs actually earn traffic and links.

Record current impressions and the queries each key page is known for, as a before picture to compare against later.

Build the redirect map

The redirect map is the single most important artifact of any migration. It is a spreadsheet with one row per old URL and the one new URL it should point to.

Map every old URL to its closest equivalent on the new site, one to one wherever possible.

Avoid chaining redirects or sending everything to the homepage, which discards the signals each page earned.

Use permanent 301 redirects for permanent moves, so the old URL's authority consolidates onto the new one.

Not every old URL will have a clean match. When several old pages collapse into one new page, point them all at that single destination and accept the consolidation. When a page is genuinely gone with no replacement, decide deliberately whether to redirect it to the most relevant parent or to let it return a 404, rather than leaving the choice to chance.

Carry the on-page signals across

Preserve or deliberately improve title tags, meta descriptions, headings, and body copy on migrated pages.

Keep structured data, canonical tags, and internal links intact on the new templates.

Rebuild the XML sitemap so it lists only the new canonical URLs.

Launch day: verify before you celebrate

Launch is a checklist, not a moment. Work through it in order, and do not call the migration complete until every item passes. The hour after a launch is also the cheapest time to catch a blocking error, so slow down here rather than rushing to announce.

Confirm the redirects fire correctly and return a 301, not a 302 or a soft 404, by spot-checking a sample across every URL pattern.

Make sure robots.txt is not accidentally blocking the new site, a frequent and quietly catastrophic mistake.

Check that any noindex tags left over from staging are removed from production.

Submit the new XML sitemap in Search Console, and for a domain change use the Change of Address tool.

Verify the new property in Search Console so you have data from the first hour.

One more launch check is easy to forget: confirm that internal links and canonical tags on the new pages point to the new URLs, not to the old ones or to a staging hostname. A page that canonicalizes to a dead staging address quietly tells search engines to ignore the version you actually shipped.

After launch: watch the recovery curve

Search engines need time to recrawl the site, follow the redirects, and reassign signals to the new URLs. Expect some movement in the first weeks. The job now is to catch problems while they are still cheap to fix.

Monitor crawl stats and coverage reports for spikes in errors, redirects, or newly excluded pages.

Watch for 404s that reveal URLs you missed in the redirect map, then add the missing rules immediately.

Compare live impressions against the baseline you recorded, page by page, not only in aggregate.

Keep the old domain's redirects live for the long term, because removing them early undoes the migration.

A clean migration usually settles within a few weeks. A sustained decline past that window is a signal that something structural is wrong, most often a redirect gap or an indexation block, both of which are findable.

The mistakes that actually cause traffic loss

Most migration failures are not exotic. They come from a short list of avoidable errors, and knowing them in advance is most of the defense.

Redirecting every old URL to the homepage instead of its true equivalent, which discards page-level relevance.

Launching with a staging robots.txt or a site-wide noindex still in place.

Changing URLs, templates, and content all at once, so that when traffic moves you cannot tell which change caused it.

Dropping the redirects after a month because the old domain looked quiet.

Treating the sitemap as decoration rather than the list that tells search engines what to crawl first.

A quieter, contrarian point: a migration is a poor time to also chase ranking gains. Change the URLs cleanly first, confirm the signals transferred, then improve. Stacking a content overhaul onto a structural move makes every problem harder to diagnose.

Where this fits our process

Because Ninetyfifth Marketing performs SEO only on sites it builds, a migration is planned into the build rather than bolted on afterward. The redirect map, the sitemap, and the Search Console setup are deliverables, not afterthoughts, and every old URL is accounted for before the new site goes live. You can read how the ongoing work is structured on the SEO service page.

Questions

What is a site migration in SEO terms?

It is any change that alters the URLs search engines have indexed or the way they crawl them. That includes domain changes, HTTP to HTTPS, replatforming, and redesigns that rename URL paths. A redesign that leaves every URL untouched is not a migration.

What is the single most important step in a site migration SEO checklist?

Building a complete redirect map before launch. Every old URL needs a permanent 301 redirect to its closest new equivalent. Miss this and you throw away the signals each page earned, which is the most common cause of post-migration traffic loss.

How long does it take to recover after a migration?

A clean migration usually settles within a few weeks as search engines recrawl and reassign signals to the new URLs. Some fluctuation in that window is normal. A decline that continues well past it points to a fixable problem, usually a redirect gap or an indexation block.

Should I migrate and redesign content at the same time?

It is safer not to. If you change URLs, templates, and content together and traffic drops, you cannot isolate the cause. Move the structure cleanly first, confirm the signals transferred, then improve the content as a separate step.

When can I remove the redirects from my old domain?

Not soon. Keep permanent redirects from the old URLs live well beyond the point where traffic looks settled. Search engines and old external links keep hitting them, and removing them too early undoes the consolidation the migration achieved.