Fix WordPress White Screen: PHP and Hosting Checks

Seeing a completely blank page instead of your WordPress site is frustrating, especially when you know visitors and customers may be hitting that same white screen. This so‑called “White Screen of Death” (WSoD) can indicate a PHP or server failure, but a blank page alone does not establish the cause. A structured, hosting‑side approach helps narrow the search rather than relying on guesses.

This guide covers logs, PHP settings, resource limits, server rules and file checks for WordPress on shared hosting or a VPS/dedicated server. Before changing settings, preserve recoverable files, database and configuration, and record the incident time and last change. Test disruptive fixes in a staging copy with separate data/cache and blocked email, payment and webhook effects. Server-level actions require the relevant administrative access; live changes need a scoped maintenance and rollback plan.

What the WordPress White Screen of Death Really Means on the Server

From the browser’s perspective, the White Screen of Death is a page with no visible content; the response itself may or may not be empty. Possible server‑side causes include:

• A PHP fatal error (syntax error, missing function/class, out‑of‑memory)
• A 500‑level HTTP error (500, 502, 503, 504) without a friendly error page configured
• A web server misconfiguration (broken .htaccess or an invalid Nginx rule)
• Hosting resource limits being hit so aggressively that PHP cannot complete the request

These problems can produce a blank page or a visible error, depending on how the response is handled. They have different fixes, so use the response and logs to establish whether this is a PHP/web‑server incident before changing settings.

Also, distinguish a real WSoD from DNS or SSL problems. If the domain does not resolve at all, or the browser shows connection/SSL errors instead of a blank page, investigate DNS, network connectivity or TLS as appropriate rather than treating it as a WordPress white screen. For genuine DNS problems, see our detailed guide on fixing DNS_PROBE_FINISHED_NXDOMAIN and common DNS errors.

Step 1 – Check Whether It’s a PHP/Server Error

Before digging into logs, confirm the symptom from multiple angles. This helps distinguish browser‑side glitches and caching quirks from server‑side failures.

Check Different URLs and Devices

• Open your homepage, a single post, and /wp-admin/ in a private/incognito window.
• Test from another browser and another device (desktop + mobile).
• If you use a CDN or WAF, use its documented cache‑bypass method, if available. Do not assume that appending ?nocache=1 bypasses caching; that depends on the cache configuration.

If every URL returns a blank page, investigate shared application startup, PHP configuration and cache behavior; this pattern alone does not establish a server failure. If only specific URLs are blank (for example, a single page or only wp-admin), investigate the plugin, theme or admin-only hook used by that request. Compare the response with matching logs before concluding that it is a PHP fatal error.

Check HTTP Status Codes

Next, check the HTTP status with your browser’s developer tools:

1. Open the site, then press F12 (or right‑click → Inspect) and switch to the Network tab.
2. Reload the page and click on the main request (usually the domain root).
3. Look at the Status code.

• 200 OK with an empty response: possible causes include a PHP exit/die before output or a misconfigured template; the status alone does not identify the cause.
• 500 Internal Server Error: investigate server‑side failures, including PHP fatal errors and .htaccess problems.
• 502/503/504: investigate gateway, availability and timeout failures. PHP‑FPM may be involved, but check which layer generated the response.

Knowing whether it’s 200 vs. 500+ already narrows your search. We’ll address both cases when we get to logs and PHP settings.

Step 2 – Read the Error Logs (Don’t Guess)

Error logs are a useful starting point, but a blank page may leave no entry if logging is disabled, the wrong log is checked, or no error is raised.

Where to Find PHP and Web Server Logs on Shared Hosting

On a typical cPanel or DirectAdmin account, you’ll find logs in one or more of these locations:

• cPanel → Metrics → Errors: recent web-server error entries, if enabled. It does not guarantee every PHP-FPM, Nginx, cron or CLI error is included; request the actual service log when needed.
• Raw Access: downloadable access logs for request correlation. Awstats: compiled traffic statistics. Neither is a combined PHP error-log viewer.
• A configured PHP error log might be in the document root, for example /home/user/public_html/error_log; verify the actual log destination.
• Per-directory error_log files may occur under wp-admin or wp-content depending on configuration. Protect all such files against public download.

