A website migration is not finished when the new homepage loads. Existing URLs must lead somewhere deliberate, enquiries must still reach the business, analytics must remain interpretable and search engines need consistent signals about what changed.
This runbook covers a move where URLs, platform, domain or structure may change. If the project also includes a complete redesign and new content, separate those decisions where practical. Google’s published guidance recommends changing one major thing at a time because it makes problems easier to isolate.
Four weeks before launch: create the inventory
Crawl the current public site and export URLs from the sitemap, analytics, Search Console, backlink data and any platform database. Include PDFs, campaign pages and pages that are not in the main navigation.
For each old URL, choose one outcome:
- Keep the same URL and replace the content.
- Move it to one closely matching new URL.
- Consolidate it into a genuinely equivalent resource.
- Remove it and return a correct 404 or 410 response.
Do not redirect every removed page to the homepage. That hides missing content from users and makes the mapping less meaningful.
Three weeks before launch: build the redirect map
Use server-side permanent redirects—normally HTTP 301 or 308—for URLs that have moved permanently. Keep query parameters only when they are still meaningful and prevent redirect chains such as old URL to temporary URL to final URL.
Test the map automatically and inspect important examples manually. The final response should be the intended page, not a soft error containing a friendly message with a 200 status.
Two weeks before launch: test the new site away from search
Use a protected staging environment or another method that prevents premature indexing. Confirm canonical URLs, titles, descriptions, headings, structured data, internal links, image alternatives, robots rules and sitemap generation.
Test forms and transactions end to end. A successful browser message is not enough: verify email delivery, CRM creation, payment status, invoice generation and any retry process. Record test orders so they can be removed from commercial reporting.
One week before launch: prepare operations
- Lower DNS time-to-live where the provider and plan allow it.
- Confirm domain, DNS, hosting and certificate access.
- Take restorable backups of the old site and relevant databases.
- Freeze or document content changes that occur during the final migration window.
- Prepare the redirect configuration and rollback decision.
- Tell support and sales teams what may look different.
- Choose a lower-traffic launch window where possible.
Launch day: work from a written sequence
- Capture the final old-site data and content changes.
- Deploy the new application and redirect rules.
- Verify HTTPS and the preferred hostname.
- Test priority old URLs, new URLs and removed URLs.
- Submit real internal form and transaction tests.
- Confirm analytics and consent behaviour.
- Publish the new sitemap and verify robots rules.
- Check server logs and monitoring before announcing completion.
Assign one person to call the rollback decision. A launch can continue with a minor display issue; it should not continue quietly when payments or enquiries are being lost.
The first 72 hours: look for patterns
Monitor 404s, redirect errors, server failures, form deliveries, conversion counts and crawl activity. Compare top landing pages with the URL map. Fix a systematic rule before patching hundreds of individual symptoms.
Keep the old hosting or backup available until recovery confidence is established, but prevent duplicate public versions from competing with the intended site.
The following weeks: let recrawling happen
Google states that ranking fluctuations can occur while pages are recrawled and reindexed. Use Search Console and the sitemap to observe progress. Keep permanent redirects in place for as long as they remain useful; do not remove them after a few days because the launch appeared successful.
Review enquiries and sales quality, not only sessions. If traffic is present but the contact journey changed, a technical migration may still have created a commercial problem.
Sources and further reading
- Google Search Central: site moves and migrations — the primary source for URL mapping, sequencing, sitemaps, monitoring and expected recrawling.
- Google Search Central: redirects and Google Search — Google’s technical reference for permanent and temporary redirect methods.
Xapner can scope migrations through its website maintenance or development services. The written scope should identify who owns redirects, data migration, DNS, testing and post-launch support.