VANKPA
The short answer
A redesign should account for the pages customers and search engines already use. Preserve valuable information, map changed URLs, and test the migration before launch. No process guarantees unchanged rankings, but a documented transition reduces avoidable broken links and lost context.
Inventory the old site
Collect existing URLs from the website, sitemap, analytics, and Search Console where available. Mark pages that receive useful traffic, earn links, or support sales. Record titles, important content, forms, and downloadable resources. Do not remove a page simply because it does not fit the new navigation; first understand what it contributes.
Map each meaningful change
For changed URLs, choose the closest relevant destination. Google advises against sending many unrelated old pages to the home page. Preserve a useful page when no equivalent exists, or make a deliberate retirement decision. Keep redirects direct rather than creating chains through several historic addresses.
Check the release carefully
Review canonical links, indexability, internal links, image paths, and sitemap entries. Confirm that staging restrictions are not carried into production. Test redirects with actual old URLs rather than reviewing only a spreadsheet. The person approving visual design may not be the person responsible for these technical checks; assign both roles.
Monitor after the move
Google notes that search visibility can fluctuate during a site move. Track missing-page errors, indexing, important landing pages, and inquiry delivery. Keep a record of launch changes so performance reviews have context. Google's guidance generally recommends keeping redirects for at least a year; retaining useful redirects longer can also serve visitors with old links.
When to take the next step
Start migration planning as soon as the redesign might change page addresses or information structure. Do not leave the URL map until release week. If the site already receives useful search traffic, include someone responsible for that evidence in design reviews so visual simplification does not accidentally remove valuable answers.
- AnalystInventories urls
- EditorMaps content
- DeveloperTests redirects
- OwnerReviews signals
Adapt these responsibilities to your team and project scope.
Before you start
- Map old URLs to relevant destinations.
- Verify production pages can be indexed.
- Keep a postlaunch issue log and owner.
Questions clients ask
Can a redesign guarantee no ranking loss?
No. Search visibility depends on many factors, and Google may need time to process changes.
Should every old page redirect home?
No. Relevant page-level destinations provide a more useful transition for visitors and search engines.
Sources & context
References checked October 6, 2026. The planning recommendations are VanKpa editorial guidance; individual project requirements vary.
A worked scenario
Consider a service business replacing its site structure. The useful outcome is to preserve useful destinations during redesign. This is a planning example, not a reported client result. The team needs a decision that can be checked against real work, rather than a feature list that looks complete during a presentation. The starting question is whether the proposed approach changes that particular task in a way the people doing it can recognize.
In this situation, removing a service answer that already attracts qualified visitors is the failure to guard against. Ask the responsible person to demonstrate an ordinary case and one difficult case using current records or safe test data. Record what they expect to happen, what actually happens, and where they need another person to intervene. Those observations establish the scope for this example; they do not justify an assumed improvement percentage or a guaranteed business result.
Decision checkpoints
| Checkpoint | Practical action | Evidence to retain |
|---|---|---|
| Prepare | Map existing important pages to approved new URLs. | The approved scope, relevant source records, and unresolved questions. |
| Verify | Review navigation and redirects before launch. | The test case, expected result, observed result, and correction needed. |
| Operate | Monitor changed pages and resolve unexpected failures. | The responsible owner, completion record, and next review trigger. |
Use these checkpoints to preserve useful destinations during redesign; they are a sequence of decisions, not a promise of a particular schedule. A completed document or screen is not enough if the underlying action still fails. Keep unresolved items visible and describe which ones prevent progression. The evidence can be a small test record, an approved mapping, or a reviewed example. It should be understandable to someone who was not present when the work happened.
Measure the useful result
A useful check for this topic is priority old URLs reaching the right destination divided by checked priority URLs. The numerator is priority old URLs reaching the right destination; the denominator is checked priority URLs. Define the sampling window, exclusions, and source of each count before interpreting the result. If only selected examples can be reviewed, describe them as a sample. Do not present a small reviewed group as a complete picture of the business, and do not assign a target simply because a round number looks persuasive.
The measure helps reveal whether the team can preserve useful destinations during redesign, but it does not explain every cause of success or failure. Inspect the underlying cases alongside the summary. If the count changes after review navigation and redirects before launch, check whether the operating result changed or the counting method changed. Retain enough context to explain the difference. When records are incomplete, state the limitation and use a direct task review instead of manufacturing a precise-looking estimate.
Step 1: Prepare the evidence
The first practical move is to map existing important pages to approved new URLs. Start with the smallest set of examples that covers the important variation in this scenario. Include an ordinary case, a case with missing information, and a case that requires intervention. Describe the intended result before reviewing the current behavior. This keeps the preparation focused on the outcome: preserve useful destinations during redesign.
For a service business replacing its site structure, the person responsible for the source information should take part in preparation. Ask that person to confirm which information is authoritative and which points still need a decision. Record those uncertainties beside the scope instead of hiding them in a general assumption. Preparation is complete when another team member can follow the agreed example and explain what evidence would allow the work to continue.
Step 2: Test the difficult case
The next move is to review navigation and redirects before launch. Compare expected behavior with observed behavior in the same test, rather than comparing two descriptions written at different times. Pay particular attention to removing a service answer that already attracts qualified visitors. A demonstration that works only for its author does not establish that the intended user can complete the task. Let the reviewer attempt the work with the instructions they would normally receive.
For this check, retain the input, the relevant condition, and the final disposition. A screenshot can illustrate the state, but the record also needs to explain what the team expected and why the result matters. If a valuable page has no appropriate replacement, hold the decision open and send it to someone with the authority to resolve it. Retest the changed case after correction; an agreement to fix something is different from evidence that the correction works.