How I Fix the WordPress White Screen of Death

When a visitor hits a blank page and the browser shows nothing but white, that is the classic WordPress white screen of death. No theme layout. No admin menu. Sometimes not even a PHP error on screen. I see this often while maintaining WordPress sites from Surat for businesses and stores, usually right after a plugin update, a theme change, or a PHP version bump.

Since WordPress 5.2, the same fault often shows a short message instead of pure white: “There has been a critical error on this website.” It is the same problem underneath, a PHP fatal error, and the fix follows the same steps.

Below is the practical process I use: how I confirm it is a real white screen, how I use Recovery Mode, how I turn on safe logging, how I isolate plugins and themes without guessing on a busy live site, and how I prevent the next blank page.

What the WordPress white screen of death looks like

A true white screen is different from a slow site or a half-loaded builder canvas. I treat it as that blank fatal state when:

• The page is completely blank — no header, footer, or error message for visitors
• Or the page shows only “There has been a critical error on this website”
• wp-admin may also be blank, or only the front end fails
• It started after an update, a new plugin, a theme switch, or a hosting PHP change
• Server or hosting logs show a PHP fatal, memory exhaustion, or a missing function

If the site is only sluggish, I start with performance checks instead — the same order I use in why a WordPress site feels slow. If the page says “Error establishing a database connection”, that is a different problem with its own steps, covered in my post on the WordPress database connection error. A white screen usually means PHP stopped before WordPress could finish rendering.

Check the Recovery Mode email first

When WordPress catches a fatal error in a plugin or theme, visitors see the critical error message and WordPress emails the site’s admin address. The subject line is “Your Site is Experiencing a Technical Issue”, usually with the site name in front. I check that inbox (and spam) before I touch any files.

• It names the plugin or theme that failed, with the error details
• Its login link ends on wp-login.php?action=entered_recovery_mode with a “Recovery Mode Initialized” notice
• After I log in, the broken plugin or theme is paused for my session only. Visitors still see the error until I fix it
• I deactivate or roll back the named plugin, check the site in a private window, then click “Exit Recovery Mode”

Typing that URL by hand only shows the notice; the pause comes from the token in the email link. With no email, I use the file-based steps below.

If the admin address is an old one, the email is lost. Afterwards I add define( 'RECOVERY_MODE_EMAIL', 'you@example.com' ); to wp-config.php with an inbox someone reads.

Back up before you chase a blank WordPress screen

Blank screens tempt people into rapid file edits. I slow down first.

• Take a full backup of files and the database, or confirm a recent one restores
• Prefer a staging clone for the first round of tests
• Note the last change: plugin update, theme edit, PHP version, or migration

If you do not have a tested restore path yet, pause and fix that foundation — the same idea behind my notes on backups that actually restore.

Turn on logging without showing errors to visitors

A blank page often hides a fatal error that display_errors is swallowing. On staging (or briefly on live with display off), I enable logging in wp-config.php above the “stop editing” line:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Then I reload the broken URL and read wp-content/debug.log. The last fatal usually names a plugin file, a theme template, or a memory limit. WordPress documents these constants in their official guide to debugging in WordPress — I follow that pattern so visitors never see raw PHP on the public site.

How I read the error line

A fatal error line looks something like this:

PHP Fatal error: Uncaught Error: Call to undefined function example_function() in /wp-content/plugins/example-plugin/loader.php:42

The file path tells me where to go next:

• wp-content/plugins/plugin-name/ — that plugin is the suspect, so I disable only that one first
• wp-content/themes/theme-name/ — the theme, very often functions.php after an edit or update
• wp-content/mu-plugins/ — a must-use plugin, not listed on the normal Plugins screen
• wp-includes/ or wp-admin/ — core. Either a core update did not finish, or a plugin called core in a way it no longer supports, so I check the stack trace lines below for a plugin or theme path

“Allowed memory size of 134217728 bytes exhausted” means the page needed more than 128 MB of memory.

Blank front end but wp-admin works (or the other way round)

Before disabling anything, I open both the home page and /wp-admin/.

• Front end blank, wp-admin works: the theme first, or a plugin that only runs on the front end. I switch to a default theme from Appearance and recheck
• wp-admin blank, front end works: usually a plugin loading admin code, like a settings page or dashboard widget. I disable plugins through the file method below
• Both blank: a plugin that loads everywhere, the memory limit, an unfinished core update, or a mistake in wp-config.php

Isolate plugins and the theme safely

Most white screens I fix are a bad plugin combination, a broken update, or a theme function that fatals after a PHP change. I almost never “deactivate everything” on a busy live store if staging exists.

1. Clone to staging with the same PHP version when the host allows it
2. Reproduce the blank page and write down the exact URL and steps
3. Via SFTP or the file manager, rename wp-content/plugins to plugins-disabled and reload
4. If the site returns, rename the folder back and move suspect plugins out one group at a time (binary search)
5. If it stays blank with plugins off, rename the active theme folder so WordPress falls back to a default theme
6. Confirm the fix twice on staging before touching production

When the log points at two plugins fighting, I use the same isolation mindset as my guide to a WordPress plugin conflict. Official troubleshooting ideas are also summarized in the WordPress FAQ troubleshooting article.

White screen after a plugin or theme update

This is the case I see most. When I know which update ran, I start with that one, not the whole plugin folder.

1. Rename only that plugin’s folder inside wp-content/plugins/, or switch away from the updated theme
2. Reload. If the site comes back, the update is the cause
3. Check whether the new version needs a newer PHP or WordPress version than the host runs
4. For wordpress.org plugins, I take the previous version from the Advanced tab of the plugin’s page as a short-term fix
5. I send the error line from debug.log to the developer and update again once they ship a fix

