Fix WordPress White Screen of Death & HTTP 500 Errors

A blank white page. No error, no design, not even a "something went wrong" message — just white space where your site used to be. This is the WordPress White Screen of Death (WSOD), and it usually shows up right after you install a plugin, switch a theme, or update WordPress core. Sometimes it's paired with a proper "HTTP 500 Internal Server Error" instead of blank white, which is really the same family of problem with a slightly louder symptom.

Here's how to find out what's actually broken and get the site back up, without guessing.

Symptom: What You're Actually Seeing

There are three common variations, and they usually mean the same underlying thing — PHP hit a fatal error and stopped executing before it could render anything:

• Pure white screen on the front end, admin, or both, with zero text.
• HTTP 500 Internal Server Error shown by the browser instead of your site.
• Partial white screen — header loads, then the page just stops.

WordPress hides PHP errors from visitors by default, which is good for security but useless when you're the one trying to fix it. The first step is always to make the errors visible to yourself.

Cause: Why This Happens

Almost every WSOD traces back to one of these:

• A plugin update or new plugin that conflicts with your theme or another plugin, or that requires a newer PHP version than your account is running.
• A theme function.php edit with a syntax error — a missing semicolon or an unclosed bracket is enough to take the whole site down.
• PHP memory exhausted — WordPress ran out of the memory limit set in php.ini or wp-config.php, common on sites with heavy plugins like WooCommerce, Elementor, or page builders.
• Corrupted core files from an interrupted WordPress update (connection dropped mid-upload, timeout, etc.).
• .htaccess corruption, which more often throws a 500 than a blank screen, but the fix path is similar.

Fix: Step by Step

1. Turn on debug mode to see the real error

Open wp-config.php via File Manager or FTP (it's in your site's root folder) and find the line that says /* That's all, stop editing! */. Just above it, add:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the site. If WP_DEBUG_DISPLAY is false, nothing shows on the front end (good for a live site), but the actual error gets written to /wp-content/debug.log. Open that file and look at the bottom — the most recent fatal error is your answer. It'll usually name the exact plugin or theme file that's causing the crash.

If you'd rather see the error directly on screen while you're working, temporarily set WP_DEBUG_DISPLAY to true instead — just switch it back once you're done, since showing raw PHP errors publicly is a security risk.

2. If a plugin is the cause: deactivate via File Manager

You often can't reach wp-admin when the site is white-screened, so deactivate plugins at the file level:

1. In cPanel, open File Manager and go to public_html/wp-content/.
2. Rename the plugins folder to something like plugins-disabled.
3. Try loading the site. If it comes back, WordPress will show "plugins folder missing" — that's expected.
4. Rename it back to plugins, then rename it once more but this time drill into the folder and rename just the suspect plugin's subfolder (the one from your debug.log), e.g. elementor → elementor-off.
5. Reload the site. If it's back, the problem plugin is confirmed — check for an update, or replace it if it's abandoned.

If you can reach wp-admin, Safe Mode (built into WordPress 6.2+) does the same thing without touching files: log in, and WordPress will offer to disable the last plugin that caused a fatal error automatically.

3. If it's a theme problem

Same idea: rename your active theme's folder inside wp-content/themes/. WordPress falls back to the default theme (Twenty Twenty-Four or similar) automatically. If the site loads, the theme's functions.php or a recent customization is the culprit — check for a stray bracket or semicolon near wherever you last edited it.

4. Raise the PHP memory limit

If debug.log shows "Allowed memory size of X bytes exhausted," add this line to wp-config.php, right above the same "stop editing" comment:

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

On SkyServer hosting you can also bump the account-wide PHP memory limit from cPanel → MultiPHP INI Editor, which is the better fix if multiple sites or a heavy plugin stack keep hitting the ceiling.

5. Restore core files if nothing above works

If the crash happened mid-update, WordPress core files can be incomplete. Download a fresh copy of WordPress from wordpress.org matching your version, then re-upload only the wp-admin and wp-includes folders (never touch wp-content or wp-config.php — that's where your site and settings live). This replaces anything corrupted without wiping your content.

6. Rule out .htaccess for the 500 variant

If you're seeing HTTP 500 specifically, rename .htaccess in your root folder to .htaccess-old and reload. If the site comes back, go to Settings → Permalinks in wp-admin and click Save — WordPress regenerates a clean .htaccess automatically.

Prevention: Avoid the Next One

• Stage updates first. Test plugin and theme updates on a staging copy before applying them to the live site — most managed cPanel accounts let you clone a site in a few clicks.
• Update one thing at a time. Bulk-updating ten plugins at once makes it much harder to identify which one broke the site.
• Keep a recent backup. A daily or weekly backup means a WSOD is a five-minute restore instead of a debugging session.
• Match PHP version to your plugins. Older plugins can silently fail on newer PHP; check your PHP version under cPanel → MultiPHP Manager before updating either side.
• Limit active plugins. Every plugin is a possible point of failure — deactivate and delete anything you're not actually using.

Frequently Asked Questions

Why does my site show a white screen with no error message at all?

By default WordPress suppresses PHP errors from visitors for security reasons. The error is still happening — it's just being logged instead of displayed. Enable WP_DEBUG_LOG in wp-config.php to capture it in debug.log.

Can a white screen happen only in wp-admin but not the front end?

Yes, and it usually points to a plugin that only loads its problematic code inside the dashboard. Try appending ?safe_mode=confirm after logging in on WordPress 6.2+, or rename the plugins folder as described above.

I renamed the plugins folder and the site still won't load. What now?

That rules out plugins. Move on to renaming the active theme folder next, then check wp-config.php for memory limits, and finally check debug.log for a core file error.

Is a white screen the same as being hacked?

Not usually. WSOD is almost always a code conflict or resource limit, not malware. That said, if debug.log references unfamiliar file paths outside your normal plugins/themes, it's worth running a malware scan just to be safe.

How do I stop this from happening after every update?

Test updates on a staging site first, update plugins one at a time instead of in bulk, and keep a recent backup so any bad update is a quick rollback rather than an emergency fix.