WordPress White Screen of Death: Emergency DIY Fixes

If your WordPress front end or admin loads as a blank white page, you are dealing with the White Screen of Death (WSOD)—and every hour offline costs leads, bookings, and trust.

This guide is for homeowners and small-business owners who need a practical emergency fixer path: identify the real failure, apply safe DIY steps, verify the site is back, and escalate cleanly when the root cause is deeper than a single plugin. Fixwebnode provides direct WordPress Support for WSOD, fatal errors, and related recovery—not a freelance marketplace. Work spans our listed service areas, including Melbourne suburbs such as Fitzroy and South Yarra when on-site or region-specific help is required.

Below you will find four distinct WSOD patterns, copy-pasteable checks, and clear “call a specialist” lines so you do not make a recoverable outage worse.

Why a White Screen of Death emergency fixer matters

WSOD is almost never “WordPress being random.” It is PHP dying before any HTML is sent—usually a fatal error, exhausted memory, a broken must-use plugin, a bad drop-in, or malware rewriting bootstrap files. Browsers show white; search consoles and customers only see downtime.

Acting in order matters: enable diagnostics, isolate the last change, restore a known-good layer (plugin, theme, core file, or wp-config.php), then harden so the same crash cannot repeat after the next auto-update. Guessing by deleting random folders often extends the outage.

Common White Screen of Death issues (unique symptoms)

Use the symptom blurb that matches what you see. Each maps to a different root cause and fix path later in this post.

• Post-update plugin fatal: Site was fine; after updating or activating one plugin (or bulk-updating several), both front end and /wp-admin go white. Host error log shows PHP Fatal error naming a plugin path under wp-content/plugins/.
• PHP memory exhaustion: Intermittent or total white screen on heavy pages (shop, Elementor, WooCommerce admin). Log or a brief flash of text mentions Allowed memory size of … bytes exhausted. Smaller pages sometimes still load.
• Theme or functions.php syntax break: White screen only on the public site while admin still works—or both fail right after a theme edit, child-theme tweak, or “code snippet” paste. Log cites parse error or unexpected token in the active theme.
• Core/bootstrap or malware-induced fatal: WSOD appears without a deliberate update; wp-config.php, index.php, or wp-includes checksums differ; odd scheduled tasks, unknown admin users, or encoded junk in wp-content/mu-plugins. Security scanners flag backdoors while the UI stays blank.

How to fix each WSOD issue step by step

Prerequisites for all DIY paths: SFTP or host file manager access, a full backup (files + database) before you change anything, and SSH if your host offers it. Prefer staging when the host provides one. Replace paths with your account’s home and site root.

Issue 1 — Plugin conflict or bad update fatal

Goal: disable the offending plugin without needing wp-admin, restore a usable site, then update or replace that plugin cleanly.

Step 1 — Turn on logging so the next load records the fatal

Via SFTP, open wp-config.php above the line /* That's all, stop editing! */ and ensure:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Reload the white URL once. Then inspect the log:

tail -n 80 wp-content/debug.log

Note any path under wp-content/plugins/some-plugin/….

Step 2 — Disable plugins from the filesystem

cd /path/to/wordpress/wp-content
mv plugins plugins.off
mkdir plugins

Reload the site. If it returns, the fault is plugin-side. Restore the folder and isolate one plugin at a time:

rmdir plugins
mv plugins.off plugins
cd plugins
mv offending-plugin-slug offending-plugin-slug.off

Or rename suspects alphabetically until the screen recovers. On hosts with WP-CLI:

wp plugin list --status=active
wp plugin deactivate offending-plugin-slug
wp plugin install offending-plugin-slug --force
wp plugin activate offending-plugin-slug

Step 3 — Verify

wp option get siteurl
curl -I https://your-domain.example

Expect HTTP 200 and a normal HTML body, not zero-length content. Turn WP_DEBUG_DISPLAY off permanently; keep the log briefly if you still need traces.

When to call Fixwebnode: Admin stays white after all plugins are off, fatals point at wp-includes, or deactivating breaks checkout/memberships you cannot rebuild yourself. Book core/plugin recovery via WordPress Core & Plugin Bug Fixing | Fix White Screen Errors.

Issue 2 — PHP memory limit exhaustion

Goal: raise limits safely, confirm the fatal is gone, then reduce the real memory hog so you are not papering over a runaway plugin.

Step 1 — Confirm the symptom in logs

grep -i "memory size" wp-content/debug.log | tail -n 20
# or host log path, e.g.:
tail -n 100 ~/logs/error.log | grep -i memory

Step 2 — Raise memory in wp-config.php

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Step 3 — Align PHP-FPM or pool limit if the host allows it

In the panel (or php.ini / multiPHP INI), set memory_limit = 256M (or higher if the host documents a safe ceiling). On some VPS stacks:

php -i | grep memory_limit

Ensure the CLI and web values are not stuck at 128M while WordPress requests more.

Step 4 — Optional temporary lift via .htaccess (Apache only, if permitted)

php_value memory_limit 256M

