You typed your web address, pressed enter, and got nothing back. No homepage. No menu. No login box. Just a flat, empty, white page staring at you. If your stomach dropped a little, I understand the feeling completely. I have run TemplateToaster for years now, and I still remember a customer calling me in a near panic because his store had disappeared behind a blank page roughly an hour before a big weekend sale.

That blank page carries a dramatic name. People call it the WordPress White Screen of Death, or WSOD for short. Here is the part most guides bury at the bottom: it is almost always fixable, and you very rarely lose any of your content while fixing it. I have walked dozens of people through this exact mess, and in this guide I am going to hand you the same checklist I use myself, in the order I actually use it.

Before we roll up our sleeves, a quick word for anyone who lands here because a fragile, badly coded theme caused the crash in the first place. A clean theme prevents a surprising number of these incidents. If you want to build one without touching a single line of PHP, our WordPress theme builder generates standards compliant code for you, you can start from one of our free WordPress themes, and if you enjoy learning the mechanics, I wrote a full walkthrough on how to create a WordPress theme from scratch. Now, on to the rescue.

What the White Screen of Death actually is

Let me clear up the biggest myth first. The white screen is not a virus, and it does not mean your database got wiped. It is simply what your browser shows when WordPress hits a fatal PHP error and dies mid render. PHP starts building the page, runs into something it cannot process, stops cold, and never sends any HTML. Your browser receives an empty response, so it paints a blank canvas.

Think of it like a chef who collapses halfway through plating a dish. The kitchen, the ingredients, and the recipe are all still there. The meal just never reaches your table. That picture matters, because the cure is about finding the one broken step, not rebuilding the whole kitchen.

Sometimes you get a friendlier version that reads “There has been a critical error on this website.” That is the same problem wearing a politer mask, and it is genuinely good news, because it usually arrives with an email and a way back in. More on that shortly.

Why WordPress shows you a blank page

Over the years I have found that nearly every white screen traces back to one of a short list of causes. Knowing them up front saves you from flailing.

  • A plugin conflict. This is the number one offender by a wide margin. You update a plugin, or two plugins fight over the same hook, and one of them throws a fatal error.
  • A broken or incompatible theme. A theme built for an older PHP version, an unfinished edit in functions.php, or an infinite loop in the template files can all stop rendering instantly.
  • Exhausted PHP memory. WordPress, your theme, and your plugins each want a slice of memory. When they ask for more than the server allows, the process dies.
  • A syntax slip in a core or config file. One missing semicolon or stray bracket in wp-config.php or functions.php is all it takes.
  • Wrong file permissions. If the server cannot read a file it needs, it gives up.
  • A corrupt .htaccess file. A bad rewrite rule can choke the whole site.
  • An outdated PHP version. Newer themes and plugins drop support for ancient PHP, and the mismatch shows up as a blank page.

If that list looks similar to the roots of other famous WordPress failures, that is because it is. The same memory and plugin gremlins also trigger the dreaded 500 internal server error and even the error establishing a database connection message. Once you learn to diagnose one, you can handle most of the family.

Step zero: figure out where the screen appears

Here is a diagnostic trick most tutorials skip, and it can cut your troubleshooting time in half. Before you change anything, notice exactly where the white screen shows up. The location is a clue.

Ask yourself three questions. Does the whole site go white, front end and admin together? Does only the public side go blank while your dashboard at wp-admin still loads? Or does just one single page or post break while everything else behaves?

When the entire site including the dashboard is down, the cause usually sits deep: memory, a core file, or a theme that loads everywhere. When the front end is white but the admin still opens, you are in luck, because you can fix things from inside WordPress. And when only one page misbehaves, suspect a shortcode, a page builder block, or a plugin tied to that specific template.

Pro Tip: Open the broken page in a private or incognito window before you touch anything. Roughly one in five “white screens” I get asked about are actually a stale cached page in the visitor’s own browser, and the live site is already fine. Thirty seconds here can save you an hour.

Turn on debug mode and read the real error

You cannot fix what you cannot see, so the single most valuable move is to make WordPress tell you what broke. By default it hides PHP errors from visitors, which is why you get a blank page instead of a useful message. We are going to flip that on, privately.

