Website migration SEO checklist: before, during and after launch
A migration framework covering baselines, URL mapping, staging, launch control and the evidence needed to recognise problems quickly.
Written by Rob Knott
A migration checklist is useful only when it reflects the change being made. A domain move, redesign, CMS replacement and navigation restructure expose different risks. The first task is therefore to define what is changing, what must remain stable and who owns each decision.
The checklist below is a control framework rather than a promise that every migration will be risk-free. It is designed to help teams expose assumptions early, preserve important signals and recognise unexpected behaviour while there is still time to act.
Before delivery: define scope and establish the baseline
Inventory the changes across domains, protocols, URLs, content, templates, navigation, rendering, platforms and tracking. Separate intentional changes from incidental ones. Google recommends changing one major thing at a time where practical, because combining a domain move, CMS replacement and redesign makes later diagnosis harder.
Build a baseline by page group and template. Capture organic landing-page traffic, conversions, rankings, indexation, crawl behaviour, internal linking and known issues. Protect verification methods for Search Console and other essential services.
- Agree success measures and acceptable temporary movement
- Identify priority URLs, templates, queries and journeys
- Export the current URL population from several sources
- Record canonical, hreflang, metadata and structured-data behaviour
- Benchmark performance and rendered content on important templates
- Assign owners for redirects, content, analytics, infrastructure and QA
URL mapping: preserve meaning, not just destinations
Map each valuable old URL to the most relevant new destination. Avoid sending large groups of unrelated pages to the homepage. Where content has genuinely been removed and no equivalent exists, a real 404 or 410 response can be more accurate than an irrelevant redirect.
Test redirect chains, loops, parameters, case differences, trailing slashes and alternate hostnames. Update important internal links to use the final URLs so users and crawlers do not need to pass through avoidable redirects.
Staging: compare behaviour at template level
Protect staging from indexation without preventing the delivery team from testing it. Review rendered pages, status codes, canonicals, robots directives, sitemaps, internal links, pagination, faceted navigation, hreflang, structured data and analytics.
Compare representative old and new pages. Confirm that important content remains present and accessible, including text that now depends on client-side rendering or interaction. Test empty states, error states and less common templates, not only the homepage.
Launch: use an ordered control plan
A launch checklist should name the owner, timing and expected evidence for each check. Confirm DNS and certificate behaviour, robots controls, redirects, canonicals, sitemaps, analytics and priority journeys immediately after release.
Crawl both known old URLs and the new site. Sample redirects manually, inspect logs and use real-time analytics where available. Record issues, severity, ownership and the decision to fix, monitor or accept.
After launch: compare groups and investigate patterns
Google processes a site move URL by URL, so some fluctuation is expected. Compare page groups, templates and query types against the baseline rather than reacting to one aggregate line. Watch indexation, crawl errors, redirected URLs, traffic, conversions and rankings together.
Keep permanent redirects in place for at least the period recommended by search engines; Google advises at least one year and notes that keeping them longer can still help users. Submit the new sitemap and preserve the records needed to explain what happened later.
Recovery: diagnose before reversing everything
If performance drops, establish whether the pattern aligns with missing pages, redirect errors, changed content, rendering, internal links, tracking or broader demand. Compare the timing and affected groups. A disciplined baseline makes it possible to narrow the problem without guessing.
Key takeaways
- Define every material change and avoid combining unnecessary variables.
- Benchmark important URL and template groups before launch.
- Map URLs to relevant equivalents and test edge cases.
- Treat staging and launch checks as owned controls, not informal reminders.
- Monitor by page group and preserve the evidence needed for diagnosis.