The WordPress White Screen of Death (WSOD) is a blank white page that appears when PHP hits a fatal error and stops rendering before any HTML reaches the browser. The four causes that account for nearly every case are: a plugin conflict (most often right after an update), PHP memory exhaustion, a fatal error in the active theme, and a PHP 8.x incompatibility in older code. The fastest reliable path: enable debug logging in wp-config.php so you can read the actual error, then deactivate plugins, swap to a default theme, and raise the memory limit based on what the log tells you. Below is the full process in the order that diagnoses the problem with the fewest wasted steps.

What the White Screen of Death actually is

You load your site and get a completely blank page. No layout, no text, no error. It can hit the whole site, only /wp-admin, or only a single post. The reason it gives you nothing to work with is deliberate: live WordPress sites are configured to suppress PHP error output (WP_DEBUG_DISPLAY off) so a crash doesn't leak file paths, database details, or stack traces to visitors. When a fatal error fires, PHP halts and you're left with whatever was sent before the crash, usually nothing.

That suppression is correct behaviour for security, but it means your first real job is not to "fix" anything yet. It is to turn the blank screen back into a readable error. Everything else is faster once you know the exact file and line that crashed.

The actual underlying causes

WSOD is a symptom. The real fault is almost always one of these:

1. Plugin conflicts (the most frequent)

A plugin you installed, updated, or reactivated introduced a PHP fatal error, or stopped being compatible with your WordPress version, PHP version, or another plugin. This spikes after auto-updates: a plugin updates overnight, calls a function that no longer exists, and the site is down by morning.

2. PHP memory exhaustion

The script tried to use more memory than PHP allows and was killed. The relevant ceiling is your host's memory_limit in php.ini; WP_MEMORY_LIMIT in wp-config.php can raise WordPress's request only up to that host ceiling. Sites running WooCommerce plus a page builder (Elementor, Divi) plus a stack of plugins are the usual victims, especially during imports, backups, or cron-heavy operations.

3. Theme errors

A syntax error or a call to an undefined function in the active theme's functions.php crashes PHP immediately. The classic triggers are a missing semicolon, an unmatched brace, or stray whitespace after a closing ?> tag, usually from editing the file directly in Appearance → Theme File Editor instead of a child theme.

4. PHP version incompatibility

Hosts have been moving accounts onto PHP 8.2, 8.3 and 8.4. Code written for PHP 7.x can throw fatal errors on these versions: passing null where a string is expected, using removed functions like create_function(), or relying on now-stricter type handling. If your site broke the same day your host changed the PHP version, this is your prime suspect.

5. Corrupted core files

An update that was interrupted, a failed restore, or a half-finished migration can leave wp-admin or wp-includes files incomplete. Less common, and worth checking only after plugins, theme, and memory are ruled out.

6. Permission problems

Permissions can change during a migration or a host switch so PHP can no longer read the files it needs. The standard targets: directories 755, files 644.

Back up first: even a broken site

Before touching anything, take a backup. A broken site is still your rollback point if a fix makes things worse. On most Indian shared hosts (Hostinger, Bluehost India, GoDaddy) you can trigger a full backup from cPanel. If UpdraftPlus or a similar plugin is installed and /wp-admin still loads, run a manual backup from there. If the admin is also white, skip ahead. You'll work over FTP or the file manager instead, and renaming folders (the method used below) is itself non-destructive and reversible.

Step 1: Check for the Recovery Mode email

Since WordPress 5.2, the site enters Recovery Mode automatically when a plugin or theme causes a fatal error, and emails the administrator address from Settings → General. The email names the offending component and includes a one-time login link that bypasses the crash. Check the inbox, and the spam folder, for a message from your own domain. Open the link, deactivate the flagged plugin or theme, and you're done.

If the admin email is wrong, the mail server isn't configured, or the error was severe enough that the mail never sent, you won't get it. Move to Step 2.

Step 2: Turn the white screen into a readable error

This is the step most people skip, and skipping it is why they spend an hour guessing. Enabling debug logging tells you the exact file and line, which usually points straight at the fix.

Enable debug logging

Open wp-config.php in your site root over FTP (FileZilla is free) or the hosting file manager. Just above the line /* That's all, stop editing! Happy publishing. */, add:

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

