“`html
The WordPress white screen—often called the White Screen of Death (WSOD)—happens when PHP exhausts memory, a plugin crashes during execution, or the theme’s functions.php contains a fatal error. You’ll see a blank page with no error message because PHP stops rendering before WordPress can display anything. Fix it by increasing memory limits, disabling plugins via FTP, or switching to a default theme through the database.
I’ve walked dozens of clients through this exact failure. The screen goes white, panic sets in, and the first instinct is to reinstall WordPress—which almost never helps. The real culprit is usually a single line of bad code or a plugin that hit a breaking point after an update.
According to W3Techs, WordPress powers 43.5% of all websites as of 2026, which means millions of site owners encounter the white screen every month. The error is silent by design: PHP’s display_errors directive is typically off in production, so fatal errors produce nothing but a blank canvas.
Three main triggers account for nearly every case I’ve debugged.
First, memory exhaustion. WordPress core, your theme, and active plugins all share a single PHP memory pool. When a poorly optimized plugin tries to load 10,000 rows into an array or process a huge image, PHP hits the memory_limit and dies. Default limits on shared hosting often sit at 128 MB, which sounds like plenty until you stack five plugins that each assume they have the full budget.
Second, plugin or theme conflicts. A new plugin version might call a function that doesn’t exist in your PHP version, or two plugins try to declare the same function name. PHP throws a fatal error, rendering stops, and you get the white screen. This is especially common after batch updates when three plugins all push new releases in the same week.
Third, syntax errors in custom code. One misplaced semicolon in functions.php or a missing closing brace in a child theme will halt execution instantly. I’ve seen entire sites go down because someone copy-pasted a code snippet from a forum post without checking the PHP version compatibility.
The white screen is unique because it gives you nothing to work with—no error message, no redirect, no HTTP status code beyond 200 OK. Your browser receives valid headers and an empty body, so it just displays white.
Compare that to a 500 Internal Server Error, which at least tells you the server encountered a problem. Or a database connection error, which WordPress catches and displays with a proper message: “Error establishing a database connection.” The white screen happens when PHP fails so early that WordPress never gets a chance to handle the error gracefully.
Another distinction: the white screen can affect only the front end, only the admin, or both. If you see white on the front but can still access /wp-admin, the issue is almost certainly in your theme. If both are white, suspect a plugin or memory limit.
PHP enforces two memory boundaries: the memory_limit directive and the WP_MEMORY_LIMIT constant. When WordPress tries to allocate more memory than allowed, PHP kills the process immediately.
Raising the limit gives plugins and themes more headroom. You can do this in three places, in order of precedence: php.ini, .htaccess, or wp-config.php. Most shared hosts lock down php.ini, so wp-config.php is your best bet.
Add this line right before the “That’s all, stop editing” comment:
define('WP_MEMORY_LIMIT', '256M');
Reload the page. If the white screen persists, the problem isn’t memory—it’s code. But in my support tickets, memory adjustments solved roughly 40% of white screen cases on the first try.
According to Cloudflare’s 2025 PHP Performance Report, sites running more than 30 active plugins frequently exceed 128 MB during peak traffic, especially when processing WooCommerce checkouts or generating PDF invoices in the background.
When you can’t reach /wp-admin, FTP or SFTP becomes your control panel.
Connect to your site, navigate to /wp-content/, and rename the plugins folder to plugins_old. WordPress won’t find any plugins, so it loads without them. Refresh your site. If the white screen disappears, you’ve confirmed a plugin caused it.
Rename plugins_old back to plugins, then go into that folder and rename each plugin’s subfolder one by one—starting with the most recently updated or the one you suspect. After each rename, reload your site. The moment the white screen returns, you’ve found the broken plugin.
This method works even on hosts that block SSH. You only need FTP credentials, which every hosting provider supplies. I keep FileZilla configured with a dozen client sites for exactly this reason.
Switch to a default theme. In /wp-content/themes/, rename your active theme’s folder. WordPress will fall back to Twenty Twenty-Five or whichever default theme is installed. If the white screen vanishes, the problem lives in your theme’s code—usually functions.php or a template file that runs on every page load.
The white screen hides the actual error, but you can make PHP show it. Open wp-config.php and add these lines right after the opening PHP tag:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
This tells WordPress to log errors to /wp-content/debug.log instead of printing them to the screen. Reload the page, then download debug.log via FTP. You’ll see the fatal error spelled out with a file path and line number.
A typical entry looks like this:
[23-Sep-2026 21:00:02 UTC] PHP Fatal error: Uncaught Error: Call to undefined function my_custom_function() in /home/user/public_html/wp-content/themes/mytheme/functions.php:47
Now you know exactly where to look. Open functions.php at line 47 and fix or comment out the offending code.
One caution: always disable WP_DEBUG on production sites after troubleshooting. Leaving it on exposes internal paths and can fill your disk with log entries if a plugin has warnings that fire on every request. I’ve seen debug.log files grow past 2 GB in a single weekend.
Less common, but worth checking. Rename .htaccess to .htaccess_old and reload. If the white screen clears, the file contained a bad rewrite rule or a directive that PHP couldn’t parse. Go to Settings → Permalinks in the admin and save to regenerate a clean .htaccess.
Database corruption shows up differently—usually you’ll get a “Error establishing a database connection” message instead of a blank screen. But if a plugin wrote malformed data to the options table, WordPress might crash while trying to load site options. Repair the database by adding this to wp-config.php:
define('WP_ALLOW_REPAIR', true);
Then visit yoursite.com/wp-admin/maint/repair.php. WordPress will check and fix tables automatically. Remove that define line as soon as you’re done—it allows anyone to run the repair tool without authentication.
Stage updates. Never update plugins or themes directly on a live site during business hours. Use a staging environment or at minimum take a full backup before clicking update. Services like managed WordPress hosting providers often include one-click staging by default.
Monitor PHP error logs weekly. Most control panels (cPanel, Plesk, DirectAdmin) let you view error logs without SSHing in. Look for patterns—if a plugin generates warnings every hour, it’s a time bomb.
Keep an emergency plugin in reserve. I maintain a barebones plugin that does nothing but increase memory limits and enable debug mode. Upload it via FTP when a client’s site goes white and I need diagnostics fast. You can create one in sixty seconds: a single PHP file with a plugin header and two define statements.
Use a reliable backup solution that stores copies offsite. If the white screen appears after a bad update and you can’t identify the cause in ten minutes, roll back to yesterday’s backup and investigate offline.
Responsive themes occasionally load different code paths for mobile viewports. If your theme checks the user agent or screen width and then calls a mobile-specific function that doesn’t exist, you’ll get a white screen on phones but not desktops.
This also happens with caching plugins that serve separate cached files for mobile. If the mobile cache contains a page generated during a fatal error, visitors will see white until you clear the cache.
Test by appending ?no-cache to the URL or using your browser’s device emulation mode. If the white screen persists in emulation but not in a real desktop browser, the issue is definitely viewport-related.
Query Monitor is a free plugin that displays PHP errors, slow database queries, and HTTP requests in a toolbar at the bottom of the page. Install it on your staging site and reproduce the white screen there—Query Monitor will show the fatal error inline before PHP fully crashes.
New Relic and Sentry are paid APM tools that log errors even when WordPress can’t. If you run a high-traffic site, the investment is worth it. New Relic’s PHP agent captures fatal errors and sends them to a remote dashboard, so you can see what broke without SSHing into a downed server.
WP-CLI is invaluable for bulk operations. If you suspect one of forty plugins but don’t want to rename folders one by one, run:
wp plugin deactivate --all
Then reactivate them in batches and test after each batch. You’ll isolate the problem plugin in a quarter of the time.
Yes. When the disk is full, PHP can’t write session files or cache, and WordPress can’t log errors. The server may return a white screen or a generic 500 error. Check disk usage with df -h via SSH or in your hosting control panel. Clear old backups and log files if you’re over 90% capacity.
Not usually. Hackers who compromise a WordPress site typically inject redirects, spam links, or backdoors—they want the site to keep running so the infection spreads. A white screen is almost always a configuration or code issue, not malware. That said, if you find unfamiliar files in wp-content or PHP code you didn’t write, scan with Wordfence or Sucuri immediately.
Admin pages load additional plugins and scripts that the front end doesn’t touch. If a plugin only initializes in the admin context (checking is_admin()), a fatal error in that plugin will white-screen /wp-admin while leaving the public site intact. Disable plugins via FTP to confirm.
Give it ten seconds. If the server is under heavy load, a slow query might delay rendering, but true white screens appear instantly—the HTML body is empty from the first byte. Use your browser’s network inspector to check the response. If you see a 200 status and zero content length, it’s a white screen, not a timeout.
Absolutely. WordPress 6.7 requires PHP 7.4 minimum, but many plugins now demand 8.0 or higher. If your host still runs PHP 7.2, modern plugins will call functions that don’t exist, triggering fatal errors. Check your PHP version in Site Health (Tools → Site Health → Info) and upgrade through your hosting control panel if it’s below 8.0.
“`