Troubleshooting the WordPress White Screen of Death on cPanel

The WordPress White Screen of Death (WSoD) is exactly what it sounds like: you visit your site and see nothing. A completely blank white page. No error message, no header, no content — just white. It is one of the most disorienting WordPress problems because it gives you zero information about what went wrong. Your site was working minutes ago, and now it is gone.

The good news is that the WSoD almost always has a predictable cause, and on cPanel hosting, you have the tools to diagnose and fix it without needing SSH access or developer experience. This guide walks through every common cause and its fix, ordered from most likely to least likely.

What Causes the White Screen of Death?

The WSoD occurs when PHP encounters a fatal error but error display is disabled (which is the default on production servers). PHP stops execution, but instead of showing an error message, the server sends an empty response. WordPress cannot render the page because the error interrupted execution before any HTML output was generated.

The most common causes, in order of frequency:

1. Plugin conflict or broken plugin update — A plugin encounters a fatal error (syntax error, missing file, incompatible function call).
2. Theme error — The active theme has a fatal error, typically in functions.php.
3. PHP memory limit exhaustion — WordPress runs out of memory before it can finish rendering the page.
4. PHP version incompatibility — A plugin or theme uses functions not available in your current PHP version.
5. Corrupted core files — A WordPress core file is missing or damaged (rare, usually caused by a failed update).
6. .htaccess errors — Malformed rewrite rules prevent PHP from executing.

Step 1: Enable WordPress Debug Mode

The first step is always to see the actual error. Open cPanel's File Manager, navigate to your WordPress root directory, and edit wp-config.php. Find the line that says define('WP_DEBUG', false); and change it to:

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

Save the file and reload your site. If a PHP error is causing the WSoD, you should now see the error message displayed on the page. The error will also be logged to wp-content/debug.log.

The error message will tell you exactly which file and line number caused the fatal error. This is the fastest path to a fix. Common error messages include:

• Fatal error: Allowed memory size exhausted — Memory limit issue (see Step 3).
• Fatal error: Uncaught Error: Call to undefined function — PHP version incompatibility or missing plugin.
• Fatal error: Cannot redeclare function — Two plugins defining the same function name.
• Parse error: syntax error — Syntax error in a theme or plugin file.

Important: After fixing the issue, set WP_DEBUG and WP_DEBUG_DISPLAY back to false. Displaying debug information on a production site exposes file paths and potentially sensitive information.

Step 2: Check PHP Error Logs

If enabling WP_DEBUG does not display the error (or if you cannot access wp-config.php because the entire site is inaccessible), check the PHP error log:

1. In cPanel, navigate to Errors (under Metrics) or Error Log.
2. Look at the most recent entries for PHP fatal errors.
3. Alternatively, use File Manager to check ~/public_html/wp-content/debug.log if WP_DEBUG_LOG was enabled.

cPanel also stores server error logs at a server level. Check the cPanel Error Log page for the most recent 300 error entries. If you are on MassiveGRID's high-availability cPanel hosting, you can also reach out to the support team who can check the server-level logs for you.

Step 3: Increase PHP Memory Limit

If the error message mentions "Allowed memory size exhausted," your WordPress site is running out of PHP memory. This is the most common WSoD cause on sites with many plugins or large media libraries.

Quick Fix via cPanel

1. Go to MultiPHP INI Editor in cPanel.
2. Select your domain.
3. Find memory_limit and set it to 256M (or 512M for WooCommerce or heavy sites).
4. Click Apply.

Alternative: wp-config.php

Add this line to wp-config.php above the /* That's all, stop editing! */ comment:

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

The cPanel setting takes precedence — the WP_MEMORY_LIMIT in wp-config.php cannot exceed the server-level memory_limit. If you set WP_MEMORY_LIMIT to 256M but the server allows only 128M, you are still limited to 128M. For a comprehensive guide to PHP settings on cPanel, see our best cPanel settings for WordPress performance.

Step 4: Disable All Plugins

If the error points to a plugin, or if you cannot determine the cause from the error log, disable all plugins to see if the site recovers.

Method A: File Manager (No WordPress Access Needed)

1. In cPanel's File Manager, navigate to wp-content/.
2. Rename the plugins folder to plugins_disabled.
3. Reload your site.

If the site loads, a plugin is the cause. Now identify which one:

1. Rename plugins_disabled back to plugins.
2. Open the plugins folder and rename each plugin's subfolder one at a time (e.g., rename plugin-name to plugin-name_disabled).
3. After each rename, reload your site. When the site breaks, the last plugin you re-enabled is the culprit.

Method B: Database (Advanced)

If File Manager is not available, you can disable plugins through the database:

1. Open phpMyAdmin in cPanel.
2. Select your WordPress database.
3. Find the wp_options table (your table prefix may differ).
4. Search for the row where option_name is active_plugins.
5. Edit the row and change the option_value to a:0:{} (an empty serialized array).
6. This deactivates all plugins. Reload your site.

Step 5: Switch to a Default Theme

If disabling plugins does not fix the WSoD, the active theme may be the cause. Switch to a default WordPress theme (like Twenty Twenty-Four) to test:

Via File Manager

1. Navigate to wp-content/themes/.
2. Rename your active theme's folder (e.g., your-theme to your-theme_disabled).
3. WordPress will automatically fall back to the latest default theme installed. If no default theme is installed, you will get a different error, but at least you will know the theme was the problem.

