A blank white WordPress page is a PHP failure that stopped before it could print anything — including its own error message. That sounds worse than it is. Since WordPress 5.2 the default is to catch a fatal error and show a “critical error” screen, so a page that is still completely blank is telling you something specific: the failure is either lower in the stack than WordPress can catch, or it is not a fatal error at all. Read the blank as a location, not a verdict.
Below is why the screen is blank rather than a message, the four things it actually means, a table to match the blank to its cause, and the step-by-step fix. If it is a live shop and the front end is down, skip to when it is not worth fixing it yourself.
Why it is blank and not the “critical error” message
Since WordPress 5.2, released in May 2019, WordPress ships with Fatal Error Protection. When a plugin or theme throws a fatal PHP error, WordPress catches it, shows visitors the generic “There has been a critical error on this website” message, and emails the admin a Recovery Mode link. The old blank white page — the “white screen of death” — was supposed to disappear with it.
So when you get a fully blank page in 2026, the interesting question is why WordPress did not show its own screen. There are only a few answers, and each one narrows the search:
- The error happened before the handler could load — in a must-use plugin, in
wp-config.php, or in a drop-in that runs early. - The handler is switched off — a
WP_DISABLE_FATAL_ERROR_HANDLERconstant, or a host that overrides it with its ownfatal-error-handler.phpdrop-in. - It is not a fatal error at all — PHP running out of memory halfway through rendering, an infinite redirect that ends nowhere, or output that never gets flushed.
If instead of a blank page you actually see the words “There has been a critical error on this website”, WordPress did catch the error — that is a slightly different, usually easier fix, and we walk through it in how to fix the WordPress critical error. This post is for the truly blank page.
The four things a blank page actually means
Almost every white screen is one of four situations. The reason this matters: the fix is different for each, and the blank tells you which one you are in before you touch a single file.
1. A plugin or theme fatal that slipped past the handler
The most common case. A plugin update, a theme switch, or an edit to functions.php introduces code your PHP version cannot run. Usually WordPress would show the critical-error screen — but if the failure lands in the wrong place, or fires during an early hook, the page goes blank first. Isolating plugins and theme is still the fix; you just do it from files, because there is no Recovery Mode email waiting.
2. PHP memory exhausted mid-render
The page starts building, runs out of memory partway, and stops — sometimes printing half a page, then white. WordPress defaults to just 40MB of PHP memory for a single site, which a heavy theme, a page builder or a bulk import can burn through. The debug log makes this one obvious: a line reading “Allowed memory size … exhausted”.
3. A parse or fatal error with errors hidden
A stray character in an edit — a missing semicolon, an unclosed bracket — is a parse error: PHP refuses to run the file at all. On a production server display_errors is off, so instead of a red error you get a white nothing. The fix is to make the error visible (the debug log), read the file it names, and undo the edit.
4. A failure before WordPress can catch anything
The one people miss. If the blank appears on both the public site and wp-admin, and there is no critical-error screen anywhere, the failure is running before Fatal Error Protection loads: a broken edit in wp-config.php, a must-use plugin in wp-content/mu-plugins, or a stale drop-in like db-error.php. This is the case where renaming plugin folders changes nothing — because the problem is below the plugins.
Match the blank to its cause
Match what you see to the likely cause, how to confirm it, and the first thing to try. Work top to bottom — the higher rows are far more common.
| Likely cause | How to confirm it | First fix |
|---|---|---|
| A plugin fatal (recent update or activation) | Rename wp-content/plugins via FTP; if the site returns, a plugin is the cause | Restore the name, then disable plugins one by one until the blank comes back |
| A theme error (edit, update or switch) | Rename the active theme’s folder so WordPress falls back to a default theme | Revert the last functions.php edit, or replace the theme |
| PHP memory exhausted mid-render | The log shows “Allowed memory size … exhausted”, or the page prints half then goes blank | Raise WP_MEMORY_LIMIT in wp-config.php (40MB is the single-site default) |
| A parse or fatal error with errors hidden | The log shows “Parse error” or “Fatal error” naming a file; the screen stays blank | Undo the edit in that file or restore it from backup; set a compatible PHP version |
| A failure before WordPress can catch it | Blank on both the front end and wp-admin, no critical-error screen, often a raw 500 | Check the last wp-config.php edit; rename mu-plugins; remove a broken drop-in |
The fix, step by step
A blank page usually means no Recovery Mode email arrived, so you work from files. You need FTP or your host’s file manager, and a backup of wp-config.php and the database before you change anything.
1. Turn on the debug log
Edit wp-config.php and, just above the line that reads /* That’s all, stop editing! */, add:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reload the site, then open wp-content/debug.log. The last Fatal error or Parse error line names the file — and therefore the plugin or theme — that failed. Keep WP_DEBUG_DISPLAY set to false so the errors go to the log, not onto the page where visitors and bots can read them.
2. Isolate plugins and theme
If the log points at a plugin, deactivate it without wp-admin: in wp-content/plugins, rename its folder (for example slow-slider to slow-slider_off). If the site comes back, that plugin was the cause. If the log points at your theme, rename its folder in wp-content/themes so WordPress falls back to a default theme like Twenty Twenty-Five. Most white screens end here — they are one broken extension meeting a PHP version it does not support.
3. If the log says memory is exhausted
A line like “Allowed memory size … exhausted” means a plugin or theme needed more PHP memory than the 40MB default. Add this to wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );256M is a common, safe bump. If it changes nothing, your host is capping PHP memory at the server level regardless of this line — that is a support ticket to your host, not another edit on your side.
4. If both the site and wp-admin are blank
Renaming plugins did nothing and there is no critical-error screen anywhere. Look below the plugins: undo your last edit to wp-config.php (a stray line here white-screens everything), rename wp-content/mu-plugins if it exists, and delete any db-error.php or php-error.php drop-in left behind by a host or a removed plugin. If the log itself is empty on a blank page, the failure is early enough that PHP could not even start logging — check the server’s own error log or ask your host for it.
When it is not worth fixing it yourself
The honest part. If the blank appeared right after you updated a plugin or edited a file, reversing that one change is not a job for anyone else — do it, and do not re-update until the changelog says the extension supports your PHP version. You do not need us for that.
Where do-it-yourself turns expensive is twofold. First, a live shop: if the front end is white during trading hours, every blank minute is lost orders, and renaming folders on the live site while customers are mid-checkout is how a small problem becomes a bad afternoon — take a backup, work on a staging copy, and switch back only once it is confirmed. Second, the blank-on-both case: when the site and wp-admin are both white, the log is empty, and the failure is in wp-config.php, a drop-in or the server, you are no longer isolating one broken plugin — you are debugging the bootstrap, and one wrong edit there takes the whole site with it. That is what our WordPress error-fixing service is for: back up first, read the real error, fix the broken part, no rebuilding.
Frequently asked questions
Why do I see a blank white page instead of the “critical error” message?
Because the failure happened before WordPress could draw its own error screen, or the fatal error handler is switched off, or it is not a fatal error at all — memory running out mid-render, or an infinite loop. Since WordPress 5.2 a caught fatal shows the “critical error” message, so a page that is still completely blank is a clue about where the problem sits, not a dead end.
Will I lose my content on a white screen?
No. A blank page means PHP stopped running code; it did not delete anything. Your posts, pages, media and WooCommerce orders are still in the database, untouched. Once the broken plugin, theme or edit is reversed, everything is exactly where it was.
The white screen shows only in wp-admin, or only on the public site — what does that tell me?
That the failing code runs in only one place. A broken admin feature can white-out wp-admin while the front end still loads, and a broken front-end plugin does the reverse. If both are blank, the cause is lower down — a must-use plugin, wp-config.php or the server itself.
I turned on WP_DEBUG and now I see the actual error instead of a blank — is that bad?
No, that is the point. The blank screen is the one WordPress problem with no visible error on it; turning on the debug log writes the real error, and the file that caused it, to wp-content/debug.log. Log it rather than displaying it to visitors, then reverse the change the log points at.
Is a white screen a sign my site is hacked?
Rarely. It is almost always a code or memory problem from a recent change, not an intrusion. If you also see pages you did not create, unexpected redirects or admin accounts you did not add, that is a different problem — a compromised site that needs cleaning, not a one-line fix.
Can raising the PHP memory limit fix it?
Sometimes. If the blank appears on heavy pages or during an import and the log says “Allowed memory size … exhausted”, raising WP_MEMORY_LIMIT helps — WordPress defaults to just 40MB for a single site. If your host caps memory at the server level, the change is ignored and it becomes a support ticket rather than another edit on your side.
Sources (verified July 2026): WordPress — Version 5.2; Make WordPress Core — Fatal Error Recovery Mode in 5.2; WordPress — Recovery Mode; WordPress Developer — Editing wp-config.php (memory defaults, WP_DISABLE_FATAL_ERROR_HANDLER); WordPress Developer — Debugging in WordPress.