WordPress White Screen of Death: Recovery Decision Tree

A blank page is a scope decision before it is a repair. The wordpress white screen of death is an empty response with no markup, no dashboard, and often no sentence from PHP. Decide whether it is the front end, the admin, or both. Preserve the URL, the time, and the last named change, then read one private log and test one plugin, theme, or edit on a staging copy. Consider resource exhaustion if a spike matches the outage, restore a verified state, and revalidate.

Editorial review date: 10 October 2026. The original publication date is unchanged.

Decide whether the blank page is front-end, admin, or both

Open the homepage logged out, and open the admin login beside it. Write which window is empty before you rename a file.

Front end only means visitors see the empty page and an editor can still open the dashboard. Name the theme and the last plugin that prints on public templates.

Admin only means the homepage renders and wp-admin is empty. A blank login runs on every admin request. A dashboard that dies after sign-in points at a widget or a forms add-on. Check the last plugin updated before that URL failed, and leave the theme if the homepage still shows its title.

Both means the homepage and wp-admin are empty together. Suspect a plugin on every request, a must-use plugin, a drop-in, a bad configuration line, or a limit that stops PHP before HTML. Read the first fatal line rather than sweeping folders.

Add one timing label: after a plugin update, after a theme switch, or during a traffic spike. Scope plus timing chooses the row.

Keep the evidence before the first change

Record the URL, logged out or signed in, the role, Pakistan Standard Time, and the HTTP status if you can see it. A server error with an empty body means PHP stopped. A success status with an empty body can be an empty template or a cached empty response.

Name the last change or write unknown. A plugin with both versions, or a theme with the switch time, is a name. Unknown means production waits until a log names a file. Copy files and the database together first. The WordPress backup handbook means a return to one moment. Restoring only one half will not explain the page. Screenshot the empty window and keep the note private, without passwords.

Do not delete the database, turn SSL off, change permissions across production, or hand-edit core. Those moves discard content, drop encryption, or hide the fatal line. Core waits for a packaged replacement on a copy.

Read the wordpress white screen of death from a private log

Paths and request fragments must stay out of public HTML. This bounded example turns logging on and leaves display off. Use it on the staging copy. With no copy yet, read production once in private, save one line, and build the copy before any code change.

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

Put those three lines in wp-config.php for the diagnosis window only. If they already exist, change them on the copy. A second set can stop PHP and create another empty page. Display stays off so visitors do not see paths. The browser may stay blank while the server writes the reason.

The log, commonly wp-content/debug.log, must be removed or rotated after the diagnosis because it can hold paths and request data. Rename it with the date and move it outside the web root, or delete it once the fatal line is in the private note, then stop new writes. The debugging in WordPress handbook separates display, which prints into HTML, from logging, which writes a server file.

Keep the earliest fatal line: the message, the file name, and the line number. Strip emails, phone numbers, names, and form text. If that log is empty, read the host error log for a failure from before those constants loaded.

Match the observation to one safe check

Pick the row you can repeat in one visit. Run only the last column, on a staging copy.

Write the result, including still blank, then keep the returned page or restore the evidence pair. Do not open the next row on production.

Isolate the last change on a staging copy

Build the copy from files and database taken together. Confirm the same scope, and rebuild the copy if it fails in a different place. Change one item: the previous plugin, the previous theme, or the component named in the fatal line. If the page returns, write the name and version and stop, without removing other plugins. If it stays blank, restore that copy's files and database together. An unknown last change uses the fatal file name, or you stop when the log names nothing.

Consider resource exhaustion as its own branch

A spike can empty the page through memory, a process limit, or a cut-off request. If one quiet request also fails, read the private log and roll back the named component on the copy. Do not edit core or widen write access. If only the spike window fails, note the times in Pakistan Standard Time, treat a higher ceiling as a hosting change, and confirm the public page and admin login afterward. Do not disable SSL, delete the database, or loosen directory permissions. A full disk quota gets one named cleanup, one reload, and a return to the log if the page is still empty.

An illustrative Quetta school admin blank

This worked example is illustrative. It is not a client incident and it uses no pupil records.

A school site in Quetta went blank only in wp-admin after a forms plugin update. The public homepage still rendered, so the theme stayed untouched. At 09:40 Pakistan Standard Time a signed-in editor saw an empty /wp-admin/ while the homepage title was normal. The forms plugin had moved from the previous version to the morning version.

On a clone, the three debug lines ran with display off. The log named a file in that plugin. The line was saved, the log removed, and only the previous version restored. SSL, the database, and permissions stayed as they were. The dashboard and sign-in returned, a sample form opened with fake details, and a fresh backup of the recovered pair was taken. Had the admin stayed empty, the clone would have been restored as a pair and the test stopped.

Restore a verified working state and revalidate

A finished backup job is not a restore. Put files and database back from the same moment.

Then check, in order: the public URL shows real content, an editor can sign in, the failed action works once, the last change is named even if it was not the cause, the debug log is gone or rotated out of the web root, and public HTML prints no errors. Take a fresh backup of that recovered state.

The hardening WordPress guidance keeps updates and access control as separate layers. Use it later, on a copy, for the next release of what you rolled back. It does not widen write access or turn SSL off, and core stays packaged until a replacement is tested on a copy.

Recovery is accepted only when these are true

A returned public page with a failed admin login stays on the admin-only branch, on a copy. A debug log in the web root also fails acceptance, because it can hold paths and request data.

Leave other symptoms on their page

Redirects, mail, and permalinks belong to the broader symptom list on WordPress bugs how to fix. That page covers redirects, mail, and permalinks. This page stays on the blank page.

Send the scope sentence, the time, the named change, whether a same-moment copy exists, and one sanitized log line. Omit passwords and the raw log. pro support can follow that package. A site that should be cloned before the next update can sit on managed WordPress hosting.

If the copy is not fixed after one isolated change, restore the known-good files and database together and stop guessing on production.