Last Update July 22, 2026

The WordPress white screen of death is a blank white page caused by a PHP fatal error, most often a plugin conflict, an exhausted memory limit, a broken theme, or a PHP version incompatibility.

To fix it: check your email for a recovery mode link, deactivate all plugins, switch to a default theme, and raise the PHP memory limit to 256MB. These steps resolve over 90% of cases.

I have fixed this error more times than I can count, and the first thing worth saying is the thing you most need to hear while staring at that blank page: your content is safe.

The white screen means the display layer crashed; your posts, pages, orders, and settings are sitting untouched in the database. This guide walks through the fixes in order, from the fastest check (your inbox) to the deeper ones, with the exact reason each step works.

What is the white screen of death, and why is there no error message?

The white screen of death (WSOD) appears when PHP, the language WordPress runs on, hits a fatal error and stops building the page mid-way. The browser receives nothing, so it shows nothing: no layout, no text, no error.

The blankness is intentional. WordPress hides raw error messages from visitors as a security measure, because a detailed PHP error can reveal file paths and configuration details an attacker could use. Helpful for security, maddening for you, since the screen gives no clue whether the cause is a minor plugin glitch or something deeper. The troubleshooting below is really one process: making WordPress tell you what it is hiding, then acting on it.

Common triggers, in rough order of frequency as of 2026: a plugin conflict (especially right after an update), PHP memory exhaustion, a theme error (often a syntax mistake in functions.php), a PHP version incompatibility, or corrupted core files from an interrupted update or migration.

Step 0: Check your email first (the step most guides skip)

Before touching any files, open the inbox of your site’s admin email. Since WordPress 5.2, a built-in fatal error protection system emails you when the site crashes, names the plugin or theme that caused it, and includes a special recovery mode link.

That link logs you into a limited dashboard where the faulty plugin is paused, and you can deactivate it with one click. If the email is there, your fix takes two minutes and you can skip most of this guide. If there is no email (the error happened outside the protection system, or mail delivery failed), continue below. Either way, take a backup before changing anything if you have any access at all; even a broken site should be backed up first.

Step 1: Read the clue in WHICH screens are white

Before fixing, diagnose. Which parts of your site are blank tells you where the problem lives, and this one observation can save you an hour of guessing.

  • Front end blank, but wp-admin loads: the problem is almost certainly your theme. Jump to Step 3.
  • Both front end and wp-admin blank: a plugin conflict or memory exhaustion is more likely. Start at Step 2.
  • wp-admin blank, but the front end works: an admin-side plugin (backup tools and security scanners are frequent culprits) or a memory limit that only trips under heavy admin scripts.
  • Only one page is blank: usually a shortcode, page builder element, or plugin running on that specific page.

If you run multiple sites on the same hosting account, also check whether they are down too. If they are, the issue is server-side, and your host is the fix, not your files.

Step 2: Deactivate all plugins

Plugin conflicts are the single most common cause of the white screen, especially right after updating a plugin. Deactivating everything at once tells you immediately whether a plugin is the culprit.

If you can reach wp-admin: go to Plugins, select all, and choose Deactivate from the bulk actions menu. If wp-admin is also blank, connect via FTP or your host’s file manager, open wp-content, and rename the “plugins” folder to “plugins_old”. This deactivates everything instantly. Reload your site.

If the site comes back, the cause is confirmed. Rename the folder back to “plugins” (they stay deactivated), then reactivate plugins one at a time, reloading after each, until the white screen returns. The last plugin you activated is your problem. Update it, replace it, or leave it off and contact its developer. In my experience, the culprit is usually the plugin updated most recently before the crash.

Step 3: Switch to a default theme

If plugins are ruled out, test your theme, because a syntax error in the theme’s functions.php file, sometimes just one missing semicolon or bracket from a recent edit, crashes PHP instantly. This is especially common after editing theme files directly.

If wp-admin works: go to Appearance, Themes, and activate a default theme like Twenty Twenty-Four or Twenty Twenty-Five. If not, via FTP rename your active theme’s folder inside wp-content/themes; WordPress will fall back to a default theme automatically (make sure one is installed). Reload the site.

If it loads now, your theme was the problem. Restore a fresh copy of the theme from its official source, redo any customizations carefully (ideally in a child theme, so future updates do not overwrite them), or contact the theme’s developer with the error details.

Step 4: Increase the PHP memory limit

If neither plugins nor the theme fixed it, your site may simply be running out of memory. WordPress installations often start with as little as 64MB of PHP memory, while sites running WooCommerce, page builders like Elementor or Divi, or many active plugins can easily need more. When a script exceeds the limit, the server kills it mid-run, and you get a white screen with no error.

Connect via FTP, open wp-config.php, and add this line above the line that says “That’s all, stop editing”:

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

Save, upload, and reload the site. This single line fixes memory-related white screens more often than people expect. If the limit will not rise, your host caps it at the server level, in which case a quick support message to your host solves it. If you were already at 256M or higher, memory was probably not your cause; keep going.

