DIRECT ANSWER
Inventory existing pages, useful content, assets, forms, connected tools and account responsibilities before redesigning. Preserve useful URLs where practical. When URLs change, map each affected page deliberately and test the result. A finished preview does not establish that the production migration is complete.
Start with a preservation inventory
Record the parts of the current website that perform a useful job. Include pages customers use, downloads, approved images and the forms or external tools connected to them. Add domain, hosting and repository access to the responsibility list without placing passwords in the document.
Keep original approved source assets where available. Identify which content must be updated and who can approve it. Separate a redesign decision from an unsupported assumption that all existing work should disappear.
If the need for replacement is still unclear, first compare a rebuild with better content.
Give each old URL a decision
| Decision | Meaning | Check |
|---|---|---|
| Keep | Useful content remains at the same address | Page and functions still work |
| Move | Useful content has a new address | Relevant destination and permanent redirect |
| Merge | Content is consolidated into a useful replacement | Replacement actually addresses the old purpose |
| Retire | No relevant replacement exists | Deliberate not-found response and updated internal links |
Google's site-move guidance recommends mapping old URLs to new destinations, updating internal references and using appropriate server-side redirects. It also explains that search fluctuations can occur during a move. A redesign should not be sold as a guaranteed way to preserve every ranking.
URL mapping worksheet
Use the decision table above for each old URL: keep, move, merge or retire, and record the destination and test result.
Avoid the homepage shortcut
Sending every removed URL to the homepage does not preserve the information those pages supplied. Choose a relevant replacement when one exists. When content is genuinely gone without a suitable replacement, handle that state intentionally.
Google's redirect documentation identifies 301 and 308 as permanent server-side redirects. Have the builder verify the actual response and final destination; a visually similar page is not evidence of a correct redirect.
Test the business functions separately
A page can render correctly while its form or booking destination is wrong. Test submissions using the contact-form checklist. Confirm the new site's approved integrations against their required behaviors, including the agreed failure path.
If the domain also handles email, have the responsible administrator document the relevant setup before changing domain settings. Do not treat a website redesign as permission to replace unrelated account configuration.
Keep a release and recovery record
Before publishing, record the approved version, destination, access owner and recovery approach. After publishing, verify actual production pages, changed URLs, forms and critical assets. Record unresolved problems rather than declaring success from a deployment status alone.
Review available search and inquiry records after the move, noting reporting periods and tracking changes. If data is missing, say so. A short-term difference does not independently identify its cause.
Use the proposal comparison guide to make migration and after-launch responsibilities explicit before work starts. Tell us what your current website must preserve.
Sources and method
Google documents URL migration and redirect behavior. The preservation inventory and release checklist are SIS operational recommendations.
Sources verified October 10, 2026: