The WordPress white screen of death: making the invisible error visible

TL;DR: A white screen is not an absence of an error. It is a PHP fatal error that occurred with error display switched off, which is the correct production setting and also the reason you can see nothing. The error message exists, with a filename and a line number; it is simply being written somewhere rather than shown.

Your entire job is to make it visible. Enable debug logging, or read the server error log, and the answer usually appears in under two minutes. Most guides instead suggest deactivating plugins one at a time, which is guessing, and on a site with thirty plugins it can take an hour to arrive at what the log would have told you immediately.

What a white screen actually is

When PHP encounters a fatal error, execution stops immediately. Nothing further is output.

Whether you see anything depends on a configuration setting. With display_errors on, PHP prints the error to the page, which is what you want in development. With it off, which is correct for production because error text leaks file paths and code structure, PHP outputs nothing at all.

The result is a page containing nothing. Not an error page, not a status code you would notice, just an empty response.

So the white screen carries exactly one piece of information: something fatal happened. The useful detail — error type, message, file, line number — was written to a log, or discarded if logging is also off.

Distinguishing it from its neighbours:

500 Internal Server Error is often the same underlying event, presented differently depending on server configuration. Some stacks return an explicit 500 status with an error page; others return an empty 200 or a blank response. The diagnostic approach is nearly identical, and the 500 error guide covers the same causes from the other direction.

502 Bad Gateway means an upstream component did not answer, which is a different failure.

503 Service Unavailable means the server is up and declining, typically a maintenance file or resource limits.

A genuinely blank page most often means PHP died quietly. That is the assumption to work from.

Front end white, admin working, and other patterns

Before doing anything, note which parts of the site are blank. This narrows the cause substantially and takes fifteen seconds.

Front end blank, admin works. The fault is in code that runs on the front end only: the active theme, or a plugin that hooks into front-end rendering. This is good news, because you have admin access and can switch theme or deactivate plugins normally.

Admin blank, front end works. The fault is in admin-only code: a plugin's settings page, an admin hook, or something in the dashboard. Frequently a plugin that only loads its admin components in the admin context.

Both blank. Something loading everywhere: functions.php, a must-use plugin, wp-config.php, or a plugin hooking early enough to affect both.

One specific page blank. A template file, a shortcode, a block, or a plugin active only on that page type. Everything else working narrows it a great deal.

Blank after a specific action. Saving a post, running an update, submitting a form. The fault is in the handler for that action, which is usually easy to identify.

Intermittent blank pages. Usually resource-related rather than a code fault, most often memory exhaustion under certain conditions rather than on every request.

Write down which pattern you have. It determines which of the sections below is worth reading.

Step one: make the error visible

Everything else is secondary to this.

Enable WordPress debug logging. Edit wp-config.php via SFTP or your host's file manager, and add above the line telling you to stop editing:

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

This writes errors to wp-content/debug.log without displaying anything to visitors, which matters because you do not want error detail public even briefly.

Reload the blank page, then open the log. The most recent entry names the error type, the message, the file and the line.

That file path is usually your answer. A path into wp-content/plugins/some-plugin/ identifies the culprit without any deactivation.

Or read the server error log. Often faster, and it requires no code changes. On shared hosting, look for an error log in your control panel, frequently named error_log in the account or site root. On a VPS, PHP-FPM and web server logs live under /var/log/.

What the entries mean:

"Allowed memory size exhausted" — you are out of PHP memory. See the memory section.

"Call to undefined function" or "undefined method" — code expecting something that is missing, usually a plugin requiring another component that is absent, deactivated, or a different version.

"Cannot redeclare" — two components defining the same function, a classic plugin conflict.

"Parse error" or "syntax error" — invalid PHP, naming the exact file and line. If you edited something recently, this is it.

"Maximum execution time exceeded" — a script ran too long.

Remove the debug constants when finished. Leaving them on grows a log file indefinitely and writes potentially sensitive information to a path that may be publicly readable.

Recovery mode, which most people miss

WordPress has a built-in mechanism for exactly this situation, and it is underused because it happens by email rather than in the browser.

When a plugin or theme causes a fatal error, WordPress detects it, sends an email to the site administrator address, and pauses the offending component. The email contains a special recovery link that logs you into the admin area with the problematic plugin or theme deactivated.

Why people miss it:

The administrator email address is wrong, abandoned, or a former employee's. This is the most common reason, and it is worth checking your admin email now rather than during an outage.

The email went to spam, which is likely if your site sends mail directly from the web server without proper authentication, as covered in the email deliverability guide.

The site cannot send mail at all, so nothing was delivered.

The fatal error occurs so early in loading that WordPress cannot reach the point of handling it.

If you receive it: use the recovery link, which gets you into the admin area. The paused component is identified, and you can deactivate it properly, update it, or replace it.

If you do not: proceed with the log-based approach above. Also take this as a signal to fix your administrator email address and your site's mail sending, because this feature is genuinely useful and only works if mail works.

The email is sent to the address in Settings, General, not necessarily to your own user account's address. Those are frequently different and nobody notices until it matters.

