How to Fix the WordPress White Screen of Death (WSOD)

The WordPress White Screen of Death (WSOD) is a blank page with no content, caused by a fatal PHP error that stops the page from loading. Fix it by using WordPress Recovery Mode, turning on debugging to read the real error, then deactivating plugins, switching themes, or raising the PHP memory limit.

You open your website and instead of your homepage you get an empty white page. No design, no text, no error box you can act on. Sometimes only the WordPress dashboard is affected; sometimes the whole site is gone. This is the problem people call the White Screen of Death, and it is stressful because there is nothing on screen to tell you what went wrong.

Take a breath: this is almost always fixable in a few minutes, and your content is usually safe in the database the whole time. This guide is for site owners on shared or managed WordPress hosting who can reach their files through a control panel, File Manager, or FTP. WSOD is one of the most common WordPress failures, and it sits inside our wider server errors guide if you want the bigger picture of hosting-side failures.

Before you change anything, narrow the cause with two quick questions. The answers point you straight at the likely culprit and save you from random guesswork.

Is the whole site white, or only part of it? If both the front end (what visitors see) and wp-admin (your dashboard) are blank, the cause is usually a shared piece: an active plugin, the active theme, a PHP memory limit that is too low, or a damaged core file. If the front end is broken but you can still log in to wp-admin, the problem is more likely a specific theme or a single plugin you can disable from the dashboard. If only the dashboard is white, suspect an admin-only plugin feature or a corrupted admin file.

Is it one page or every page? A single blank page (for example one post or one product) points to that page's specific content, shortcode, or block. Every page blank points to a site-wide cause like a plugin, the theme, or memory. Note what changed just before the screen appeared: an update, a new plugin, or an edit to your theme's code is the usual trigger.

WordPress runs on PHP, the programming language that builds each page on the server before sending it to your browser. When PHP hits an error it cannot recover from, it stops running the script. That is called a fatal error: PHP gives up mid-page and returns nothing, so your browser shows an empty white page.

By default, WordPress hides PHP error messages from visitors for security, which is why you see a blank screen rather than the actual problem. Since WordPress 5.2, newer sites often show a friendlier message instead: "There has been a critical error on this website." It is the same underlying event as the classic white screen, just with a message and, importantly, an email to the admin. Common triggers for a fatal error include:

A white screen is closely related to the 500 Internal Server Error. Both come from server-side failures; the 500 shows an error page, while WSOD often shows nothing because display of errors is switched off. The fixes overlap a lot.

There are two paths, depending on whether you can still reach your dashboard. If wp-admin loads, you can fix most cases from inside WordPress by deactivating plugins and switching themes. If the whole site is white, you work through your host's File Manager or FTP instead, renaming folders and editing files directly. The step-by-step below covers both. Here is the order of attack, from safest and most likely to succeed:

• Check your admin email for a Recovery Mode link (fastest win).
• Turn on debugging to read the real error message.
• Rule out plugins, then the theme.
• Raise the PHP memory limit if the log says memory is exhausted.
• Clear caches, then reinstall core files as a last resort.

1. Back up first. Before you touch a single file, make a full backup of your site's files and database so you can undo any change. If you cannot reach the dashboard, use your host's backup tool or File Manager. See our website backups guide for the safest way to do this.
2. Check for a WordPress Recovery Mode email. Since WordPress 5.2, a fatal error sends an email to your admin address (the one under Settings → General) with the subject line about a technical problem. Open it and click the recovery link: it logs you into a special Recovery Mode session with the faulty plugin or theme already paused, and it names exactly what failed. This alone solves many cases. If no email arrived, check spam, or move on to the next step.
3. Turn on debugging to see the real error. Edit wp-config.php in your site's root folder and, just above the line that says /* That's all, stop editing! */, add define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true);. Reload the page. Errors are now written to wp-content/debug.log (and may show on screen). Open that log and read the newest lines: they name the file and cause, for example "PHP Fatal error" followed by a plugin path or "Allowed memory size ... exhausted."
4. Deactivate all plugins. If you can reach wp-admin, go to Plugins, select all, and choose Deactivate. If the site is fully white, use File Manager or FTP to rename the /wp-content/plugins folder to plugins_old. Reload your site. If it comes back, a plugin was the cause: rename the folder back to plugins, then reactivate plugins one at a time, reloading after each, until the white screen returns. The last one you enabled is the culprit — leave it off and look for an update or a replacement.
5. Switch to a default theme. If plugins were not the cause, suspect your theme. From the dashboard, activate a default theme such as Twenty Twenty-Four under Appearance → Themes. With no dashboard, rename your active theme's folder inside /wp-content/themes (for example mytheme to mytheme_old); WordPress falls back to a default theme automatically. If the site loads, the theme was at fault — reinstall a fresh copy or contact the theme developer.
6. Increase the PHP memory limit. If your log shows an "allowed memory size exhausted" error, give PHP more room. Add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php, or raise memory_limit in php.ini or a .user.ini file. Our PHP settings guide shows exactly where to change these values on common hosts. Reload the site after saving.
7. Clear all caches. A fix can be hidden by cached copies of the broken page. Clear your caching plugin's cache, your browser cache (or use a private window), and any cache at your host or CDN level. Then reload the site to confirm the fix is really live.
8. Reinstall fresh core files. If nothing above works, WordPress's own files may be corrupted. Download a fresh copy of WordPress from wordpress.org, then upload only the wp-admin and wp-includes folders over the old ones via FTP, overwriting them. This replaces core files without touching your content, themes, or plugins. Reload the site once the upload finishes.

