A website redesign changes more than its appearance. It changes the routes people use to reach services, articles and campaign pages. An old URL may live in a search result, a client email or a printed brochure long after the navigation has been redesigned.
Create the URL migration plan while the new structure is being designed. Leaving it until launch turns useful editorial decisions into a rushed list of technical redirects.
Build an inventory with evidence
Start with the existing sitemap and a crawl, then add URLs from analytics, search reporting and known campaigns where those sources are available. Include useful pages that are absent from the main navigation.
Record the page's current purpose, its proposed destination and the reason for the mapping. This encourages the team to decide whether content is moving, merging, being rewritten or being retired.
For a hypothetical agency website, three overlapping service pages might become one stronger page. That can be a sensible editorial change, but the new destination should address the important intent of the old pages. Sending every removed page to the homepage gives visitors little help.
Match meaning, not just spelling
A redirect should bring the visitor to the closest useful destination. Similar slugs do not guarantee equivalent content. Check what the old page promised and whether the new page fulfils that promise.
Where there is no replacement, decide deliberately how the site should respond and what navigation can help the visitor recover. Do not manufacture a misleading destination simply to avoid every not-found response.
Also preserve fragment links where they matter. A redirect to a new page does not automatically ensure that an old section anchor still identifies useful content. Campaign and documentation links may need special review.
Keep the implementation reviewable
Store the mapping in a form the development team can test and the content team can inspect. Separate exact page mappings from broad pattern rules so a convenient wildcard does not accidentally redirect unrelated routes.
Test for chains and loops. A request should not bounce through several historical versions of the site before reaching its destination. Check that the final page is available, has the intended canonical URL and is included in discovery where appropriate.
Update internal links to their final destinations instead of relying on redirects for normal navigation. The redirect is a compatibility layer for old links, not the preferred path through the new site.
Verify the real response after deployment
A mapping that works in a local router may behave differently behind a hosting platform or CDN. Check representative old URLs against the deployed environment, including trailing slashes, query strings and any case-sensitive paths that the previous site used.
Check the HTTP response and final content, not only whether the browser appears to land somewhere. Keep a small set of important old links as a repeatable release check.
After launch, review newly observed missing URLs and decide whether they reveal an omitted mapping, an external typo or content that should return. This is focused maintenance, not an invitation to create endless redirects without purpose.
Our WordPress modernisation work treats the URL plan as part of the rebuild, so the site can change shape without abandoning the routes people already use to find it.