In DirectAdmin, locate the domain’s log tools actually enabled by the provider. On a server you administer, /var/log/httpd or /var/log/nginx are example directories, not guaranteed paths. Read the loaded configuration and confirm the request’s virtual host and handler.

PHP‑FPM Logs on VPS and Dedicated Servers

If you run your own VPS or dedicated server, PHP is often served via PHP‑FPM. Check:

• /var/log/php-fpm/error.log is one package-dependent example.
• /var/log/php8.1-fpm.log illustrates a historical version-specific name; PHP 8.1 no longer receives upstream security fixes. Use the log configured for the supported version actually serving the site.
• Check configured pool settings in www.conf or the relevant pool file. The FPM master log, PHP application error log and captured worker output are distinct settings; an empty master log does not exclude a PHP error.

Web server logs live in paths like /var/log/nginx or /var/log/httpd. If you’re not sure, your hosting support can point you to the right file.

What You’re Looking For in the Logs

Reproduce the white screen (load the page), then immediately refresh the error log. Match entries to the request time and affected site. Look for lines containing:

• PHP Fatal error
• Allowed memory size of … bytes exhausted
• Call to undefined function or Class not found
• Parse error (syntax error, unexpected ‘}’ etc.)
• mod_fcgid: read data timeout in 45 seconds or upstream timed out (Nginx)

Copy the exact error message and the file path it references. Even if you don’t write PHP, the filename and line number identify where the error surfaced and can guide investigation of a plugin, theme, core file or PHP setting. They do not necessarily identify the root cause.

Step 3 – Fix Common PHP‑Level Causes

Use the matching error and request context to choose a branch below. Change one setting at a time, retain its previous value, and verify the effective web-runtime setting and user operation after the change.

Increase PHP memory_limit if It’s Exhausted

If your log shows something like:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate ...)

then the request exceeded PHP’s configured memory allowance, not necessarily the server’s physical RAM. The example shows a 128M limit, which can be too low for heavy themes, builders, or WooCommerce. Investigate unexpected memory growth before treating a higher limit as the fix.

To increase memory_limit on cPanel without touching the system‑wide configuration:

• If enabled, open cPanel → MultiPHP INI Editor. Select the affected domain; Home Directory can affect multiple sites.
• For the documented Editor Mode workflow, select the domain’s PHP INI settings and edit the existing directive.
• memory_limit = 256M is an example, not a universal target. Choose an allowed value from measured need and aggregate account memory capacity.
• Click Save, then verify the effective value in a request to that domain and repeat the failing operation. Basic Mode uses Apply instead. Select PHP Version is a separate provider/CloudLinux interface; do not assume it has the same tabs or buttons.

On a server you administer, identify the PHP INI actually loaded by the site’s FPM service. /etc/php.ini and /etc/php/8.1/fpm/php.ini are package/version-dependent examples; the latter is historical, not a recommendation to run unsupported PHP 8.1. Back up the active setting and check pool-level administrative overrides. The next memory value is illustrative and belongs in INI, not the shell.

memory_limit = 512M

Validate the loaded configuration and use the documented reload/restart procedure for the installed, supported FPM service during a planned change. The following inherited command illustrates the naming syntax of an old PHP 8.1 systemd service; do not copy it without selecting the correct current service. A restart can interrupt requests:

systemctl restart php8.1-fpm

The PHP allocation limit and aggregate account PMEM quota are different controls; raising one does not raise the other. A WordPress WP_MEMORY_LIMIT setting can request an allowed PHP increase only when defined before WordPress loads, without duplicating an existing constant. Administration can use WP_MAX_MEMORY_LIMIT separately. These settings cannot override a non-changeable host limit. See the shared-hosting resource-limit guide and measure memory across simultaneous requests before choosing more capacity.

Check You’re on a Compatible PHP Version

Many WSoD incidents start right after a PHP upgrade. A site that worked on PHP 7.4 may fail on PHP 8.x because a plugin or theme relies on removed features or behavior that changed between versions. Typical errors include “Call to undefined function” or “Unsupported operand types”.

Per-domain PHP selection depends on enabled interfaces and installed versions. cPanel MultiPHP Manager and CloudLinux PHP Selector are different tools; DirectAdmin also depends on the provider’s setup.

