A local business website incident is any failure that materially blocks or misleads customers: the site is unavailable, a contact form drops requests, hours or phone numbers are wrong, redirects lead elsewhere, checkout handoff fails, or unauthorized content appears. Respond by preserving evidence, reducing customer harm, and verifying recovery from the public internet.
Start one timestamped incident record
Assign an incident identifier, lead, technical operator, communications owner, and decision authority. Record the first confirmed symptom, detection source, public URLs, affected customer actions, release identifier, hosting provider, and known recent changes. Use a consistent time zone.
Keep observation separate from diagnosis. “The contact form returns 500 at 07:18” is evidence. “The deployment corrupted the database” is a theory until logs and configuration support it. NIST's SP 800-61 Rev. 3 frames preparation, detection, response, and recovery as connected risk-management activities. Escalate suspected unauthorized access, malicious redirects, exposed data, or content tampering through the approved security and privacy process.
Measure public impact before changing production
From a logged-out browser and, if possible, a second network, test the homepage and representative service pages. Record status code, final URL, visible business name, phone, address, hours, certificate state, and critical links. Submit a clearly marked synthetic form without real customer data and confirm whether it reaches the authorized destination. Test booking, map, ordering, or payment handoffs without creating a real purchase or appointment.
Check whether the incident affects one device, one region, cached visitors, all public traffic, or only authenticated administration. Preserve response headers, content hashes for stable files, screenshots where useful, and hosting logs. Do not paste customer form contents, tokens, or account secrets into the incident record.
Contain the smallest confirmed failure
If only a widget or integration is failing, disable or bypass that component using an approved reversible change rather than taking down the whole site. Publish an accurate temporary contact path when necessary. Do not invent business hours, availability, or response promises during an outage.
For a bad release, identify the exact known-good production deployment. Cloudflare's Pages rollback documentation says that successfully built production deployments are valid rollback targets and preview deployments are not. Other platforms differ, so confirm eligibility before declaring rollback possible. Record the selected target identifier and its known limitations.
If compromise is suspected, do not destroy logs or broadly reset account, DNS, or payment settings without the authorized security owner. Preserve evidence and follow the organization's credential and access procedure. Move responder coordination outside the affected website administration if its integrity is uncertain.
Keep an action and communication timeline
For every change, record operator, approval, reason, expected result, actual result, and rollback. Note customer-facing messages and where they appeared. Status updates should state confirmed scope, available workaround, unresolved risk, and the next update time. Avoid claiming that all requests were received when the form delivery path is not verified.
If the incident involves URL changes, preserve the intended mapping. Google's site-move guidance recommends mapping old URLs to new ones and using redirects to corresponding destinations. Check for loops, chains, unrelated destinations, and missing pages. Search results will not necessarily change immediately when production is repaired, so report the live technical recovery separately from search visibility.
Recover and verify externally
Restore the known-good deployment or apply the smallest tested fix. Then rerun the entire public checklist. A 200 response is not enough: verify visible contact details, hours, navigation, forms, phone and map links, booking or ordering handoffs, redirects, robots controls, canonical URLs, and representative structured metadata when relevant.
Confirm the live response matches the intended release using content or asset hashes. Test from a clean session so administrator cookies do not hide a public problem. Observe long enough for caches, delayed form delivery, webhook retries, and scheduled content to settle. Reconcile synthetic form IDs with the destination system.
Close with learning, not guesswork
Document the leadup, cause if established, customer impact, containment, recovery, evidence gaps, and follow-up actions. Actions might include external uptime checks, synthetic form monitoring, content approval, immutable release receipts, redirect tests, or a rollback rehearsal. Give each an owner and due date.
The incident is resolved only when critical customer paths are verified publicly, affected submissions are accounted for as far as evidence allows, and remaining uncertainty is clearly owned. A dashboard's green light is useful, but the business needs proof that a customer can reach and use the restored site.
Sources
- NIST SP 800-61 Rev. 3 — National Institute of Standards and Technology, April 3, 2025
- Rollbacks — Cloudflare, April 21, 2026
- Site Moves and Migrations — Google Search Central