Website Recovery Planning Guide

A recovery plan doesn’t need to be long to be useful. It needs to answer the handful of questions you’d otherwise have to figure out from scratch, under pressure, while something is broken. This guide walks through building one in about 30 minutes.

Step 1: Write down where your backups actually live

Start with the basics: where are your backups stored, and how do you access them? Include login details or, better, a note on where those credentials are kept securely. If backup access depends on a single person, note that explicitly — it’s a gap worth closing.

Step 2: Define how you’ll choose which backup to restore

You don’t need a complex decision tree. A simple rule works for most situations:

1. Identify roughly when the problem started.
2. Find the most recent backup taken before that point.
3. Confirm what that backup includes and what would be lost by restoring it.

Write this rule down so it’s the same process every time, rather than being reinvented during each incident.

Step 3: Assign responsibility

Even for a one-person operation, it helps to write down explicitly who makes the call to restore, who has the access to do it, and who verifies the result afterward. For teams, this avoids the delay of figuring out ownership in the moment.

Step 4: Define what “resolved” looks like

Decide in advance what you’ll check after a restore to confirm the issue is actually fixed:

• Does the site load correctly on its key pages?
• Is the specific issue that triggered the restore gone?
• Does anything else look different from what you expect?

A short, consistent checklist here prevents declaring an incident closed too early.

Step 5: Note what a restore won’t fix

Not every incident is solved by restoring a backup. If the underlying cause is a compromised account, a vulnerable plugin, or an ongoing configuration issue, restoring a backup may bring the problem right back unless the root cause is also addressed. Your plan should include a reminder to ask “why did this happen” before considering the incident closed, not just “is the symptom gone.”

Step 6: Store the plan somewhere you’ll actually find it

A recovery plan that lives only in your memory isn’t much better than no plan at all. Put it somewhere accessible independent of the site itself — since if the site is the thing that’s broken, you don’t want your plan to be unreachable too.

Step 7: Revisit it periodically

Treat the plan as a living document. Review it whenever your hosting, backup tooling, or team changes, and after any real incident — update it with anything you learned that would have made the response smoother.

Putting it together

A minimal recovery plan is really just a written answer to five questions: where are the backups, how do you choose one, who decides, what does resolved look like, and what won’t a restore fix on its own. Pair this guide with our Website Backup Checklist and What to Check Before Restoring a Website for the full picture.

The takeaway

The difference between a stressful incident and a manageable one is rarely the technology — it’s whether the decisions have already been made ahead of time. Thirty minutes spent writing down these answers now can save hours of confusion later.