Plan a redesign without losing useful content
Inventory an existing website, decide what to keep or retire, and test old addresses against the new site with a worked migration decision table.
A redesign changes what readers see; it may also change the addresses they use to reach it. Start by recording the current content and its purpose before drawing the replacement navigation.
Keep a useful page at its existing address when that still makes sense. If the address must change, connect the old one directly to its genuine replacement. Some old material has no suitable successor and should be removed honestly.
Build an inventory from more than one source
Combine a crawl or page list with current navigation, sitemaps, known external links and any useful access or Search Console data you already have. Include downloads and meaningful query URLs, not only the pages visible in the menu.
Use columns for the exact old address, page purpose, useful information, accuracy concerns, assets, known links, proposed action, final destination and owner. An address list shows which URLs you know about. It does not establish the quality of backlinks, the rights to old images or the accuracy of the content.
Where the evidence is thin, record that limit. A promising slug is not enough to reconstruct an article that nobody has seen.
Make a content decision before a routing decision
| Content decision | What to do with the material | What to decide about the address |
|---|---|---|
| Keep | Retain accurate content that still serves a clear task | Usually keep the useful existing URL |
| Improve | Correct, expand or restructure the content | Preserve the URL if the page's purpose remains the same |
| Consolidate | Bring genuinely overlapping material into a stronger page | Redirect relevant old pages directly to that replacement |
| Retire | Remove an expired offer or service with no equivalent | Return a real missing or removed response |
| Investigate | Identify what the URL actually represented | Keep the uncertainty visible until evidence supports a decision |
Changing every address to look tidier creates work and risk without necessarily helping a visitor. Separate a visual redesign from a URL change where you can.
A worked migration decision table
Fictional example: Alder & Grain is replacing an older repair-workshop site. These addresses illustrate decisions; they are not historical Content Charlie routes.
| Old address | Evidence and reader intent | Chosen outcome | Reason |
|---|---|---|---|
/furniture-repairs/ |
Current scope and suitable-item information | Keep at the same address; update the copy | The task remains useful |
/chair-repair.html |
An older page about the same wooden-chair service | 301 to /furniture-repairs/ |
The new page contains the chair-repair information and next step |
/assessment.php?id=12 |
A specific appointment-preparation guide | 301 to /how-assessment-works/ |
The complete current process is the equivalent destination |
/assessment.php?id=99 |
No record of this item | 404 | An unfamiliar ID must not silently become the ID 12 guide |
/special-offer-2020/ |
An expired campaign with no replacement offer | 410 | A current service page cannot fulfil the old offer |
/downloads/care-notes.pdf |
An owned, still-accurate document | Keep the actual PDF at its exact address | Readers expect a usable document |
/images/client-chair.jpg |
An image with unconfirmed republication rights | Do not republish; return 404 if unavailable | An unrelated image would not restore the original asset |
/old-contact/ |
Verified former contact page | 301 to /contact/ |
The current contact function fulfils the same general task |
/not-a-real-page/ |
Unrecognised address | 404 | The site should not invent content for arbitrary paths |
Google's site-move guidance recommends explicit mappings and warns against sending unrelated old pages to a homepage. Removed content can return 404 or 410. A visual “not found” message delivered with a successful 200 status is a different technical response.
Treat queries and files as real destinations
In the example, id=12 and id=99 mean different things. Do not remove all query strings just because some are tracking parameters. Ask the developer which parameters identify content and which can safely be normalised.
Likewise, a PDF link should still download a real PDF when you say it has been retained. If an owned document is no longer accurate, decide whether to replace the document, point to a genuinely suitable explanation or retire it. An HTML page disguised with a .pdf address is not the same resource.
Assign content and launch responsibilities
Give each page one factual approver. Record who has access to the original assets and who will resolve missing information. Review the page map before polishing individual layouts, then confirm the approved destination of each important old address.
Keep a copy of the current site and configuration that can support recovery. Agree who makes the switch and what would trigger a rollback. Do not discover at launch that the old supplier controls the domain account or the only usable backup.
Test destinations and the journey between them
For each mapped URL, check the first response, any redirect destination and the final page. Confirm that a redirect goes directly to the final useful address and that the page actually answers the original question.
Also check internal links, canonical URLs and the sitemap against the intended public addresses. Test a sample through the real web server, including a query URL, a file and a deliberately missing address. A server can treat old .php paths differently from ordinary content routes.
Google advises checking indexing directives during a move and monitoring afterwards. It also notes that rankings can fluctuate during URL changes; a tidy mapping is not a guarantee of unchanged traffic.
Review what happens after launch
Keep a dated record of the release and the important changes. Check whether known pages remain reachable, whether people encounter unexpected errors and whether the new content still answers enquiry questions. Distinguish a broken destination from an old offer intentionally removed.
Use the launch checklist for the final handover. For an ongoing review of content and search observations, use measuring whether content helps.
The source notes
Sources and further reading
- Google Search Central: How to move a site Checked 4 November 2026