If the server ignores this, rely on panel/php.ini instead—do not stack conflicting directives.

Step 5 — Verify and find the hog

wp plugin list
wp theme list
curl -s -o /dev/null -w "%{http_code} %{size_download}\n" https://your-domain.example/

Re-test the page that previously died (cart, builder UI). If WSOD only returns under load, disable page builders or heavy optimization plugins one at a time after a backup.

When to call Fixwebnode: Host caps memory below what WooCommerce or your builder needs, raising limits changes nothing, or CPU pegs with no clear plugin. That pattern often hides object-cache misconfig or malware loops—specialist triage is faster than endless limit bumps.

Issue 3 — Broken theme or functions.php syntax

Goal: restore a default theme from disk so PHP can boot, then repair or roll back the custom theme.

Step 1 — Read the parse error

tail -n 50 wp-content/debug.log

Look for Parse error / syntax error and a line number inside wp-content/themes/your-theme/functions.php (or a template).

Step 2 — Force a default theme via database or WP-CLI

If SSH/WP-CLI works even when the front is white:

wp theme list
wp theme install twentytwentyfour --activate

Without WP-CLI, using host phpMyAdmin, in the wp_options table set template and stylesheet to a stock theme folder name that exists under wp-content/themes/ (for example twentytwentyfour).

Step 3 — Quarantine the broken theme for diffing

cd wp-content/themes
mv your-child-theme your-child-theme.broken

Reload. If the site returns on the default theme, restore customizations from backup into a clean child theme rather than re-pasting the same snippet blindly.

Step 4 — Syntax-check PHP before reactivating

php -l wp-content/themes/your-child-theme.broken/functions.php

Fix the reported line (missing semicolon, unclosed quote, stray BOM, or a botched add_action callback). Only then move the folder back and reactivate.

Step 5 — Verify templates

wp theme list --status=active
curl -I https://your-domain.example

When to call Fixwebnode: The broken code is minified, ionCube-encoded, or spread across many templates; admin also whites out after theme switch; or a “helper” plugin wrote the bad PHP. Use the same Fitzroy white-screen bug-fixing path linked above for structured core/theme repair.

Issue 4 — Core file damage or malware-driven fatal

Goal: prove whether WordPress core matches upstream, strip obvious drop-ins, and stop if you hit backdoors—do not half-clean a compromised site.

Step 1 — Integrity check with WP-CLI

wp core verify-checksums

Unexpected file modifications outside wp-content are a red flag. Also list drop-ins:

ls -la wp-content/ | egrep 'advanced-cache|object-cache|db.php|sunrise.php'
ls -la wp-content/mu-plugins 2>/dev/null

Step 2 — Reinstall core files only (does not delete wp-content)

wp core download --force
wp core verify-checksums

Step 3 — Look for PHP webshells and rogue admins (read-only first)

grep -R --include='*.php' -E 'eval\s*\(|base64_decode\s*\(|gzinflate\s*\(' wp-content/uploads 2>/dev/null | head
wp user list --role=administrator

Unknown administrators, recent mystery plugins, or encoded payloads in uploads mean this is no longer a simple WSOD DIY.

Step 4 — If the host offers malware scanning, run it and save the report

Do not mass-delete matches without a backup restore plan; deleting the wrong file can worsen fatals.

When to call Fixwebnode immediately: Checksums fail repeatedly, you find encoded malware, users you did not create, or WSOD returns after core reinstall. That is incident response, not a theme tweak—use Emergency WordPress Malware Removal & Security so backdoors, cron, and persistence are removed together and the white screen does not reappear after the next cache purge.

When DIY is enough vs when to book Fixwebnode

DIY is enough when: you have a current backup; logs name one plugin or one theme file; renaming that component restores HTML; core checksums pass; and no unknown admins or webshells appear. Document what you changed, clear caches (plugin, host, CDN), and re-test checkout/forms.

Book Fixwebnode when: both front end and admin stay white after plugins and theme quarantine; fatals sit inside core or must-use loaders; memory raises do nothing; WooCommerce or membership data is at risk; or malware indicators show up. Direct specialist handling beats stacked temporary hacks—especially when multiple failure modes stack (for example a hacked site that also exhausts memory).

Geography is straightforward: check coverage on the All service areas page if you need region-aligned help; remote recovery still follows the same emergency fixer workflow for WSOD.

After recovery, harden once so you are not back here next week: keep PHP on a supported version, limit admin users, disable file editing (define('DISALLOW_FILE_EDIT', true);), schedule off-host backups, and update plugins individually rather than in blind bulk batches on production.

Get the white screen fixed—talk to Fixwebnode

If you have already tried safe isolation and the page is still blank—or you would rather not risk the database and payment flows—start a conversation with Fixwebnode. Bring your host login method, the approximate time the WSOD began, and any debug.log fatals you captured.

Request direct help through WordPress Support and outline that you need White Screen of Death emergency recovery. We will pick up from the failed layer—plugin, theme, core, or malware—and work toward a stable, bootable site without marketplace bidding or generic freelancing detours.