WordPress White Screen Fix: 7 Methods Compared (2026)

Enable Debug Mode to See the Actual Error

WordPress hides errors by default. The white screen means PHP hit a fatal error but display_errors is off, so you get nothing. Turn on WP_DEBUG to expose what broke.

Edit wp-config.php and add these lines before the 'stop editing' comment:

With debugging on, reload the page. You'll see a fatal error, warning, or notice that points to a file and line number. That tells you whether a plugin, theme, or core file is responsible.

In support tickets I handled, the usual culprit was a plugin that hadn't been updated in two years trying to call a deprecated function. The error log confirms it immediately.

• define('WP_DEBUG', true);
• define('WP_DEBUG_LOG', true);
• define('WP_DEBUG_DISPLAY', false);
• Check wp-content/debug.log for the logged error

Rename the Plugins Folder to Isolate Conflicts

Plugin conflicts cause most white screens. A recent update may have introduced a fatal error, or two plugins are trying to load the same class. Renaming the plugins folder deactivates everything at once without touching the database.

Connect via FTP or SSH. Navigate to wp-content and rename 'plugins' to 'plugins-disabled'. Reload your site. If it comes back, you know a plugin was responsible.

Rename it back to 'plugins', then rename individual plugin folders one at a time to find which one broke. Start with plugins updated in the last week.

Once you identify the bad plugin, check for updates or replace it. If no update exists, contact the developer or find an alternative. Leave it disabled until you confirm a fix.

Increase PHP Memory Limit for Resource Exhaustion

WordPress allocates memory for each request. Image processing, bulk imports, and plugin-heavy dashboards can exceed the default 128M limit, causing a fatal error mid-render. The page goes blank because execution stopped.

Edit wp-config.php and set the memory limit to 256M:

Reload the site. If the white screen clears, memory was the bottleneck. You can confirm by checking error logs for 'Allowed memory size exhausted' messages before the fix.

Some hosts enforce a lower limit at the server level. If 256M doesn't work, contact your host or check php.ini for memory_limit. I've seen shared hosting cap it at 128M regardless of wp-config.

• define('WP_MEMORY_LIMIT', '256M');
• Place this line above 'stop editing' in wp-config.php
• For admin area only, also set define('WP_MAX_MEMORY_LIMIT', '256M');

Switch to a Default Theme to Rule Out Theme Errors

Theme updates sometimes corrupt template files or introduce syntax errors. If the white screen appeared right after a theme update, the theme is suspect. Switching to a default theme bypasses the problem.

You can't use the admin dashboard if it's down. Connect via FTP and rename your active theme folder inside wp-content/themes. WordPress will fall back to a default theme (Twenty Twenty-Three, Twenty Twenty-Four, etc.). Reload the site.

If the site loads, your theme is broken. Restore the original theme folder, then replace it with a clean copy from the theme developer. If you customized files directly, you'll need to reapply those changes.

Another option: update the database directly. Open wp_options, find 'template' and 'stylesheet' rows, and change both values to 'twentytwentythree' or another installed theme. This works when FTP isn't available.

Verify File Permissions and Ownership

Incorrect permissions prevent WordPress from writing to cache files, session data, or uploads. A white screen can result if WordPress tries to create a file and gets a permission denied error. The request fails silently.

Check ownership first. All WordPress files should be owned by the web server user (www-data, nginx, or your hosting account user). If files are owned by root or another user, the web server can't modify them.

Set directory permissions to 755 and file permissions to 644. Run these commands via SSH:

After fixing permissions, clear any server-side cache (Redis, Memcached, Varnish). Stale cache entries can persist even after you fix the underlying issue.

• find /path/to/wordpress -type d -exec chmod 755 {} \;
• find /path/to/wordpress -type f -exec chmod 644 {} \;
• chown -R www-data:www-data /path/to/wordpress
• Never set 777 permissions; it's a security risk

Compare All Seven Methods: Which One to Use First

Here's the comparison. Debug mode is always first because it tells you what's actually broken. Plugin isolation comes next because conflicts are the most common cause. Memory and theme fixes follow if the error log points to resource limits or template files.

Debug mode: Fast, non-invasive, gives you the error message. Use this first every time. Trade-off: You have to interpret PHP errors, which can be cryptic if you're not familiar with the codebase.

Plugin isolation: Works for 60-70% of white screens I've seen. Fast to test. Trade-off: Renaming folders deactivates everything at once, so you have to test plugins one by one to find the exact conflict.

Memory limit increase: Solves exhaustion errors immediately. Trade-off: If your host caps memory at the server level, this won't work. You'll need to upgrade your plan or move hosts.

Theme switch: Confirms theme errors in under a minute. Trade-off: You lose your active theme until you replace it with a clean copy. If you edited theme files directly, those changes are gone.

Permission fixes: Essential if the error log shows 'Permission denied'. Trade-off: Requires SSH or FTP access. Some managed hosts restrict chmod commands, so you'll need to contact support.

Cache clearing: Quick and harmless. Trade-off: Rarely the sole cause, but stale cache can mask the real fix. Always clear cache after applying any other method.

Disk space check: Eliminates a silent failure mode. Trade-off: If you're out of space, you'll need to delete old backups or logs before WordPress can write files again. Check inode limits too, not just disk space.

Clear Browser and Server-Side Cache

Cached responses can persist even after you fix the error. Your browser may serve a stale white page from its cache, or a caching plugin (W3 Total Cache, WP Super Cache) might hold onto the broken output.

Clear your browser cache first. Hard refresh (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac) bypasses the cache for one request. If the site loads after a hard refresh, the fix worked but your browser was serving old data.

Flush server-side cache next. If you use Redis or Memcached, restart the service. If you use a caching plugin, log into WordPress via SSH or database edit and deactivate the plugin temporarily. Object cache can hold stale data for hours.

CDN cache matters too. If you use Cloudflare or another CDN, purge the cache from their dashboard. Some CDNs respect Cache-Control headers, but manual purging is faster.

Check Disk Space and Inode Limits

A full disk blocks WordPress from writing logs, cache files, or session data. The white screen appears because WordPress can't complete the request. Error logs won't help here because the system can't write the log entry.

Run 'df -h' to check disk usage. If you're at 100%, delete old backups, archived logs, or unused media files. Look in wp-content/uploads, wp-content/cache, and any backup directories your backup plugin created.

Inode limits are less obvious. Some hosts cap the number of files you can create regardless of disk space. Run 'df -i' to check inode usage. If you're at 100% inodes, you'll need to delete thousands of small files (cache fragments, session files, temporary uploads).

Shared hosting often has low inode limits. I've seen accounts hit the cap with 80GB free because cache plugins created 500,000 tiny files. Switch to a VPS or dedicated server if you need higher limits.

Final Recommendation by Use Case

If you have SSH or FTP access, start with debug mode, then isolate plugins. That combination solves 80% of white screens in under ten minutes. If the error log points to memory, bump the limit. If it points to a theme file, switch themes.

If you don't have access, ask your host to enable debugging or provide error logs. Many managed WordPress hosts include a staging environment where you can test fixes without affecting production. Use staging to rule out plugins and themes before touching the live site.

For recurring white screens after updates, the problem is usually a poorly coded plugin or theme that conflicts with core changes. Replace it. Testing on a staging site before updating production prevents this entirely.

If none of these methods work, check for server-level issues: disk space, inode limits, or PHP version incompatibility. Some plugins require PHP 7.4+ and fail silently on older versions. Your host can confirm the active PHP version and upgrade it if needed.