You update a plugin, or paste in a code snippet a tutorial told you to add, and the next time you load the site there is nothing. No error, no half-rendered header, no familiar WordPress error page. Just a flat white browser tab, and if you check the title bar it still shows whatever the last page loaded said.
You reload. Same result. You check wp-admin. Also blank. You view source and the document is either empty or cuts off mid-tag, because the page genuinely stopped generating partway through.
This is the WordPress White Screen of Death, and despite the name it’s one of the more mechanical, more diagnosable failures a site can have. It isn’t a hack, and it isn’t a mysterious WordPress bug. It’s PHP hitting a fatal error and, following its own configuration, telling nobody about it.
What a white screen actually is
A fatal PHP error (an uncaught exception, a call to an undefined function, a class that can’t be found, memory exhaustion) stops the PHP process dead at the line where it happens. Nothing after that line runs, including the rest of the HTML your theme was in the middle of outputting. On most production servers, the display_errors PHP directive is switched off, which means instead of printing “Fatal error: …” into the page, PHP just stops. Whatever HTML made it out before the crash is what the browser receives: often nothing, if the failure happened early in the request.
This isn’t something WordPress invented. Any PHP application behaves this way when display_errors is off, which is the correct, security-conscious default for a live site: you don’t want file paths and stack traces printed to random visitors. WordPress adds its own layer on top with the WP_DEBUG family of constants, but they default to off too, so a plain install gives you the same silence at the WordPress level that the server gives you at the PHP level.
The screen isn’t always literally blank, either. Depending on exactly where the crash happens, you might get a bare white page, a page with your header and nothing else, or a generic 500 Internal Server Error from the web server itself rather than from WordPress. All three point at the same underlying event: a fatal error with nowhere configured to display it.
The fastest way to see the real error
Before guessing at causes, get PHP to write down what actually happened. Open wp-config.php and add the following above the line that reads /* That's all, stop editing! Happy publishing. */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUG_LOG tells WordPress to write every notice, warning, and fatal error to a file. WP_DEBUG_DISPLAY set to false, combined with forcing display_errors off, is what keeps the raw error text from leaking onto the page for any visitor who happens to load it while you’re debugging. You want the error captured, not broadcast. Reload the page that was white, then open wp-content/debug.log through FTP, SFTP, or your host’s file manager. The most recent entry at the bottom of the file will typically read something like PHP Fatal error: Uncaught Error: Call to undefined function... along with the exact file and line number that failed.
If editing wp-config.php isn’t convenient (you’re on a phone, or you’d rather not touch the site further while it’s broken), check the host’s own PHP error log instead. Most control panels (cPanel’s “Errors” tool, Plesk’s log manager, or an equivalent in a managed-WordPress dashboard) keep a running PHP error log independently of WordPress, and it will show the same fatal error without you changing anything on the site itself.
The log is the fastest route to the answer and the least pleasant to read, because the one fatal error you need sits between four hundred deprecation notices from a theme nobody has updated since 2019.
Paste it below. The analyser groups repeated messages, reads the guilty plugin or theme out of the file path, converts the memory figures into megabytes, and hides the noise. There is a switch that masks your server paths as well, for when you want to paste an excerpt into a support forum without publishing your directory structure.
debug.log analyser
Paste the contents of wp-content/debug.log, or drop the file on the box, and read it as a short list instead of a wall of text: repeated lines are grouped, the plugin or theme behind each one is named, and memory figures are converted to megabytes. The file is read in this browser tab and never leaves it.
or press Enter to pick a .log or .txt file. It is read in this tab, nothing is uploaded.
Up to 5 MB is read, longer files are cut and that is said below.
| Severity | Message | Source | Count | Last seen |
|---|
Lines that belong to the entry above them, stack traces, "#0" frames and "thrown in" lines, are folded into that entry. For grouping, numbers, paths and hex values are replaced with placeholders, so the same error from two requests counts once. Masking changes the copied summary only: the table always shows the paths as they stand in the file.
The usual suspects
Once you can see the actual error, or even before you can, four causes account for most white screens, roughly in order of how often they show up.
- A plugin or theme update that doesn’t get along with something else. Plugins, themes, WordPress core, and the server’s PHP version all move on independent release schedules. An update can call a function that a slightly older PHP version doesn’t have, or step on a hook another plugin relies on in a way neither developer tested for. The WordPress Plugins screen checks that a plugin declares compatibility with your WordPress and PHP versions. It does not catch a runtime conflict between two specific plugins.
- A manual edit to
functions.phpwith a syntax error. A missing semicolon, an unclosed brace, a stray closing PHP tag copied from a tutorial: any of these will fatal. Becausefunctions.phploads on every single request, front end and admin alike, a mistake there doesn’t break one page, it breaks the whole site. Our guide to editing functions.php safely covers where these edits should actually go so a typo can’t take the site down this completely. - PHP memory exhaustion. The literal error is usually “Allowed memory size of X bytes exhausted (tried to allocate Y bytes).” This shows up constantly around bulk image operations: regenerating thumbnails after changing which image sizes WordPress registers is a classic trigger, since it loads and resizes every image in the library in one pass. Our piece on WordPress image sizes walks through exactly this kind of regeneration and why it’s memory-hungry.
- A PHP version bump on the host’s end. Hosts periodically retire old PHP versions server-wide, sometimes automatically. A plugin that hasn’t been updated in years can be relying on something that no longer exists:
create_function()andeach(), for instance, were both removed in PHP 8 after years of deprecation warnings. The plugin worked fine yesterday and fatals today with no changes on your end at all.
A systematic order for finding the cause
Reading the error in debug.log often tells you exactly which file is at fault. When it doesn’t, or when the log itself is empty because the crash happened before logging could kick in, work through these three checks in order. Each one rules a cause in or out without needing wp-admin to be reachable.
1. Isolate a plugin conflict
If wp-admin still loads, go to Plugins, deactivate everything, and reactivate one at a time, reloading the front end after each one, until the white screen comes back.
If admin is also white, connect over FTP or SFTP and rename the wp-content/plugins folder to something like plugins-disabled. WordPress checks that each active plugin’s file exists on every load; when the whole folder is missing, it drops every plugin from the active list on its own and adds an admin notice about it, without you touching the database. Rename the folder back, then move plugins out of it one at a time (or back into it one at a time) to isolate which one is fatal.
If you have SSH access, WP-CLI does the same job faster and doesn’t require renaming anything:
wp plugin deactivate --all
wp plugin list
wp plugin activate plugin-slug-hereWP-CLI runs against the WordPress installation directly through PHP, bypassing the browser entirely, which is exactly why it still works when every page in a browser is white.
2. Switch the active theme when admin is unreachable
A broken theme behaves the same way as a broken plugin: a fatal error in functions.php or a template file takes the whole site down. With WP-CLI:
wp theme list
wp theme activate twentytwentyfourWithout shell access, the same change can be made directly in the database through phpMyAdmin or whatever database tool your host provides:
UPDATE wp_options
SET option_value = 'twentytwentyfour'
WHERE option_name IN ('template', 'stylesheet');Replace wp_ with your site’s actual table prefix if it’s been changed from the default, and confirm the theme’s folder name (its “slug”) matches exactly. That’s what template and stylesheet store, not the theme’s display name.
3. Raise the memory limit to confirm or rule out exhaustion
If debug.log shows an “Allowed memory size exhausted” error, or you suspect one because the crash coincides with a bulk operation like regenerating thumbnails, raise the limit temporarily in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );WP_MEMORY_LIMIT sets the ceiling for a normal WordPress request, up from a default of 40M. WP_MAX_MEMORY_LIMIT sets the higher ceiling WordPress requests for memory-intensive admin contexts specifically (including image processing during thumbnail regeneration), and it already defaults to 256M on its own, so push it past that default, to 512M or higher, to get a real test rather than a no-op. If raising both makes the white screen go away, memory exhaustion was the cause, and you now know to either keep the higher limit, regenerate thumbnails in smaller batches, or ask the host whether the server’s own PHP memory_limit is capping you lower than these defines can reach. WordPress can only request up to whatever the server actually allows.
When the white screen looks different
The site broke right after an automatic update, and nobody touched it. Check the site’s update log or your host’s activity log for what updated in the hours before the crash. This is almost always cause #1 or #4 above: a plugin update landing on an incompatible PHP version, or a background core auto-update pairing badly with an old plugin.
The front end loads fine, but wp-admin is white. The fatal error is happening in code that only runs on admin_init or a similar admin-only hook. Narrow the plugin search to ones with dashboard widgets, settings pages, or admin notices, since those are the ones executing code your front-end visitors never trigger.
It only happens when uploading or editing an image. This is memory exhaustion specifically inside GD or Imagick while generating thumbnail sizes for that one file. A single very large original, or a site with many registered image sizes, multiplies the memory needed per upload. Raise the memory limit as above and confirm before assuming it’s something else.
You fixed it, and it came back a few hours later on its own. Look for a scheduled task (a cron-triggered backup, an image regeneration plugin, or a caching plugin rebuilding its cache) that re-runs the same memory-heavy operation on a schedule. Fixing the immediate crash doesn’t fix a recurring job still configured to trigger it again.
Safer editing habits
Most white screens caused by hand-edited code trace back to editing a live functions.php directly, with no safety net between a typo and the entire site going down. A child theme’s functions.php, or a small site-specific plugin holding your custom code, isolates that risk: if it fails, WordPress can deactivate just that one plugin instead of taking the theme’s core file down with it.
Keep a backup before any update or edit, not just as a recovery option but because knowing you can revert in one click makes it easier to leave debug mode on and actually read the error rather than undoing changes blind. If backups have been slow or huge, a bloated media library is often why: trimming unused and duplicate uploads shrinks both the backup and the site’s overall memory footprint during operations like thumbnail regeneration. And where a staging copy of the site is available, test plugin and theme updates there first. It turns a white screen into a five-minute non-event instead of a live outage.
Where this leaves you
A white screen feels like an emergency because it hands you nothing to work with. In practice it’s one of the more mechanical failures in WordPress to trace, once you accept that the blank page is a symptom, not the problem: the problem is a single fatal error sitting in a log file, waiting to be read.
The debug constants and the diagnostic order above will find that error in the large majority of cases: turn on logging, read the log, and if the log doesn’t point cleanly at one file, isolate plugins, then theme, then memory, in that order. Each step either confirms the cause or rules it out completely, so you’re never left guessing at what to try next.
Once the site is back, the fix that actually matters is the one that stops the next white screen: a child theme instead of live edits, a staging site for updates, and debug logging left in a state where you can flip it on in seconds instead of discovering, mid-outage, that you’ve never had to before.
