1. Inventory the site before designing its replacement

Record current URLs, important search landing pages, useful downloads, contact destinations and the content each page provides. Include pages that are difficult to reach through navigation but still receive visits or enquiries. Keep a recoverable copy of the existing site.

Mark each item to retain, improve, combine or remove, with a reason. A new navigation label does not require a new URL. Preserve useful addresses where the content and purpose remain the same.

2. Map necessary changes individually

For every URL that must change, identify the closest relevant replacement and plan a permanent redirect. Do not send unrelated retired pages to the home page simply to avoid an error. A genuinely removed page without a suitable replacement may need an appropriate not-found response.

Update internal links and sitemap entries to the intended destination. Plan canonical signals alongside redirects, and check that important images or downloads have not been forgotten during the content move.

  • Keep the old URL, intended outcome and new destination in one mapping table.
  • Test for loops, chains and destinations that no longer match the original purpose.
  • Assign responsibility for redirect configuration and verification.

3. Test a protected preview against the plan

Check representative page types on mobile and desktop, using real headings, photographs and product or service details. Compare the rebuilt pages with the inventory so that important explanations and links have not silently disappeared.

Keep staging protected, then document which development restrictions must change at launch. Review contact journeys, metadata, indexing instructions and redirects. Separate visual approval from technical acceptance, and identify who can authorise release and restore the previous version if necessary.

4. Verify the public site after release

Recheck priority URLs, redirects, contact destinations and crawl settings on the live site, not only in preview. Record any failed checks and their owners. Search systems may need time to process changes; a successful deployment does not confirm that every new page has been indexed.

Compare subsequent search and enquiry evidence with the baseline, allowing for seasonality and other business changes. Maintain the redirect plan after launch rather than removing it when the design project closes.

Common questions

Must a redesign change every URL?

No. A visual or content improvement often works at the existing address. Change URLs only for a clear reason, with a plan for affected visitors and links.

Can a careful migration avoid all search changes?

No. Testing reduces preventable problems, but search performance can fluctuate while systems process a changed site. A zero-impact promise would be misleading.

When is the redesign finished?

Agree separate milestones for design approval, technical release, public verification and later performance review. Each answers a different question about completion.