True Measure / Website changes
Map your pages before a website redesign
Decide which addresses stay, which change and what evidence will verify each result.
Use paper or your own notes for answers and checklist marks. No answers are collected or saved on this page.
Give every existing page a considered decision
Before changing a website, list its existing page addresses and the useful job each page performs. Include important downloads as well as pages. Use your sitemap, navigation, available reports, and known shared links as starting points; note anything you have not yet inventoried.
This is a planning and verification record for you and your developer. It is not a complete migration plan. If the page address will stay the same, write “keep URL” rather than inventing a redirect task.
Current website / proposed website:
Owner / developer / planned launch:
Where the existing URL list came from:
Known gaps in that list:
1. Record the reason to preserve or change each page
Repeat this block for each page or download. Record evidence, not just a preference for the new design.
Existing full URL:
What can a visitor do or learn here?
Evidence of value: ☐ Customer use ☐ Search report ☐ Known links ☐ Campaign/printed material ☐ Important reference ☐ Not yet checked
Evidence source / date / what it shows:
Decision: ☐ Keep ☐ Update ☐ Merge ☐ Remove ☐ Unresolved
Reason:
New full URL, “keep URL,” or proposed removal handling:
If moved or merged, does the destination answer the original visitor’s need?
2. Agree on the technical work
| Item for the developer | Agreed handling / owner |
|---|---|
| Old-to-new URL mapping | |
| Permanent redirects where appropriate | |
| Removed pages with no suitable replacement | |
| Internal links and navigation | |
| Relevant images and downloadable files | |
| Sitemap and launch indexing checks |
Do not use the home page as an automatic destination for every removed page. Ask what the relevant destination is, or how a genuinely removed page should be handled. Google’s site-move guidance recommends mapping URLs and warns against irrelevant redirects. Source
3. Keep a launch verification log
| Old URL / test date | Expected result | Observed result and verifier |
|---|---|---|
- ☐ The old address leads to the agreed result.
- ☐ The final page contains the intended content and working next step.
- ☐ The developer has checked the actual HTTP response, not just the visible page.
- ☐ Important internal links and downloads have been checked.
- ☐ The unresolved list has a named owner.
Fictional example: An old repair-service page is merging into a broader repairs page. The destination must still explain that repair service. Sending the old link to an unrelated home page would not answer the same need.
Read the result
Separate content decisions from technical verification. “The new page exists” does not close an unchecked old address. Ask the developer to confirm unresolved handling before launch and agree how you will monitor problems afterward.
Next unresolved URL / owner / evidence needed:
Source note
Google’s site-move documentation covers URL mapping, redirect configuration, testing, and monitoring. It also notes that search rankings can fluctuate during a move. This worksheet cannot promise preserved rankings or replace a site-specific technical migration plan.