When a WordPress site breaks immediately after an update, the fastest path is usually not to keep changing settings. Preserve the failure, establish a rollback point and identify which layer changed.
First priority: if the site is still taking orders, submissions or logins, protect current data before restoring an old database backup.
1. Identify what changed
Record the exact update or server change that happened before the failure: WordPress core, a plugin, a theme, PHP, database, cache configuration or hosting environment. If several updates ran together, the job becomes dependency isolation rather than a simple rollback.
2. Separate a visible error from a blank failure
A PHP fatal error, HTTP 500, blank page and broken layout point to different layers. Server and PHP logs are usually more useful than repeatedly refreshing the page. If debugging output is enabled, avoid exposing stack traces to public visitors.
3. Test the plugin boundary
If wp-admin is unavailable, plugin folders can be disabled carefully from the filesystem to test whether execution returns. Re-enable one change at a time. Do not permanently rename a large set of folders without recording the original state.
4. Check the active theme only after plugins are understood
Theme failures are common after PHP or template changes, but changing both plugins and theme at the same time removes useful evidence. Work one boundary at a time.
5. Treat PHP upgrades as application changes
A site can run for years with code that becomes fatal on a newer PHP version. Deprecated behavior may turn into warnings or hard errors depending on the code path. If the failure began with a PHP change, test the application stack against that change directly.
6. Clear caches only when you know which cache you are clearing
Browser cache, page cache, CDN cache, PHP opcode cache and Redis object cache are different systems. Clearing everything can sometimes hide a repeatable symptom without fixing the cause.
7. Restore only as far as necessary
A file rollback may be enough for a plugin or theme failure. Restoring the entire database can overwrite new orders, users or content. Match the rollback to the layer that actually changed.
When to stop debugging in production
If the fault is intermittent, data-sensitive or involves checkout, authentication or scheduled processing, reproduce it in staging whenever possible. Production is for confirming the fix, not for uncontrolled experiments.