Connect to your site over FTP or your host’s file manager, open wp-config.php in the root folder, and find the line that says that is all, stop editing. Just above it, add these lines:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Save the file and reload your site. WordPress now writes every error to a file at wp-content/debug.log. Open that log and read the last few lines. You will usually see something blunt and helpful, a fatal error naming an exact plugin folder, theme file, and line number. That single line points straight at the guilty party, so the rest of this guide becomes a matter of acting on what the log already told you.

I keep WP_DEBUG_DISPLAY set to false on purpose, so visitors never see raw errors while you work. If the FTP route is new to you, pick a friendly client from my roundup of the best FTP clients for WordPress users and you will be connected in a couple of minutes.

Pro Tip: Once you have fixed the site, go back and remove these debug lines or set them to false. Leaving a debug log running forever is a small security and performance leak, and tidy is always better.

Let Recovery Mode do the work for you

Here is the modern shortcut the old guides never mention, and it changed how I handle these calls. Since WordPress 5.2, the platform ships with a feature called Fatal Error Protection.

When a plugin or theme triggers a fatal error, WordPress quietly emails the site administrator. That email names the component that crashed and includes a Recovery Mode link. Click it, and you log into a safe version of your dashboard where the broken plugin or theme sits paused, ready to delete, replace, or roll back through the normal admin screens, with no FTP required.

So before you do anything technical, check the inbox tied to your admin email, including spam. The fix might already be waiting, which is a strong argument for keeping that admin address current and monitored.

Fix 1: deactivate your plugins

If your debug log fingered a plugin, or you cannot read the log yet, plugins are where the smart money goes first. They cause the majority of white screens I see.

If your dashboard still loads, this is easy. Go to Plugins, select them all, and deactivate everything in one move, then reload the site. If the white screen clears, a plugin was the cause. Now switch them back on one at a time, checking the site after each, until the screen goes white again. The last plugin you enabled is your troublemaker, so delete it, find an alternative, or contact its developer.

If the dashboard is also down, you do the same thing over FTP. Browse to wp-content, find the folder named plugins, and rename it to something like plugins_off. WordPress finds no plugins and deactivates them all at once. If your site comes back, rename the folder back to plugins, then rename individual plugin folders inside it one by one to catch the guilty one.

This “disable, then add back one at a time” rhythm is the core of WordPress troubleshooting in general. I leaned on the same approach when I wrote about the 6 most common WordPress problems and their solutions, and it almost never lets me down.

Fix 2: switch to a default theme

If plugins are not the problem, your theme is the next suspect, especially if the screen went white right after a theme update or a tweak to functions.php.

The test is simple: temporarily activate a stock WordPress theme like Twenty Twenty Four. If your dashboard works, just activate it from Appearance, then Themes. If the dashboard is down, go over FTP into wp-content/themes and rename your active theme’s folder. WordPress cannot find it, so it falls back to a default theme automatically, which often brings the site straight back.

If swapping the theme fixes the white screen, you have your answer. The cleanest long term cure is to stop editing the parent theme directly, because the next update wipes your changes and can reintroduce the crash. Build a child theme instead, so your edits live safely apart from the original. And if the old theme is broken beyond repair, here is how to delete a WordPress theme the proper way rather than leaving dead files on the server.

An honest aside from running a theme company: most theme triggered white screens I see come from heavily modified free themes or abandoned ones that never got updated for current PHP. A well coded, actively maintained theme almost never does this, which is exactly why I obsess over clean output in our own builder.

Fix 3: raise the PHP memory limit

Memory exhaustion is a quiet, common cause, and the tell is often a half loaded page or a white admin area that shows up only on heavier screens. When WordPress runs out of the memory the server granted it, the process stops and you get the blank page.

Give it more headroom. Open wp-config.php again and add this line above the stop editing comment:

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

Save and reload. I usually start at 256M, which is comfortable for most sites in 2026. If your host caps memory below that at the server level, the wp-config value alone will not win, so raise the limit in php.ini or your .htaccess file, or simply ask your host to bump it. Many shared hosts do it in one support reply.

Pro Tip: If you have to keep raising memory every few weeks, that is a symptom, not a solution. A single bloated plugin is usually hogging it. Use the debug log and a quick WordPress website audit to find the real glutton instead of feeding it forever.