• Open Select PHP Version or a similar menu.
• Note the current version and whether it still receives security updates; prioritize upgrading unsupported versions.
• If the white screen appeared after an upgrade, consider a temporary rollback only if the previous version remains security‑supported and compatible with the current site. Otherwise, prioritize fixing or replacing the incompatible component.
• Then test and fix compatibility issues on a staging copy before upgrading again.

We’ve covered per‑site PHP selection in detail in our article on managing multiple PHP versions on cPanel and DirectAdmin. And if you’re planning a permanent jump to PHP 8.x, our PHP 8.x upgrade checklist walks through the compatibility and performance tuning steps we recommend for WordPress.

Make Sure Required PHP Extensions Are Enabled

Some plugins rely on specific extensions: curl, mbstring, intl, imagick, zip, etc. If an extension is missing after a PHP version change, you might see fatal errors or a blank page.

Use the extension controls actually supplied for the selected PHP version/handler; do not assume every cPanel account offers Select PHP Version. Confirm the extension is loaded in the site’s web requests. On a server you administer, package names must match the distribution and supported PHP branch. The old example apt install php8.1-mbstring php8.1-intl illustrates a versioned Debian/Ubuntu naming pattern, not a current installation recommendation. Select the correct available packages, test configuration and apply the service’s documented reload/restart procedure.

Resolve Syntax Errors and Corrupted Files

If your logs show Parse error messages (unexpected T_STRING, unexpected ‘}’ etc.), PHP can’t even interpret the file. This often happens after a failed manual edit or partial upload.

Common hosting‑side fixes:

• Preserve the named file and logs, then fix or revert a verified faulty edit in staging using authorized File Manager or SFTP access.
• For a core path such as wp-includes/some-file.php, compare against the same WordPress version’s official clean package; the filename is illustrative. Replacing core files is separate from upgrading the database.
• For a plugin/theme, use a trusted compatible release and account for schema migrations before rollback. If unauthorized modification is suspected, investigate access and persistence rather than assuming re-uploading the file resolves the incident.

This is one more reason why solid backups are non‑negotiable. If you don’t already have them, start with our guide on WordPress backup strategies for shared hosting and VPS or, for full‑account recovery, our Full cPanel backup and restore guide.

Step 4 – Check Web Server Rules, .htaccess and Timeouts

Not every white screen is purely a PHP issue. Apache and Nginx configuration problems are also common culprits, especially after migrations or manual rewrites.

Test .htaccess Rules Without Losing Protections

Where Apache or a compatible LiteSpeed configuration reads .htaccess, invalid directives or rewrites can break requests. Apache alone does not make PHP php_value directives valid: mod_php requires suitable override permissions; cPanel LSAPI may manage its own section. PHP-FPM/CGI generally needs its documented INI mechanism. Nginx does not read this file directly.

Prefer a staging test of the specific directive identified by the log. Removing the entire file can remove access restrictions, HTTPS redirects and handler selection. Preserve these at another effective layer before any live isolation test:

1. Make a protected backup of .htaccess; do not leave .htaccess.bak publicly downloadable. Test the suspect rule in staging.
2. If removing a rule restores the request, investigate its effect in .htaccess; this alone does not prove all remaining configuration is correct.
3. When WordPress permalink rules need regeneration, use Settings → Permalinks. If the file is not writable, review and apply the rules WordPress provides. A default .htaccess is not a replacement for custom security/handler rules or a different multisite/subdirectory layout.

Compare with the protected .htaccess.bak copy and keep required access, TLS and application rules. Restore or fix only understood directives, then test both allowed and denied requests before ending maintenance.

Nginx and FastCGI Timeouts

A 504 response or “upstream timed out” requires identifying which proxy/upstream hop timed out. PHP-FPM is one possibility; a slow dependency, saturated queue or separate proxy limit can also be involved. Correlate the exact error with service and application measurements.

• Extremely heavy queries or slow plugins
• Under‑provisioned PHP‑FPM pools (too few children, long queues)
• Low CPU or IO capacity on the server

You can often mitigate this by:

• For fastcgi_read_timeout, remember the limit is between successive reads from FastCGI, not total response duration. Increasing it can lengthen waits without fixing the cause.
• Set pm.max_children from measured concurrency and total memory headroom. pm.max_requests controls requests before a worker respawns; it does not increase concurrent workers or repair a leak.
• Reduce costly queries/dependencies and bound background work. Add capacity only where measurement shows a shortage; a VPS label does not promise dedicated CPU or eliminate application faults.

