01
Create the inventory before changing URLs
List existing service pages, useful articles, downloads and high-value entry pages. Include enquiry forms, payment or booking connections and account owners. A migration plan should explain where each important item will go; a homepage redirect is not a substitute for mapping distinct useful pages.
02
Approve the new site in a protected preview
Review the content and business workflows before switching public traffic. Confirm that preview access and indexing controls are appropriate, then ensure any launch-only indexing blocks are removed from the public version. The responsible developer should document which controls change at release.
- Compare service names, contact details and important claims.
- Test representative mobile and desktop journeys.
- Confirm required content and files are present.
03
Assign a release owner and a rollback decision
Agree who changes hosting or domain settings, who tests immediately afterwards and who decides whether to roll back. Record a recoverable backup and the limits of recovery, especially where orders or new enquiries may arrive during the change. Do not assume a backup has been tested simply because a file exists.
04
Check discovery after release
Review HTTP status, canonicals, redirects, sitemaps and indexing controls. Monitor Search Console and real customer journeys after launch. These checks reduce avoidable errors but do not guarantee unchanged rankings; search systems can take time to process a changed site.