Cause: plugin or theme fatal error

The most common cause. Once the log names the file, resolution is quick.

If a plugin is named: rename that plugin's folder in wp-content/plugins/ via SFTP or file manager. WordPress deactivates any plugin whose directory it cannot find, so the site returns immediately.

If a theme file is named: rename the active theme's folder. WordPress falls back to a default theme if one is installed, which is a good reason to keep one present rather than deleting them all.

If a core file is named: the fault is usually still a plugin, since plugin code executes inside core functions. Read the full stack trace rather than only the first line.

Common triggers:

A plugin update introducing a bug or a new dependency. A plugin requiring a newer PHP version than the server runs. Two plugins declaring the same function or class. A plugin updated while a companion extension was not, which is common with WooCommerce extensions. A theme update overwriting customisations. A premium plugin whose licence lapsed and which now behaves unexpectedly.

Then resolve properly. Getting the site back by renaming a folder is triage, not a fix. Check for an update, look at the plugin's support forum for a known issue, or replace it if it is abandoned. A plugin that fataled and has been left disabled for weeks is also a plugin worth deleting.

Prevention: update from staging, not live. Almost every fatal caused by an update would have been caught there.

Cause: memory exhaustion

The signal: the log says allowed memory size exhausted, with a byte figure.

PHP caps how much memory a script may consume. Exceeding it terminates the script, which produces a blank page when display errors are off.

The immediate fix: add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php, or raise memory_limit in your PHP configuration if you have access.

Note that WP_MEMORY_LIMIT cannot exceed the server-level limit. If your host caps memory_limit at 128M, setting 256M in wp-config.php does nothing. Check both.

But read this as a symptom, not a cause. A normal WordPress page load does not need large amounts of memory. Exhausting 256M means something specific is wrong.

What actually consumes it: a plugin loading an entire large dataset into memory instead of processing in batches. An import or migration handling a big file in one pass. Image processing on very high-resolution uploads, which is genuinely memory-intensive. A plugin conflict producing an infinite loop. Or an accumulation of plugins each holding their own footprint.

Which operations fail tells you which case you have. If only imports and bulk actions fail, raising the limit is reasonable, since those are legitimately heavy. If ordinary page loads exhaust memory, raising the ceiling postpones the failure and you should find the responsible plugin.

On a VPS, check whether swap is configured. Without it, memory pressure kills processes rather than slowing them, as covered in the new VPS checklist.

Pattern	Likely cause	First check	First action
Front end blank, admin fine	Theme or front-end plugin	Debug log	Switch to default theme
Admin blank, front end fine	Admin-side plugin code	Debug log	Rename plugin folders
Both blank	functions.php, mu-plugin, wp-config	Error log, recent edits	Restore edited file
One page blank	Template, shortcode, page-specific plugin	Debug log	Identify the component
Blank after an update	Plugin or theme fatal	Recovery mode email, log	Rename that component
Blank after editing code	Syntax error	Log names file and line	Restore previous version
Intermittent blank	Memory exhaustion	Log for memory message	Raise limit, then find cause
Blank on save or submit	Handler for that action	Debug log	Identify the plugin

Cause: a syntax error you introduced

If the white screen appeared immediately after you edited a file, this is almost certainly it.

The log says parse error or syntax error, with a file and a line number. That line, or occasionally the one before it, contains the fault: a missing semicolon, an unclosed brace, a stray character, or a PHP opening tag in the wrong place.

The most common victim is functions.php, because it loads on every request including the admin area, so a syntax error there takes the entire site down including your route back in.

The fix: restore the previous version of the file via SFTP. If you have no copy, correct the error at the named line.

Two habits that prevent this entirely:

Use a code snippets plugin rather than editing functions.php directly. A snippets manager typically validates code before saving and can disable a broken snippet without taking the site down, which is exactly the safety net missing when you edit theme files.

Never edit PHP through the WordPress dashboard file editor. There is no undo and no safety check, and a mistake locks you out of the very interface you would use to fix it. Disable it with define('DISALLOW_FILE_EDIT', true); in wp-config.php.

wp-config.php deserves specific mention. A syntax error there produces a blank screen with no debug logging possible, since the file defining the debug constants is itself broken. Keep a known-good copy outside the site, which turns this from a reconstruction into a thirty-second restore.

Recovery without any access

When logs are unavailable and recovery mode did not reach you, fall back to elimination in this order.

Check wp-config.php for syntax errors first if you edited it recently, since a fault there blocks everything including debug logging.

Deactivate all plugins at once by renaming wp-content/plugins to plugins-off via SFTP. If the site returns, a plugin is responsible. Rename the folder back, then reactivate one at a time from the dashboard, checking after each. On a large site, binary search is much faster: enable half, test, halve again.

Switch theme by renaming the active theme's folder so WordPress falls back to a default.

Check for a mu-plugins directory. Must-use plugins load automatically and do not appear in the plugin list, so they survive the bulk deactivation above. If the directory exists and you did not create it, that is worth investigating on its own terms.

