The first visit to a redesigned website might begin with an old search result, not the new homepage. If that link leads to a missing service page, the refreshed design offers little help. A contact form that accepts an enquiry but never delivers it creates a quieter failure.

Migration sign-off needs evidence that existing routes, search access and customer journeys still work.

1. Set the scope and assign responsibility

Record whether the project changes hosting, the domain, page addresses, content or the content management system. For a hosting move that preserves URLs, test availability and functionality; the change of server alone requires no redirects. A redesign that removes or reorganises pages also needs a URL transition plan.

For a business searching for web development manchester, URL mapping and launch testing belong in the brief alongside design requirements.

Assign responsibility for those tasks and subsequent fixes. Agree who can approve launch, who can pause it and what test results they need to make that decision.

2. Save a usable baseline

Before replacing the existing site, create a URL inventory with a crawler, which follows links and records pages. Supplement it with the XML sitemap, Search Console data and analytics records to capture addresses that have slipped out of navigation.

Record which landing pages attract search visitors, which queries bring them in and which pages generate enquiries or sales. Save page titles and useful content so that material customers need survives the redesign.

Give commercially valuable pages extra manual attention while accounting for the full URL inventory. Keep dated exports and record the launch date: these provide a starting point for investigating later changes.

3. Map old addresses to relevant replacements

Build a mapping sheet listing each existing URL, its intended outcome and its replacement where appropriate. If `/workplace-training` becomes `/training/workplace`, for example, the old address should redirect to the equivalent new page.

Use a permanent server-side redirect, such as a 301, for a permanent move. Test the response and destination, recording whether each redirect reaches the correct working page in a single step. A completed spreadsheet is the plan; the test results show whether it works.

For deleted content with no relevant replacement, an appropriate 404 (not found) or 410 (gone) response is preferable to a blanket redirect to the homepage.

Update internal links to point straight to final URLs, leaving redirects to handle visits through old links and bookmarks.

4. Test the site you will actually launch

Protect the staging copy, where development testing takes place, with access controls. Check the launch configuration for leftover `noindex` instructions and unwanted `robots.txt` restrictions on intended public pages. These controls serve different purposes: `noindex` tells search engines to exclude a page from their index; `robots.txt` restricts crawling and does not reliably keep an address out of search results.

Request a crawl comparison showing missing pages, broken links and unexpected redirects. Check canonical URLs, which signal the preferred version of a page, and ensure the XML sitemap lists intended live addresses rather than staging URLs.

Test customer journeys end to end. Submit an enquiry and confirm receipt in the correct inbox or system. Complete a test checkout where relevant, try mobile navigation and verify that analytics records the expected activity.

Treat missing priority pages, accidental indexing exclusions and failed enquiry routes as launch blockers. Repeat essential checks on the live site immediately after switching over to confirm that the deployment succeeded.

5. Monitor changes and know when to act

Name the person checking Search Console, analytics and enquiry records after launch, with a route for escalating faults. Compare priority landing pages as well as site-wide totals, using comparable periods and allowing for seasonal differences.

When analytics traffic falls sharply, check tracking first. Then inspect search clicks, page accessibility and indexing. If visits remain stable but enquiries fall, test forms and customer journeys. Search clicks, recorded visits and actual enquiries measure different things; compare their trends rather than expecting matching totals.

Search engines need to revisit changed pages, and visibility can fluctuate without a universal recovery timetable. Use technical evidence to decide which changes need a fix and which warrant further monitoring.

For critical failures, agree who can restore service and how new orders or enquiries will be preserved during any rollback. The handover should leave named people responsible for a tested URL map, a launch record and a clear route for fixing faults.