A blank WordPress page can feel like a total outage, but it often points to one failed component. WordPress white screen troubleshooting works best when you collect evidence before changing files, plugins, or server settings.
The white screen of death may come from a fatal PHP error, exhausted memory, a broken update, incompatible code, or incorrect file permissions. The right recovery path depends on what changed and what your logs report.
Start with scope and recent changes
First, determine how much of the site has failed. Open the public homepage, a known page, /wp-admin/, and, if relevant, a WooCommerce or contact form page. Record which URLs show a blank response and which still work. This initial comparison gives WordPress white screen troubleshooting a clear starting point.
Next, ask what changed immediately before the failure. Useful clues include:
- Plugin, theme, WordPress, or PHP updates
- Hosting moves or control panel changes
- New custom code snippets
- Changes to caching, security, or permissions
- Sudden traffic increases or storage warnings
Do not repeatedly refresh while making unrelated changes. Save the time of the first failure, recent change details, and any visible error message. That timeline helps separate a code failure from a hosting or database problem.
If the page shows a database connection message rather than a blank screen, use the separate database connection diagnostic guide. A white screen and a database failure need different checks.
Use logs before changing WordPress files
Server and PHP logs usually provide the most useful first clue. Your hosting panel may label them “PHP errors,” “error logs,” or “site logs.” A managed host may need to provide them for the affected domain and time period.
Look for entries containing terms such as Fatal error, Allowed memory size, Call to undefined function, Class not found, or a plugin and theme path. The file path often identifies the component that failed. This evidence is central to WordPress white screen troubleshooting because it narrows the repair before you disable anything.
WordPress can also write debugging information to wp-content/debug.log. If you can edit wp-config.php, place these settings before the line that says “That’s all, stop editing”:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );This records errors without displaying technical details to visitors. Use debugging temporarily, protect the log from public access, and turn it off after recovery. Do not paste credentials or private customer data into a support request.
For a structured approach, compare your evidence with Google’s Effective Troubleshooting guidance. Form one likely hypothesis, test it, and record the result instead of changing several variables at once.
Try WordPress Recovery Mode
Modern WordPress installations may activate Recovery Mode after detecting a fatal PHP error. WordPress sends an email to an administrator with a special sign-in link. That link can let you access the dashboard while the failing plugin or theme is paused for your session.
Check the administrator mailbox, including spam and quarantine folders. Use the newest recovery email, and avoid forwarding the link. It contains a temporary access token.
After signing in, inspect the critical error notice. WordPress may name the plugin, theme, or file that triggered the failure. Deactivate the identified component, then test the public site in a separate private browser window.
Recovery Mode is not a permanent repair. The underlying code may still be incompatible, incomplete, or incorrectly configured. Update it only after confirming compatibility and creating a backup. If no email arrived, continue with hosting file access, a staging copy, or help from the host.
Check PHP memory and server limits
A site can fail when a request needs more memory than PHP allows. Logs often show this as “Allowed memory size exhausted.” Large imports, page builders, image processing, backups, and poorly behaved plugins can increase memory use.
Check the effective PHP memory limit in the hosting panel or a controlled WordPress diagnostic screen. Do not assume a value in one configuration file applies to every request. PHP-FPM, the web server, command-line PHP, and the hosting account may use different settings.
WordPress sometimes accepts a higher application memory setting in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );That line does not override a lower server-enforced limit. Ask the host whether the account, PHP worker pool, or plan imposes another ceiling. Also check disk space and process limits, because a memory symptom may accompany a broader resource problem.
Increasing memory can restore access, but it may hide a plugin defect or an inefficient custom feature. Capture the error first, make one change, and retest. Avoid choosing a large value without confirming the server’s available resources.
Test plugins without losing configuration
Plugins are a common source of fatal errors after updates or PHP changes. If the dashboard works through Recovery Mode, deactivate the suspected plugin there. If it does not, use the hosting file manager or SFTP.
With file access, open wp-content/plugins and rename the suspected plugin directory. For example, add .disabled to its folder name. WordPress will no longer load that plugin. Rename only one component at a time, then test the site.
If you do not know which plugin failed, rename the entire plugins directory to temporarily disable all standard plugins. Restore the original directory name after testing. Then reactivate plugins individually until the failure returns.
This method preserves plugin files and database settings, but it can affect forms, caching, security controls, and site features. Tell visitors that maintenance is underway if the site serves customers. For a deeper controlled sequence, see our guide to recovering WordPress after a plugin conflict. WordPress white screen troubleshooting becomes faster when you disable one suspected component at a time.
Rule out a broken theme
A theme can trigger a blank page through a PHP syntax error, an incompatible function, or damaged files. If plugins are not responsible, switch temporarily to an installed default theme.
When the dashboard is unavailable, use the database carefully or rename the active theme directory through SFTP. Renaming the folder prevents WordPress from loading it, but the site still needs another valid theme installed. Do not delete the theme before confirming that you have a clean replacement.
Database changes require extra caution. The active theme is stored in the WordPress options table, but the table prefix varies. Confirm the correct database and take a backup before editing values. A hosting technician can perform this step with less risk.
After access returns, inspect the theme’s error path and compare its version with the required PHP version. Restore a known-good copy rather than editing production theme files blindly. Custom themes should also be tested on staging before updates reach the live site.
Verify file ownership and permissions
Incorrect permissions can stop WordPress from reading PHP files, loading styles, or writing required directories. They can also create a security weakness when permissions are too open.
Typical recommendations often use directories with execute access for the web server and files with read access. However, the correct owner, group, and permission values depend on the host, web server, deployment method, and security model.
Check whether the failure began after:
- Restoring a backup
- Uploading files as a different system user
- Running a deployment script
- Changing the PHP handler or hosting account
- Moving the site between servers
Compare affected files with a known-good WordPress package of the same release. Do not recursively apply a copied permission command without understanding its effect. That can break uploads, expose configuration files, or change ownership across unrelated sites.
Restore safely and prevent a repeat
Once the cause is clear, make the smallest repair that addresses it. Roll back one plugin or theme, restore a clean file, correct a verified server limit, or return permissions to the host’s documented model.
Test more than the homepage. Check administrator access, forms, media uploads, scheduled tasks, checkout flows, caching, and error logs. Clear caches only after confirming that the application works at the origin server.
Then document the failed component, the evidence, the change, and the result. Keep a recent tested backup and use staging for major WordPress, PHP, theme, and plugin changes. Official WordPress guidance also covers performance analysis and optimization, which can help identify resource pressure before it becomes an outage.
WordPress white screen troubleshooting is safest when each test answers a specific question. If logs are unavailable, file access is restricted, or the site handles orders and customer data, professional remote assistance may be appropriate. Tech Rescue Ops LLC can help collect evidence and apply a controlled recovery plan without guessing.