Via phpMyAdmin

1. In wp_options, find the rows where option_name is template and stylesheet.
2. Change both values to twentytwentyfour (or whatever default theme is installed).

If the site loads with a default theme, the issue is in your theme's code. Common fixes include reverting a recent theme update, checking functions.php for syntax errors, or contacting the theme developer.

Step 6: Check .htaccess

A corrupted or misconfigured .htaccess file can prevent PHP from executing entirely. In File Manager:

1. Navigate to your WordPress root directory.
2. Rename .htaccess to .htaccess_backup.
3. Reload your site.

If the site loads (but pages other than the homepage may show 404 errors because rewrite rules are missing), the .htaccess was the problem. Regenerate it by going to Settings > Permalinks in WordPress and clicking Save Changes. WordPress will write a fresh .htaccess file.

Common .htaccess issues that cause the WSoD:

• Malformed rewrite rules from a security plugin
• Conflicting redirect rules from multiple plugins
• PHP handler directives that do not match the server's PHP configuration
• Accidentally deleted or corrupted content during manual editing

Step 7: Check PHP Version Compatibility

If the WSoD appeared immediately after a PHP version change in cPanel, a plugin or theme is incompatible with the new PHP version.

1. Go to MultiPHP Manager in cPanel.
2. Switch your domain back to the previous PHP version.
3. Reload your site.

If the site recovers, identify which plugin or theme is incompatible by checking the error messages in debug mode. Update the incompatible component or find an alternative. Then switch back to the newer PHP version. For guidance on PHP version changes, see our cPanel settings guide.

Step 8: Reinstall WordPress Core

If none of the above steps fix the issue, WordPress core files may be corrupted. This is rare but can happen during failed updates or if malware modified core files.

1. Download a fresh copy of your WordPress version from wordpress.org.
2. Extract the archive on your computer.
3. Using cPanel's File Manager, upload the wp-admin and wp-includes folders from the fresh download, overwriting the existing files.
4. Do NOT overwrite wp-content — this folder contains your themes, plugins, and uploads.
5. Do NOT overwrite wp-config.php — this contains your database credentials.

This replaces all WordPress core files with known-good copies while preserving your content, configuration, and customizations.

Preventing Future White Screens

• Use a staging site — Test every update, plugin installation, and theme change on a staging environment before applying to production.
• Maintain regular backups — When a WSoD occurs, a recent backup lets you restore to a working state in minutes.
• Monitor PHP memory usage — Keep your memory_limit well above what your site actually uses. Check usage in cPanel's Resource Usage tool.
• Update one thing at a time — When updating plugins, update one at a time and verify your site after each. Bulk-updating 10 plugins at once makes it impossible to identify which one caused a problem.
• Keep PHP updated — Use a current, actively supported PHP version. Security-only PHP versions receive fewer compatibility updates from plugin developers.

Quick-Reference Troubleshooting Flowchart

Frequently Asked Questions

Is the White Screen of Death the same as a 500 Internal Server Error?

Not exactly, though they can have overlapping causes. A 500 error is an HTTP status code returned by the web server, often caused by .htaccess errors, server misconfigurations, or PHP fatal errors. The WSoD specifically means PHP started executing but encountered a fatal error before producing any output. A 500 error may display a server error page, while the WSoD shows nothing at all. The troubleshooting steps overlap significantly — if you see a 500 error, follow the same steps but also check .htaccess first.

The White Screen only appears on the admin dashboard, not the front end. Why?

This usually indicates a plugin conflict that only manifests in the admin context. The admin dashboard loads additional PHP files and scripts that the front end does not. Enable WP_DEBUG, then try accessing /wp-admin/. The error message will point to the specific plugin. You can also disable plugins via File Manager or phpMyAdmin (Steps 4A and 4B) without needing admin access.

Can a hacked site cause the White Screen of Death?

Yes. Malware can inject malicious code into WordPress core files, theme files, or plugin files. If the injected code contains syntax errors or calls undefined functions, it triggers a fatal error and causes the WSoD. If you suspect a hack, scan your files with a security plugin (Wordfence) or manually compare your WordPress core files against a fresh download. Check wp-config.php for any code you did not add, and inspect functions.php in your active theme for injected code at the top or bottom of the file.

I see a white screen but only on certain pages. What does this mean?

Page-specific WSoD indicates content or template-specific errors. Common causes: a page builder block that references a deactivated plugin, a shortcode from a removed plugin, or a custom template file with a PHP error. Enable WP_DEBUG and visit the specific broken page — the error will reference the exact file and line number. If it is a page builder issue, try editing the page in the WordPress admin and removing any broken blocks or shortcodes.

My site shows the WSoD after a WordPress auto-update. What happened?

WordPress auto-updates occasionally fail mid-process — especially if the server times out during the file replacement phase. This leaves a mix of old and new files that is inconsistent. Follow Step 8 (reinstall WordPress core) by uploading fresh wp-admin and wp-includes folders. This resolves the issue in almost all cases. To prevent this, ensure your hosting plan has sufficient resources and that max_execution_time is set to at least 300 seconds. On MassiveGRID's high-availability cPanel hosting, the infrastructure is designed for reliable background update processes.