When the site is back, remove the two WP_DEBUG lines you added (or set them to false) so error details are hidden from visitors again.

The mistakes that turn a five-minute fix into an afternoon are almost always these:

• Editing live code with no safety net. Pasting a snippet into functions.php on the production site is the single most common way people cause WSOD in the first place.
• Renaming folders without a backup. If a rename goes wrong or you lose track of the original name, you want a backup to fall back on. Take one first, every time.
• Forgetting to clear the cache. You fix the real problem but still see white, assume the fix failed, and start breaking other things. Clear every cache before you judge the result.
• Leaving WP_DEBUG on in production. Debug output can expose file paths and other details to visitors and attackers. Turn it off once you are done.

Most white screens are avoidable with a few habits. Use a staging site — a private copy of your site — to test plugin updates, theme changes, and any custom code before they touch the live site. Many managed WordPress hosts offer one-click staging.

Update carefully: update one plugin at a time and check the site after each, rather than clicking "update all" and hoping. Keep the number of plugins lean, since every extra plugin is another thing that can conflict. Finally, keep your PHP version current and supported — running an outdated PHP version is a frequent, silent cause of fatal errors when a plugin drops support for it. Pair that with a reliable backup routine so recovery is always one restore away.

Why is my WordPress site just a blank white page?

A blank white page nearly always means a fatal PHP error stopped the page from loading, and WordPress hides the error from visitors by default. The usual causes are a plugin conflict, a theme problem, an exhausted PHP memory limit, or a syntax error in custom code. Turn on WP_DEBUG in wp-config.php to reveal the exact error, then fix that cause.

What is Recovery Mode and where's the email?

Recovery Mode is a WordPress feature (since version 5.2) that detects a fatal error and emails your admin address a special login link. Clicking it logs you in with the broken plugin or theme paused, and the dashboard tells you exactly which one failed. The email goes to the address under Settings → General; if you cannot find it, check your spam folder and confirm that address is correct and monitored.

How do I deactivate plugins if I can't log in?

Use your host's File Manager or an FTP client to open the /wp-content folder, then rename the plugins folder to plugins_old. This deactivates every plugin at once. If the site loads, rename it back to plugins and reactivate plugins one by one from the dashboard, reloading after each, until the white screen returns — that last plugin is the cause.

Is the white screen my host's fault?

Usually not. WSOD is almost always a site-side issue: a plugin, theme, memory setting, or code error. Your host is only likely to blame if every site on the account is down at once, or if your error log points to a server process rather than a WordPress file. A quick test: if a plain HTML file uploads and loads fine, the server is healthy and the problem is in your WordPress setup.

Will I lose my content and settings?

Almost never. Your posts, pages, and settings live in the database, which a white screen does not touch. WSOD is a page-rendering failure, not data loss. Renaming a plugin or theme folder only disables that code; it leaves your content intact. Taking a backup first is still wise so you can undo any change with confidence.

What does "There has been a critical error on this website" mean?

It is the modern, friendlier version of the White Screen of Death shown by WordPress 5.2 and later. It means the same thing — a fatal PHP error stopped the page — but instead of a blank screen it shows a message and emails the admin a Recovery Mode link. Follow the same steps: check the email, enable debugging, and rule out plugins, theme, and memory.

The White Screen of Death looks alarming but it is one of the more predictable WordPress problems. It means a fatal PHP error, so your job is simply to find which piece failed. Start with the Recovery Mode email, turn on WP_DEBUG to read the real error, then work through plugins, theme, memory, cache, and finally a core reinstall — taking a backup before each risky change. To make recovery painless next time, set up a dependable backup routine now: read our website backups guide to put one in place. If you would rather zoom out to other server-side failures, the server errors guide is the hub for this whole category.

• WordPress Developer Documentation — Debugging in WordPress (WP_DEBUG, WP_DEBUG_LOG).
• WordPress 5.2 release notes — Fatal error protection and Recovery Mode.
• WordPress Support — Editing wp-config.php and increasing the memory limit.
• PHP Manual — memory_limit and fatal error behaviour.