WordPress Site Down After an Update: Fix It

September 7, 2026

WordPress site down after an update, showing a fatal error warning

Updated for WordPress 7.1 and PHP 8.3 — 7 September 2026.

If your WordPress site is down after an update, the fastest route back is a restore point, not a diagnosis. A white screen or a fatal error after updating a plugin, theme or core almost always traces to one extension, and you can find which one in about ten minutes — but do the rollback first if the site earns money, because troubleshooting a live outage costs more than it saves. Fix it, then find out why.

Check your email before you touch anything

WordPress has emailed you a recovery link, and it may be the whole fix. Since version 5.2, core catches fatal PHP errors and sends the site administrator an email containing a secret link into recovery mode, with the offending plugin or theme paused so you can log in normally. The Make WordPress Core announcement covers how the mechanism works.

Check spam as well as your inbox. There is a real catch here worth knowing: if the fatal error happens before your SMTP plugin loads, WordPress falls back to sending mail directly from the web server, and server-sent mail is frequently filtered or blocked outright. So the email that would rescue you is sent through the least reliable path available, exactly when you need it most. If it never arrives, that is not unusual and it is the same delivery problem that breaks contact forms.

Roll back if the site matters

A restore point taken immediately before the update is a one-action fix, and it should be your default when a store or booking site is down. Restore, confirm the site is serving, and only then work out what happened — on staging, at your own pace, with nobody watching.

If you do not have a restore point from immediately before the update, this is the moment that argument stops being theoretical. A safe WordPress update routine exists to make sure the next outage takes one click instead of an afternoon, and testing a backup you have never restored is how you find out whether the restore you are about to rely on actually works.

Turn on error logging so you can see the cause

A white screen is PHP failing with error display switched off, so your first job is making the error visible without showing it to visitors. Add these to wp-config.php, above the line that reads /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

That combination writes errors to a file while showing visitors nothing. WP_DEBUG_LOG writes to wp-content/debug.log by default, and the WordPress debugging documentation confirms both the constants and that path.

Two warnings that matter more than the technique. First, wp-content/debug.log is inside your web root, which means it can often be read by anyone who guesses the URL — and it will contain file paths and sometimes query fragments. Delete it when you are done, or point the log somewhere outside the web root. Second, WordPress documentation is explicit that debug mode is not meant for production, so turn all three back off the moment you have your answer. Leaving WP_DEBUG on permanently is a slow information leak.

The last few lines of that log almost always name a file. That file’s path tells you the plugin or theme responsible without any further guesswork.

Deactivate plugins to isolate the culprit

If you can still reach the dashboard, deactivate every plugin at once, confirm the site returns, then reactivate one at a time until it breaks again. The one that breaks it is your answer. It is crude and it is reliable.

Locked out of the dashboard? With SSH and WP-CLI you can do the same thing without it:

wp plugin deactivate --all
wp plugin activate <plugin-slug>

Reactivate one slug at a time and reload between each. The WP-CLI plugin documentation covers the full flag set. With no SSH access, renaming the wp-content/plugins folder to plugins-off over SFTP has the same effect — WordPress cannot find them, so it deactivates them all. Rename it back afterwards and reactivate individually.

If you cannot get into wp-admin at all, the ways back into WordPress admin covers that separately.

When it is the theme, not a plugin

If deactivating every plugin changes nothing, the theme is next. Switch to a default theme such as Twenty Twenty-Five, either from Appearance or with WP-CLI, and reload. If the site returns, your theme or child theme is the problem — most often a function calling something that a core or PHP update removed. If it is a customisation you added, it belongs in a child theme rather than the parent.

Renaming the active theme’s folder over SFTP forces WordPress to fall back to a default theme, which is the equivalent escape hatch when you have no dashboard and no SSH.

When it is PHP, not WordPress

A site that breaks right after a PHP version change rather than a plugin update is a different problem with a similar face. Errors mentioning removed functions or changed syntax point at code written for an older PHP than the one now running it; the PHP migration appendices list what changed between versions.

The honest fix is updating or replacing the offending code. Rolling PHP back buys you time, and it is a reasonable emergency measure, but it leaves you on a version that will eventually stop receiving security fixes. Treat it as a deadline, not a solution.

Frequently asked questions

What causes the WordPress white screen of death?

A fatal PHP error with error display turned off, so nothing renders. The cause is usually a plugin or theme incompatible with the version of WordPress or PHP now running. Enabling WP_DEBUG_LOG turns the blank page into a filename.

I never received the recovery mode email. Why?

Most often because the fatal error occurs before any SMTP plugin loads, so WordPress sends the message directly from the web server — a path that is frequently filtered as spam or blocked. Check spam, then fall back to WP-CLI or SFTP.

Can I just restore and skip the diagnosis?

You can, and for a live store you should restore first. But do the diagnosis afterwards on staging, because the update will still be waiting next time — and it may be a security release you cannot postpone indefinitely.

Is it safe to delete wp-content/debug.log?

Yes. WordPress recreates it when logging is enabled. Deleting it when you finish is good practice, since it sits in the web root and contains server paths.

The site works logged in but not logged out. Is that this problem?

Probably not — that pattern usually means a cache is serving a stale or broken page to visitors. See WordPress changes not showing.