Website migration: a practical plan for protecting useful pages

Inventory what exists

Collect existing URLs from the website, available sitemaps and relevant search or analytics tools. Identify pages that attract useful visits, enquiries or external links, while recognising that traffic alone does not define value. Include downloadable resources, images used elsewhere and important campaign landing pages. Mark who owns each content area and whether it should remain, change or be retired. An inventory prevents the project from discovering essential pages only after users report that they are missing.

Map every important destination

Create a mapping between old URLs and their planned destinations. Preserve a useful address when there is no good reason to change it. If several pages are combined, choose a destination that genuinely answers the original need. Redirecting every removed URL to the homepage can confuse users and fails to preserve context. Where no replacement exists, decide deliberately how the site should handle removal. Keep the mapping understandable to content and technical reviewers alike.

Review content and indexing settings

Compare key titles, headings, body content and internal links before and after the change. A visual redesign can accidentally remove information that helped visitors make decisions. Check canonical addresses, language alternatives and which pages should be indexable. Staging environments need appropriate controls, but those controls must be reviewed for production. Google Search Central’s site move guidance provides a useful reference for planning redirects and monitoring the transition when addresses change.

Test technical and commercial journeys

Verify redirects with their actual response behaviour and destination, avoiding unnecessary chains. Check navigation, internal search, forms, telephone links and checkout or booking steps where relevant. Confirm that emails reach the intended recipients and that integrations use the correct production endpoints. Test representative devices and consent-dependent behaviour. A page returning successfully is not sufficient evidence that the business journey works; complete the actions a real visitor would take and inspect what the team receives.

Prepare launch responsibilities and recovery

Agree who changes domain or hosting settings, who approves the final content and who watches for problems. Record the dependencies, including email services associated with the domain. Back up relevant data and document a recovery approach suited to the migration. Avoid changing unrelated systems at the same time unless required, because that can make diagnosis harder. Keep the URL mapping and test results available to everyone responsible for launch decisions.

Monitor and correct after launch

Check important pages, redirects, incoming enquiries and available search reporting after publication. Some changes in crawling or search visibility may occur, so investigate evidence rather than assuming either success or failure from one day of data. Look for broken internal links, unexpected exclusions and requests reaching the wrong destination. Update the sitemap and retain necessary redirects. Record issues with an owner and a clear priority so post-launch attention focuses first on disrupted user journeys.

Keep a short migration register

For each important page, record its old address, new address, content decision, redirect outcome and owner. Add a final column for the contact or buying action associated with it. This turns a technical URL list into an operational checklist. Review the highest-value journeys before launch and mark evidence of the completed checks. When a problem appears afterwards, the register helps identify the intended behaviour and the person who can resolve it.

Preserve the original URL mapping after launch rather than overwriting it with a clean list of new addresses. The old-to-new relationship remains useful when investigating external links, unexpected requests and later content changes.