Website redesigns are often approved by looking at screens: a new homepage, clearer navigation, and better photography. But someone might arrive through a link saved years ago, a sales PDF, or an advertisement nobody updated. If that address stops working, they never see the approved design.
Our recommendation is to treat URLs as a project deliverable. Before launch, the business and technical team should agree on which addresses stay, which change, and which content is retired. The following map turns that conversation into decisions you can verify.
Build an inventory with owners
Create a table with the current address, content type, business purpose, owner, and proposed action. Add a notes column for associated forms, downloadable documents, language versions, or campaigns still using the page.
Do not rely on navigation alone. Ask sales for the links they use, review the content manager's catalog, and gather addresses from current materials. A page with few visits may still matter to an active negotiation or existing customers.
Record where each entry came from so questions can be resolved later. If nobody recognizes a page, do not automatically delete it: ask what information it contains and who might need it. The inventory is complete when every relevant address has a decision, including those you will keep unchanged.
Choose destinations by content
We use four working decisions: keep, move, consolidate, or retire. Keeping an address avoids changing it merely for appearance. Moving preserves its purpose at a different URL. Consolidation brings pages together when they now share a useful answer. Retirement requires confirming that the content no longer has a purpose and lacks an equivalent replacement.
For example, an old maintenance page can point to a new maintenance service page if it explains the same scope. It should not point to an unrelated service just because both belong to the business. Document the reason for each consolidation instead of leaving it in the developer's memory.
Google recommends permanent server redirects for lasting moves and warns against redirecting many old pages to an irrelevant homepage. It also recommends avoiding redirect chains. These technical criteria support the map; they do not guarantee that rankings remain unchanged. Official site migration guidance.
Specify what each row must pass
Add the expected destination, expected response, and observed result. For a retained page, verify that its content opens. For a moved page, record the initial response and final address. For a retired page, agree with the technical team on an appropriate missing-content response and a screen that lets people continue navigating.
Include variants that actually existed: historical capitalization, trailing slashes, or another language's routes. Do not invent hundreds of combinations without evidence. Separate commercial parameters that need to survive from filters or values that no longer make sense on the new website.
Test a nonexistent address too. If every unknown route ends at the homepage, a superficial visual review can hide a broader problem. This check is part of our proposed acceptance process, not a search engine certification.
Review complete journeys in the test environment
The table does not replace opening pages. Choose representative journeys: an old link to a service, an article to a service, language navigation, and a document download. Confirm that people find the information that brought them there.
Ask the team for a test record identifying loops, intermediate hops, and broken destinations. Review links in navigation, cards, the footer, and sales materials you can edit. Updating them avoids depending on redirects indefinitely for links under your control.
When reviewing the handover, request concrete evidence and named owners, as discussed in what to look for when hiring a web agency. A screenshot of the new homepage does not prove that earlier entry points still work correctly for visitors.
Agree on launch and follow-up
Reserve a launch window when someone can review the website and fix issues. Save the previous configuration, assign who can decide to roll back, and write down which failures would justify that decision: unavailable service pages, the wrong language, or interrupted critical journeys.
After publication, repeat the priority checks against the actual domain. Maintain an issue list with the URL, evidence, owner, and resolution date. Avoid changing every route again while investigating one isolated failure.
The final handover should include the inventory, approved map, test results, and maintenance instructions. If you are preparing a redesign, KAIZO Digital's web development service can include this work in the initial scope alongside content, design, and publication.