How to fix WordPress white screen fix: Troubleshooting Checklist

Common Symptoms and Failure Patterns

The white screen can manifest in different areas of your WordPress installation. Identifying where the failure occurs helps narrow the root cause.

Frontend-only white screens while the admin area works normally typically indicate theme errors or frontend-specific plugin conflicts. Admin-only white screens suggest plugin conflicts in the admin context or corrupted core files. Sitewide white screens affecting both frontend and admin usually point to PHP memory limits, fatal syntax errors, or corrupted wp-config.php.

• Blank page with no HTML source code in browser inspector
• HTTP 200 response code but zero content length
• Partial page load that stops mid-render
• White screen only on specific pages or post types
• Intermittent failures that resolve after page refresh

Enable Debug Mode and Check Error Logs

This writes errors to wp-content/debug.log instead of displaying them on screen. Check this file after reproducing the white screen to see fatal errors, warnings, and notices.

Also check your server's PHP error log, typically located at /var/log/php-fpm/error.log or configured in php.ini under error_log. Your hosting control panel may provide log viewers under error logs or PHP logs sections. Look for fatal errors, memory exhaustion messages, or maximum execution time exceeded notices.

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

Increase PHP Memory Limit

If wp-config.php changes have no effect, the server-level php.ini may enforce a lower limit. Check your current limit by creating a temporary file named info.php in your WordPress root with this content: <?php phpinfo(); ?>. Access it via browser at yourdomain.com/info.php and search for memory_limit. Delete this file immediately after checking to avoid exposing server configuration.

To increase server-level limits, edit php.ini (location varies by host: /etc/php.ini, /etc/php/8.x/fpm/php.ini, or accessible via hosting control panels). Set memory_limit = 256M and restart PHP-FPM or Apache. On shared hosting where php.ini access is restricted, create or edit .htaccess in WordPress root and add php_value memory_limit 256M.

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

Isolate Plugin and Theme Conflicts

Replace wp_ with your actual table prefix if different. This clears the active plugins list. Reactivate plugins through the admin interface afterward.

To test for theme conflicts, switch to a default WordPress theme. If the admin is accessible, go to Appearance > Themes and activate Twenty Twenty-Four or another default theme. Via FTP or SSH, edit wp-config.php and add define('WP_DEFAULT_THEME', 'twentytwentyfour'); before the require_once line at the bottom. Alternatively, run this database query:

• UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
• UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';

Verify PHP Version Compatibility

WordPress core, plugins, and themes each have minimum PHP version requirements. Running outdated or incompatible PHP versions causes fatal errors when unsupported functions are called.

Check your current PHP version with the info.php method described earlier or by running php -v via SSH. WordPress 6.4 and later require PHP 7.4 minimum, with PHP 8.0 or higher recommended. Many plugins now require PHP 7.4 or 8.0.

If your PHP version is below the minimum requirement, coordinate with your hosting provider or upgrade via your hosting control panel's PHP version selector. Before upgrading PHP in production, test compatibility in a staging environment. Some older plugins written for PHP 5.6 may break on PHP 8.x due to deprecated function removal.

Check plugin and theme documentation for their specific PHP requirements. If a plugin is no longer maintained and incompatible with modern PHP, look for actively maintained alternatives.

Check File Permissions and Ownership

Replace www-data with your server's actual web user. On shared hosting environments, ownership is often managed automatically and manual changes may not be permitted.

• chown -R www-data:www-data /path/to/wordpress

Repair or Replace Core Files

Visit yourdomain.com/wp-admin/maint/repair.php in your browser. This page offers two options: repair database only or repair and optimize database. Choose repair first. Remove the WP_ALLOW_REPAIR line from wp-config.php after completion to prevent unauthorized access.

For manual core file replacement, download the same WordPress version from wordpress.org/download/releases/ that matches your current installation (check wp-includes/version.php for your version number). Extract the archive and upload wp-admin and wp-includes directories via FTP, overwriting existing files. Do not replace wp-content or wp-config.php to preserve your themes, plugins, and configuration.

Always back up your entire WordPress directory and database before replacing core files. Use your hosting control panel's backup tool or run manual backups via SSH with tar and mysqldump commands.

• define('WP_ALLOW_REPAIR', true);

Check Server Resources and Limits

Add this line near the top of wp-config.php after the opening <?php tag. On shared hosting, extremely high values may be blocked by server-level policies.

Check server load and resource usage with top or htop via SSH. High CPU or memory usage from other processes can starve PHP execution. On shared hosting, contact your provider if resource limits are consistently exceeded to discuss plan upgrades or optimization strategies.

• set_time_limit(300);