When you open your WordPress site and see nothing but white, you're staring at the White Screen of Death. No error. No helpful message. Just blank.
I've walked through this exact screen with hundreds of site owners over the years. The white screen happens because PHP hit a fatal error and WordPress couldn't render anything—not even an error page. In most tickets, the root cause is one of nine mistakes: memory exhaustion, a bad plugin, corrupted theme files, or a server misconfiguration. Each leaves the same blank canvas, but the fix is different.
Let's catalogue the mistakes I see most often and the correct way to handle each.
Mistake 1: Ignoring PHP memory limits
WordPress sites run out of memory when plugins, themes, or large media libraries demand more RAM than PHP allows. The default limit is often 32M or 64M. That's not enough for most modern WordPress installs.
When memory runs out mid-execution, PHP dies silently. You get the white screen.
The correct approach:
Raise the memory limit to at least 128M, preferably 256M. Add this line to wp-config.php just above the "stop editing" comment:
define('WP_MEMORY_LIMIT', '256M');
If that doesn't work, the server itself may enforce a lower ceiling. Check php.ini or your hosting control panel and set memory_limit = 256M. Restart PHP-FPM or Apache afterward.
Verify the change by creating a temporary info.php file:
<?php phpinfo(); ?>
Upload it to your document root, visit yoursite.com/info.php, and search for "memory_limit." Delete the file once you confirm the value. If the limit still won't budge, your host may require you to upgrade your plan or contact support to remove the cap.
Mistake 2: Activating a plugin without testing
Plugin conflicts are the number one cause of white screens in my support queue. A poorly coded plugin calls a function that doesn't exist, clashes with another plugin's namespace, or triggers a fatal error during activation.
Most people activate plugins directly in production. When the screen goes white, they panic because the WordPress admin is also blank—they can't deactivate the plugin the normal way.
The correct approach:
Deactivate all plugins via FTP or SSH. Connect to your server, navigate to wp-content/plugins/, and rename the plugins folder to plugins-old:
cd /home/username/public_html/wp-content
mv plugins plugins-old
Refresh your site. If it loads, the culprit was a plugin. Create a new plugins folder, then move each plugin back one at a time, refreshing after each. When the white screen reappears, you've found the offender.
If you need that plugin, check for updates or search the plugin's support forum for known conflicts. Sometimes switching to an alternative plugin is faster than waiting for a fix.
Going forward, test new plugins on a staging site first. Most managed WordPress hosts offer one-click staging; cPanel users can clone the site into a subdirectory.
Mistake 3: Using a broken or outdated theme
Themes can break in several ways: a syntax error in functions.php, missing template files after a bad update, or incompatibility with your current PHP version. When WordPress tries to load a broken theme, it fails and renders nothing.
People often realize the theme is broken only after they've already switched to it in the Customizer.
The correct approach:
Switch to a default WordPress theme via the database. Connect to your database with phpMyAdmin or the MySQL command line:
USE your_database_name;
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';
Replace your_database_name with your actual database name and wp_options with your table prefix if it's not wp_. Replace twentytwentyfour with whatever default theme you have installed—Twenty Twenty-Three, Twenty Twenty-One, etc.
Refresh the site. If it loads, the old theme was the problem. Before switching back, update the theme or restore it from a clean backup. If the theme's functions.php has custom code, review it for syntax errors—missing semicolons, unclosed brackets, or deprecated functions.
Mistake 4: Editing core files or themes in production
Direct edits to theme files or WordPress core via the built-in editor are dangerous. One typo in functions.php and you're locked out. The editor doesn't validate syntax before saving.
I've seen site owners add a custom snippet from a tutorial, save, and immediately lose access to both the front-end and admin.
The correct approach:
Never edit live. Use a local development environment or staging site. If you must edit directly, use FTP or SSH so you can revert quickly.
If you're already locked out, connect via SFTP, download the file you edited, and open it in a real code editor like VS Code. Look for syntax errors: missing semicolons, unmatched quotes, or incorrect function names. Fix the error, re-upload, and refresh.
Better yet, disable the theme and plugin file editors entirely. Add this to wp-config.php:
define('DISALLOW_FILE_EDIT', true);
This removes the "Edit" menu from the WordPress admin and forces you to use proper tools.
Mistake 5: Letting PHP versions drift out of compatibility
WordPress itself supports a wide range of PHP versions, but plugins and themes often don't. If your host auto-upgrades PHP from 7.4 to 8.1 and your theme still uses deprecated functions, the site breaks.
Conversely, running PHP 7.2 on a modern theme built for 8.0+ can trigger fatal errors. The white screen is the same either way.
The correct approach:
Check your current PHP version. In cPanel, go to MultiPHP Manager. Via SSH:
php -v
Cross-reference that version with your theme and plugin requirements. Most plugins list their minimum PHP version on the WordPress.org repository page or in the readme file.
If you recently upgraded PHP and the site broke, downgrade temporarily to the previous version via cPanel or your hosting panel. That buys you time to update or replace incompatible plugins.
If you're on an old PHP version (7.2 or earlier), you're overdue for an upgrade. Test on staging first, then upgrade production incrementally—7.4, then 8.0, then 8.1—checking the site after each step.
Mistake 6: Corrupt or missing .htaccess file
A broken .htaccess file doesn't always cause a white screen, but it can if a bad rewrite rule or syntax error crashes Apache before WordPress loads. I've also seen white screens when .htaccess is missing entirely and the server doesn't know how to route requests.
The correct approach:
Rename your .htaccess file via FTP:
mv .htaccess .htaccess-old
Refresh the site. If it loads (even if permalinks are broken), the .htaccess was the issue. Go to Settings > Permalinks in the WordPress admin and click "Save Changes" without changing anything. WordPress will regenerate a clean .htaccess.
If you had custom rules (redirects, security headers, caching directives), review .htaccess-old and re-add them one block at a time, testing after each.
On Nginx servers, .htaccess is ignored. Check your Nginx config file for syntax errors:
sudo nginx -t
If the test fails, the error message will point to the line and file.
Mistake 7: Database connection failures without error reporting
When WordPress can't connect to the database, it usually shows "Error establishing a database connection." But if WP_DEBUG is off and the connection fails in a weird way—like during a plugin's activation hook—you might see a white screen instead.
This happens after a host migrates your database, changes the database password, or when the MySQL service crashes.
The correct approach:
Verify your database credentials in wp-config.php. Check these four constants:
define('DB_NAME', 'your_database_name');
define('DB_USER', 'your_database_user');
define('DB_PASSWORD', 'your_database_password');
define('DB_HOST', 'localhost');
If you're not sure what they should be, check your hosting control panel under "MySQL Databases" or "Database Manager." The host is usually localhost, but some providers use 127.0.0.1 or a remote hostname.
Test the connection from the command line if you have SSH access:
mysql -u your_database_user -p -h localhost your_database_name
Enter the password when prompted. If you get "Access denied" or "Unknown database," the credentials are wrong. If you connect successfully, the database itself is fine—the problem is elsewhere.
So what if credentials are right but the screen is still white?
Enable debug mode. Open wp-config.php and change these lines:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
This writes errors to wp-content/debug.log instead of printing them on screen. Reproduce the white screen, then check the log:
tail -f wp-content/debug.log
The log will show the exact file, line number, and error message. That's your starting point.
Mistake 8: Exhausting PHP execution time
Some operations—importing large XML files, running complex queries, or generating reports—take longer than PHP's max_execution_time allows. When the timer runs out, PHP stops. If WordPress was mid-render, you get a white screen.
This is common during WooCommerce imports or when a backup plugin tries to process thousands of files.
The correct approach:
Increase the execution time limit. Add this to wp-config.php:
set_time_limit(300);
Or adjust it in php.ini:
max_execution_time = 300
Restart PHP-FPM or your web server. If the white screen persists, the script may be hanging indefinitely rather than timing out. Check the error log for clues.
For long-running tasks like imports, use WP-CLI instead of the admin interface. CLI bypasses the web server timeout:
wp import myfile.xml --authors=create
Mistake 9: Ignoring server-level errors
Not every white screen is WordPress's fault. Sometimes Apache runs out of memory, Nginx hits a fastcgi_buffer limit, or the disk fills up. PHP logs the error, but WordPress never gets far enough to display anything.
In these cases, disabling plugins and switching themes won't help.
The correct approach:
Check the server error log. On cPanel, go to Metrics > Errors. Via SSH, tail the Apache or Nginx error log:
sudo tail -f /var/log/apache2/error.log
# or
sudo tail -f /var/log/nginx/error.log
Look for lines that coincide with your page load. Common culprits:
- Disk full:
No space left on device. Rundf -hto check disk usage and clear old logs or backups. - Out of memory:
Cannot allocate memory. Increase server RAM or optimize PHP-FPM pool settings. - Segmentation fault: Usually a PHP extension bug. Disable extensions one by one in
php.inior recompile PHP.
If the log shows nothing, the request might not be reaching the server. Check your DNS, firewall, and CloudFlare cache.
What to check first
When you see a white screen, start with the fastest diagnostics. Enable WP_DEBUG_LOG, check the debug log, and rename the plugins folder. That covers 80% of cases in under five minutes.
If those don't work, check server logs, PHP version compatibility, and memory limits. The white screen is silent, but the logs almost always tell the story. Once you find the error message, the fix is usually straightforward.
Keep a checklist: debug mode on, plugins off, default theme, check logs. Run through it methodically and you'll find the mistake.
Common questions
Can a white screen corrupt my database?
No. The white screen is a symptom, not a cause. Your data is safe; WordPress just can't render the page.
Why does the white screen only appear on some pages?
Because the error is triggered by code that runs only on those pages—a specific plugin shortcode, a custom page template, or a widget in that page's sidebar.
Will reinstalling WordPress fix it?
Rarely. Reinstalling core files can help if they're corrupted, but it won't fix plugin conflicts, memory limits, or database connection issues.
How do I prevent white screens in the future?
Test changes on staging, keep plugins and themes updated, monitor your error logs, and never edit live files directly.
Fix the mistake, not the symptom
The white screen is just the final output. The real issue is always upstream: a plugin that wasn't tested, a memory limit that wasn't raised, a theme that wasn't updated. Fix the mistake and the screen comes back.
Keep your logs accessible, your backups current, and your instincts skeptical. When something breaks, assume it's one of these nine patterns first. Chances are high you'll be right.