A website migration changes more than design. URLs, redirects, templates, crawl directives, canonicals, internal links, analytics, sitemaps, and hosting behavior can all shift at once. A useful checklist turns those moving parts into evidence that can be reviewed before and after launch.
Use the checklist as a control log. Every item should answer five questions: what evidence proves the current state, what counts as pass or fail, how severe is failure, who owns the correction, and how will the team verify the fix after deployment.
The operating sequence in this resource uses three phases:
- Pre-launch, 8-12 weeks before: inventory, baseline capture, mapping, staging validation, and ownership.
- Launch day: production cutover checks, redirect verification, crawl access, measurement, and issue logging.
- Post-launch, 4-12 weeks after: comparison against the baseline, crawl and index monitoring, and revalidation of corrected issues.
The timing is a planning reference, not a universal requirement. A smaller migration may need less lead time, while a multi-system move may need more.
Use the migration mistakes guide to understand what each failed check can look like in practice. The checklist itself should remain evidence-driven so the team does not close an item simply because someone remembers doing it.