Technical SEO

SEO Migration Checklist

A practical checklist for preserving crawlability, indexability, rankings, analytics, and conversion paths during a website migration or redesign.

An SEO migration is any release that changes how important URLs are discovered, rendered, indexed, understood, or measured. Redesigns, CMS moves, domain changes, URL changes, platform changes, and large content restructures all count.

The goal is not to avoid all fluctuation. The goal is to protect the pages and signals that matter, then monitor the launch tightly enough to catch regressions quickly.

Migration types

Migration TypeSEO Risk
Domain changeHigh risk for redirects, canonical signals, brand queries, backlinks, and Search Console data.
URL structure changeHigh risk for redirect mapping, internal links, sitemap cleanup, and lost long-tail URLs.
CMS or platform changeRisk for rendering, metadata, schema, canonicals, redirects, page speed, and tracking.
RedesignRisk for content removal, heading changes, internal links, UX, conversion paths, and JavaScript rendering.
Content consolidationRisk for lost query coverage, weak redirect targets, and missing internal links.
International or locale changeRisk for hreflang, canonicals, language targeting, and regional URL mapping.

The more signals change at once, the more careful the release needs to be.

Pre-migration inventory

Export the current site before changing it:

  • Crawlable URLs.
  • Indexable URLs.
  • XML sitemap URLs.
  • Organic landing pages.
  • Top pages by clicks, impressions, conversions, and links.
  • Current title tags, meta descriptions, canonical tags, headings, and status codes.
  • Existing redirects.
  • Backlinked URLs.
  • Important internal links.
  • Structured data coverage.
  • Analytics events and conversion paths.

Keep the exports. They become the comparison set after launch.

URL mapping

Every valuable old URL needs a decision:

Old URL DecisionUse When
KeepThe page still exists with the same URL and purpose.
Redirect 1:1The content moved to a clear equivalent page.
ConsolidateSeveral similar pages should point to one stronger destination.
Return 404 or 410The page has no useful replacement and no meaningful value.
NoindexThe page is useful for users but should not appear in search.

Redirects should preserve intent. Do not redirect every removed URL to the homepage. A weak redirect target can act like a soft 404 and frustrate users.

Staging checks

Before launch, test staging or preview URLs:

CheckRequirement
RobotsStaging can be blocked, but production launch rules must be ready.
Status codesImportant pages return 200; removed URLs have planned destinations.
RedirectsOld-to-new mappings work with minimal hops.
CanonicalsCanonical tags point to the final production URL, not staging or old URLs.
MetadataTitles, descriptions, headings, and page copy survived the move.
Internal linksNavigation and body links point to final URLs, not old or staging URLs.
Rendered HTMLPrimary content and links are visible after rendering.
SchemaJSON-LD remains valid and matches visible content.
SitemapsXML sitemaps include only canonical, indexable production URLs.
AnalyticsPage views, events, form submissions, and conversions still fire.

Do not launch with known staging canonicals, blocked production paths, or missing redirects.

Launch checklist

On launch day:

  1. Remove production robots blocks that were only for staging.
  2. Deploy redirects.
  3. Verify top old URLs redirect to the right new URLs.
  4. Verify top new URLs return 200.
  5. Verify canonicals point to production canonical URLs.
  6. Verify XML sitemaps are live and reference final URLs.
  7. Verify internal links use final URLs.
  8. Verify analytics and conversion tracking.
  9. Verify forms, calls, booking links, tool submissions, and key CTAs.
  10. Submit or refresh sitemaps in Search Console and Bing Webmaster Tools.
  11. Annotate the migration date in reporting.

Keep the old crawl and the new crawl side by side.

Post-launch monitoring

WindowChecks
First 24 hoursStatus codes, robots, canonicals, redirects, analytics, top pages, forms.
First weekCrawl errors, indexed URL samples, sitemap processing, ranking volatility, lead paths.
Weeks 2-4GSC clicks and impressions by page group, redirect hits, missing old URLs, query coverage.
Months 2-3Recovery trend, backlink target updates, content gaps, internal-link refinements.

Monitor page groups, not just total sessions. A homepage can recover while product, service, or local pages remain damaged.

High-risk mistakes

  • Launching with noindex or robots blocks from staging.
  • Canonical tags pointing to old URLs or staging URLs.
  • Redirecting many distinct pages to one generic page.
  • Removing content that supported long-tail rankings.
  • Changing URLs, content, templates, and tracking at the same time without backups.
  • Forgetting image, PDF, or asset URLs that earn links.
  • Leaving internal links pointed at redirected URLs.
  • Failing to preserve analytics events and conversion tracking.
  • Not monitoring Search Console after launch.

Migration report

After launch, maintain a simple report:

FieldNotes
Migration dateExact release date and time.
Migration typeDomain, URL, CMS, redesign, content consolidation, or mixed.
URL map statusCount of kept, redirected, removed, and unresolved URLs.
Top page statusSample of important pages and their current status.
GSC trendClicks, impressions, pages, queries, countries, and devices.
Issues foundCrawl, index, redirect, canonical, rendering, tracking, or conversion issues.
Fixes shippedDate, owner, affected page group.
Next decisionMonitor, fix, revert, consolidate, or expand.

If traffic drops after launch, use the Traffic Drop Diagnosis workflow before assuming the migration failed completely.

Related concepts to validate during a migration include Redirects, XML Sitemap, Canonical URL, and Hreflang for international sites.

For URL-level planning, use the Migration Redirect Map Template.

Useful source references