At Green Hat, I owned architecture for more than 30 concurrent client projects. When I arrived, developers pushed files straight to production, with no environment separation and no rollback path.
When a WordPress site goes down after a plugin or PHP update, the recovery order is: capture the real error, disable all plugins, fall back to a default theme, then check whether your PHP version changed underneath you. Restore a backup last.
A restore erases the evidence and reinstalls the same broken combination that took the site down forty minutes ago. You are just creating a time loop of bugs.
Why WordPress sites break after a plugin or PHP update
Four things can break WordPress after an update:
- A plugin update ships code that conflicts with another plugin.
- A core update changes an API something was relying on.
- A theme calls a function that no longer exists.
- And a PHP version change, which your host may have made without asking you.
That last one causes the most total outages and is the hardest to spot, because nobody on your team did anything. When PHP 8.0 landed, Make WordPress Core counted 48 backwards-incompatible changes in PHP itself. Code that produced a quiet warning on PHP 7.4 throws a fatal error on PHP 8. create_function() was deprecated in 7.2 and removed in 8.0, and plugins abandoned in 2018 still call it. utf8_encode() and utf8_decode() were removed in 8.4.
The floor keeps rising too. WordPress 7.0 "Armstrong" shipped on 20 May 2026, requiring PHP 7.4 and recommending 8.3 or higher, and PHP 8.2 loses security support in December 2026. Hosts respond by moving everyone forward. Bluehost's own documentation lists PHP 7.3, 7.4, 8.0, and 8.1 as deprecated, with support starting at 8.2.
The recovery decision tree
Work top to bottom and stop at the first branch that gets the site loading. Every step below is reversible, which is why this order is safe to run on a live site.
Site is down after an update
│
├─ Did a Recovery Mode email arrive?
│ ├─ YES → open the link, read the named plugin/theme, go to Step 5
│ └─ NO → enable WP_DEBUG_LOG, reload, read debug.log (Step 1)
│
├─ Rename wp-content/plugins → plugins-off (Step 2)
│ ├─ Site loads → plugin conflict → go to Step 5
│ └─ Still down ↓
│
├─ Rename the active theme folder (Step 3)
│ ├─ Site loads → theme or functions.php
│ └─ Still down ↓
│
├─ Check PHP version in the hosting panel (Step 4)
│ ├─ Changed → roll back one version to confirm
│ └─ Unchanged → core files or database, escalate
│
└─ Reactivate plugins one at a time (Step 5)
Step 1: Capture the actual error
Before touching a single file, find out what WordPress is actually complaining about. Never guess the problem.
Check the site's admin email first. Recovery Mode has been part of WordPress since version 5.2: when a fatal error fires on a normal page load, WordPress emails the administrator a one-time link that logs you in with the offending plugin or theme paused for your session only. That email usually names the extension, which skips you straight to Step 5.
Two reasons it might be missing. WordPress rate-limits it to one per day by default, per the recovery_mode_email_rate_limit filter documented on developer.wordpress.org. And Recovery Mode only fires on regular page loads, so anything thrown during cron produces no email at all.
If nothing arrived, get the log yourself. Edit wp-config.php over SFTP and add this above the "stop editing" line:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG_DISPLAY defaults to true, so setting it to false keeps stack traces off a public page while WP_DEBUG_LOG writes them to wp-content/debug.log. Reload the broken page, read the last twenty lines, and note the file path and line number.
Pull the server-level PHP error log too. Errors that kill the request before WordPress loads its handler never reach debug.log.
Step 2: Disable every plugin at once
Renaming the plugins folder separates a plugin problem from an environment problem in about ten seconds, and it needs no dashboard access.
Over SFTP, rename wp-content/plugins to wp-content/plugins-off. WordPress can no longer find the plugin files, deactivates all of them, and loads. WordPress.org documents this method directly. Rename the folder back, and every plugin stays deactivated until you switch it on individually, which is the state you want for Step 5.
With SSH access, WP-CLI is cleaner:
wp --skip-plugins --skip-themes plugin list --status=active
wp --skip-plugins --skip-themes plugin deactivate --all
The --skip-plugins and --skip-themes global parameters stop WP-CLI from loading the broken code before it runs your command, which matters when the fatal error is severe enough to take WP-CLI down with it. Note that mu-plugins still load regardless, so check wp-content/mu-plugins if the site stays broken with everything else off.
Step 3: Fall back to a default theme
If the site is still broken with every plugin disabled, the theme is next, and the test takes fifteen seconds.
Rename the active theme's folder inside wp-content/themes. WordPress falls back to a bundled default theme automatically. If the site comes back, the failure lives in your theme, and nine times out of ten it lives in functions.php calling something PHP no longer provides.
This is also where you find out whether anyone put custom business logic in a theme instead of a plugin. That code just vanished from the running site, which is a diagnosis and a maintenance problem in one.
Step 4: Check whether your PHP version changed
With plugins and theme both eliminated, check the PHP version before you go anywhere near core files. Log into the hosting control panel, look at the current version, and compare it against what the site ran last week.
Hosts change this on their own schedule, sometimes with a warning email that lands in a shared inbox nobody reads. From the owner's side, it looks identical to a plugin breaking, because the symptom is the same white screen.
If the version moved, roll it back one step in the control panel. The change usually applies within a minute. If the site returns, you have your answer and a deadline, because that older version is going away. Use the window to run the failing plugins on staging against the newer version, update what can be updated, replace what has been abandoned, then move production forward deliberately.
If the PHP version held steady and the site is still down with plugins and theme disabled, you are looking at corrupted core files or a database problem. wp core verify-checksums will tell you whether core was modified. At that point, you are past the quick-recovery playbook, and the WordPress maintenance strategy question of whether you have a tested, restorable backup becomes the whole conversation.
Step 5: Reactivate one plugin at a time
Bisecting the plugin list is tedious, and it is the only method that ends with a definite answer.
Rename the plugins folder back, then activate plugins one at a time from the dashboard. After each activation, load the front page and the admin screen that was failing. When the error returns, you have the culprit.
Start with anything updated in the last 48 hours, then anything touching the same subsystem as the failure. A checkout error points at payment gateways and shipping plugins. An admin-only crash points at page builders. On a site with 40 plugins this takes about twenty minutes, which beats three days of theorising.
When the site loads but something is still broken
Partial failures after an update cost more than total outages, because nobody notices them for days. The site returns, the homepage looks fine, and the thing that actually generates revenue is quietly dead. WooCommerce subscription webhooks are the classic version, where the gateway logs a delivery failure while WordPress logs a success and both records are technically correct.
After any recovery, walk the transactional paths by hand. Place a test order, submit a form, trigger a webhook, confirm outgoing email still leaves the server. A dashboard reporting no errors means nothing here.
When to stop and escalate
Escalate when the site has been down for more than an hour and you still have not identified the failing component, or when the fix requires editing plugin code you did not write.
If the error appears only under load, or intermittently, you are at a resource or timeout ceiling, and WordPress speed optimization work is the actual repair.
Then there is the expensive version, the one that shows up as a pattern. A site that goes down after routine updates, over and over, has an environment problem wearing an update problem as a costume. Bringing in help when a senior dev isn't enough usually costs less than the fourth outage.
What actually prevents the next one
Every step above exists because someone updated production directly. Remove that, and most of this article stops being necessary.
The setup that works: a staging environment mirroring production, updates applied there first, a 24-hour soak before pushing live, and off-site backups you have actually restored at least once. Minor WordPress releases have installed themselves automatically since version 3.7, so that layer is handled. Plugins and PHP are where the discipline has to live.
At Green Hat, moving 30+ projects onto a dev/staging/production pipeline with pull-request approval cut deployment errors by half. Deployments got faster because there was one reviewed path to production and no way to silently overwrite a running site.
The next deadline is already on the calendar. PHP 8.2 loses security support in December 2026, and WordPress 7.1 arrives on 19 August 2026. You can meet those dates on staging in an hour, or meet them at 9 am on a Monday with the store down.
If your WordPress site keeps going down after routine updates, the outage is the symptom and the deployment process is the diagnosis. That's the kind of work I take on: getting a real staging pipeline in place so updates stop being an event.