A new website should keep its useful connections.

Record the current starting point

Save an inventory of existing pages before agreeing the new structure. Use the current sitemap, a crawl and any available search or analytics reports. Identify commercially useful pages, incoming links and content that visitors still need.

Assign someone to review that list with the business. A developer can identify a URL, but may not know that it appears in a printed brochure, an active advert or an important customer email. Those connections deserve a place in the migration plan.

• Existing URLs and the purpose of each important page.
• Current search and enquiry data, where available.
• External campaigns and systems linking into the website.

Decide what stays and what moves

Keep established useful URLs when the page purpose remains the same. For changed URLs, prepare a direct mapping to the closest relevant replacement. Content without an equivalent needs an explicit decision rather than an automatic redirect to the homepage.

Review the mapping alongside the new navigation and content plan. A combined service page may need a different destination from a removed product, so the decision should follow what the old visitor expected to find.

Align the pages and search signals

Each indexable page should identify its preferred URL consistently. Check canonical links, internal links and the sitemap against the same route list. This is also the time to confirm titles, descriptions and a clear main heading.

A sitemap is a discovery aid, not a reason to include every exported file. Keep redirected and non-indexable URLs out, and only use modification dates that represent real content changes.

• One preferred URL for each distinct page.
• Navigation and contextual links to the preferred destinations.
• Metadata that matches the final content and page purpose.

Check staging and production separately

A staging site needs a reliable noindex directive. Blocking all crawling in robots.txt prevents a crawler from reading that directive, so the two controls should not be treated as interchangeable.

Before launch, inspect the actual production responses. A staging setting copied to the live host can make good pages non-indexable. Equally, a production build uploaded to staging needs protection appropriate to that host.

• Confirm the live host is indexable where intended.
• Confirm staging serves noindex and can be crawled to read it.
• Keep essential CSS, JavaScript and images accessible.

Test the launch as a visitor

Open the important old URLs and follow them to their destinations. Check the final pages, navigation, mobile layout and enquiry journeys. Do this against the deployed site as well as a local preview, because hosting redirects and headers may differ.

Keep a copy of the previous release and a record of the changes. After launch, use Search Console and your available enquiry reporting to watch for errors and unexpected changes. Search processing is not instant, and a successful deployment does not by itself establish a ranking outcome.

• Direct redirects, working destinations and genuine error responses.
• Visible content and usable forms on mobile and desktop.
• A named owner for post-launch checks and follow-up fixes.