Raise the memory limit temporarily to test whether memory is the constraint.

Reinstall core. Download a fresh copy of your WordPress version and overwrite everything except wp-content and wp-config.php, which resolves corrupted core files from a failed update.

Check PHP version. If your host upgraded PHP recently, an incompatible plugin can fatal. Revert the version if possible, then update the component.

Restore from backup. Often faster than continued diagnosis, and this is where a tested backup proves its worth. Restore to get online, then diagnose on staging rather than under pressure.

Contact your host. They can see logs you cannot.

FAQs

What causes the WordPress white screen of death?

A PHP fatal error occurring with error display switched off, which is the correct production setting. The most common underlying causes are a plugin or theme fatal error, a syntax error in edited code, memory exhaustion, or incompatibility after a PHP version upgrade. The error message exists in a log; it is simply not being shown.

How do I see the actual error behind a white screen?

Add WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY set to false to wp-config.php, which writes errors to wp-content/debug.log without displaying them publicly. Alternatively read the server error log, usually accessible from your control panel on shared hosting or under /var/log/ on a VPS. Either gives you a file and line number.

Why is my admin area white but the front end works?

Because the fault is in admin-only code, typically a plugin's settings page or an admin hook that only loads in the dashboard context. Rename plugin folders via SFTP to isolate it, or check the debug log, which will name the file directly and save the elimination work.

What is WordPress recovery mode?

A built-in mechanism where WordPress detects a fatal error, pauses the offending plugin or theme, and emails the site administrator a special link that logs you in with that component deactivated. It only works if your administrator email address is current and your site can actually send mail, which is why many people never receive it.

Why did I not receive a recovery mode email?

Usually because the administrator email in Settings, General is wrong or abandoned, the mail went to spam because the site sends directly from the web server without authentication, or the site cannot send mail at all. Sometimes the fatal error occurs too early in loading for WordPress to handle it.

How do I deactivate plugins when I cannot access wp-admin?

Rename the wp-content/plugins folder to something else via SFTP or file manager, which deactivates all plugins at once. To isolate one, rename just that plugin's directory. WordPress deactivates any plugin whose folder it cannot find, so the site should return immediately if a plugin was responsible.

Why did my site go white after editing functions.php?

Almost certainly a syntax error, and functions.php is particularly damaging because it loads on every request including the admin area, so the fault takes down your route back in. Restore the previous version via SFTP. Using a code snippets plugin instead avoids this, since it can validate and disable snippets without breaking the site.

What is the difference between a white screen and a 500 error?

Frequently the same underlying event presented differently by the server. Some configurations return an explicit 500 status with an error page while others return an empty response with no visible status. The diagnostic approach is essentially identical: make the error visible via logs, then act on the file it names.

How do I fix memory exhausted errors in WordPress?

Add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php, noting that this cannot exceed the server-level memory_limit, so check both. Then investigate why, because normal page loads should not exhaust that much. Typical causes are a plugin loading a large dataset at once, image processing on very large uploads, or a plugin conflict causing a loop.

Can a PHP version upgrade cause a white screen?

Yes. If your host upgrades PHP and a plugin or theme uses code that is invalid in the newer version, it fatals. Revert to the previous PHP version if your host allows it to restore the site, then update or replace the incompatible component rather than remaining on an unsupported PHP version permanently.

What are mu-plugins and why do they matter here?

Must-use plugins in wp-content/mu-plugins load automatically and do not appear in the plugin list, so they survive renaming the regular plugins folder. If bulk deactivation does not resolve a white screen, check whether this directory exists. A file there you did not create is worth investigating for other reasons entirely.

Should I just restore from backup?

It is a reasonable and often faster choice when you cannot access logs and elimination is dragging on. The caveat is that restoring without understanding the cause means recurrence, particularly if the trigger was a plugin update that will be applied again. Restore to get online, then reproduce and diagnose on staging.

Conclusion

The white screen feels like the worst WordPress failure because it gives you nothing, and that is precisely the illusion. The error exists in full detail, with a filename and a line number, sitting in a log file. The entire task is making it visible.

Two minutes with WP_DEBUG_LOG or the server error log usually replaces an hour of deactivating plugins one at a time. Do that first, every time.

Before that, spend fifteen seconds noting the pattern. Front end blank with a working admin is a theme or front-end plugin and leaves you with easy access. Both blank points at functions.php, a must-use plugin, or wp-config.php. That distinction alone eliminates most of the search space.

Check your administrator email address while things are working, not during an outage. WordPress recovery mode is genuinely good and it fails silently for the most mundane reason: the email goes to an address nobody has read in two years.

And keep known-good copies of wp-config.php and your theme's functions.php somewhere outside the site. Those two files cause a disproportionate share of white screens, and having a copy turns a stressful reconstruction into a thirty-second restore.

HostCloud gives you error log access from the control panel, PHP version switching with rollback, one-click staging for testing updates, and automated daily backups you can restore yourself. Plans from ₹99 a month at https://hostcloud.in.