Website migration checklist

1. Capture the existing site

Record the public URLs you intend to preserve or replace. For each important page, note the HTTP status, title, main heading, canonical URL and indexing directives. Include sitemap URLs and pages linked from navigation, but add important unlinked pages manually.

Keep this baseline unchanged so later scans can be compared against the same point in time. A partial inventory is still useful, but label its coverage clearly rather than treating it as a full audit.

2. Make a decision for every old URL

Assign each old page a destination or an explicit removal decision. Pages that stay at the same address, pages moving to a relevant new page and pages being retired need different treatments. Avoid a catch-all redirect to the homepage: it hides missing decisions and often disappoints visitors.

Use a redirect map that records the old URL, intended final URL, action and reason. Have someone review it before launch.

3. Review the replacement on staging

• Check mapped destinations for missing pages and server errors.
• Compare titles and main headings; intentional copy changes should be reviewed, not automatically called failures.
• Look for canonical tags pointing at staging and internal links to missing pages.
• Check the launch plan for any staging noindex directive; it should not remain on production.

A staging scan cannot prove that live redirects work. Save redirect validation for the live site.

4. Verify after launch

Request the old URLs again and confirm that expected moves use permanent redirects, reach the approved destination and do not loop or take unnecessary hops. Check that live pages load, can be indexed when intended, and declare the correct canonical URL.

Recheck fixes against live responses. A resolved issue should be backed by a successful new request rather than an unchecked assumption. Follow the post-launch SEO checklist for the detailed handoff.

5. Report the coverage and limitations

Share which URLs were discovered, requested, fetched and compared, alongside pages that could not be tested. A timeout or blocked page is not a passing result. PixelReplica checks public HTML only; JavaScript-rendered content and protected staging sites need a separate manual or browser-based review.

See how findings and coverage are presented in the sample report.