Website Migration SEO Checklist: 30 Steps to Protect Rankings During a Site Move

Every website migration carries the same risk: you can do 95% of it right and still lose most of your organic traffic because of one missed redirect or an unsubmitted sitemap. Migrations don't fail gradually — they fail on launch day, and recovery can take months even when the fix is simple.

This checklist covers 30 items across five areas: pre-migration planning and audit, URL mapping and redirects, technical foundations, content preservation, and post-launch monitoring. It's built for in-house SEOs, developers, and founders planning a domain move, CMS switch, replatform, or redesign who need a clear go/no-go signal before flipping the switch. Work through each section, or use the interactive tool below to score your migration plan in 10-12 minutes.

Pre-Migration Planning & SEO Audit

Most SEO website migrations become a headache because no one knows what's currently working, which pages matter most, or how success will be measured afterwards. Proper pre-migration planning is the difference between a smooth cutover and spending the post-launch period trying to figure out what broke instead of fixing it.

Crawling and Inventorying the Existing Site

Before you can map anything, you need a complete picture of what exists. Run a full crawl of the live site to capture every indexed URL, including pages that don't appear in the main navigation — orphaned pages, old campaign landing pages, and paginated archives are the ones most often forgotten and most likely to break.

Benchmarking Rankings and Traffic

You can't measure migration damage without a baseline. Record current rankings for priority keywords, organic traffic by page, and conversion data for at least the past three months. This is the dataset you'll compare against for weeks after launch to confirm the migration held.

Identifying Top-Performing Pages and Backlink Targets

Some pages carry a disproportionate share of your organic value — either through rankings, traffic, or inbound links. Flag these explicitly so they get extra scrutiny during redirect mapping and QA. Losing a page that ranks for a head term is a very different problem to losing a thin blog post.

Defining a Timeline and Rollback Plan

Migrations should have a documented sequence: when DNS switches, when the old site goes read-only, and what triggers a rollback. Without this, "we'll fix it after launch" becomes the default plan, and SEO issues compound for days before anyone notices.

Staging the New Site with Noindex

The new site needs to be fully built and testable before launch — but it must not be indexable while it's there. A staging environment without proper noindex tags or robots blocking risks duplicate content competing with the live site, or worse, the staging version getting indexed instead of the real one.

URL Mapping & Redirect Strategy

Search engines don't automatically understand where your old pages moved. If redirects are incomplete, misconfigured, or missing entirely, rankings, backlinks, and traffic can disappear overnight. Here are the checkpoints that protect your URLs.

Building a Complete 1:1 Redirect Map

Every URL from the crawl in section one needs a destination on the new site — not a blanket redirect to the homepage. A 1:1 map (or as close as structurally possible) is the single highest-impact piece of migration work, and it should be built from the actual URL inventory, not from memory of "the important pages".

Implementing 301s, Not 302s

Permanent redirects (301) tell search engines to transfer ranking signals to the new URL; temporary redirects (302) don't, and search engines may keep the old URL indexed indefinitely. Check the redirect type at the server or platform level — many CMS SEO migration tools default to 302 without making this obvious.

Eliminating Redirect Chains and Loops

A URL that redirects to another redirect, which redirects again, adds crawl delay and can eventually break entirely. Audit the full redirect map for chains longer than one hop and collapse them to a single direct redirect from old URL to final destination.

Testing Redirects Before Launch

Every redirect in the map should be tested against the staging environment — not assumed to work because the rule was written correctly. Spot-checking a handful of "important" URLs isn't enough; bulk-test the full map with a crawler against staging so chains, loops, and 404s surface before go-live, not after.

Handling Parameters and Legacy URL Patterns

Old sites often have URL parameters, trailing slashes, uppercase variants, or legacy patterns from a previous platform that still receive traffic or hold link equity. Decide explicitly how each pattern is handled in the redirect map — don't let edge cases fall through to a default 404.

Technical Foundations

Even a perfectly designed website can become invisible to search engines if the technical setup isn't handled correctly. A single mistake in robots.txt, canonicals, HTTPS configuration, or sitemap management can undermine months or years of SEO work. These checks help ensure search engines can crawl, understand, and trust the new site from day one.

Regenerating and Submitting the XML Sitemap

The sitemap should reflect the new site's URL structure exactly, with no old URLs and no staging URLs left in it. Submit the new sitemap in Search Console as part of the launch sequence, not as an afterthought days later — it speeds up discovery of the new structure.

