Short answer: if the site failed immediately after an update, that update is the first hypothesis — not yet the diagnosis. The new version may simply have exposed an incompatibility that already existed with your PHP version, theme or another plugin.
The first five minutes
- Record exactly what was updated, to which version, and at what time.
- Check whether the failure affects the whole site or one route, and whether
/wp-admin/loads. - Look for the WordPress recovery email in the administrator inbox.
- Confirm a backup exists from before the update — if not, snapshot the broken state now.
Get back in and read the log
If the site loads, deactivate the updated component from the admin. If not, rename its folder inside /wp-content/plugins (or the theme folder) over SFTP. Then enable WP_DEBUG_LOG and read /wp-content/debug.log — it names the file and line, which tells you whether the update itself failed or merely exposed a pre-existing incompatibility.
Deactivate or roll back?
Deactivating restores access fast but may disable payments, forms or memberships. Rolling back requires knowing the previous version and whether the update ran a database migration — a rollback after a completed migration can corrupt data. Snapshot before you roll back, since the rollback is itself a change you may need to undo.
Before you update again
The repair is not finished when the site loads. Know which version works, what condition caused the failure, and test the specific feature the component controls — not just the home page. For business-critical plugins, reproduce the update on staging with a verified rollback route so a bad release never hits production first.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Timing makes the update the first hypothesis, not proof. A safe response records versions, preserves the broken state and determines whether files, dependencies or a database migration changed.
- 1
Record component, previous/new version and exact update time.
- 2
Capture the fatal error and whether admin, front end or one route is affected.
- 3
Check release notes and whether a database migration ran.
- 4
Test rollback on a snapshot or staging copy before changing production data.
What must be verified
- The exact triggering feature works on the chosen version.
- Database schema and code version are compatible.
- A future update path is tested with backup and rollback.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →