# Restoring a site after a failed update

> White screen, critical error, inaccessible admin area after an update: the method to get back to a working state without losing orders placed in the meantime.

- Source canonique : [https://allaux.fr/en/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee](https://allaux.fr/en/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Rename wp-content/plugins to plugins-off over FTP first: if the site comes back, a plugin is at fault and you re-enable them one by one. If the screen stays blank, restore the file backup alone and leave the database untouched: the orders and content saved since the update live there, and a full database restore would wipe them. Export them first if the database has to go back too.

## What I check first

A failed update doesn’t always show up the same way, and the symptom points directly to the diagnosis. Before restoring anything, I work out exactly what’s broken: the entire site, only the admin area, or just one specific feature such as the WooCommerce checkout. Restoring a full backup blindly, without this diagnosis, often means fixing a minor problem at the cost of avoidable data loss.

The exact cause is almost always one of three things: maintenance mode stuck on after an interruption, a plugin or theme incompatible with the new version, or a PHP fatal error in code that was never tested against this configuration. Telling these three cases apart before acting avoids restoring a full backup when a simple plugin deactivation would have been enough.

## What you see after an update that went wrong

- White Screen of Death: no page renders, neither on the front end nor in the admin area
- "There has been a critical error on this website" message, with or without visible technical detail
- Admin area inaccessible while the public site seems to work normally
- Public site erroring out while the admin area stays accessible, often a sign of an issue specific to the active theme
- Site stuck in maintenance mode after an interrupted update, showing the usual "briefly unavailable for scheduled maintenance" message

## How I restore a site after a failed update

1. **Reading the debug.log** — I enable or check the debug log to pinpoint the exact cause: maintenance mode stuck on (the .maintenance file not removed), an incompatible plugin, or a specific PHP fatal error with the file name involved.
2. **Isolating via FTP rename** — If the log points to a specific plugin or theme, I disable it by renaming its folder over FTP, bypassing the admin area if it’s inaccessible. WordPress treats a renamed folder as a missing plugin and disables it automatically.
3. **Checking after isolation** — If the site works again after this targeted deactivation, the cause is confirmed. I can then look for a compatible version of the plugin or an alternative, without having touched the database.
4. **Full restore if the cause stays unclear** — If the log doesn’t allow the cause to be isolated quickly, or if several elements seem responsible at once, I restore the database and files backup taken before the update rather than keep searching blindly.

## The point of no return: orders placed in the meantime

> If the WooCommerce shop kept receiving orders between the backup and the incident, simply restoring that backup overwrites those orders in the database. Before any restore, I extract the recent orders (export or targeted copy of the relevant tables) to re-inject them afterwards. Once the restore runs without that extraction, those orders are gone.

## How I check after restoring

> Public site and admin area display, admin login, the full checkout through to payment, and the presence of orders placed before the incident, including any manually re-injected after an extraction.

## Related pages

- **Critical error on this site** — The possible causes behind this generic message and the method to tell them apart quickly. ([/wordpress-woocommerce/erreur-critique](/wordpress-woocommerce/erreur-critique))
- **Enabling WordPress debug mode** — How to enable WP_DEBUG and read debug.log without exposing errors to site visitors. ([/guides/activer-mode-debug-wordpress](/guides/activer-mode-debug-wordpress))
- **Reading WooCommerce error logs** — Where to find and how to interpret WooCommerce-specific logs, distinct from the general WordPress log. ([/guides/lire-logs-erreurs-woocommerce](/guides/lire-logs-erreurs-woocommerce))
- **Backing up a shop before an intervention** — What a backup needs to cover before any update or risky intervention, so it’s actually useful the day you need it. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))

## FAQ

### Can stuck maintenance mode really break everything?

Yes. If an update gets interrupted (network drop, execution timeout), the .maintenance file WordPress creates temporarily can stay in place and lock the whole site behind the "under maintenance" message. The fix is often as simple as deleting that file over FTP.

### How do you know if it’s the theme or a plugin at fault?

The debug.log usually names the exact file behind the fatal error, which directly identifies the plugin or theme responsible. Without a clear lead, I disable plugins one by one via FTP rename until the site works again.

### Can you avoid losing orders when doing a full restore?

Yes, by extracting the orders placed between the backup and the incident before running the restore, then re-injecting them into the restored database. It’s a manual step that has to happen before, never after.

### How long does restoring a site after an incident take?

A targeted plugin deactivation is sorted in a few minutes. A full restore with prior order extraction takes longer, usually from one to several hours depending on database size.