We go deeper into these performance‑related server tweaks in our article on fixing high TTFB for WordPress and PHP sites and in our broader guide on server‑side optimizations for WordPress (PHP‑FPM, OPcache, Redis and MySQL).

Step 5 – Check Hosting Resource Limits and Process Caps

Account resource enforcement can contribute to failed requests, but the specific limit and server/handler determine the response. A blank page alone does not establish a quota failure.

Account‑Level Limits on Shared and Reseller Hosting

When CloudLinux LVE is configured, limits may include:

• CPU/SPEED: processing capacity; the modern percentage scale is relative to one core, while a panel may normalize it to the account allowance.
• PMEM: aggregate physical memory under LVE accounting, including shared/cache accounting as applicable.
• IO/IOPS: disk throughput and operation rate, respectively.
• EP: entries into the LVE, not every connection or PHP worker. NPROC: total processes and threads inside it.

CPU and disk IO/IOPS normally throttle work. At PMEM exhaustion, cache reclamation is attempted before some LVE processes may be killed, commonly leading to 500/503. Apache mod_hostinglimits can return 508 when EP entry is refused; NPROC exhaustion prevents new process creation. LiteSpeed EP accounting differs, including workgroup master/child behavior. Do not generalize every limit into “PHP was killed” or assume an automatic queue.

If enabled, inspect Resource Usage and correlate usage, units, configured limits and faults with the incident time and application log. When evidence shows a constraint, combine these approaches:

• Optimize the costly path in staging. Verify public cache eligibility and invalidation while excluding login/session, cart, checkout and private responses; preserve scheduled-job and backup deadlines.
• Compare actual allocations, service control and management responsibilities for any capacity change. Shared hosting, VPS and dedicated labels alone do not determine whether the failing operation will succeed.

We explain how these limits work and how to interpret the graphs in our guide on cPanel resource limits and the “Resource Limit Reached” error.

PHP‑FPM max_children and System‑Level Caps on VPS

A VPS or dedicated server can still have configured LVE, container, OS or service limits. Confirm the actual environment rather than assuming EP or provider restrictions disappear:

• PHP-FPM: pm.max_children caps concurrent served requests. Too few workers can increase waiting; too many can pressure total memory and contribute to OOM. Size from measurements, not a universal formula.
• System/service controls: LimitNOFILE and ulimit can constrain open files and other resources. A descriptor limit can cause open/accept failures; it does not necessarily kill a PHP process. Check the exact error and active service limits.

Failures under load can produce blank responses or 502/504 errors. Correlate service queues, memory, CPU, IO and application errors over the same period; a graph alone does not prove causality. For monitoring design, see VPS monitoring with Prometheus, Grafana and Uptime Kuma.

Step 6 – Use WordPress‑Aware Debugging Without Breaking Production

Sometimes logs alone aren’t enough, especially if the error is triggered only under certain conditions. In that case, WordPress’s own debugging tools help — as long as you enable them carefully.

Enable WP_DEBUG Safely

Prefer staging. In wp-config.php, edit existing definitions rather than defining the constants twice. Place them before WordPress loads, before the wp-settings.php inclusion and the “That’s all, stop editing!” comment. Keep true/false as unquoted booleans. Restrict web access to the log and confirm PHP can write it before enabling a short, controlled live diagnostic window if needed:

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

With WP_DEBUG active and writable storage, this logs eligible errors to wp-content/debug.log. Disabling display does not make that file private and cannot cover every error before WordPress starts; keep server-level PHP display_errors off too. Reproduce one controlled request, then match debug.log entries by time. If empty, check the actual PHP/FPM log and whether logging has started.

Keep WP_DEBUG_DISPLAY disabled for live traffic and verify log downloads are denied. After diagnosis, set WP_DEBUG back to false, retain only needed redacted evidence in protected storage and remove temporary logs/test files.

Disable Plugins and Themes via File System

Use the logs and last change to isolate a likely component in staging first. Disabling plugins on a live store can affect checkout, authentication, security and scheduled jobs; plan maintenance and recovery before using the filesystem method:

