Website Migration SEO Checklist: What to Verify Before Launch

A website migration SEO checklist should establish where each important old page will go, verify that its destination works, and assign responsibility for checking search performance after launch. Checking only the homepage leaves the rest of the move untested.

This guide applies to domain moves and changes to page addresses during a CMS replacement or website rebuild. If your hosting changes while public URLs stay identical, use a hosting migration plan instead. The checks below reduce avoidable implementation mistakes, but they cannot guarantee unchanged rankings or traffic.

Define the move and capture a baseline

Before approving development, write a short migration brief. List the domains or paths that change, the content that stays and the pages that merge. Name the person who approves exceptions. Separate essential changes from improvements that can wait.

Google recommends making major changes sequentially where practical, and warns that search visibility can fluctuate while it processes a move. See its site migration guidance. A domain change, redesign and extensive content rewrite together make later diagnosis harder.

Create a baseline for the pages that matter commercially. Record organic landing-page visits, Search Console clicks and impressions, and the enquiries or purchases attributed to those pages. Save comparable periods and note campaigns or seasonal demand that could distort comparisons.

Record the current customer journeys too: can visitors open a brochure, reach a product detail page and submit an enquiry? Assign separate owners for search checks and customer journeys. An indexing issue and a broken form require different responses.

Map old URLs to relevant destinations

Create a reviewable URL mapping sheet with columns for old address, proposed destination, intended action, page owner and verification status. Start with your CMS inventory, then reconcile it against analytics, sitemaps and known external links.

Content reviewers need to understand the mapping as well as developers do. Add a plain-language reason for every merger or removal. For example, two overlapping maintenance pages could lead to one consolidated maintenance guide, provided the replacement actually covers both subjects.

Record the decision for each page:

• For a retained page, preserve its address where practical or map it to the equivalent replacement.
• When merging content, confirm that the consolidated destination answers the old page's main question.
• Record each retirement decision explicitly and check whether a relevant replacement exists.
• For a moved download, test the actual document destination, including links from surviving pages.

Do not treat a homepage redirect as a universal fallback. Google warns that irrelevant destinations can confuse visitors and may be treated as soft 404s. Have the content owner approve ambiguous mappings before implementation.

For existing broken-link problems, the guide to auditing redirect chains and lost backlinks provides a useful companion review.

Use this table to check the mapping before launch:

Verify permanent redirects and their destinations

For permanently moved public pages, ask engineering to implement server-side permanent redirects where possible. Google's redirect documentation recognizes both 301 and 308 responses as permanent redirects, with the destination serving as a canonicalization signal.

Test the old address and its destination. Does the old address return the intended redirect? Does the final page contain the right content? A technically valid response can still send a visitor to an unsuitable page.

Check representative examples from every rule pattern, plus individual exceptions. Include trailing slashes, older campaign addresses and any parameters that change page content. Test for loops and unnecessary intermediate stops.

Check request handling separately from search signals. MDN's explanation of 308 redirects states that they preserve the request method and body. If rules touch forms or application endpoints, have engineering verify their behavior separately. Choosing a permanent status for search purposes does not establish that a submission workflow still works.

Check canonical URLs, links and sitemaps together

Inspect the final production configuration, including values inherited from staging. A template can display the correct page while naming an old domain as its preferred address.

Google describes redirects and canonical annotations as strong canonicalization signals, while sitemap inclusion is weaker. Its canonical URL documentation advises consistent signals and internal links to preferred URLs.

Before release, check the following:

• Confirm that important destination pages return successful responses and show their intended content.
• Check that canonical annotations identify the intended production URLs.
• Update navigation, contextual links and download links to final destinations.
• Check that the new sitemap contains intended canonical URLs.
• Remove development indexing restrictions from pages intended for search.
• Verify that production settings do not expose staging addresses in generated links.

Check each template, then investigate exceptions across the pages using it. The existing technical crawl auditing guide offers related context for ongoing discovery checks.

Check whether Search Console Change of Address applies

For a qualifying domain or subdomain move, Google's Change of Address documentation says to use the tool after moving and redirecting the site. It requires ownership of both properties under the same Google account.

The tool is not intended for path changes within one site, HTTP-to-HTTPS moves, or switches between www and non-www on the same domain. Record whether your move qualifies rather than adding the task to every launch plan automatically.

Homepage-only approval leaves deeper pages untested. Bulk mappings also need content review, and settings checked on staging must be checked again in production. Another is assuming a successful Change of Address request validates every page. Keep page-level acceptance checks in the launch plan.

Avoid removing functioning redirects simply because the new site has launched. Google recommends retaining them for at least a year, and longer where useful for visitors. Include their continued operation in the handover responsibilities.

Assign migration monitoring and unresolved issues

After launch, review outcomes by page group: services, products, articles and downloads. Compare combined old and new landing-page activity so that disappearing old addresses are not automatically mistaken for lost demand.

Use a simple issue register containing the affected page group, observed symptom, supporting evidence, owner and next review date. Separate confirmed defects, such as a redirect loop, from visibility changes that still need investigation.

Agree on escalation triggers before launch. Examples include failed enquiry journeys, widespread incorrect destinations or a production template carrying an unintended indexing restriction. Traffic movement alone needs context from demand, measurement continuity and page-level checks.

Have the content owner and engineering lead review the URL mapping sheet together. Approve the destinations, assign unresolved exceptions and schedule the production verification window before setting the launch date.