Before a website redesign goes live, agree what must be kept, map any changed addresses and request evidence for the launch checks. After launch, repeat the checks on the public site. A working preview is only one part of that record.
Your website may contain more value than the pages in its menu: a linked PDF, a service answer that attracts useful searches, a booking route or an old address still used in an email. Make those items visible before replacing the site.
This checklist is for a service-business owner working with a delivery partner. It connects the technical checks to a decision you can review. If you are still deciding the scale of the project, start with repair or rebuild.
Download the rebuild preservation pack
Use the workbook to agree the scope and responsibilities, then complete the two blank records. The worked files show how unresolved evidence can hold up a launch. You can use them with any delivery partner.
| File | What you can do with it |
|---|---|
| Workbook and decision record, Markdown | Read the instructions, field definitions and fictional example. Copy the blank launch decision into your own document. |
| Blank URL-preservation record, CSV | Record what stays, moves, combines or goes, with the expected result and evidence. |
| Blank launch-check record, CSV | Assign checks before cutover, immediately after launch and during follow-up. |
| Worked URL-preservation record, CSV | Inspect five fictional page and download decisions. |
| Worked launch-check record, CSV | See the fictional checks, missing evidence and decision to hold the release. |
These are static text files, with no formulas or macros. Open the Markdown in a text editor, or copy its prompts into a document. Import the CSVs as UTF-8 with URL, date and status columns treated as text. Duplicate rows as needed. The files do not scan a site, update themselves or send your entries to us. Keep completed records and private evidence in your own workspace.
1. Agree what is changing and who can approve it
Write down whether the project changes the design, content, navigation, platform, page addresses or domain. A redesign does not require changing every URL. Avoid combining several major changes simply because they can share a launch date.
Name the business approver, the delivery lead, the person checking search and measurement, and the person receiving enquiries. One person may hold several roles. Record who can pause the release and what happens if a live check fails.
Our HR advisory case shows a concrete structural decision: a broad offer became distinct service choices and a route based on the buyer’s problem. That is evidence of the delivered presentation. It does not establish that every business needs those changes or that a migration checklist preserved rankings.
Ask for: the agreed page plan, changed systems, approval owner, cutover plan and a practical recovery plan. Confirm what happens to new enquiries or other data if the team restores an earlier version. These are project controls to agree with your team.
2. Inventory what the current website does
Combine a crawl or CMS export with the sitemap, relevant search landing pages, analytics, known inbound links and the team’s own records. A single list can miss an unlinked page or a useful file. Identify any gaps in coverage.
Include service pages, articles, case studies, PDFs, important images, forms and external booking steps. For each item, record its purpose and the evidence for keeping, improving, combining or removing it. A page with little recorded traffic can still answer an important buying question.
Save a dated baseline before changes begin. Keep the search property, dates, country, device and search type beside the export; record analytics and received enquiries separately. Use the measurement guide for that wider record.
Ask for: the inventory, its sources and omissions, plus a decision for every in-scope item. Keep credentials and private customer data out of shared worksheets.
3. Match each URL decision to its expected result
| Decision | What the team should demonstrate |
|---|---|
| Keep | The address still serves the intended page or file successfully, with useful content retained. |
| Move | The old address uses an appropriate permanent redirect to the relevant final replacement. Test the destination as well as the redirect. |
| Combine | The receiving page genuinely covers the material and buyer need being retained. Map each old address to that relevant destination. |
| Remove | The owner accepts the retirement. If there is no similar replacement, return a real 404 or 410 response and remove obsolete internal links. |
For permanent moves, Google recommends server-side redirects such as 301 or 308 and direct routes to the final destination. Sending unrelated old pages to the homepage can confuse users and be treated as a soft 404. A missing-page message served with status 200 is also a problem to investigate. Google’s redirect guidance and crawl-error guidance.
Update internal links, canonical references and the sitemap to the intended URLs. Check linked files and important images too. For a multilingual site, include the relevant language references in the technical scope rather than assuming a small-site worksheet covers them.
Keep redirects for as long as possible, generally at least one year according to Google. A post-launch review date is not a redirect expiry date. Domain moves also need their own plan; Google’s Change of Address tool is not required for ordinary path changes on the same domain. Site-move guidance.
4. Request evidence from the replacement site
Agree the expected result before marking a check complete. For each check, retain the page or route, environment, time with timezone, actual result, evidence reference, owner and next action.
| Check | Evidence to request |
|---|---|
| Content and buyer routes | Approved service details, useful answers, proof and downloads remain available. A buyer can reach the relevant service and enquiry route on a phone and with a keyboard. |
| URL behavior | The in-scope old and new addresses match the preservation map. Record the actual response and final destination, including intentional removals. |
| Search controls | Review the intended production robots rules, HTML robots metadata, response headers, canonicals and sitemap. Identify development-only controls that must change at cutover. |
| Enquiry delivery | An agreed, clearly labelled test reaches the intended recipient. Check the visible success or failure response and actual receipt separately. |
| Measurement | The intended analytics destination receives the expected test events under the recorded consent conditions. Check missing or repeated events and keep test activity identifiable. |
| Ownership and recovery | The business can access agreed accounts. The team can explain the release, support and recovery responsibilities. |
A private preview should keep its protection. On production, remove only the development-only blocks that conflict with the intended public pages. A noindex instruction can be in page HTML or an HTTP response header. A robots.txt block is different: it can stop Google from fetching the page and seeing noindex. Google’s noindex guidance.
For analytics, check the actual destination and events, not only whether a tag was detected. Google’s tag troubleshooting and DebugView guidance explain those checks. DebugView is a collection diagnostic, not proof of final acquisition attribution.
An analytics form_submit records interaction activity. Confirm the enquiry separately in the receiving system; do not turn the event into a qualified lead or sale. Enhanced measurement definitions.
5. Make a launch decision from the unresolved items
Use Not checked, Pass, Fail or Not applicable for individual checks. A pass needs evidence. Not applicable needs a reason and an owner. These are worksheet labels, not Google status codes or an automated score.
Agree which requirements block cutover. Examples include a missing important download, an irrelevant redirect, an unintended indexing block or an essential form whose delivery has not been established. Record exceptions explicitly; a long list of green rows must not hide one unresolved essential route.
Some checks can only be completed after the public site changes. Assign those checks and the response to failure before cutover, leaving their status as Not checked. Ready for cutover with live checks assigned is different from live checks completed.
Worked example: a launch stays on hold
The downloadable example describes a fictional payroll advisory business on payroll.example. Every business detail, response and check result is constructed teaching material. No website was tested and no customer result is represented.
| Fictional finding | Decision |
|---|---|
| The main service page keeps its address and approved content in the preview | Pass for that preview check only. Production remains untested. |
| An old service address goes to the homepage instead of its relevant replacement | Fail. Correct and retest the redirect. |
| A useful onboarding PDF returns a missing-file response | Fail. Restore the file or agree a relevant replacement, then retest. |
| The contact form shows success, but recipient receipt is unverified | Not checked for delivery. Obtain the missing evidence. |
| A retired offer has no replacement and returns the agreed 410 response | Pass for that intentional preview removal. It does not cancel the other failures. |
The fictional release decision is Hold. Fix the redirect and missing file, establish test-enquiry receipt, and record fresh evidence. The live production checks remain assigned and untested. The workbook shows this decision alongside the CSV rows so the conclusion remains attached when the files are shared.
6. Recheck the public site and keep observing
Immediately after cutover, repeat the agreed checks on the public domain. Confirm important pages, redirects, downloads, indexing controls, enquiry receipt and measurement. Save new observations with their production environment and time. Preserve the earlier preview record.
Monitor Search Console for unexpected exclusions, crawl problems and changes to relevant landing pages and queries. A successful live URL test or sitemap submission does not guarantee indexing. Google also warns that rankings may fluctuate while a site move is processed. URL Inspection guidance and site-move guidance.
Do not wait for a reporting milestone to fix a confirmed broken route or indexing block. Agree early checks with your team, then use the 30, 60 and 90-day review for the wider business decisions. Compare complete, consistent periods and note other changes. The observation calendar cannot promise a recovery date.