Fix 4: clear every cache you have

This one feels too simple to matter, yet it rescues people constantly. After you fix the underlying error, your site can keep serving the old broken page from a cache, making you think nothing changed.

Caches stack up in more places than people expect: your browser, your caching plugin, your host’s server side cache, and any CDN such as Cloudflare sitting in front of the site. Clear all of them. Purge the caching plugin, flush the host cache from your hosting panel, and clear the CDN cache from its dashboard. Then load the site in a fresh incognito window to be sure you are seeing the current version rather than a ghost.

If clearing caches alone brings the site back, the real fix probably landed a step or two earlier, and a stale copy was hiding your success.

Fix 5: increase the maximum execution time

Sometimes the white screen is really a timeout in disguise. A script, an import, or a theme function takes longer than PHP allows, the server kills it, and the page never finishes. This often shows up during big imports, backups, or page builder saves.

The setting that governs this is max_execution_time, measured in seconds. The default is frequently thirty, which is tight for heavy operations. You can raise it through php.ini, your .htaccess file, or wp-config.php depending on your host. I wrote a focused tutorial on how to increase the max execution time in WordPress that walks through each method, so I will not repeat all the code here. The short version: lifting it to 120 or 300 seconds clears most timeout driven blank pages.

Fix 6: check your file and folder permissions

Wrong permissions are an underrated cause, and they tend to appear after a clumsy migration, a restore from backup, or a host change. If the web server cannot read a file it needs, it stops, and you get the familiar blank page.

WordPress has sane defaults, and you want to match them. Set folders to 755, regular files to 644, and lock down wp-config.php tighter at 440 or 400 so it is not world readable. Apply these from your FTP client by right clicking a file and choosing the permissions or “file attributes” option, or over SSH if your host gives you terminal access. Never set anything to 777, no matter what a random forum post says, because that hands write access to everyone and is a real security hole. If the whole tree is wrong, most FTP clients can apply permissions recursively to a folder and its contents in one action.

Fix 7: repair a corrupt .htaccess or core file

When the screen stays white after the steps above, suspect a damaged .htaccess file or a corrupted core file. The .htaccess file controls rewrites and redirects, and one bad rule can take the site down without warning.

Resetting it is painless. Over FTP, rename your existing .htaccess in the root to .htaccess_old, then reload. If the site comes back, the old file was the problem. Log in, go to Settings, then Permalinks, and click Save without changing anything, and WordPress writes a fresh, clean .htaccess for you. To understand what actually lives in that file, my WordPress .htaccess file guide breaks it down rule by rule.

For a corrupt core file, 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. Those two folders hold the engine and never your content, so replacing them refreshes the core without touching your posts, pages, uploads, or settings. A close cousin of this problem, the cannot modify header information error, often hides in the same place, an extra blank line at the top or bottom of a PHP file, so scan for stray whitespace while you are in there.

Fix 8: update PHP or roll back the last change

Two final moves catch the stubborn cases.

First, check your PHP version. Themes and plugins evolve, and many now require PHP 8.0 or newer. If your host is still serving something ancient, a modern plugin can fatal out on activation and leave you blank. Most hosting panels let you switch PHP versions in a dropdown in under a minute. While you are tidying up, it is worth confirming you are on a current, supported WordPress release too, and my note on how to check your WordPress version shows the quickest way.

Second, if the white screen appeared immediately after you updated a specific plugin, theme, or WordPress itself, the cleanest cure is often to undo that one update rather than chase its symptoms. I put together a careful walkthrough on downgrading a WordPress version, plugin, or theme for exactly this situation. And when nothing else works, restoring last night’s backup is not a defeat, it is the fastest route back to a working site, which is why I will not stop preaching about backups in the next section.

How to stop the white screen from coming back

Fixing the crash feels great. Never seeing it again feels better. A few habits make recurrences rare.

Take real backups, automatically, and store them off the server. With a recent backup, the white screen drops from a crisis to a minor annoyance, because the worst case is a quick restore. Pick something dependable from my list of the best WordPress backup plugins and set it on a schedule you never have to think about.

