A website redesign changes more than colours and navigation. Old links, search results, bookmarked pages and sales documents may still point to the previous site. A migration plan gives each useful URL a clear destination and makes the new experience understandable to people arriving through those older paths.
No checklist can guarantee unchanged rankings. The practical objective is to avoid preventable access and content problems while measuring what happens after launch. Separate technical migration work from a simultaneous rewrite of every service proposition; combining both makes unexpected changes harder to explain.
Build an inventory before changing routes
Collect URLs from the current sitemap, analytics, the CMS and a site crawl. Add important documents and manually maintained landing pages. Record page purpose, traffic where available, backlinks where known, owner and proposed destination. Do not assume the sitemap contains every URL people use.
For a hypothetical consultancy, an old logistics case might already appear in proposals. Preserve its address if the underlying project is still relevant. Changing that slug simply because the new title reads better creates avoidable maintenance work.
Map each old page deliberately
Google describes URL mapping and redirects in its site move guidance. Apply that guidance through a reviewed mapping sheet rather than an indiscriminate redirect to the homepage.
| Old content | Practical treatment |
|---|---|
| Same service and purpose | Preserve the URL when possible |
| Clear replacement | Redirect to the relevant replacement |
| Several overlapping guides | Choose a useful consolidated destination |
| Permanently removed material | Return an appropriate missing-page response |
Check redirects for loops and unnecessary chains. A deleted case should not send readers to an unrelated industry merely to avoid a missing page.
Review the staging environment
Keep unfinished staging content out of search, but verify the production configuration separately. Teams sometimes carry a staging noindex instruction into launch. Check rendered HTML, canonical URLs, robots rules, sitemap domain and links to images or downloads.
Test the important journeys on desktop and mobile: service discovery, project reading, enquiry submission and article navigation. A visually attractive hero does little for an old search visitor whose required content has disappeared below it.
Preserve useful meaning
Titles, headings and descriptions should match the new visible content. Keep the information that helped the old page answer its question, including evidence, limitations and relevant internal links. Improve clarity without replacing specific explanations with repeated marketing phrases.
Google's helpful content guidance provides a useful editorial reference. Our recommendation is to review each migrated page as a reader task: can someone still understand the service, judge the evidence and take the intended next step?
Launch with a short observation plan
Before release, assign owners for redirects, content corrections and infrastructure failures. Save the previous route inventory and record the deployment time. After launch, inspect important URLs, broken links, form results and search indexing reports. Compare like-for-like periods rather than interpreting a single day's traffic as proof of success or failure.
If an important destination is wrong, fix it directly. If content performance changes, investigate page intent and indexing before repeatedly renaming URLs. Keep a migration log so later reviewers can distinguish deliberate consolidation from accidental loss.
A successful redesign leaves the site easier to use and the transition explainable. Explore Core Web Vitals, then use the content migration plan to organise the editorial work. Our web application team can help scope the migration and its verification.