Website migration checklist

A safe website migration starts with a complete inventory and a tested rollback path. Preserve URLs where possible; where they must change, map every valuable old URL to the closest relevant new URL with a permanent server-side redirect. Launch only after content, analytics, forms, canonical tags, robots rules and backups have been checked.

Scope and limitations

This checklist covers a typical move between hosting environments, content management systems, HTTPS configurations or domains. It is not a substitute for an application-specific deployment plan. Complex applications, payment systems, regulated data, custom authentication, email migration, multi-region infrastructure and large domain changes may require separate engineering, security, privacy or legal review.

Do not combine an avoidable redesign, CMS replacement, domain change and URL restructure into one release. Fewer simultaneous variables make faults easier to identify and reverse.

Phased migration checklist

1. Inventory and baseline

Export all indexable URLs from the sitemap, CMS, analytics, Search Console and a crawl.
Record status, canonical, title, description, H1, structured data, hreflang and internal links for each important URL.
Identify forms, logins, checkout paths, scheduled jobs, APIs, webhooks, DNS records and third-party integrations.
Save current traffic, conversion, ranking and crawl-error baselines.
Create verified file and database backups and document the exact rollback procedure.

2. Build and validate the destination

Keep the staging site inaccessible to search engines and unauthorised visitors without carrying those blocks into production.
Preserve successful URLs; create an explicit one-to-one redirect map for changed URLs.
Reproduce essential metadata, structured data, language alternates, XML sitemaps and robots rules.
Test the destination with production-like PHP, database, caching, TLS and web-server settings.
Run functional tests for navigation, search, forms, accounts, payments and integrations that are actually in scope.

3. Cut over deliberately

Lower DNS TTL in advance only when a DNS change is planned and the authoritative provider supports it.
Freeze content or record the final content delta before the last database synchronization.
Enable permanent redirects, then verify representative and high-value URLs before opening traffic.
Remove temporary noindex, authentication or robots blocks from the public destination.
Update internal links, canonicals, hreflang, sitemaps and structured-data URLs to their final destinations.

4. Verify and monitor

Crawl old and new URL lists; reject redirect chains, loops, soft 404s and redirects to irrelevant pages.
Check server logs, application errors, forms, conversions, analytics collection and important user journeys.
Submit the new sitemap and use URL Inspection for representative pages.
Monitor indexing, crawl errors, traffic and conversions against the recorded baseline.
Keep useful permanent redirects for at least the period recommended by search-engine guidance and update controllable backlinks.

Website migration FAQ

Should every old URL redirect to the home page?

No. Redirect an old URL to the closest genuinely equivalent destination. If no useful replacement exists, a clear 404 or 410 can be more accurate than an irrelevant home-page redirect.

Can staging use noindex?

It can, but access control is stronger because it prevents public crawling. Whatever method is used, include its removal in the launch checklist and verify the rendered production response.

How long should redirects remain?

Google recommends keeping site-move redirects for as long as possible and generally at least one year. Users and old links can benefit from keeping valid redirects longer.