wordpress white screen of death (wsod)
all you see is a blank white page. it is almost always a fatal php error from a plugin, theme, or memory limit. four fix paths.
the white screen of death is wordpress shorthand for 'php hit a fatal error and the server returned nothing'. the page is blank because php errors are suppressed by default in production. enabling debug logging immediately tells you what broke. it is almost always one of three things: a plugin that crashed after an update, a theme function that broke after a php version bump, or the memory limit being hit while loading too many plugins at once.
what this looks like to a visitor
- front page or wp-admin shows a blank white screen
- happened after updating a plugin or theme
- happened after migrating hosts or wordpress versions
- site shows nothing but the page source has html
what a public browser check can see
we hit the homepage and report status code + body. wsod often returns 500 with an empty body, sometimes 200 with empty body — both are diagnosable from outside.
we look at the raw html. if the response is empty, that is one class of wsod. if the html shell is partial (ends mid-tag), that is a php fatal error after some output.
x-powered-by, server, and link headers tell us the php version, hosting setup, sometimes the wp version. all useful for narrowing the fix.
wp-content/cache/ may be writing a broken cache that returns blank. .htaccess corruption causes blank responses. all of these have signatures the public check can spot.
we do not log into your site. we do not scrape customer data. we open your public homepage in a real browser session and report what we see. no security claims unless we can prove them from the public surface.
the deeper picture
the four common causes: (1) plugin fatal after update. you ran updates, one plugin's new version is incompatible with another plugin or with your php version. fix: rename the plugin folder via sftp to disable it, then update or replace. (2) theme function broken. customised themes that use deprecated wordpress functions break when wp core removes those functions. fix: switch to a stock theme temporarily, identify the bad function, patch the theme file. (3) memory limit hit. your php install has 64mb but wordpress is loading 30 plugins. fix: bump memory in wp-config.php and php.ini. (4) corrupted .htaccess. after a migration or a plugin's broken rewrite rule. fix: rename .htaccess and let wordpress regenerate it from settings → permalinks.
fix it yourself
step 1: enable wp_debug in wp-config.php (define('WP_DEBUG', true); define('WP_DEBUG_LOG', true);). this writes errors to wp-content/debug.log instead of suppressing them. step 2: read the log, find the fatal error, identify the plugin or theme file. step 3: rename the offending plugin's folder via sftp (this disables it). step 4: bump the php memory limit (define('WP_MEMORY_LIMIT', '256M');). step 5: if you cannot get into wp-admin to start with, do steps 3 and 4 via sftp directly. test again after each change.
run the audit on YOUR site — check for "wordpress white screen of death (wsod)"
we open your homepage in a real headless browser and report what we see. no login, no plugin install.
public browser check · no signup · result on the next page
or pay us once.
you can fix all four if you have sftp/ssh access and willing to dig in. the debug log makes it tractable. if you are locked out of wp-admin and not comfortable with sftp, or this is your business site bleeding orders, the $149 emergency fix path: we get the site back online same-day (usually within 2 hours), identify the root cause, document it, set up a staging-environment recommendation so the next update does not blow up production. done in hours, not days.
frequently asked
showing php errors on the public site leaks internals (file paths, plugin internals, sometimes credentials). debug should be on while diagnosing, off in production. always.
rarely, but yes — malicious code injected into a theme function can throw fatals. if the wsod started without any update on your part, that is a flag to scan for compromise. covered in the $149 fix.
wp 5.2+ has fatal error recovery — wordpress detects the crash, emails the admin a recovery link. it works if your sending mail works. if it does not (and silent contact-form failures are the most common reason it does not), you fall back to manual sftp recovery.
if the backup is recent (yesterday) and you can identify what changed since, restoring is fast. if you do not have backups, fix forward — restoring an old wordpress on a current php version often just creates a new wsod.
other fix guides
- why is my wordpress site slow— what an external browser sees when your wordpress homepage takes too long to render — and the four things that are almost always behind it.
- shopify checkout feels broken — how to find out why— a public browser check of your shopify storefront can surface the visible reasons people abandon. here is what we look for.
- contact form looks fine but i'm not getting emails— this is the most common silent failure mode of small-business websites. four reasons it usually is — and how a public check can rule out the wrong ones.
- wix site not showing on google — what a public check can tell you— your wix site exists, but it does not appear in google search results. four reasons that explain almost every case.
built by vøiddo — a small studio shipping ai-flavoured products, free dev tools, chrome extensions and weird browser games. legal · support@voiddo.com