Know what you can restore.
A website includes code, stored data and uploaded files. They can have different version and recovery mechanisms.
Match the recovery plan to the part of the site the task may change.
Record the starting code version.
Keep the relevant theme and custom code in a private repository. Save a known working baseline before editing and save later changes so versions can be compared.
Identify the code version used for a release. This helps the team return to earlier code when that is the appropriate correction.
Keep database recovery separate.
WordPress content and many operational records are stored in its database. Theme-code history does not restore those records.
Before a task that could affect data, verify the relevant backup and how recovery would work. Restoring an older database can also affect records created after that backup, so preserve newer live activity in the recovery plan.
Account for uploaded files.
Images and other uploads need their own recovery coverage. A database record can refer to a file that code history does not contain.
Know where the site’s media is stored and how the required files are backed up. Avoid treating a successful code restore as proof that the full page has recovered.
Protect orders and submissions.
When code moves from staging to live, preserve current production orders, form submissions and customer data. Moving a code change does not require replacing all live data with a staging copy.
Choose the deployment and recovery procedure with the site’s operator or developer before the first consequential task.
Verify coverage before the release.
Confirm the baseline, backup scope and restore procedure. After a release or recovery, inspect the site and test the function affected by the work.
Keep the task small enough that the team can understand what changed and how to check it.