Skip to content
Website Rescue Rescue

WordPress Errors

WordPress Website Broke After an Update

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

A WordPress core, plugin, or theme update loaded incompatible or broken code. Use recovery mode or rename the last-changed plugin/theme folder to restore the site, roll back safely from a backup or prior zip, then retest the update on staging—not by stacking more production updates.

Sites that fail right after an update usually show a critical error, white screen, or HTTP 500 while the database content is still intact. This guide covers isolating core vs plugin vs theme updates, using recovery mode, rolling back without wiping content, and turning the outage into a staging habit so the next release is tested first.

Intermediate

What the error means

Updates replace PHP and assets under wp-admin/wp-includes (core), wp-content/plugins/, or wp-content/themes/. If the new code fatals on your PHP version, conflicts with another active package, ships a bad release, or leaves mixed old/new files after a partial update, WordPress cannot finish bootstrapping. Auto-updates and bulk Dashboard → Updates runs make it harder to know which package broke first. Recovery mode, FTP renames, and error logs isolate the bad code; staging is where you retry—not live checkout or lead-capture traffic.

Common symptoms

  • Site broke immediately after a WordPress core, plugin, or theme update (manual or automatic)
  • Critical error message, white screen of death, or HTTP 500 on the front end and/or wp-admin
  • Admin recovery email arrives naming a plugin or theme and offering a recovery-mode link
  • wp-content/debug.log or the host PHP log points to a file inside a just-updated package
  • Only certain features fail (checkout, forms, builder, login) while other pages still load
  • Site Health or the Updates screen shows the new version, but the site only recovers when that package is off or rolled back
  • Bulk update finished, then the homepage went blank while other plugins still look “active”

Most likely causes

  1. 01 New package version incompatible with current PHP (especially PHP 8.0+ type and dynamic-property fatals)
  2. 02 Conflict between the updated package and another active plugin or the active theme
  3. 03 Incomplete update leaving a mix of old and new files in core, plugin, or theme directories
  4. 04 Plugin or theme now requires a newer WordPress (or companion add-on) version than you are running
  5. 05 WordPress core minor/major update exposing an outdated plugin that previously “happened to work”
  6. 06 Page, object, or opcode cache still serving broken bytecode or cached error pages after a partial update

What changed before the problem started

  • Manual update from Dashboard → Updates or a plugin/theme Update now link
  • Automatic background updates overnight for core, plugins, or themes
  • Bulk update of several packages in one click
  • Update paired with a PHP version change the same day
  • Staging sync or deploy that pushed newer core/plugin/theme files to production

Troubleshooting steps

  1. 01

    Use recovery mode if WordPress emailed a recovery link

    Open the “Your Site is Experiencing a Technical Issue” email on a trusted device, click the recovery-mode link, and log into wp-admin. Deactivate the plugin or theme WordPress names (or the one you just updated). Reload the front end in a private window. Success signal: critical error / WSOD / 500 is gone for visitors after the deactivate, not only in your recovery session.

  2. 02

    Isolate the last-changed package via FTP or file manager

    If wp-admin is down, open wp-content/plugins/ or wp-content/themes/ in SFTP/FTP or the host File Manager. Sort by modified time, rename the newest folder to slug.disabled, and reload. For a suspected core update, restore core files from a pre-update backup rather than deleting wp-admin. Success signal: the site loads after one targeted rename or core restore alone.

  3. 03

    Distinguish one-plugin fatal from a multi-package batch

    If several plugins updated together, disable the most recently modified folder first, then the next, until the site loads. Re-enable safe ones one at a time with a front-end check after each. This is slower than renaming everything at once but tells you which slug actually broke production. Success signal: you can name the single package whose disable restores the site.

  4. 04

    Confirm the culprit in the error log before reactivating

    Enable WP_DEBUG_LOG with WP_DEBUG_DISPLAY false, or open the host PHP error log, and match “Fatal error” lines to a path under plugins, themes, or core. Do not reactivate that package until you have a previous zip, vendor hotfix, or confirmed compatible version. Success signal: log path and the folder you renamed agree on the same slug.

  5. 05

    Roll back safely—prefer restore over delete

    Restore the previous plugin/theme folder or matching WordPress core from a backup, or upload the prior version zip from the vendor archive / wordpress.org older releases when available. Prefer renaming over deleting so you keep files for comparison. Purge page cache and CDN after rollback. Success signal: site stable on the older version with no fatals after a few page loads.

  6. 06

    Pause further updates and schedule staging

    Turn off auto-updates for the broken package (and other high-risk plugins) until you have a staging clone with the same PHP and WordPress versions. Retest the new release there first. Success signal: production stays on the rolled-back version; staging is where you retry.

When to stop troubleshooting

Pause if you cannot access files or recovery email, you keep disabling the wrong package, database migration damage is suspected, malware-looking files appear after an update, or the site is a live store mid-promotion. Hand off with the package slug, from/to versions, update time, log lines, and backup timestamp rather than stacking more updates on production.

Information to collect before requesting help

  • 01 What updated: WordPress core, plugin slug(s), theme, and from/to version numbers
  • 02 Whether wp-admin still loads or a recovery email arrived
  • 03 Exact error presentation (critical error, WSOD, 500) plus screenshot
  • 04 PHP version and WordPress version
  • 05 Error log lines naming the failing file path
  • 06 List of other packages updated in the same batch and their timestamps
  • 07 Backup availability from before the update (files and database)

How a professional repairs the problem

We identify whether core, a plugin, or a theme failed from logs and update timestamps, then isolate it with recovery mode or a targeted folder rename—without wiping the whole stack. After front-end and admin access return, we roll back or patch to a compatible release, flush caches, and verify critical journeys (home, login, forms, checkout). Finally we document a safer update process: staging first, selective auto-updates, and PHP/WordPress compatibility notes so the next release does not take production down again.

Frequently asked questions

Is a core update failure different from a plugin update failure? +
The symptoms look the same, but core lives in wp-admin and wp-includes. Prefer restoring matching core files from backup over deleting folders. Plugin/theme failures are usually fixed by renaming one directory under wp-content.
Will rolling back delete my posts and orders? +
Restoring plugin or theme files does not wipe posts, pages, or WooCommerce orders in the database. A full database restore to an older backup can overwrite newer content—restore files first when that is enough.
Should I update everything else to “catch up” while the site is down? +
No. Bulk updates on an already broken site make bisecting harder and can add more fatals. Stabilize first, then update one high-risk package at a time on staging.
Auto-updates broke my site—should I turn them all off? +
Keep auto-updates for trusted, low-surface security plugins if you have reliable backups and monitoring. Disable auto-updates for complex commerce, builders, membership plugins, and major core jumps until you have a staging workflow.
Why does the site still fail after I rolled back the plugin? +
Another package in the same batch may also be broken, a must-use plugin may still load, a drop-in may be involved, or cache may be serving old errors. Check logs again, clear all caches, and inspect mu-plugins.
What is the staging lesson after an update outage? +
Clone production, apply the same update there first, and only promote when home, login, forms, and checkout pass. That habit turns a production emergency into a controlled release.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.