When a WordPress update breaks a site, you’ll usually see a white screen, a “There has been a critical error on this website” message, or PHP fatal errors in the logs. The fastest fix: identify the plugin, theme, or core update that triggered it, roll back just that component (or restore from a pre-update backup), then re-test the rest one at a time. The real win, though, is catching it from your dashboard before the client ever notices.
What “broke” actually looks like
A failed update rarely produces a polite error. Across a fleet of client sites you’ll see one of these failure modes, and knowing which one you’re looking at tells you where to dig:
- White Screen of Death (WSOD), a blank page, no text. Usually a PHP fatal error with display disabled.
- “There has been a critical error on this website.”, WordPress’s fatal-error handler (since 5.2) caught a crash and stopped rendering. The admin gets a longer version: “…check your site admin email inbox for instructions.”
- Recovery Mode, WordPress emails the admin a special login link and auto-pauses the offending plugin or theme so you can still reach
wp-admin. This is your single best diagnostic gift. - Half-broken, front end loads but the checkout, a form, or the block editor throws errors. Often a plugin-version mismatch after a partial update.
Step 1: Detect it fast, before the client calls
The difference between a five-minute fix and an angry phone call is detection time. If you manage 10–500 sites, manually loading each one after update day doesn’t scale.
Manual / free checks
- Uptime monitoring on the public URL (UptimeRobot, BetterStack, or a self-hosted check). A critical error often still returns HTTP 200 with an error body, so HTTP-200-only monitors miss it, look for ones that check for a known string or a 500-class response.
- Recovery Mode emails, make sure every site’s admin email is a mailbox you watch, not the client’s. This alone surfaces most fatal errors within seconds of the bad update loading.
- A scripted sweep with WP-CLI across your sites:
wp eval 'echo "OK";'per install will exit non-zero / print a fatal if PHP is crashing.
Fleet detection with a dashboard
A multi-site management tool turns “check 200 sites by hand” into one screen. Siteward runs uptime checks against each site’s public URL and pulls health data from a lightweight child plugin, then flags critical errors and names the culprit, so instead of “Site X is down” you see “Site X: fatal after WooCommerce 9.4 update.” Because the engine runs checks in parallel, a 200-site fleet is scanned in seconds rather than minutes, and being self-hosted means that status data stays on your own server. See the full feature list for how detection and update monitoring fit together.
Step 2: Diagnose which update broke it
Don’t guess. WordPress will tell you exactly what crashed if you ask it.
Read Recovery Mode first
If you got the Recovery Mode email, click the link. WordPress shows precisely which plugin or theme it paused and the file + line number of the fatal. That’s frequently your whole diagnosis in one click.
Enable WP_DEBUG and read the log
No email? Turn on logging. In wp-config.php:
define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );, writes towp-content/debug.logdefine( 'WP_DEBUG_DISPLAY', false );, keep errors off the live front end
Reload the broken page, then open wp-content/debug.log. A line like PHP Fatal error: Uncaught Error: Call to undefined function ... in /wp-content/plugins/acme-forms/acme.php on line 212 points straight at the plugin and version that broke. With WP-CLI: wp plugin list --update=available shows what changed, and wp config set WP_DEBUG true --raw toggles debugging without editing files by hand.
Check the server error log too
Memory-exhaustion and timeout failures (common with big core or WooCommerce updates) often land in the host’s PHP error log (/var/log/php-fpm/ or via your panel) rather than debug.log. Allowed memory size … exhausted means bump WP_MEMORY_LIMIT, not roll back.
Step 3: Roll back safely
Once you know the culprit, choose the least-destructive fix that restores the site.
| Scenario | Fastest safe rollback |
|---|---|
| One plugin update broke it | wp plugin install acme-forms --version=2.3.1 --force (downgrade to the last known-good version), then deactivate auto-updates for it |
| Plugin paused via Recovery Mode | Deactivate it from the Recovery Mode dashboard, roll it back, re-activate |
| Theme update broke it | Switch to a default theme, downgrade, re-test the child theme |
| Core update broke it | wp core update --version=6.6.2 --force to step back one minor version |
| Can’t reach wp-admin at all | Rename the plugin folder via SFTP/SSH to force-deactivate, then diagnose |
| Multiple things changed / DB altered | Restore the pre-update backup (e.g. UpdraftPlus), then re-apply updates one at a time |
Rules of thumb: keep the WP Rollback plugin or WP-CLI’s --version flag handy for single-component downgrades; reach for a full backup restore only when a database migration ran or several components changed at once. Always take a fresh backup of the broken state before restoring, so you don’t lose orders or form submissions captured between the bad update and now.
Step 4: Prevent the next one
Most “update broke the site” emergencies are preventable with a repeatable process:
- Stage first. Push updates to a staging clone, smoke-test the key pages (home, checkout, a form, the editor), then promote. A 10-minute staging pass beats a 2-hour live recovery.
- Batch and sequence. Never click “update all” across every site at once. Update one or two pilot sites, watch for 24 hours, then roll the batch. If something breaks, it breaks on your test site, not the client’s storefront.
- Pin risky plugins. Disable auto-updates for page builders, WooCommerce, and anything with custom code; let low-risk utilities auto-update.
- Verify backups before update day, not after. A backup you never tested is a guess. Pro tiers in Siteward surface UpdraftPlus backup health so you can confirm every site has a recent, non-failing backup before you touch a single update.
- Monitor continuously. Pair uptime checks with critical-error detection so a regression that slips past staging is caught in minutes.
If you’re doing this across many sites and paying per-site fees with ManageWP-style tools, the math gets painful fast. Siteward is a self-hosted MainWP/ManageWP alternative with one flat price for unlimited sites, see pricing for the free dashboard and the Agency/Lifetime tiers that add backup and cron health.
A 5-minute emergency checklist
- Confirm the failure mode (WSOD, critical error, partial).
- Check for a Recovery Mode email, it may name the culprit instantly.
- Enable
WP_DEBUG_LOG, reload, readdebug.log+ server log. - Downgrade the single offending component, or restore the pre-update backup if the DB changed.
- Re-test, re-enable updates selectively, and note the bad version so it doesn’t get re-applied.
FAQ
How do I know which update broke my WordPress site?
Enable WP_DEBUG_LOG in wp-config.php and reload the broken page, wp-content/debug.log will name the exact plugin, theme, and line that threw the fatal error. WordPress Recovery Mode emails often name the culprit directly, and wp plugin list --update=available shows what changed.
How do I fix the “There has been a critical error on this website” message?
Check the site’s admin email for the Recovery Mode link, which auto-pauses the offending plugin or theme. If there’s no email, enable debug logging to find the fatal error, then downgrade the responsible plugin/theme/core version or restore your most recent pre-update backup.
Can I roll back a single WordPress plugin instead of restoring a whole backup?
Yes. Use WP-CLI, wp plugin install plugin-slug --version=1.2.3 --force, or the free WP Rollback plugin to revert just the one component to its last known-good version. Restore a full backup only when a database migration ran or several things changed at once.
How can I catch a broken update before the client notices?
Monitor every site’s public URL for 500-class responses or critical-error text, route Recovery Mode emails to a mailbox you watch, and use a fleet dashboard that flags fatal errors. Siteward scans all your sites in parallel and names the update that caused the crash, so you’re fixing it before the phone rings.
Why does my uptime monitor say the site is fine when it’s actually broken?
WordPress’s critical-error page often returns HTTP 200 with an error body, so monitors that only check for a 200 status report “up.” Use a check that looks for a known healthy string on the page or treats the critical-error message as a failure.