Scope and preparation
Version 1.0 · Prepared October 27, 2026
Scope: A static website release, not a server recovery procedure. The checklist below combines checks exercised during a CyberWebNet website release with recommendations clearly labelled as such. It does not establish that every future release is safe.
A green build proves that a build completed. It does not prove that visitors receive the reviewed files, that a mobile menu works, or that security headers survived deployment. Keep three separate receipts: the source you approved, the files you built, and the responses people actually receive.
1. Freeze a candidate, not a moving branch
Record the exact source revision and the build output's file hashes. Bind review and CI evidence to that revision. GitHub exposes workflow logs at job and step level; read the actual relevant run rather than relying on a remembered green badge.[12] If a later merge has a different revision, verify its content matches the reviewed tree and check its own required gates.
Stop if: an unexplained file changed after review, or the evidence belongs to a different candidate.
2. Check the output before deployment
Run the project's existing build, regression suite and dependency audit. Inspect generated routes, internal links, search data and the error page. Keep the tools and versions with the private receipt. For the website release used here, the recorded candidate suite passed 71 tests, alongside a generated-search DOM regression. The independent local review recorded Astro 7.4.1 and Node 22.23.4. These are historical test details, not a recommendation to install those versions today.
Stop if: a test failed, the generated content is wrong, or private material appears in public output. A dependency audit without findings is not proof that software has no vulnerabilities.
3. Use a preview, but treat its URL as public
Cloudflare Pages previews let you inspect a version without replacing production.[10] Do not put private conversations, credentials, or operational inventories in a preview. A hard-to-guess URL is not a substitute for tested access control.
Exercise real tasks: open navigation with a keyboard, reach the skip link, use search and its reset, and follow an article back to its parent section. Check narrow screens as well as desktop. Do not stop at the homepage.
4. Verify the hosted responses
After an authorized release, compare the actual public files against the frozen manifest. Check redirects, canonical URLs, the missing-page response, and security headers. Test the policy in a real browser: a locally served page alone does not show that the hosting provider enforced its headers.
The recorded production acceptance for this example matched 29 public file hashes. It checked 16 HTML documents at four viewport widths—320, 390, 768 and 1440 pixels—for 64 page/viewport checks, and exercised 16 interactions. It also checked unchanged security headers and blocking of the deliberately tested inline script/style cases. Those are specific checks, not an exhaustive security audit or accessibility certification. They used Chromium emulation, not Safari or physical phones. The release's acceptance was observed October 26, 2026 in America/Phoenix; this guide has not rerun that release.
Stop if: hosted content differs without explanation, intended controls fail, or unexpected requests/errors appear. A successful deploy job is not visitor acceptance.
5. Prepare a return path without pretending you tested recovery
Record a known-good production target and who can authorize returning to it. Cloudflare documents that successfully built production deployments can be rollback targets; preview deployments cannot.[13] Keep preparation separate from an actual rollback drill. The website evidence used here retained a prior successful production target; it did not execute a live production rollback.
Recommendation, not an exercised step in this guide: test a return procedure in an appropriately isolated environment before depending on it. A source archive and matching hashes do not establish bare-metal or storage-system recovery.
A useful completion note
Write: “Revision checked; build and named tests passed; hosted files matched; listed visitor tasks worked; rollback target retained; remaining limits recorded.” Replace each phrase with its real result or say “not checked.” That is more useful than “deployed successfully.”