# Rebuild preservation and launch review workbook

Prepared by SEO Informatica. Technical sources reviewed 9 October 2026.
Companion guide: https://seoinformatica.com/website-redesign-seo-checklist/

Use this record with the people delivering and approving your website. It helps you retain decisions and evidence. It does not inspect a website, calculate readiness, certify a migration or guarantee rankings. It is a starting record for a service-business website; expand the scope for domain moves, multilingual sites, ecommerce, applications or other specialist requirements.

**All business details and results in the worked files are fictional. No website was tested. The example is not a client project, an executed experiment or an SEO result.** Keep these labels when sharing the example.

## Choose the files

| File | Purpose |
| --- | --- |
| `url-preservation-blank.csv` | Five empty starter rows. Add every in-scope page, file or route; duplicate rows as needed. |
| `launch-checks-blank.csv` | Sixteen suggested checks grouped before cutover, immediately after cutover and follow-up. Every status starts Not checked. |
| `url-preservation-worked.csv` | Five fictional decisions and preview observations. |
| `launch-checks-worked.csv` | The corresponding fictional review, with failures and missing receipt evidence. |
| This workbook | Instructions, field definitions, fictional evidence notes and a blank launch decision. |

The files are UTF-8 text with no formulas, macros, account connection or automatic scoring. Import CSVs with URL, date and status columns as text. A blank field means no value has been recorded. Do not replace unknowns with zeros, passes or guessed destinations. The row counts are starter material, not a limit or evidence that your inventory is complete.

Keep your completed records privately. Reference approved evidence files rather than copying customer messages, personal information, credentials or tokens into a shared spreadsheet. No entries are sent to SEO Informatica through these files.

## Use the pack in this order

1. Name the business approver and delivery lead. Agree what is changing, what is in scope and where supporting evidence will live.
2. Combine the current site's crawl or CMS export, sitemap, relevant search/analytics records, known links and business knowledge. Record omissions. Add useful downloads, images, forms and booking routes.
3. Record the purpose and evidence for each item. Choose Keep, Move, Combine or Remove only when the decision is supported. Leave the decision blank and the status Not checked if it remains unresolved.
4. Define the expected outcome before testing. A kept page should work at its retained address; a moved page needs a relevant permanent route; an intentional removal without a similar replacement may correctly return 404 or 410.
5. Agree which checks are required for each stage, assign people and dates, and record actual observations separately from the expectations.
6. Decide whether the pre-cutover requirements are met. Production-only checks can remain Not checked before release, but must have named owners, a time and a response to failure. Do not call those checks passed.
7. After cutover, create new production records. Preserve the earlier preview evidence; do not overwrite it. Continue follow-up and retain the redirect ownership plan.

Our status labels are suggested project controls. They are not Google status codes:

- **Not checked:** no adequate evidence yet, including a partial check that leaves its acceptance requirement unresolved.
- **Pass:** actual evidence supports the expected result for the recorded environment and scope only.
- **Fail:** observed behavior conflicts with the agreed result.
- **Not applicable:** the approver records why the requirement does not apply. Keep the reason in `approved_exception` or the URL record's `reason`, and name the approver in the decision record.

Do not derive readiness from a pass percentage. Resolve required failures and unknowns at the relevant stage. If accepting an exception, record its consequence, mitigation, approver and next review. A critical fault may need to stop or reverse the release; agree that response before launch and account for new data received after cutover.

## URL-preservation field dictionary

| Field | What belongs here |
| --- | --- |
| `record_id`, `record_type` | Stable reference and whether this is your own record or the labelled fictional example. |
| `current_url`, `purpose` | Full current address and the buyer or operational task it serves. |
| `current_evidence` | Inventory source, useful content, relevant search/link evidence or business reason. Include scope and dates where available. |
| `decision`, `reason` | Keep, Move, Combine or Remove, with justification. Blank means unresolved. |
| `planned_url` | Intended full address. Leave blank for a deliberate removal without a replacement, and explain it in `reason`. Never use a homepage as an automatic fallback. |
| `expected_result` | Required response, final destination, retained content and any route-specific acceptance requirement. |
| `owner` | Person responsible for the decision or check. Name other approvers in the decision record. |
| `environment`, `checked_at` | Actual preview or production address/context, plus date/time and timezone. If a check is incomplete, label a review time separately from a test time. |
| `observed_result`, `evidence_reference` | What was actually seen and where the capture/report can be inspected. Describe missing evidence explicitly. |
| `status`, `next_action` | Current check status and the next concrete action. Use a new row/revision for a later environment or retest. |
| `source`, `source_reviewed_at` | Method basis and its documentation review date, separate from your test date. |

## Launch-check field dictionary

