Preserve old website URLs when their content remains useful; redirect moved pages to the closest relevant replacement, and let truly retired pages return a helpful not-found response. Start with a complete URL inventory, then approve each destination before launch. This avoids the common mistake of sending every old address to the homepage, which can confuse visitors and obscure whether important content or routes were missed.
Redirects preserve routes, not every old page
A redesign should preserve an old URL when the page still serves a useful purpose, and redirect it when its content has moved or been retired. The destination should satisfy the same visitor need as closely as possible. Redirecting every removed page to the homepage may prevent a dead-end response, but it often leaves visitors and search engines without a relevant replacement.
Treat redirects as part of the information architecture and launch plan, not a last-minute technical patch. First establish which existing URLs matter, what each one should become, and who can approve uncertain decisions. The right plan depends on actual content and visitor needs, not merely on how many URLs the new site has.
Inventory the old URLs before mapping them
Build a list from more than the visible navigation. Include a crawl of the current site, the XML sitemap, server logs where available, analytics landing-page reports, and known links from email campaigns or partner sites. These sources reveal different things: a page absent from navigation may still receive visits, and a URL missing from analytics may still be linked externally.
Record each URL, its purpose, current status, and any signals that matter to the business, such as inbound links or recurring customer references. Include non-HTML assets when appropriate. A product PDF, policy document, or application endpoint may be important even though it is not a normal web page. Check parameterized URLs carefully so useful variations are not overlooked.
Choose a destination that matches the visitor's intent
Classify each address as keep, move, merge, retire, or investigate. A moved service page usually maps to its new equivalent. When two pages are consolidated, choose the destination that carries the shared information and explain any missing detail there. A retired offer with no genuine replacement may need a helpful category or archive page, or it may correctly return a not-found response.
Avoid sending unrelated old URLs to one general page just to make the error report look clean. A redirect tells browsers and crawlers that a resource has moved; it does not make unrelated content equivalent. For pages with no suitable successor, provide a clear not-found page with useful navigation rather than implying that the old content still exists.
Design redirect behavior around the actual URL structure
Use a permanent redirect when the move is intended to last. Keep the redirect map explicit and maintainable, especially if the site includes legacy routes, dynamic pages, or application paths. A broad rule can catch many URLs, but it can also redirect the wrong content or interfere with valid routes. Review rule order and test representative examples before deployment.
Preserve query parameters when they identify content or carry meaningful campaign or application state; remove or normalize them only when there is a defined reason. Also test URL variants that the old site accepted, such as capitalization, trailing slashes, and encoded characters. A redirect chain—where one old URL redirects to another old URL before reaching the final page—adds unnecessary hops. Point each mapped URL directly to its intended final destination where feasible.
Test behavior, not just the spreadsheet
A mapping document is a specification, not proof that the live server follows it. In a staging environment or controlled test, request representative old URLs and verify the response code, final destination, and number of hops. Check that redirected pages do not loop, and confirm that URLs meant to stay live still return the expected content.
Include edge cases: a path with a query string, an old file download, a retired page, and a route handled by the application rather than the content system. If redirects are implemented at the server or application layer, test the interaction with routing and caching as well. Keep the approved mapping under version control or in another shared record so future maintainers can understand why rules exist.
Monitor the launch and correct real failures
After launch, check server logs and crawl reports for requests to old paths, unexpected not-found responses, redirect loops, and destinations that return errors. Review important inbound links and campaign URLs directly. Search-engine reporting can help identify crawl problems, but it is only one signal; it will not replace checks of customer journeys and application behavior.
When a missed URL appears, determine whether it needs a relevant redirect, a restored page, or a deliberate not-found response. Record the reason and update the map. Do not keep adding broad rules merely to suppress errors. If a migration includes many pages or complex application routes, assign one person to own the map and another to verify the implementation before the old site is retired.
Redirect planning checklist
- Export the current URL list, including pages, images, downloadable files, and important query-based URLs.
- Mark each URL as keep, move, merge, retire, or investigate; assign an owner to uncertain pages.
- Map moved pages to their closest relevant destination, and define a useful destination for genuinely retired content.
- Test redirects for status, destination, chains, loops, query parameters, and trailing-slash or case behavior.
- After launch, review server logs and search-console crawl reports for old URLs still receiving requests or returning errors.
Questions about this approach
Should every old URL redirect to the new homepage?
Redirect it to the closest relevant page only if that page genuinely serves the same need. If no suitable replacement exists, a useful not-found page is usually more accurate than a redirect to the homepage.
How long should a redesign redirect stay in place?
Keep the redirect map as an ongoing operational record. Review it when content is moved again, an application route changes, or logs show important requests to retired addresses. Remove obsolete rules only after checking that they are no longer needed and do not support another active path.
Can a business owner manage redirects without a developer?
A small, simple site may be managed with a carefully tested mapping and a clear owner. More complex sites—especially those with many dynamic routes, downloads, or application paths—benefit from development support to prevent broad rules from breaking valid journeys.
For help applying this approach, explore our custom web design services.
Discuss your project with Full Blown Studio
Tell us what needs to work better and what you have tried. Discuss your project, email bob@fullblown.com, or call (661) 429-0940.
