A local business website change can affect how customers call, visit, book, order, or ask for help. Keep evidence that proves the intended release reached the public hostname and that critical customer paths still work. A local build, hosting receipt, or screenshot alone is not live verification.
Define the release and approval
Save the change request, purpose, owner, approver, maintenance window, affected pages, content records, forms, redirects, environment variables, third-party widgets, and exclusions. Identify the previous and candidate release by commit, artifact hash, and hosting deployment ID. Record who can authorize rollback.
The Microsoft operational security evidence guide describes change evidence covering impact, testing, approval, and back-out planning. Keep restoration steps, named personnel, and the checks used to validate service after recovery.
Capture a public before-state
From a logged-out browser, record HTTP status, final URL, page title, visible business name, phone, address, hours, service area, and critical links. Save response headers and hashes for a few stable files. Test mobile navigation and keyboard access to essential actions.
Submit a synthetic contact or booking request using invented data and a unique identifier. Confirm receipt at the authorized destination and record timestamps. Do not use a customer’s personal information or complete a real charge or appointment merely to test the site. For external map, ordering, or booking services, verify the handoff URL and visible destination.
Inventory analytics and consent behavior only to the level needed for the change. Record tag or configuration versions and a synthetic event if authorized. Do not treat analytics counters as proof that a form or purchase completed.
Preserve URL and search-control evidence
Save the old-to-new URL map, redirects, canonical URLs, robots directives, sitemap entries, and representative structured data. Google's site-move guidance recommends mapping old URLs to new ones and using redirects to corresponding destinations. Record status and final destination for each representative URL.
Check for redirect loops, chains, soft error pages, and unrelated destinations. Preserve the reason for intentional removals. Search results may update later than the live site, so distinguish technical deployment state from search visibility.
Keep deployment and platform receipts
Record build time, source revision, dependency lockfile hash, artifact or manifest hash, deployment ID, environment name, and provider result. Protect secrets; record variable names and managed-secret references, never secret values.
If using Cloudflare Pages, the rollback documentation says successfully built production deployments are valid rollback targets and preview deployments are not. Confirm the known-good production target is eligible before the change and save its ID. Other hosts require their own evidence.
Verify the public after-state
Repeat the external checklist against the public hostname from a clean session. Compare status, redirects, visible business data, form delivery, phone and map links, booking or ordering handoffs, security headers, canonical URL, robots controls, sitemap, and structured metadata. Compare live file hashes with the intended manifest.
Record cache observations and test from another network when practical. A provider dashboard can report successful deployment while an edge or custom domain still serves older content. Preserve the public response rather than inferring it.
Check accessibility affected by the change: headings, labels, focus order, keyboard operation, alternative text, contrast, and error messages. Keep results and exceptions, not only a score.
Rehearse rollback and retain decisions
On a controlled scope or scheduled exercise, restore the known-good production release. Record start time, operator, deployment target, provider response, time public content changes, and every repeated customer-path check. Confirm a new synthetic form reaches the proper destination and redirects return to the expected map.
Store evidence by sensitivity. Form messages and administrative logs need tighter access than public HTML hashes. Define retention and deletion authority. The closing record should distinguish prepared, deployed, publicly verified, rolled back, and unresolved states, with owners and dates.
A trustworthy website change pack lets another reviewer reconstruct what was intended, what reached the public domain, which customer actions were tested, and whether recovery actually restored them. It proves the live experience rather than just preserving deployment paperwork.
Sources
- Microsoft 365 Certification sample evidence guide operational security — Microsoft Learn
- Site Moves and Migrations — Google Search Central
- Rollbacks — Cloudflare, April 21, 2026