| Field | What belongs here |
| --- | --- |
| `check_id`, `record_type` | Stable check reference and record provenance. |
| `stage`, `check` | Before cutover, Immediately after cutover or Follow-up, and the task being checked. |
| `expected_result` | A specific acceptance result, agreed before testing. Split a broad row into smaller checks when necessary. |
| `required_for_stage` | Agree Yes or No with the approver; explain exclusions. The template's “Agree with approver” remains unresolved. |
| `owner`, `due_at` | Named responsible person and deadline/timezone for that stage. |
| `environment`, `checked_at` | Exact test environment and observation time with timezone. Blank means not recorded. |
| `observed_result`, `evidence_reference` | Actual result and reference to inspectable evidence; separate an assertion from a tested observation. |
| `status`, `next_action` | One of the four defined statuses and the next required check or fix. |
| `approved_exception` | Reason, consequence, mitigation and named approver for an exception or not-applicable decision. Otherwise leave blank. |
| `source`, `source_reviewed_at` | Documentation or project-control basis, and the review date. |

For forms, retain user-facing response, application acceptance where available, recipient receipt and measurement as separate observations. A success message or `form_submit` event does not establish actual receipt or qualification. Agree any test with the recipient, label it clearly and exclude it from commercial reporting. Do not submit sensitive information merely to test a form.

## Fictional example and its evidence notes

The fictional business uses `https://payroll.example`. All observations below are constructed. References F1-F6 point to these scenario notes, not to real reports or captures. Scenario review time is 9 October 2026 at 09:00 UTC. No release date is supplied.

- **F1 / U1:** The preview serves the retained `/services/payroll/` page with status 200 and its approved content. This supports a preview Pass for U1 only.
- **F2 / U2:** `/payroll-services/` responds with a 302 to the homepage. The agreed outcome is a 301 directly to `/services/payroll/`, ending at the useful service page. The wrong destination and temporary status fail that agreement.
- **F3 / U3:** `/downloads/onboarding.pdf` returns 404. The inventory says the useful file must remain and a retained page links to it. This is a failed preservation check.
- **F4 / U4:** `/services/retired-offer/` returns 410, with a helpful error page and no remaining internal links. The fictional owner has accepted retirement and no similar replacement exists. This is an intentional removal, not a missing-file fault.
- **F5 / U5:** `/contact/` displays success for a test, but recipient receipt is unverified. The full delivery requirement stays Not checked.
- **F6 / C1, C2, C5, C7, C8, C9, C10:** For this limited example, the scenario stipulates that the other listed preview/planning requirements have been met. The fictional roles are Business approver and Delivery lead. These assumed passes are not executed tests and say nothing about production. In your record, each needs real, separate evidence and named people.

The worked launch checks therefore show C3 and C4 as Fail, and C6 as Not checked. C11-C16 remain Not checked because production has not launched in this scenario. Their placeholder dates must be replaced with agreed dates before any real release decision.

**Worked decision: Hold release.** Resolve U2 and U3, verify actual enquiry receipt for U5, retain new evidence and review the required pre-cutover checks again. Production observations are still pending. This decision does not predict what search traffic would do.

## Blank launch decision record

Copy and complete this section. Its empty state is not an approval.

- Project and current site:
- Proposed release/version and exact scope:
- Inventory sources, coverage gaps and record revision:
- Intended change window and timezone:
- Business approver and delivery lead:
- Required pre-cutover checks and their evidence:
- Failed or unverified required items:
- Accepted exceptions, consequences, mitigation and approver:
- Decision: Hold / Ready for cutover with live checks assigned / Live checks completed / Follow-up in progress
- Reason for decision and evidence references:
- Decision date/time and timezone:
- Named owner, due time and response to failure for every pending live check:
- Release/recovery plan, including newly received enquiries or other data:
- Production readback evidence and remaining issues:
- Redirect retention owner, planned duration and handover terms:
- Next review date and responsible person:

Keep the decision history. Ready for cutover is not evidence of a successful launch. Live checks completed is not proof of indexing, rankings or commercial performance.

## Technical references and boundaries

Reviewed 9 October 2026. The guide and suggested records interpret these sources; Google does not certify this worksheet.

- Site moves, mapping, retention and monitoring: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- Permanent and temporary redirects: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Removed content and soft 404s: https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors
- Noindex and crawl access: https://developers.google.com/search/docs/crawling-indexing/block-indexing
- Canonical references: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
- Sitemap guidance: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
- Google tag troubleshooting: https://support.google.com/analytics/answer/15756500?hl=en
- DebugView: https://support.google.com/analytics/answer/7201382?hl=en
- Form measurement definitions: https://support.google.com/analytics/answer/9216061?hl=en
- URL Inspection: https://support.google.com/webmasters/answer/9012289

Google advises keeping redirects generally at least one year; useful links may justify longer. Leave intentional preview/private protection in place. Review both HTML and response headers on public pages. A sitemap or successful live test cannot promise indexation. Search processing may take time and positions can move. Observation dates are a project schedule, not a recovery guarantee.

After launch, continue with https://seoinformatica.com/after-a-rebuild-30-60-90-days/ . For scope and responsibilities, see https://seoinformatica.com/website-rebuild/ .