Step 5: Turn on debug mode and read the actual error

If the site is still blank, stop guessing and make WordPress show you the real error. Debug mode replaces the silent white screen with the actual PHP message, which names the file and line that failed.

In wp-config.php, add (or edit) these lines above “That’s all, stop editing”:

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

With logging on, the error is written to a file at wp-content/debug.log instead of being shown to visitors. Open that file and read the last entry. It will look technical, but you only need the first line: it names the failing file (which tells you the plugin or theme responsible) and the error type. Copy that first line into Google and you will almost always find the exact fix. Turn debug mode off after troubleshooting; it is a diagnostic tool, not a permanent setting.

Step 6: Replace the WordPress core files

If the log points at WordPress core files, or an update was interrupted partway, the engine itself may be corrupted. The fix sounds drastic but is safe: replace every core file with a fresh copy, without touching your content, settings, themes, or plugins.

Download the latest WordPress from wordpress.org, unzip it, and delete the wp-content folder from the download (this is the critical step, since wp-content holds your themes, plugins, and uploads). Then upload everything else to your site’s root via FTP, overwriting the existing files. Your wp-config.php and wp-content stay yours; only the engine gets replaced. Reload the site.

Step 7: Check with your host (when it is not your site at all)

If every step above leaves the screen white, the problem may be on the server, not in WordPress. A failed server update, a PHP version change your host rolled out, or a resource limit they imposed can white-screen a perfectly healthy site.

One cause worth naming specifically for 2026: PHP version incompatibility is among the fastest-growing triggers of the white screen right now, as hosts move servers to PHP 8.3 and 8.4 while older themes and plugins, built for PHP 7.x, produce fatal errors on the newer versions.

Ask your host whether your PHP version changed recently; many hosting panels also let you switch PHP versions yourself. Dropping back one version (say, from 8.4 to 8.2) and seeing the site return confirms the diagnosis, and then the real fix is updating or replacing the outdated theme or plugin, since old PHP versions lose security support.

How to prevent the white screen of death

Nearly every white screen traces back to a preventable pattern, and a few habits remove most of the risk.

Update one thing at a time, not in bulk, so when something breaks you know exactly what caused it. Test major updates on a staging copy if your host provides one. Keep plugins and themes updated (outdated code is what breaks on new PHP versions), and delete the ones you do not use.

Avoid editing theme files directly on a live site; one typo in functions.php is enough for a full white screen, so use a child theme and test changes. Keep automated backups running so the worst case is a restore, not a rebuild. And know your PHP version, because when your host upgrades it, old plugins are the first thing to break.

Conclusion

The white screen of death looks catastrophic and is usually simple: a plugin conflict, a theme error, exhausted memory, or a PHP incompatibility, with your content sitting safe in the database the whole time. Fix it in order: check your email for the recovery mode link, read which screens are white for your first clue, deactivate plugins, switch to a default theme, raise the memory limit to 256M, then turn on debug logging and read the real error.

Replace core files if the engine is corrupted, and ask your host about PHP changes if nothing else works. Over 90% of cases resolve within the first few steps, and the prevention habits (one update at a time, staging, backups, current plugins) keep it from coming back.

Frequently Asked Questions

What causes the WordPress white screen of death?

A PHP fatal error that stops the page from rendering. The most common triggers are plugin conflicts (especially after updates), exhausted PHP memory, theme errors such as a syntax mistake in functions.php, PHP version incompatibilities, and corrupted core files from an interrupted update or migration.

Is my content lost when I see the white screen of death?

No. The white screen is a display failure, not data loss. Your posts, pages, media, orders, and settings remain safely stored in the database. Once the underlying error is fixed, everything reappears exactly as it was. Still, back up before troubleshooting so a wrong edit cannot make things worse.

How do I fix the white screen if I cannot log in to wp-admin?

Use FTP or your host’s file manager. Rename the wp-content/plugins folder to deactivate all plugins, rename your active theme’s folder to force a default theme, and edit wp-config.php to raise the memory limit or enable debug logging. All the main fixes work without dashboard access.

Why does the white screen show no error message?

WordPress hides raw PHP errors from visitors on purpose, because detailed error output can expose file paths and configuration details that help attackers. Enabling WP_DEBUG with WP_DEBUG_LOG writes the hidden error to a log file at wp-content/debug.log, where you can read the real cause safely.

Why did my site white-screen right after a plugin update?

The updated plugin most likely conflicts with another plugin, your theme, or your PHP version. Deactivate it via FTP by renaming its folder inside wp-content/plugins, and the site should return. Then check whether an updated version or a replacement plugin is available before reactivating.

Can a PHP update cause the white screen of death?

Yes, and it is one of the fastest-growing causes as of 2026. Hosts are moving servers to PHP 8.3 and 8.4, and older themes and plugins written for PHP 7.x can throw fatal errors on them. Temporarily switching to an older PHP version confirms the diagnosis; the lasting fix is updating the outdated code.