Maintenance
An update broke your site. How to undo it, fast.
27 August 2026 · 6 min read
On this page
You clicked update and the site is now blank, broken, or missing something important. This is recoverable, almost always, and usually within fifteen minutes.
Work top to bottom.
If you can still reach the admin
Deactivate the plugin you just updated. Plugins → Installed Plugins → Deactivate. If the site comes back, you have found it.
Then roll it back rather than leaving it off. The free WP Rollback plugin adds a "Rollback" link to each plugin, letting you reinstall the previous version in two clicks. Reinstall the version that worked, and leave it there until the developer ships a fix.
If you cannot reach the admin
The white screen, or a fatal error page. WordPress is failing before it can render anything, which means you need file access — SFTP, or your host's file manager.
Rename the plugin folder. Go to wp-content/plugins, find the folder for the plugin you updated, and rename it — akismet becomes akismet-off. WordPress cannot find it, so it deactivates it automatically, and the site usually returns immediately.
If you do not know which one, rename the whole plugins folder to plugins-off. That disables everything at once. If the site comes back, rename it back and then rename plugins one at a time until it breaks again — that names your culprit.
If it is a theme, rename the theme folder in wp-content/themes. WordPress falls back to a default theme, which is ugly but working.
Do not delete anything while diagnosing. Renaming is reversible; deleting is not, and you may need the files to work out what happened.
Read the actual error
The white screen is hiding a message. Turn logging on by adding this to wp-config.php, above the line that says "stop editing":
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
Reload the site, then read wp-content/debug.log. It will name the file and line, which names the plugin. WP_DEBUG_DISPLAY set to false matters — it logs without showing errors to visitors.
Turn all three off again once you are done. Leaving debug on in public is a security problem of its own — it reveals file paths and software versions to anyone who triggers an error.
The common causes
A PHP version mismatch. The new version requires PHP 8.1 and your host runs 7.4. The debug log says "syntax error, unexpected" in a file you have never opened. Fix: ask your host to upgrade PHP, which is usually one click and free.
A plugin conflict. Two plugins that were compatible are not any more. Fix: roll one back and report it to both developers.
A theme template override. Your theme carries customised templates that the updated plugin no longer expects — very common with WooCommerce. WooCommerce → Status flags outdated templates.
Memory exhaustion. "Allowed memory size exhausted" in the log. Add define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php, and if that does not help, ask your host.
When to restore a backup instead
Restoring is the blunt instrument. Use it when the site is badly broken, you cannot identify the cause, and you have a backup from before the update.
The cost is everything since that backup — orders, comments, form submissions, content. On a shop, restoring can be worse than the outage. Try rolling back the single plugin first, always.
Preventing the next one
Back up before updating, every time. Not weekly — immediately before, so the restore point is minutes old rather than days.
Update in the right order: core, then plugins, then themes.
Check afterwards. Homepage, a key inner page, a form, and checkout if you have one. This is the step that turns "we updated" into "we know it still works".
Use staging for anything major. Most decent hosts include one free.
Do not update on a Friday unless you plan to be around for the consequences.
That routine is thirty minutes a week, and it is what our care plans do for you — with a rollback in minutes if something moves, rather than you discovering it on Monday.