Website Migration Runbook: Protect URLs, Search and Enquiries

Website migration A website migration needs a full URL map, safe release plan and close checks after launch.

The new homepage loads, everyone relaxes, and the migration is only half done. 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

1. Capture the final old-site data and content changes.
2. Deploy the new application and redirect rules.
3. Verify HTTPS and the preferred hostname.
4. Test priority old URLs, new URLs and removed URLs.
5. Submit real internal form and transaction tests.
6. Confirm analytics and consent behaviour.
7. Publish the new sitemap and verify robots rules.
8. 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. However, 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.

A migration timetable in practice

An independent lighting retailer moves 1,800 products to a new platform. The inventory turns up 1,840 live URLs: the extra 40 are old campaign landing pages nobody remembered.

The redirect map takes the longest. Roughly 1,500 products map one-to-one. About 240 discontinued lines have no equivalent. they are pointed at the nearest category rather than the homepage, because a shopper who lands on a category can still buy something. Sixty URLs are genuinely dead stock with no successor and return 410 rather than 301.

Launch happens on a Tuesday at 7am, deliberately: the quietest hour of the quietest trading day, with the whole team available rather than a Friday evening when nobody is. Organic sessions dip about 12% in week two and recover by week five, which is roughly what a clean migration of this size looks like.

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.

We 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.

Quick website migration action plan

1. Crawl the old site first. Write down the result. Name one owner.
2. Save every useful old URL. Test this step. Keep proof of the test.
3. Map moves to the best new page. Use real data. Check each fact.
4. Keep titles and core copy where needed. Ask one user. Note what feels hard.
5. Test redirects before DNS changes. Fix each fault. Run the check again.
6. Keep both sites backed up. Set a due date. Review the result.
7. Watch errors after the move. Write down the result. Name one owner.
8. Check forms and sales each day. Test this step. Keep proof of the test.
9. Choose one clear goal. Use real data. Check each fact.
10. Name the owner for each task. Ask one user. Note what feels hard.
11. Test the full path before launch. Fix each fault. Run the check again.
12. Set the next review date. Set a due date. Review the result.
13. Keep the plan where staff can find it. Write down the result. Name one owner.
14. Use plain words in each note. Test this step. Keep proof of the test.
15. Save proof for each key check. Use real data. Check each fact.
16. Fix one issue at a time. Ask one user. Note what feels hard.
17. Check the result with a real user. Fix each fault. Run the check again.
18. Remove work that does not help the goal. Set a due date. Review the result.
19. Share each major change with the team. Write down the result. Name one owner.
20. Run the same checks after each update. Test this step. Keep proof of the test.
21. Check the source of every key fact. Use real data. Check each fact.
22. Keep private data out of public notes. Ask one user. Note what feels hard.
23. Plan what to do when a check fails. Fix each fault. Run the check again.
24. Give each choice a clear reason. Set a due date. Review the result.
25. Keep old files until new work is proven. Write down the result. Name one owner.
26. Ask for help when the risk is high. Test this step. Keep proof of the test.
27. Check phone and desktop views. Use real data. Check each fact.
28. Make the next step easy to find. Ask one user. Note what feels hard.
29. Track the result that matters most. Fix each fault. Run the check again.
30. Close each task when proof is saved. Set a due date. Review the result.

Use this website migration plan as a live check. Keep the notes short. Review the work after each major change.