Reviewing Robots.txt for the New Environment

Robots.txt rules written for a staging or development environment sometimes get carried into production by accident, blocking search engines from crawling the live site entirely. Check this file the moment the new site goes live — it's one of the most common causes of a sudden, total traffic collapse post-migration.

Updating Canonical Tags to New URLs

Canonical tags should point to the new URL structure, self-referencing correctly on every page. Leftover canonicals pointing to the old domain or old URL patterns send mixed signals and can cause the new pages to be ignored in favour of URLs that no longer exist.

Migrating and Validating Structured Data

Schema markup — product, article, FAQ, breadcrumb, or organisation data — needs to carry over and validate cleanly on the new platform. CMS migrations frequently drop or mangle structured data, so test key page types with a schema validator rather than assuming a like-for-like rebuild preserved it.

Confirming SSL and HTTPS Configuration

If the migration includes a domain change or hosting move, certificate configuration needs to be correct from the first request — mixed content warnings or certificate errors at launch erode trust signals and can affect crawling. Confirm HTTPS is enforced site-wide with no HTTP fallback left active.

Content & On-Page Preservation

A migration should move your SEO assets, not reset them. Title tags, headings, internal links, content depth, and image data all contribute to rankings, and losing them during a rebuild can cause pages to decline even when redirects are flawless. This matters on any platform, whether you're migrating from WordPress to React or vice versa.

Carrying Over Title Tags and Meta Descriptions

A platform migration is not the moment to silently rewrite every title tag — that's a separate project with its own testing. Unless a deliberate on-page SEO refresh is planned and resourced, titles and meta descriptions should transfer unchanged so rankings aren't disrupted by two changes at once.

Preserving Heading Structure on Key Pages

New templates often restructure H1/H2/H3 hierarchy for design reasons, sometimes demoting the page's main heading or removing it altogether. Check that priority pages retain a single, clear H1 and a heading structure that still reflects the page's topic.

Rebuilding Internal Linking

Internal links are frequently the most-overlooked casualty of a migration — contextual links inside body content don't get remapped by automated tools the way navigation and redirects do. Audit a sample of migrated pages for broken internal links pointing to old URL patterns.

Preserving Image Alt Text and File Names

Image search traffic and accessibility both depend on alt text and descriptive file names surviving the move. Bulk image migrations sometimes strip alt attributes or rename files to generic CMS-assigned strings — check a sample of image-heavy pages specifically.

Protecting High-Value Content from Thinning

"Simplifying" or "modernising" content during a redesign often means cutting word count, removing sections, or merging pages — and that's exactly the content most likely to be ranking well already. Flag top-performing pages from section one so editorial changes to them get SEO sign-off before launch.

Post-Launch Monitoring & Recovery

Launching the new site isn't the finish line — it's the beginning of the validation phase. Some migration issues only reveal themselves after search engines start crawling and processing the new setup. The faster you identify traffic drops, indexing problems, or broken redirects, the easier and cheaper they are to fix before they become long-term ranking losses.

Updating Search Console and Verifying Ownership

If the domain or subdomain has changed, a new Search Console property needs verifying, and a change-of-address request should be filed where applicable. Without this, you're flying blind on index coverage and crawl errors for the new site precisely when you need that data most.

Monitoring Index Coverage for Errors

Watch the index coverage report daily for the first two weeks post-launch. A spike in "not found" or "crawled, not indexed" pages is an early warning sign that something in the redirect map or technical setup is wrong — catching it in days rather than weeks limits the damage.

Tracking Rankings and Traffic Against Baseline

Compare daily rankings and organic traffic against the baseline data captured before migration. Some short-term fluctuation is normal as search engines reprocess the site, but a sustained drop beyond the normal range across multiple pages signals a structural problem, not noise.

Fixing Crawl Errors and Broken Links Promptly

404s, server errors, and broken internal or external links discovered post-launch should be triaged and fixed within days, not left for the next sprint. Each unresolved error is either a lost redirect opportunity or a dead end for both users and crawlers.

Defining Triggers for the Recovery Plan

Decide in advance what traffic or ranking drop triggers escalation — for example, a 20% drop in organic sessions sustained for three days. Having this threshold agreed before launch means the team reacts to data immediately rather than debating whether a drop is "normal" while it gets worse.