Where the blank page comes from
The WordPress white screen of death is a PHP fatal error with the message hidden. The page is blank because PHP stopped before WordPress printed anything at all, so the repair is never guessing which plugin it was: it is making the error visible, reading the one line that names the file, and then acting on that line.
Written for whoever is looking at a white browser window right now, with or without access to the dashboard. The first half is what the blank page can be and how to tell the versions apart. The second half is the sequence that gets the site back without breaking something else on the way.
A white screen is PHP stopping halfway
PHP builds your page top to bottom and streams it out. When it hits a fatal error, it stops. If that happens early, before any HTML has been sent, the browser receives an empty body and renders nothing. If it happens later, you get half a page: a header, a menu, and then nothing.
Where the page cuts off is therefore a clue worth reading before anything else. Completely empty points at something loading very early, which in practice means the main configuration file, a must-use plugin, or a plugin loaded near the front of the queue. Half a page points at whatever was rendering when it died, which is usually a theme template or a shortcode.
Recovery mode may have already emailed you the way in
Modern WordPress does not always leave you locked out. When a fatal error happens, recovery mode sends an email to the admin and super admin address containing a secret link, and following that link puts you into a dashboard where the plugins and themes causing the fatal error are paused for you.
Check that mailbox before you reach for SFTP. Two details decide whether the email is any use. It goes to the address in Settings then General, which on a site somebody else built is often a mailbox nobody reads, and that can be overridden with the RECOVERY_MODE_EMAIL constant. The link also expires, with the recovery_mode_email_link_ttl filter controlling how long it lasts, so an email from last Tuesday will not help you today. Recovery mode is also tied to a cookie on your machine rather than to your user account, which is why it does not survive a switch to a different browser.
The debug log is the only thing that names the cause
Everything else in this article is inference. The log is evidence. WordPress ships the switches for it and they are off by default: WP_DEBUG defaults to false, and turning it on with define( 'WP_DEBUG', true ); triggers debug mode throughout WordPress.
On a live site you want the log without the output, which is three lines in the wp-config file above the stop editing comment, per the debugging documentation:
define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );
The errors then go to debug.log in the content directory, usually wp-content/debug.log, and not onto the page where a customer or a search engine could read them. WP_DEBUG_DISPLAY defaults to true, so leaving it out is what causes those sites you have seen with warnings printed above the logo. If wp-content is not writable, WP_DEBUG_LOG also accepts a path to a file of your choosing instead of true. Reload the broken page once after saving, then open the log.
Memory exhaustion is the classic silent version
The white screen with nothing in the log, or with a single allowed memory size line, is almost always this. WordPress raises PHP's memory itself: by default it attempts to increase the allocation to 40MB for a single site and 64MB for multisite, with the code at the beginning of wp-includes/default-constants.php.
Those defaults are floors rather than ceilings, and a site with a page builder, a store and thirty plugins will pass them. You raise it in the wp-config file with define( 'WP_MEMORY_LIMIT', '96M' );, and for the dashboard specifically with WP_MAX_MEMORY_LIMIT, which defaults to 256MB and is the one that matters during imports and updates. The configuration reference notes that both have to be set before wp-settings.php is included, which is what the stop editing comment is marking. A host that caps PHP memory below what you ask for will ignore the constant entirely, and then the number in your config is decoration.
White in the dashboard and white on the front point at different things
Work out which surfaces are broken first, because the answer narrows the list a long way. A blank front end with a working dashboard is usually the theme or a front-end-only plugin. A blank dashboard with a working front end is usually an admin-side plugin, and the front end is being served from a cache rather than being healthy.
Both blank means something loading on every request: the configuration file itself, a must-use plugin in wp-content/mu-plugins, a dropin such as object-cache.php, or a PHP version change under the whole site. One page blank while the rest of the site works is the memory and timeout case, because that page is doing more work than the others.
A blank 500 and a blank 200 are different problems
Open the browser network tab, or send a headers-only request from the command line, and look at the status code the blank page came with. This distinction gets skipped constantly and it is worth ten minutes of guessing.
An empty body with a 500 is PHP dying, which is what this article is about. An empty body with a 200 is something that ran to completion and chose to send nothing: a caching layer that stored an empty response, a redirect loop that resolved to nothing, a maintenance or coming soon plugin, or a theme template with no output. A 200 means the error is not in the log because there was no error, and you should be looking at caching and plugins that intercept output instead.
Your own browser can keep showing you a page that is already fixed
Once a blank response has been cached, it gets served to you after the fault is gone, and people undo a correct fix because of it. Full page caching plugins, the host's own cache and a CDN edge can all hold it.
Test with a cache buster, meaning any unused query string on the end of the URL, or in a private window, and check from a device on a different network if you can. If the URL with a query string works and the plain one does not, the site is fixed and you are looking at a stored copy. Purging the cache is then the last step rather than the first.
Getting the site back in the right order
The instinct is to start deactivating plugins. That works eventually and it costs you an hour, plus whatever else breaks while half the site is switched off. This order is faster and leaves less mess.
Read the last lines of the log first
With logging on and the broken page reloaded once, open wp-content/debug.log and go to the bottom. A PHP fatal error line carries the message, the file and the line number, and the file path is the answer: wp-content/plugins/some-plugin/includes/class-thing.php tells you which plugin to disable without disabling anything else.
Read the message too, not only the path. Calling an undefined function or method usually means a plugin expecting a companion plugin or a newer core version. A class not found often means a failed or partial update. Allowed memory size exhausted is the memory case above. Syntax error means somebody edited a file, and if that file is in a theme, the culprit is often the dashboard's built-in file editor, which is why define( 'DISALLOW_FILE_EDIT', true ); is worth adding once the site is up.
Deactivate plugins from the command line, not the dashboard
If you have shell access, this takes one command. The WP-CLI plugin deactivate command accepts either a named plugin or the whole set, and the exclude option is what makes it usable on a real site:
wp plugin deactivate --all --exclude=woocommerce
Then reload. If the white screen is gone, reactivate in small groups rather than one at a time, since halving the list finds the offender in far fewer reloads than walking it. Note which plugins were active before you start, because deactivating everything does not remember the list for you, and a store with a dozen extensions is not something to rebuild from memory.
Renaming the plugins folder works when you have no shell
Without WP-CLI, do the same thing over SFTP or your host's file manager. Rename wp-content/plugins to plugins-off and reload the site. WordPress finds no plugins, deactivates all of them in the database, and the fatal error disappears if a plugin caused it.
Rename the folder back to plugins afterward. The plugins reappear in the dashboard deactivated, and you can switch them on in groups. One warning: do this on a store during business hours and you have turned off checkout, so if the site is transacting, take the outage deliberately or wait for a quiet hour. Do not delete anything at this stage. A renamed folder is reversible and a deleted one takes settings with it.
Switch themes only after plugins are ruled out
Theme faults are less common than plugin faults, so this is step two rather than step one. If plugins are all off and the screen is still white, rename your active theme's folder in wp-content/themes. WordPress falls back to a default theme when the active one is missing, which is enough to get you into the dashboard.
If that fixes the front end, the fault is in the theme, and the usual candidates are a child theme calling something the parent removed in an update, or a function added to functions.php by hand. Check whether the theme was updated recently, and whether there is a child theme at all, because an update that replaced a parent theme's files is a different repair from a bad edit.
Raise the memory limit, and know when it is the wrong fix
When the log says allowed memory size exhausted, raise the memory constant and reload. That is a legitimate fix for a legitimate need: large imports, big media libraries, a store with a lot of variations.
It is the wrong fix when the number keeps needing to go up. Memory that climbs month after month is usually one plugin loading everything into an array, or a query with no limit on it, and raising the ceiling buys a few weeks before the same white screen returns on a bigger page. The distinction is whether you set it once and forget it, or set it three times in a year. The second pattern is a performance problem being paid for with memory.
A PHP version bump is the cause people miss
Nothing changed on the site, and the site went white. Almost always something changed underneath it. A host moving you to a newer PHP release, or somebody switching the version in a hosting panel, turns code that previously emitted a deprecation notice into code that throws a fatal error.
The tell is timing: no update in the plugin log, but the break lines up with a maintenance window or a panel change. The fix is not reverting PHP and leaving it, because the old version stops receiving security fixes and the next forced move breaks the same thing again. Go back one version to get the site up, then update the plugin or theme that cannot handle the new one, test it on a copy, and move forward. Forms and receipts are worth checking after any PHP move, since mail sent through the server's default mailer fails without leaving a trace on the site, which is the argument for a real sending path such as Email Delivery for Cloudflare.
Keeping it from happening again
Every fix above is done under pressure, which is the expensive way to do any of them. The cheap version is prepared in advance: SFTP or shell credentials somebody currently has, an admin email address somebody reads so recovery mode can reach you, logging configured before you need it, and a copy of the site where an update can fail harmlessly. Most white screens arrive attached to an update, and an update applied to a staging copy first turns an outage into a Tuesday afternoon.
That is the shape of managed WordPress maintenance. Each update is reviewed, applied at the right time, watched, and rolled back if it misbehaves; updates are tested in staging against your site first, and site error monitoring and daily form submission testing run alongside, so a page that loads perfectly and is still broken gets noticed. Managed PHP upgrades are part of it too, which is the version of this problem most providers will not touch. On managed WordPress hosting the same work has more room: free one-click staging, a restore point before risky changes, automated daily backups kept 14 days, and rollbacks handled by our team rather than by you at eleven at night. If you are weighing that against doing the upkeep yourself, the maintenance comparisons lay the options out, and the wider managed WordPress page shows where the pieces meet.
Two neighboring posts are worth a look while you are here. Maintenance mode is the screen people confuse with this one, and it protects far less than its name suggests. And a missed publish schedule is the same lesson from the other side: the parts of a WordPress site with no browser attached are the parts nobody is watching.