Website migration SEO checklist: before, during and after launch

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

Turn the checklist into owned decisions

A useful plan names who decides, who builds and who verifies. Product and editorial owners decide which pages and journeys the destination must serve. Engineering owns implementation of redirects, rendering and release controls. Analytics owns continuity of measurement. Search advice connects those decisions to risk and evidence; it cannot replace the people who control the platform.

For each phase, write down the required output and the evidence that will prove it is ready. Before build, that may be a signed-off change inventory and page-group baseline. Before launch, it is a tested URL map, rendered-template checks and a list of release blockers. After launch, it is a segmented monitoring report and an issue log with owners. A checked box without an artefact is only an assertion.

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.

Use the redirect-map testing method to turn those destination decisions into a repeatable URL-level check.

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.

If the move also replaces the publishing platform, the CMS migration requirements give the team a more detailed content-model and template acceptance list.

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.

Run a rehearsal and define go or no-go criteria

A rehearsal tests the sequence as well as the website. Run the redirect validation, crawl, analytics checks and priority journeys against a production-like environment. Record how long each check takes, what evidence it produces and who can make a release decision.

Agree the defects that must block launch. A missing redirect on one low-value retired page is not equivalent to sitewide noindex, broken canonicals or absent analytics. Clear thresholds prevent both avoidable launches and last-minute panic over minor issues.

The rehearsal should also test rollback and communication. The team needs to know which changes can be reversed safely, which need a forward fix and how incidents will be reported without several people working from different assumptions.

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.

Document the corrective action and the evidence expected if it works. Some fixes can be validated immediately through crawling or rendered HTML. Search reprocessing takes longer, so define leading technical checks separately from later visibility and traffic outcomes.