• Temporarily rename wp-content/plugins to plugins.off to prevent ordinary plugins in that directory from loading. This does not rule out must-use plugins or separate drop-ins.
• Test the request and visit the Plugins screen if accessible. Restore the directory name, verify actual activation state and activate components individually in staging; restoring the name alone is not a guaranteed persistent deactivation workflow.
• For themes, first ensure a compatible default theme is installed. Prefer activating it through the admin interface; if unavailable, preserve the active theme and test a temporary rename, checking parent/child dependencies and actual fallback.

Use a tested compatible fix or alternative for the identified component. A version rollback needs code/database compatibility and security support; restoring files does not reverse every migration. Validate checkout, login and jobs before reopening live traffic. The WordPress staging guide explains preparation; a clone must have separate data/cache and blocked external side effects before it runs.

Step 7 – Prevent Future White Screens with Solid Hosting Practices

Once you’ve recovered from a WSoD, use the momentum to harden your stack so the next issue is either less likely — or at least easier to diagnose.

Set Up Regular Backups and Test Restores

A backup supports recovery only when its contents, consistency and restore path match the application. Plan for:

• Consistent files, database, configuration and any offloaded media/keys, including a pre-change recovery point and an independently stored copy.
• Backup frequency from acceptable data loss, retention from recovery/legal needs and restore time from the service target; daily copies or a fixed 7–30-day range are not universal answers.
• Regular isolated restore tests with email, payments, webhooks and jobs disabled before the restored application starts. Reconcile new transactions before any production database rollback.

Use the WordPress backup strategies guide to define coverage. For supported account-level files, databases and mail, consult the cPanel backup and restore guide. A full cPanel archive is not a guaranteed atomic snapshot or a self-service restore of every server setting; verify scope and permissions.

Harden WordPress and the Server

Unauthorized code changes can also break PHP. When suspected, preserve evidence, investigate the entry point and persistence, and apply verified recovery. Preventive controls include:

• Keep supported core, themes and plugins current using trusted releases and tested updates.
• Set ownership, permissions and runtime write access for the actual handler; 644/755 examples are not a universal fix and permissions alone do not prevent all compromise.
• Protect wp-login.php with suitable rate limits, strong credentials and 2FA while checking legitimate user access.
• Use compatible WAF/security controls as part of the stack and test their effect; they do not replace patching and application access control.

We maintain a detailed WordPress hardening checklist that covers file permissions, salt keys, XML‑RPC, and host‑level protections like UFW and Fail2ban.

Choose Hosting Aligned with Your Site’s Load

Consider a different allocation or service model when verified necessary work keeps hitting limits after tested improvements, or required configuration control is unavailable. Workload patterns to measure include:

• WooCommerce stores with many plugins and heavy queries
• Membership and LMS sites with logged‑in traffic
• Agencies hosting dozens of client sites under one account

Choose capacity from measured peak work, concurrent memory, storage and operational needs. More resources can address a real shortage but do not fix incompatible code, unsafe cache rules or broken configuration. Confirm the selected plan’s limits, support scope and migration/rollback responsibilities before moving.

When to Ask Hosting Support for Help

There are moments when it’s smarter to escalate than to keep poking around:

• The logs clearly show server‑level issues (disk full, MySQL refusing connections, PHP‑FPM failing to start).
• You don’t have access to relevant logs or PHP config on a managed environment.
• Multiple sites on the same server are showing white screens at once.

In your ticket, include:

• Affected URLs without session tokens or unnecessary personal data.
• Reproduction timestamps with time zone, actual status/response and affected user operation.
• Only relevant error lines, with passwords, tokens and personal data removed; use the authorized support channel.
• Recent component/PHP/migration changes, their current state and any rollback already attempted.

This evidence helps the support team identify the right request and service. Resolution time and the work included depend on the incident and support agreement.

Bringing It All Together

The WordPress white screen is a symptom, not a single diagnosis. Compare the HTTP response, matching logs and last change before altering memory_limit, PHP versions or account capacity. Missing log entries do not rule out a failure.

Apply the smallest evidence-backed correction: a compatible component fix, a tested setting change, a specific .htaccess repair or measured capacity adjustment. Verify the original operation plus relevant login, checkout and jobs; then remove temporary diagnostics and confirm access protections remain effective.

Keep the incident record, tested recovery point and successful validation steps. Revisit backup restoration, staging isolation and monitoring against the site’s actual workload. If you need provider help, request the missing logs, permitted configuration controls and explicit service scope rather than assuming a hosting migration will resolve every white screen.