Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Errors & Diagnosis

WordPress White Screen of Death: How to Diagnose It Safely

A blank page means PHP stopped and the error is hidden, not absent. Here is the exact command-level sequence to find the cause without exposing anything.

Short answer: a white screen means PHP stopped executing and WordPress is hiding the error from visitors. The error still exists — it is written to a log. Your job is to read that log, then isolate the component, not to guess.

First, map where the blank appears

Load the front page, a single post, and /wp-admin/. A blank front end with a working admin points at the theme or a front-end plugin. Everything blank, admin included, points at a global fault — memory, a must-use plugin, PHP, or a corrupted core file. This one observation removes half the possibilities.

Turn on the log, not on-screen errors

Add these three lines to wp-config.php, just above /* That's all, stop editing! */:

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

Reload the blank page and open /wp-content/debug.log. The last Fatal error line names the file, the line and the function. Keep WP_DEBUG_DISPLAY off so errors never render to visitors — they leak file paths and plugin names. If you have hosting access, the server’s PHP error log carries the same detail.

Isolate plugins over SFTP, one by one

If the log blames a plugin, or you cannot reach the admin at all, work at file level:

  1. Over SFTP or the hosting file manager, rename /wp-content/plugins to plugins_off. That disables every plugin at once. If the page returns, a plugin is the cause.
  2. Rename the folder back to plugins. WordPress now shows the plugins as deactivated.
  3. Re-enable them one at a time and reload after each. The one that brings the blank screen back is the culprit — which is what you actually need to know, rather than just clearing the symptom.

Rule the theme in or out

If plugins are clear, rename the active theme’s folder inside /wp-content/themes. WordPress falls back to a default theme automatically, and if the blank screen clears, the fault is in the theme — most often a recent edit to functions.php or a template calling a function removed in a newer PHP version.

Memory and incomplete files

If the log says “Allowed memory size exhausted”, add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php — and note many hosts cap this at server level, so confirm it applied. A blank screen that began right after an upload or migration can mean missing files; reinstalling WordPress core over itself replaces core files without touching your content.

Preserve first, then verify

Back up the current state before editing, and remove the debug constants when you finish so a log file does not sit exposed. A loading home page is not proof — re-test the exact route that failed, sign in to the admin, and submit a form, because a memory or PHP-compatibility cause is often waiting on another page.

See the official WordPress debugging documentation for the supported constants.

WP REPAIR INCIDENT STANDARD

How to narrow the fault without guessing

A white screen is not a diagnosis. The useful distinction is whether PHP failed before WordPress loaded, while a plugin or theme was loading, or only on one route.

WP RepairDiagnostic model
1Request2PHP / server3WordPress4Component
Follow the chain until you find the first point that stops behaving as expected.
01

Compare the front page, one inner URL and /wp-admin/ to map the scope.

02

Read the server PHP log as well as debug.log; an early bootstrap failure may never reach WordPress logging.

03

Record the exact PHP version and the most recent deployment or update.

04

Disable only the component named by the fatal error before testing broader isolation.

What must be verified

  • The exact failed URL loads twice without a new fatal error.
  • The administrator and a business-critical form or checkout path work.
  • Debug display is off and temporary logging is removed or protected.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident