Website Rescue Checklist: When Your Site Goes Down

Immediate actions that reduce damage and speed up recovery when a website is down or compromised.

Direct Answer

When a site goes down, stabilise it before you change anything. Most of the damage in a rescue comes from panicked edits, not the original fault.

Get it back to a known good state first, then find and fix the actual cause, then clean out whatever got in.

Only turn everything back on once monitoring is watching it, so if it happens again you find out before your customers do.

1) Stabilise before you change anything

Do not random-fix in production while under pressure. Capture current symptoms, isolate access, and preserve forensic value.

Fast but controlled triage prevents a second outage caused by rushed changes.

• Confirm outage scope
• Lock down admin access
• Snapshot logs and files

2) Remove threat, then patch root cause

Recovery is not complete until the root weakness is fixed. Cleaning visible malware alone leads to repeat incidents.

Core patching, credential rotation, and hardening should be done in the same window as restoration.

3) Re-enable with monitoring

Bring the site back with active checks in place so regressions are caught quickly.

Post-incident monitoring and backups are part of closure, not optional extras.

Implementation Playbook

• 1 Confirm outage impact and affected systems immediately.
• 2 Restrict access and isolate risky components.
• 3 Capture logs, timestamps, and file-state evidence.
• 4 Restore from known-good state where required.
• 5 Patch vulnerable plugins/themes/core components.
• 6 Rotate credentials and API keys tied to the stack.
• 7 Reinstate services with active monitoring enabled.
• 8 Run smoke tests on forms, checkout, and critical routes.
• 9 Document root cause and the exact remediation steps.
• 10 Apply long-term hardening and backup verification.

Common Mistakes to Avoid

• Treating launch date as fixed while scope keeps changing.
• Skipping technical QA because the design looks complete.
• No owner for approvals, causing review bottlenecks.
• Launching without monitoring or backup verification.
• Ignoring mobile conversion flow until after launch.

Follow-up Questions People Ask

Not always. Decide based on risk and exposure. In some cases isolation plus controlled traffic handling is safer than a hard shutdown.

No. Backups restore state, not security posture. You still need root-cause patching and credential rotation.

Immediately. Alerting thresholds should be tightened during the post-incident period while the system stabilises.

LET’S TALK

Tell us about your project. We’ll get back to you within 24 hours. Emergency? Call us directly.