Website redesign URL migration is the plan that keeps existing addresses working when page structure changes. Visitors, emails, and other sites already point at the old paths. A new menu does not update those links. You map the old URL to the closest new page and redirect when the path must change.
This is a launch checklist, not an essay on rankings. Search basics live in the Articles section. Here, the job is: nothing important should 404 on day one.
Build the map before you design the menu
Export the current URLs from the CMS, analytics “landing pages,” and any campaign links you still pay for. For each URL, choose one outcome:
- Keep the same path if the page still exists
- Redirect (301) to the new equivalent
- Merge several thin pages into one stronger page, each old URL redirecting to it
- Retire only when there is truly no successor, and even then say so with a useful page rather than a blank error if the topic still matters
Do this in a spreadsheet with columns: old URL, new URL, action, owner. The new information architecture should respect this map. If the new structure cannot name a destination, the IA is not finished.
Prefer stable, readable paths. Changing /services/crm to /solutions/platform-crm-v2 because the slogan changed is an expensive cosmetic.
Redirects and what they must not do
- One hop where possible. Chains of three redirects are harder to debug and easier to break.
- Redirect to the relevant page, not everything to the homepage.
- Keep query strings that campaigns need, or document that they are dropped.
- Update internal links to the new URL so the site does not depend on redirects forever.
- Test the map on staging with the same rules production will use.
A redesign is also the moment people forget files: PDFs, images used in old emails, and www versus apex. Include them in the map if they receive traffic.
Launching a redesign without losing URLs
- Export old URLs and traffic landing pages
- Map each one to keep, redirect, or retire
- Implement redirects on staging and test a sample
- Launch, then crawl for 404s
- Fix gaps in the first week and update internal links
After launch
Crawl the old list. Any 404 is a row that was missed or a redirect that points at a missing new page. Check a few external links you do not control, such as a directory profile. Watch the error log for a week. Editors should stop recreating the old slug “because it looks nicer” without a redirect from whatever they replaced.
Take a backup before the cutover so a bad deploy can be rolled back. See backup restoration testing.
A practical example
A company replaces /web-design-johor and /web-design-kl with one services page at /web-digital/design. Both old URLs 301 to that page. Internal menus already use the new path. A PDF linked from a 2024 proposal stays at its old file URL because partners still download it. The team finds two 404s the next day from a blog path nobody exported, adds the redirects, and does not “fix” them by sending those posts to the homepage.
Key takeaways
- Inventory URLs before you freeze the new structure.
- Redirect each moved page to its closest successor.
- Test on staging, then crawl again after launch.
- Update internal links so redirects are a safety net, not the navigation.
FAQ
Should we redirect every deleted blog post to the homepage?
Only if there is no closer article or category. A homepage redirect for a specific guide frustrates the visitor and hides the fact the content is gone.
Do we need a redirect if the path did not change?
No. Keep the template change on the same URL. Redirects are for addresses that moved or were merged.
Who keeps the spreadsheet?
Whoever is accountable for the launch. After go-live, store it with the project notes so the next redesign does not start from zero.