What each line does:

  • WP_DEBUG: switches on error reporting.
  • WP_DEBUG_LOG: writes errors to wp-content/debug.log instead of the page.
  • WP_DEBUG_DISPLAY set to false: keeps errors out of the public page. Leave this off on a live site.
  • display_errors set to 0: a second guard at the PHP level against leaking errors to visitors.

Read the log

Reload the broken URL once, then open wp-content/debug.log. A memory crash reads like this:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 126976 bytes) in /home/site/public_html/wp-includes/wp-db.php on line 2162

That 134217728 is 128MB: go to Step 4. A plugin crash names the file directly:

PHP Fatal error: Uncaught Error: Call to undefined function some_function() in
/wp-content/plugins/some-plugin/main.php on line 47

The path tells you which plugin: go to Step 3. A theme crash shows a path under /wp-content/themes/; jump to Step 5. Reading the path before acting saves you from blindly disabling things that were never the problem.

Remove these debug lines once the site is fixed. Debug logging left on a production site grows the log file indefinitely and risks exposing it if the directory is browsable.

Step 3: Deactivate all plugins

Plugins are the most common cause, and disabling all of them at once is the fastest way to confirm or rule that out. If the site returns, a plugin is responsible; you then re-enable them one at a time to find which.

If /wp-admin still loads

Go to Plugins → Installed Plugins, tick the select-all box, choose Deactivate from Bulk Actions, and apply. Reload the front end. If it works, reactivate plugins one by one, checking the site after each, until one brings the white screen back.

If /wp-admin is also white

Over FTP or the file manager:

  1. Connect to the server and open /wp-content/.
  2. Rename the plugins folder to plugins-disabled.
  3. Reload your site.

Renaming the folder deactivates every plugin at once. If the site loads, rename the folder back to plugins. WordPress keeps them all deactivated, so the site stays up, then log in and reactivate them one at a time, testing between each, until the culprit reappears.

Once you've found the bad plugin

  • Check for an available update; the crash is often a known bug the developer has already patched.
  • Send the plugin's support the exact line from your debug.log; it's far more useful than "your plugin broke my site".
  • If it's abandoned (no update in a long time, or marked untested with your WordPress version on its repository page), replace it with a maintained alternative.

Step 4: Raise the PHP memory limit

If the log said "Allowed memory size … exhausted", add this to wp-config.php above the "stop editing" line:

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

For a busy WooCommerce or page-builder site, 512M is a reasonable ceiling:

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

If it has no effect

Remember the host's php.ini ceiling overrides this. If raising WP_MEMORY_LIMIT changes nothing, the server limit is lower than your request. On cPanel hosts, open Select PHP Version → Options (or MultiPHP INI Editor) and raise memory_limit there. On managed hosts (Cloudways, Kinsta, WP Engine) set it in the dashboard. On Indian shared plans where the limit is locked, raise a support ticket asking specifically: "Please increase memory_limit for my account to 256M." A precise ask gets actioned faster than "my site is slow".

Step 5: Switch to a default theme

If plugins are clean and the log points at a theme file, test with a stock theme like Twenty Twenty-Five. If the site loads on it, your theme holds the fault.

If /wp-admin loads

Go to Appearance → Themes and activate a default theme, then check the front end.

If /wp-admin is white

  1. Open /wp-content/themes/ over FTP.
  2. Confirm a default theme folder exists (twentytwentyfive, twentytwentyfour, or twentytwentythree).
  3. If none is present, download one from the WordPress theme directory and upload its folder.
  4. Rename your active theme's folder, for example astra to astra-old.
  5. With its folder missing, WordPress falls back to the newest installed default theme automatically.

If the default theme works, inspect functions.php

Theme-side crashes almost always live in functions.php. Check for:

  • Whitespace or blank lines after a closing ?> tag.
  • A missing semicolon or unmatched brace from a recent edit.
  • Custom code calling a function removed in your PHP version.

If you pasted a snippet in recently, remove it and retest. If the theme still breaks untouched, download a fresh copy from its source and replace the folder. The longer-term fix is to keep custom code in a child theme or a small site-specific plugin so a theme update never wipes it and a bad snippet is easy to disable.

