Gate one: make the release boundary explicit
Start the checklist with a plain statement of what changes and what is preserved. Include the platform, hostnames, protocol, URL paths, content, navigation and analytics. Record the release version and intended date. Otherwise two people can approve the same checklist while imagining different launches.
Assign a release owner who can stop deployment, a routing owner who can change redirects, a content owner who can approve replacements and a measurement owner who can validate reporting. Put contact details in the operational handover, not public documentation. Decide who covers the first business day after launch, when previously unseen journeys often emerge.
For each item, use four fields: expected behaviour, evidence location, accountable owner and pass or exception. Replace “check canonicals” with “all sampled product pages reference their intended public product URL”. Consult the migration planning guide when deciding which risks belong in this release.
Gate two: reconcile the URL inventory
A crawler finds reachable links; it does not prove that you have the whole estate. Combine its export with CMS records, sitemaps, search landing pages, analytics and available server requests. Mark each URL's discovery source so disagreement becomes informative. A URL present only in logs may be an old campaign page, a useful download or meaningless noise.
The evidence checklist should contain an archived source inventory, a cleaned working inventory, the rules used to clean it and an exception list. Retain original case and encoding before normalisation. Do not strip every query parameter: a language, product variant or document identifier may change the content.
Prioritise manual review using business function and visitor need, not only current clicks. New pages and seasonal resources may have little recent data. Mark old broken URLs separately from working pages so the migration is not blamed for inherited errors. Save baseline HTML for representative templates and the pages that would be expensive to reconstruct.
Gate three: approve page outcomes before writing rules
Give every in-scope URL one explicit disposition: retained, redirected, merged or removed. The destination must be known and reviewed before routing configuration is accepted. “Find a related category later” is an unresolved decision. A large group of old pages pointing to one broad destination needs editorial scrutiny because similarity of topic is not the same as equivalent usefulness.
The redirect map should distinguish exact matches from pattern-based proposals. Test collision cases, including a legacy path that already exists in the new application. Agree what happens to genuinely retired material without a replacement. Do not turn every missing route into a homepage redirect.
Include image and document moves where appropriate, along with historical hostname variants. Approve destinations in the intended language and market. A successful response on an overseas equivalent is not necessarily the right result for a customer following a local delivery-policy link.
Gate four: compare content and discovery on staging
Restrict staging appropriately and make production restrictions a separate release check. A staging robots file is not access control, and a blocked crawl cannot confirm whether a noindex instruction exists inside a page. Document exactly which mechanism protects the preview and how that mechanism differs from public production.
Compare old and new templates using the same representative URLs. Check headings, substantive text, product details, language, contextual links and downloads. Open pages directly in a fresh browser session, rather than relying only on navigation from the homepage. Route-based applications can behave differently on direct requests.
Test category-to-detail discovery, pagination and empty states. A sitemap cannot compensate for a menu that no longer exposes important sections. Run browser checks for consent states and delayed modules where they affect visible content. Keep expected editorial removals separate from accidental omissions; otherwise every text difference becomes an alert and genuine losses disappear in the noise.
Gate five: test the public delivery layers
A preview pass does not establish production readiness. The CDN may add a robots header, the edge may rewrite Location headers and a security service may challenge automated requests. Exercise the intended public configuration using an agreed test route or controlled deployment process. Verify certificate coverage before any HTTPS legacy address is expected to redirect.
Developer acceptance criteria should require mapped URLs to reach approved destinations, retained pages to deliver the correct content and missing pages to return an actual error response. Internal links must use final URLs. Production canonicals and sitemaps must use the approved public host. No temporary authentication or broad indexing restriction may remain on intended public pages.
Include a negative control: an invented URL that should not exist. If it returns the homepage with status 200, the application fallback can conceal mapping failures. Include a real old URL whose query changes meaning, so parameter handling is tested rather than assumed.
Illustrative example: make an ambiguous checkbox testable
Illustrative example: a publisher has a checklist item reading “redirects tested”. The homepage and ten new articles work, so the item initially looks complete. The inventory also contains older PDF guides and article addresses with an obsolete date prefix. Those have not been exercised.
Rewrite the item into three acceptance groups. First, all mapped article sources must return a permanent redirect to the reviewed article. Second, retained PDFs must load with the expected content type and useful filename. Third, a sample of old date paths must resolve without a detour through a generic archive page. Record request evidence and expected targets alongside each group.
If a legacy PDF lacks an equivalent, its owner must decide whether to retain it or remove it honestly. The release owner can now see the remaining decision and assess its importance. This example illustrates how to improve a checklist; the numbers and circumstances describe no measured project.
Distinguish failed checks from misleading signals
When a check fails, reproduce it before expanding the incident. A missing title in one extraction may reflect a parser setting; missing main content in the browser is a different problem. A crawler blocked by its own authentication configuration does not establish that the production site blocks Google. Preserve request headers, time, environment and response details.
Consider competing hypotheses systematically. If every URL redirects to the same place, suspect a catch-all rule before blaming mapping data. If only one region fails, inspect delivery and access policies. If analytics alone declines, test consent and event delivery. If a new page works directly but cannot be found through navigation, investigate discovery.
A small sample cannot clear unsampled templates. Conversely, a single pre-existing broken link should not automatically block an unrelated infrastructure change. Use documented impact and scope to decide. The release QA workflow can turn confirmed regressions into reproducible developer tickets.
Gate six: authorise launch and preserve a route back
Before release, assemble the evidence, open exceptions, known limitations and recovery procedure in one decision record. Classify unresolved faults by affected journeys and available workarounds. Broad noindex, broken priority routing, invalid certificates and failed transactions are practical reasons to stop. Agree this before the deadline creates pressure to reinterpret failures.
Rehearse rollback for the relevant layer. Reverting code may preserve the database, but restoring an old database can discard orders and edits. DNS reversal has caching consequences. Cached permanent redirects can continue affecting visitors after the server changes. Name these risks explicitly and prefer a targeted repair where it is safer.
At launch, repeat the smallest critical production checks immediately: a retained page, a moved page, a missing page, a document and a conversion journey. Then expand coverage. Use the monitoring plan to assign observation periods and incident ownership. A signed checklist closes preparation; it does not guarantee indexing, rankings or the absence of later faults.
Frequently asked questions
How many URLs should we test before migration?
Test the complete mapping mechanically where feasible, then review representative content manually across templates and edge cases. Include priority destinations individually. Sampling should follow distinct behaviour, such as language or routing rules, rather than a convenient round number. Document what remains outside coverage.
Can we approve launch with outstanding SEO issues?
Yes, if the issues are understood, bounded and explicitly accepted by the release owner. Distinguish inherited defects from release regressions. An isolated low-impact metadata problem differs from a sitewide restriction. Record the consequence, owner and repair plan rather than hiding a failure behind a tick.
What evidence should developers attach to a failed check?
Include the source URL, expected destination or content, actual status and response, environment, timestamp and steps to reproduce. For rendered differences, provide the relevant page state and text or screenshot. A ticket saying only that SEO is broken leaves engineering to rediscover the problem.
Should a checklist include analytics checks?
Yes. A release that changes event collection can make a healthy migration look like a loss. Confirm representative page views and business events under the expected consent conditions. Keep measurement approval separate from search approval so one working system does not conceal a fault in the other.
When is the checklist finished?
Preparation is finished when launch gates are passed or exceptions approved. The release remains under observation until production checks, unresolved incidents and operational ownership are settled. Redirect upkeep, certificate renewal and regression checks then continue as maintenance rather than staying in an indefinitely open launch task.