Your website broke right after an update: how to roll back safely and find the conflict

The symptom

You (or an automatic updater) applied an update — a plugin, a theme, a framework dependency, or a PHP version bump on the server — and now the site shows a white page, a generic "There has been a critical error on this website", a 500 error, or a broken layout with pieces missing. Sometimes the front end still loads but /wp-admin is locked, or the reverse. The tell-tale sign is timing: everything worked minutes ago and the only variable that changed was the update. That timing is your best diagnostic asset, so note exactly what was updated and when.

What it usually means

A single component now expects something the rest of the stack no longer provides. The four common patterns: a plugin or theme update introduced code incompatible with your PHP version (very common when the host also moved you from PHP 7.4 to 8.1+); two updated components now clash; an update ran a database change that only half-completed; or a dependency/library version no longer matches what the application calls. A fatal PHP error stops the whole page from rendering, which is why a small conflict can take the entire site down rather than degrading one feature.

What we check first

We enable logging before touching anything. In wp-config.php we set define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); then reload the broken page and read wp-content/debug.log. The last fatal line names the culprit directly, e.g. PHP Fatal error: Uncaught Error: Call to undefined function ... in /wp-content/plugins/some-plugin/inc/class.php on line 212 — that file path is the conflicting component. In parallel we check the server error log (often the hosting panel's error_log, /var/log/php-fpm/ or /var/log/nginx/error.log) and confirm the active PHP version with php -v. If admin is reachable we deactivate the just-updated plugin; if it is not, we use WP-CLI: wp plugin deactivate <slug>, or wp plugin deactivate --all to prove the theory, then reactivate one by one to find the exact conflict. For a bad theme we switch with wp theme activate twentytwentyfour to restore access.

What you can safely check yourself

Confirm the timeline: check your update history or host backup log to see exactly what changed and when. Try loading /wp-admin separately from the front page — knowing which side is down narrows the cause. If you have a recent full backup taken before the update, note its timestamp; that is your clean rollback point. You can safely deactivate the single plugin you just updated from the admin plugins screen if it still loads, and you can clear any caching plugin or CDN cache, which sometimes clears a stale-asset breakage on its own. Screenshot or copy the exact on-screen error text before changing anything.

What NOT to touch

Do not delete plugins, themes, or files to "clean up" — deleting a plugin can also drop its data. Do not change the PHP version back and forth repeatedly hoping it fixes itself; pick a target and test deliberately. Do not run database repair or import an older SQL dump over a live database without a backup first, and never edit wp-config.php credentials or the wp_options siteurl/home values unless you know exactly why. Above all, do not click "update everything" again to try to escape the problem — you will lose the ability to tell which change caused what.

What a 30-minute diagnosis can determine

In a focused 30-minute session we can usually get the site back to a usable state and name the real cause. That means capturing the fatal error from debug.log, identifying the exact plugin/theme/PHP incompatibility, deactivating or rolling back only that component to restore the site, and telling you whether the fix is permanent or a temporary hold. You leave the session knowing which component broke, why, and whether it needs an update, a downgrade, a patch, or a PHP-version decision — not a vague "something with the update".

When it becomes a bigger job

It grows beyond a quick rollback when the update ran an irreversible database migration and reverting the plugin leaves the schema mismatched, when a discontinued or abandoned plugin has no version compatible with your required PHP, or when several components are entangled and each one's fix breaks another. It is also bigger when there is no clean pre-update backup, so recovery means reconstructing state, or when the safe path is to build a staging copy, reproduce the conflict there, and fix it properly before touching production again. In those cases the work is planned and tested rather than done live under pressure.

Frequently asked questions