Step 6: Check PHP version compatibility

If the site broke right after a PHP version change, this is the likely cause.

  1. Open cPanel and find Select PHP Version or MultiPHP Manager.
  2. Note the current version.
  3. If you're on 8.3 or 8.4 and the site just broke, drop temporarily to 8.2 and reload.

If downgrading revives the site, you've confirmed an outdated plugin or theme, not a reason to live on old PHP. Newer PHP releases are faster and receive security fixes that older ones don't, and each version line eventually stops getting them. So treat the downgrade as a diagnosis: update or replace the incompatible component, then move back up. Check each plugin's "Tested up to" and required-PHP notes on its repository page before you do.

Step 7: Raise PCRE limits for very long content

If the white screen only hits specific long posts (pages with thousands of words or deeply nested shortcodes) and the log mentions PCRE rather than memory, the regex engine is backtracking past its limit. Add to wp-config.php:

ini_set( 'pcre.recursion_limit', 20000000 );
ini_set( 'pcre.backtrack_limit', 10000000 );

These raise the limits WordPress and many plugins rely on when parsing large blocks of text. This is a narrow fix: only reach for it when the symptom is content-length specific.

Step 8: Clear every cache layer

Sometimes the fault is already gone and you're staring at a cached copy of the broken page. Clear from the outside in:

  1. Browser: hard refresh with Ctrl+Shift+R (Cmd+Shift+R on Mac), or test in a private window.
  2. Caching plugin: purge all cache in WP Rocket, W3 Total Cache, or LiteSpeed Cache.
  3. Host cache: Cloudways, Kinsta, and SiteGround run their own server cache that clears separately.
  4. CDN: if you're on Cloudflare, purge cache from its dashboard.

Step 9: Check file permissions

After a migration or host change, wrong permissions can stop PHP reading what it needs. The standard set:

  • Directories: 755
  • Files: 644
  • wp-config.php: 600 (or 640) to keep credentials off other accounts on the server

In an FTP client or file manager, select the files, right-click, and choose "File Permissions" / "CHMOD" to set these.

Step 10: Re-upload core files

If everything else is clean, core files may be corrupt. The safe way to replace them:

  1. Download the current release from wordpress.org/download.
  2. Unzip it locally.
  3. Delete the wp-content folder from the extracted files so you don't overwrite your themes, plugins, and uploads.
  4. Upload the rest over FTP, overwriting when prompted.

This refreshes wp-admin, wp-includes, and the root PHP files while leaving your content untouched.

When none of it works: it's the server

If you've worked through every step and the screen is still white, the fault is below WordPress. Open a host ticket with specific questions rather than "my site is down":

  • "Are there fatal errors in the Apache/Nginx or PHP error log for my domain right now?"
  • "Is my account hitting memory, process, or I/O limits?"
  • "Is ModSecurity or another WAF blocking requests to my site?"
  • "Was the PHP version changed recently on this server?"
  • "Is the database accepting connections for my site?"

Paste your debug.log lines into the ticket. Targeted questions get a real engineer to look; vague ones get a canned reply.

Stopping it from happening again

Update deliberately, not automatically

Turn off fully automatic plugin updates on production. Update on a staging copy first, or update one plugin at a time on live and check the site after each, so when something breaks, you already know which change did it. Auto-updates that fire overnight are a recurring source of these crashes.

Keep the plugin list short

Every plugin is more code that can fatal on the next WordPress or PHP bump, and inactive ones still sit on disk as future risk. Audit periodically and delete what you no longer use. Plugin bloat also drags on performance; if rankings are part of your concern, our guide on white-hat SEO techniques covers how it ties into Core Web Vitals.

Automate backups

Run daily backups through UpdraftPlus or your host's system, and trigger a manual one before any major update. Rolling back to yesterday's working copy is far faster than debugging a live crash.

Use staging for changes

Never test plugin updates, theme edits, or big changes on the live site. Most managed hosts include one-click staging. If yours doesn't, LocalWP clones the site to your machine for free so you can break things safely.

Monitor uptime

A free monitor like UptimeRobot pings your site on an interval and alerts you the moment it goes down, so you find the white screen before a customer does.