A rollback is a stopgap, since old versions miss security fixes. The real cure is testing updates on a WordPress staging site before plugin updates.

Other causes I check after a white screen

If plugins and theme are clean, I keep going down a short list.

Memory limit

Fatals that say “Allowed memory size exhausted” need more PHP memory or a lighter stack — not another page builder add-on. I raise the limit carefully on staging first, then remove the heavy offender when one plugin is the clear cause. The line goes in wp-config.php above the “stop editing” comment:

define( 'WP_MEMORY_LIMIT', '256M' );

WordPress cannot go above the host’s PHP memory_limit, so that may need raising too. More in my post on the WordPress memory limit.

Corrupt or incomplete update

A half-updated core, plugin, or theme can white-screen both front and admin. Re-uploading a fresh copy of the broken component (from wordpress.org or a trusted vendor zip) often clears it after a backup.

Stuck after an automatic update

During an update, WordPress puts a .maintenance file in the site root and shows “Briefly unavailable for scheduled maintenance.” If the update times out, that file and a half-copied plugin or core can be left behind.

• I delete .maintenance from the site root
• If a plugin was mid-update, I replace its folder with a fresh copy
• If core was mid-update, I re-upload wp-admin, wp-includes, and the root files from the same WordPress version
• I never upload over wp-content or wp-config.php; that is where the site’s own files and settings live

Bad code in wp-config, .htaccess, or a must-use plugin

A syntax error in wp-config.php, a broken rewrite rule, or a fatal in wp-content/mu-plugins can blank the site even when the theme looks fine. I compare those files to a known-good backup and temporarily move mu-plugins aside on staging.

PHP version mismatch

Code that ran on PHP 7.4 can fatal on 8.1+. After a host PHP bump, I read the log, update or replace the outdated plugin/theme, and only then leave the new PHP version on.

How I recover the live site after staging proves the fix

1. Take a fresh backup of live
2. Apply only the proven change (remove or replace the bad plugin, restore the theme file, raise memory, or roll back the broken update)
3. Purge page cache, object cache, and CDN
4. Retest the homepage, a key inner page, wp-admin, forms, and (for stores) cart and checkout
5. Turn WP_DEBUG_DISPLAY off and remove temporary debug noise once the site is stable

I do not leave debug display on for the public. Logging can stay briefly while I watch for recurrence; then I tighten it again.

When the cache hides the fix

Sometimes the error is fixed but visitors still get a white page, because a caching plugin, the host’s server cache, or a CDN saved the blank response.

• I purge the caching plugin, the host cache, and the CDN after every fix
• I test in a private window, not only in my logged-in browser
• If only logged-out visitors see white, I suspect the cache first

How I prevent the next blank page

• Update plugins and themes on staging first, especially security tools, builders, and checkout extensions
• Keep a short inventory of what each plugin does so overlapping tools get removed
• Avoid editing plugin or theme core files on production
• Note the PHP version after every successful maintenance window
• Keep backups you have actually restored once
• Set a real inbox for the Recovery Mode email so the alert is not lost

When a client wants that done on a schedule, it fits under my WordPress maintenance and security work — careful updates, backups, and a quick smoke test after each batch. Performance-related fatals (timeouts, heavy queries) sometimes overlap with WordPress speed optimization, but a true white screen still starts with the error log.

Quick white screen checklist

• Confirm it is a full blank page or the critical error message, not a slow or partial load
• Check the admin inbox for the Recovery Mode email
• Backup (or use staging) before file changes
• Enable WP_DEBUG_LOG with display off; read debug.log
• Read the file path in the error: plugins, themes, mu-plugins, or core
• Rename plugins folder, then binary-search the culprit
• Fall back to a default theme if plugins are not the cause
• Check memory limit, incomplete updates, .maintenance, mu-plugins, and PHP version
• Apply the proven fix on live; purge caches; retest critical paths
• Turn public error display back off

Frequently asked questions

What causes the WordPress white screen of death?

Almost always a PHP fatal error: a plugin or theme update, two plugins clashing, a PHP version change, running out of memory, or an unfinished update. The error log tells you which.

Is “There has been a critical error on this website” the same thing?

Yes. Since WordPress 5.2, WordPress catches the same fatal error, shows that message instead of a blank page, and emails the admin a Recovery Mode link.

I did not get the Recovery Mode email. What now?

Check spam and confirm which address is set as the admin email. If it is still missing, rename the plugins folder via SFTP or the file manager and turn on the debug log.

Will I lose my content?

Usually not. Posts, pages, and settings live in the database, and a white screen does not delete them. Back up before changing files.

How do I fix it without FTP or wp-admin access?

Most hosts have a file manager in the control panel that can rename folders and edit wp-config.php. Host support can also check the PHP error log for you.

Why is only wp-admin white?

Usually a plugin that loads code only in the admin area, such as a settings page or dashboard widget. The debug log will name it.

Why is it white only on mobile, or only for logged-out visitors?

That points to a cached blank page. Purge every cache layer and test in a private window.

When should I call a developer?

When the log names something you do not recognise, when it is a store taking orders, or when you have no backup you trust. That is the work I do — see how I fix WordPress errors.

A blank WordPress screen feels dramatic, but the fix is usually a clear fatal in the log plus calm isolation. If your site went blank after an update and you want a second pair of hands from Surat, email me at rnitinb@gmail.com or use the contact page — I am happy to dig in on staging and get the pages rendering again.