Define what is moving
A hosting move, a domain change and a complete rebuild are different projects. Write down which are involved. Changing the design does not require changing every URL. Keeping suitable established addresses reduces avoidable mapping and redirect work.
List the services attached to the domain, including email, forms, booking software and any external verification records. A website move should not accidentally interrupt a service that was outside the project brief.
Before the new site is ready
- Inventory existing URLs using the site, sitemap and available search or analytics data. Include important files and campaign destinations.
- Decide which content stays, improves or is genuinely retired. Map each moved URL to the most relevant replacement rather than sending everything to the homepage.
- Record existing titles, canonical targets and indexing directives so important settings can be compared.
- Make recoverable copies of the website and any changing data. Agree who can authorise launch and who can reverse a failed release.
- Prepare a test environment with appropriate access restrictions. Track those restrictions explicitly so they are not carried into production.
Test the customer journey before switching
Use representative devices and browsers. Check navigation, forms, confirmation screens, telephone links and booking or checkout handovers. Verify the receiving system, not just the message shown in the browser. For a dynamic application, agree how records created during the transition will be handled.
Test redirects against the URL map and inspect the final destination. Check that pages intended for search return the correct content and use the right canonical. Confirm internal links point directly to the intended URLs. Google’s site-move guidance covers URL mapping, redirects and search monitoring.
| Check | Evidence to record |
|---|---|
| Domain and HTTPS | The intended domain loads securely without unexpected redirects. |
| Indexing settings | Public pages are accessible and accidental staging restrictions are removed. |
| Old addresses | Important old URLs reach the agreed replacement or an intentional removal response. |
| Enquiries and transactions | Test requests reach their destination and the receiving team confirms them. |
| Email and other services | Existing domain-dependent services still operate. |
| Recovery route | The team knows who can act if a serious fault appears. |
After launch, watch for specific failures
Review missing-page responses, important customer journeys and search data. Compare the same URLs and query groups where possible. Search visibility can fluctuate around a move; diagnose patterns before making more unrelated changes. Keep a release log so a later issue can be tied to what changed.
Do not retire the previous infrastructure until required checks and recovery arrangements are satisfied. Keep redirects in place for as long as they are needed, rather than treating them as a launch-week task. Submit the current sitemap through the established search-management process where you have access.
If traffic or enquiries fall
First verify the practical journey and the tracking. Then review URL mappings, indexing controls and removed content. The search visibility troubleshooting guide separates traffic changes from indexing problems; the enquiry guide helps when visits continue but messages stop.
If a migration is part of changing supplier, use the handover checklist to establish account control before launch. If the reason for replacement is still uncertain, settle the redesign-versus-rebuild decision first.
Plan a relaunch with fewer unknowns
Send the current website, the intended changes and any fixed launch date. We can discuss the migration work alongside a new website brief.