Test changes before they touch your live site. The single biggest reason people get blindsided is updating a plugin or theme directly on production and meeting the conflict in front of their visitors. A staging copy removes that risk, and my guide on how to set up a WordPress staging site makes it approachable even if you are not technical.

Keep things current and lean. Update WordPress and your extensions deliberately, delete plugins you no longer use, and resist installing five tools to do one job. Fewer moving parts means fewer collisions, and tightening your overall WordPress security closes the door on the hacked file edits that sometimes trigger blank pages too. To compare this error with its siblings, my overview of the WordPress errors that frustrate people most is a handy companion.

Where TemplateToaster fits in

We built TemplateToaster because we were tired of watching good businesses get taken down by fragile, bloated themes. A large share of the white screens I get asked about come from themes that were never coded cleanly, or that broke the moment PHP moved forward. When the foundation is solid, this whole category of problem mostly disappears.

That is the philosophy behind our offline builder. It produces clean, standards friendly theme code, it does not bury you in scripts that fight each other, and you stay in control of what loads. If your recent crash came from a theme you no longer trust, building a lean replacement is a permanent fix rather than another patch.

Final word

The White Screen of Death looks terrifying and is almost always tame once you stop guessing and start reading the error. So breathe, open that debug log, and let it tell you the truth. From there it is a calm walk down the list: plugins, theme, memory, caches, execution time, permissions, .htaccess, PHP, backup. Work top to bottom, change one thing at a time, and recheck after each move. Nine times out of ten you will be back online before your coffee goes cold, and the tenth time, your backup has your back.

The people who handle this best are not the most technical. They are the ones who set up backups and a staging site before anything breaks. Be that person, and the next blank page will be a five minute story instead of a bad day.

FAQs

Can the WordPress White Screen of Death cause me to lose my content or data?

No, in almost every case your content stays completely safe. The white screen is a rendering failure caused by a fatal PHP error, not a database deletion. Your posts, pages, media, and settings still live in the database and the uploads folder while the screen is showing. The only realistic way to lose data is if you respond by deleting the wrong files in a panic, which is exactly why you take a backup before making changes.

Why does my WordPress white screen only appear on the admin dashboard and not the front end?

A white screen limited to wp-admin while the public site loads normally usually points to a plugin or theme function that runs only in the dashboard, or to a memory limit that the heavier admin screens exceed first. Try raising the PHP memory limit, then deactivate plugins by renaming the plugins folder over FTP. Because the admin area loads more code than a cached front end page, it is often the first place memory exhaustion reveals itself.

Is the “There has been a critical error on this website” message the same as the White Screen of Death?

Yes, it is the modern, friendlier face of the same fatal error. Newer WordPress versions replaced the pure blank page with that worded message and added Fatal Error Protection, which emails the admin a Recovery Mode link to the paused plugin or theme. So if you see that sentence rather than a blank page, check your admin email first, because WordPress has likely already identified the culprit and given you a one click way back in.

How do I fix the white screen if I cannot access my dashboard or FTP at all?

If both the dashboard and FTP are unreachable, use your host’s file manager inside the hosting control panel, which needs only your hosting login. From there you can rename the plugins folder, swap the theme, edit wp-config.php, and reset .htaccess exactly as you would over FTP. If even the control panel is unavailable, open a support ticket with your host, since they can deactivate plugins, raise limits, or restore a backup from the server side for you.

Does a page builder like Elementor or a caching plugin make the White Screen of Death more likely?

Heavy page builders and aggressive caching plugins do raise the odds, mainly through memory pressure, timeouts, and stale cached pages, though they are rarely broken on their own. A complex builder can push memory and execution time past their limits on big pages, and a caching layer can keep serving a broken page after you have fixed it. Raising the memory limit and execution time, then clearing every cache, resolves most builder related blank pages.

Will updating PHP to a newer version fix or cause the white screen?

Updating PHP usually fixes more white screens than it causes, but test on a staging site first to be safe. Modern themes and plugins increasingly require PHP 8.0 or higher, so an outdated PHP version is a frequent hidden cause. The risk runs the other way only with very old plugins that were never updated for current PHP, so confirm your active plugins and theme are maintained, then switch PHP versions in your hosting panel and check the site.