Category: Troubleshooting

A white screen is a page that returned nothing. The server answered, the browser has a document, and the document is empty. No theme, no error, sometimes not even a login form.

That silence is the problem. WordPress suppresses PHP error output in production, so when a plugin, a theme or your own code throws a fatal error, execution stops before any HTML is printed. You get a blank page instead of the line that names the file. WordPress’s Advanced Administration Handbook lists the White Screen of Death first among common WordPress errors, which tells you how routine this is.

On modern installs you will often see “There has been a critical error on this website” instead of pure white. Same condition, friendlier wording. The recovery sequence below is identical, and it overlaps heavily with fixing plugins that stopped working.

What the scope of the blank page already tells you

Before you rename anything, work out exactly where the white screen appears and where it does not. This is free information and it removes most of the suspect list.

What is blank	Look here first
Front end and admin, everywhere	Code that loads on every request: a plugin, the theme’s functions.php, an mu-plugin, an edit to wp-config.php, memory exhaustion, a PHP version change
Admin blank, front end fine	Admin-only plugins: security suites, capability and role managers, admin UI customisers, page builders. Also memory pressure on heavy admin screens
Front end blank, admin fine	Theme templates, or a cache layer serving a stored blank response to logged-out visitors while you bypass it
One page or one template	That template file (front-page.php, home.php), a broken shortcode, or a builder, SEO or cache plugin acting on that content
One admin screen only	The plugin that owns that screen. A role-management plugin white-screening the Users page is a real reported case
The block editor only	An editor integration. Open the browser network tab and look for failing /wp-json/ requests
Only for logged-out users or only on mobile	Caching plugin, host cache, CDN or reverse proxy

Write one line before you touch anything: what is blank, when it started, what changed immediately before. “Front end loads, /wp-admin is white since the plugin auto-update last night” is a diagnosis. “Site is broken” is not.

Check for the recovery mode email first

Since WordPress 5.2, a fatal error puts the site into recovery mode instead of leaving you locked out. WordPress emails the administration address with a link that pauses the plugin or theme that failed and lets you into wp-admin for that session. The subject looks like “[your site name] Your Site is Experiencing a Technical Issue”, and the message usually names the extension. Core’s fatal error recovery mode announcement describes this as the answer to exactly the case where the backend would otherwise be unreachable.

Most people never see it. The address in Settings then General is an old inbox, the site’s outbound mail is broken, or it landed in spam. Check spam, check the address, and set RECOVERY_MODE_EMAIL in wp-config.php to something someone reads before you need it.

One thing to hold on to: recovery mode pauses, it does not fix. Reactivating the same broken version puts the white screen straight back.

Turn on logging before you change anything

This is the step people skip, and it is the one that ends the outage fastest. Edit wp-config.php over SFTP or the host’s file manager, above the line that says “That’s all, stop editing”, and set:

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

WordPress’s debugging handbook documents this combination: errors go to wp-content/debug.log rather than to the page, which matters because visitors should not be reading your file paths. If a WP_DEBUG line already exists set to false, change that line rather than adding a second one.

Reload the blank page to reproduce the error, then open debug.log and read the end of it. Also open the host’s own PHP error log in cPanel, Plesk or the hosting dashboard and search near the bottom for “fatal error”. WordPress’s log does not capture everything: PHP-FPM failures, permission problems and server-level errors only show up there.

Two cautions. Editing wp-config.php in a plain text editor with a missing semicolon creates a second fatal error on top of the first, so keep an untouched copy of the original. And turn these lines off once you are done.

The file path in the error is the answer

Fatal errors are ugly but specific. What you are looking for is the path, not the wording:

PHP Fatal error: Uncaught Error: Call to undefined function ... in /wp-content/plugins/plugin-name/...
PHP Parse error: syntax error, unexpected ... in /wp-content/themes/theme-name/functions.php
PHP Fatal error: Uncaught Error: Class '...' not found
require(): Failed opening required '...' in /wp-content/mu-plugins/...
Fatal error: Allowed memory size of 134217728 bytes exhausted

A path under /wp-content/plugins/ names the plugin. A path under /wp-content/themes/ points at the theme or child theme, usually at code someone added to functions.php. A path under /wp-content/mu-plugins/ is a must-use plugin failing to load, which happens before normal plugins load and confuses people who have already deactivated everything. A path in wp-config.php is your own edit. And 134217728 bytes is 128M, so that last line is a resource limit, not a bug in the file it names.

Plugins: the most reported cause, and how to isolate one

Practitioner consensus across support forums and agency runbooks puts plugins first by a wide margin, usually within minutes of an update or a new activation. There is no measured dataset behind that ranking, but every source type reports the same order.

If the log named a plugin, act on that one. If you have no usable log and no admin access, isolate at the filesystem level over SFTP or the file manager:

1. Write down the currently active plugins if you can, or run wp plugin list over SSH. You need to be able to put the site back the way it was.
2. Rename the single suspect folder, for example wp-content/plugins/plugin-slug to plugin-slug-off. WordPress deactivates a plugin whose files have gone.
3. No obvious suspect? Rename wp-content/plugins to plugins.old, create an empty plugins folder, and move the plugins back one at a time, reloading the site after each.
4. When the white screen returns, the plugin you just moved back is the one.

With SSH available, wp plugin deactivate <slug> does the same thing without leaving renamed directories behind, and it is the cleaner option for an admin-only white screen.

Two traps. Deleting a plugin instead of renaming its folder can take its settings with it. And on a WooCommerce site, deactivating WooCommerce itself clears the white screen while breaking cart, checkout and account pages, so isolate the extensions around it, payment gateways and shipping plugins first, rather than the store.

Once you know which plugin, the fix is a version decision: update it if a newer release fixes the fatal, roll it back to the previous version if the update caused it, or replace it if it has been abandoned. Leaving it paused is not a fix.

Themes: a syntax error in functions.php takes the whole site

Themes are the second most reported cause, and a hand-edited functions.php is the usual route. One missing semicolon typed into the built-in Theme File Editor on a live site produces a site-wide blank page and, because the editor is inside wp-admin, locks you out of the tool you used to break it.

Rename the active theme folder in wp-content/themes/. WordPress falls back to a default theme such as Twenty Twenty-Five, provided one is actually installed. If it is not, you will trade the white screen for a “theme directory does not exist” error, so check first. If the site returns on the default theme, the fault is in your theme files: revert the recent edit, restore from a backup of that file, or reinstall the theme. Keeping changes in a child theme and out of the live editor is what stops the repeat, and the same discipline applies when you are editing WordPress themes without losing work.

Memory exhaustion: a real cause and an over-applied fix

“Allowed memory size of X bytes exhausted” is the one white screen that tells you its own cause, when logging is on. The process died before printing anything, which is why it is often a pure blank rather than a critical error page. Typical triggers are imports, backups and restores, security scans, image processing and heavy page builders.

The fix in wp-config.php:

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

Three things people get wrong here. The M matters: '512' without it is not 512 megabytes. WP_MEMORY_LIMIT cannot exceed the host’s global PHP limit, so setting 512M on a plan capped at 128M changes nothing and you will wrongly conclude memory was not the issue. And raising the limit without finding out what consumed the memory just moves the failure to the next import. Community advice is consistent that 256MB is enough for an ordinary WordPress site, so a site that needs more has a specific consumer worth identifying.

PHP version changes, .htaccess and leftover update files

If the blank page appeared the day the host moved you from PHP 7.4 to 8.x, the code stopped being compatible, not the server. The fast recovery is rolling PHP back in the hosting control panel. The actual fix is updating core, plugins and themes for compatibility, testing on staging, then upgrading PHP again. Sitting on an old PHP version indefinitely trades one outage for a worse one later.

Where the white screen followed a migration, a restore or an interrupted update, look at files rather than code:

• A leftover .maintenance file in the WordPress root keeps the site in update mode. Delete it and reload.
• A broken .htaccess can stop requests reaching WordPress. Rename it to .htaccess-old, test, and if that fixed it regenerate the rules by opening Settings then Permalinks and saving once admin access is back. Do not rewrite custom rules you do not understand; stores and membership plugins depend on them.
• A failed core update can leave mismatched files. Re-uploading fresh core files from WordPress.org, excluding wp-content and wp-config.php, resolves that. Do this when there is evidence of corruption, not as a first move.

Fixed it and still seeing white? Clear every cache layer

A broken response gets cached like any other. The fix ships, you see the site, and visitors still get a blank page. Purge in this order: the caching plugin, the host’s page cache, the object cache, the CDN, then the browser. Clearing only your browser cache is the classic false negative.

On WooCommerce, caching the cart, checkout and account pages produces partial white screens and stale data even when nothing else is wrong. Confirm those exclusions are in place.

When to stop and get help

Escalate rather than keep testing when:

• You cannot get error output from either WordPress or the server.
• Renaming the whole plugins directory did not bring the site back, which points at core, the theme, an mu-plugin or the environment.
• The trigger was outside WordPress: a PHP upgrade, a database change, a host migration, altered file ownership.
• The same white screen returns after you reverse the change you believed caused it.
• The site earns money and you have a clean backup. Restoring and diagnosing afterwards on a copy beats a long live investigation.

Hand over the useful evidence: the scope line, the last confirmed change, what you already tested, and the first fatal error line from the log. If you would rather not work through folders and logs yourself, SiteSelf can run the same sequence on a connected site and report what it changed and what it checked, which is what getting a broken WordPress site working again looks like when you ask for it in chat; file-level and code work needs hosting access, not just the connector plugin.

What keeps it from coming back

Most repeat white screens come from the habits that produced the first one. Update risky extensions one at a time so the timeline stays readable. Take a backup before updates and check it restores. Point RECOVERY_MODE_EMAIL at a monitored inbox. Keep PHP edits out of the built-in Theme and Plugin File Editors on live sites. Replace plugins that have not been updated in six months rather than hoping. And know your host’s real PHP memory ceiling before the day you need it.

Frequently asked questions

Is a white screen a sign my site was hacked?

Usually not. Plugin conflicts, theme code, memory limits, failed updates and PHP version changes account for the overwhelming majority of reported cases. Malware is worth scanning for when the white screen keeps returning after a clean fix or when you find files you did not put there, but diagnose the ordinary causes first.

Why is only /wp-admin white while the front end works?

Something that runs only on admin requests is failing: a security plugin, a capability or role manager, an admin UI customiser, or a page builder’s backend. It can also be memory pressure on a heavy admin screen. Isolate from SFTP or WP-CLI, since you cannot reach the Plugins screen to do it in the dashboard.

Does a white screen damage my search rankings?

No data quantifies the impact, and short outages are not the same as a site disappearing. What you can do is check what Googlebot actually received: run the live test in Search Console’s URL Inspection tool on an affected URL once the site is back, and confirm it renders content rather than an empty page.

Do I need to reinstall WordPress?

Only when you have evidence of corrupted core files, such as a fatal error pointing at a file inside wp-includes or a core update that failed partway. Re-uploading fresh core files excluding wp-content and wp-config.php is safe, but it is not a diagnosis and it will not fix a plugin fatal.

The white screen appeared right after a core update. What now?

Treat it as a compatibility problem between the new core version and one extension, not as a broken update. Caching plugins are a recurring culprit in support threads after core releases. Isolate plugins as above, then check whether the vendor has shipped a compatible version before you roll anything back.

Can I just deactivate everything and be done?

It restores the site, and it costs you the information. Renaming the whole plugins directory tells you “a plugin did it” without telling you which one, and it leaves plugins the site depends on switched off. Record the active list, then re-enable one at a time until the screen goes white again.

A plugin that stopped working rarely stopped on its own. Something changed first: the plugin updated, WordPress core updated, the host moved you to a newer PHP version, someone added a caching rule, someone pasted a snippet into a theme file. The plugin is where the failure shows up. It is often not where the failure started.

That is why the first move is not deactivation. It is a two-minute pass to record what changed and what exactly is broken. If the break started right after an edit to functions.php, for example, the edit is your prime suspect, and there are safer ways to make theme changes that survive the next update. If it started right after a Tuesday morning update run, you already have a short list.

Write down what changed before you touch anything

Four things, in a note, before you start clicking:

• The last change on the site: plugin update, core update, theme switch, PHP version change, new caching or security rule.
• The exact failing surface: which page, which action, front end or admin, logged in or logged out, checkout or contact form.
• Whether it fails in a private window too. If it works there, you are looking at a cache or a logged-in-only difference, not a broken plugin.
• Whether WordPress has already told you. Open Plugins → Installed Plugins and look for a plugin marked as paused with a notice that it was deactivated because of a fatal error. That notice names the file that crashed. People miss it constantly.

Then read the logs rather than guessing. WordPress’s debugging handbook documents WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY in wp-config.php. On a live site, turn logging on and display off, then read wp-content/debug.log and the server error log. A PHP failure leaves a file path pointing at the plugin or theme that caused it. A cache problem leaves no error at all, which is itself a clue.

The causes, roughly in the order they happen

A conflict introduced by an update

This is the most common one, and the trigger is usually an update that ran in the last day or two. Two plugins touch the same hook, one ships a new script that collides with another, or a plugin and the theme both try to control the same template. WooCommerce’s own self-service guide names the same three suspects for store problems: outdated software on the site, a conflict with the theme, and a conflict with another plugin.

Repeat offenders in practitioner reports are the big ones, because they are the ones doing the most work: WooCommerce on major versions that run database migrations, and Elementor plus its add-on packs, where an add-on lags a version behind the builder.

A cache serving the old version

The most under-diagnosed layer by a distance. You fix the problem, the page still looks broken, so you assume the fix failed and change something else. Clear the caching plugin, the host cache and the CDN, in that order, then retest in a private window. While you are debugging, switch off minification, deferred JavaScript, critical CSS and Cloudflare Rocket Loader. Combining and deferring scripts is exactly the sort of thing that hides a plugin’s JavaScript from logged-out visitors while it works fine for you.

The signature to recognise: it works when you are logged in and fails when you are not. That is almost always stale cached output, not a plugin bug.

The plugin works, the template has nowhere to put it

A plugin can be installed, active, licensed and running correctly while showing nothing on the page, because the theme template does not include the area or hook it renders into. This comes up constantly in WooCommerce and page-builder setups, where a custom product template replaced the standard one and dropped the hook the plugin attaches to.

Before you start a conflict test, ask the cheap question: does this plugin’s output have anywhere to appear? Switching to a default theme for thirty seconds answers it.

PHP version, memory, or a snippet with a typo

Three different problems that produce similar-looking breakage. Plugin code that does not run on the site’s PHP version. Memory exhaustion on a small hosting plan carrying WooCommerce plus a page builder plus a security scanner. Or a snippet copied off a blog into functions.php with a missing semicolon.

The errors are distinctive enough to sort quickly:

• Parse error: syntax error, unexpected ... points at a code edit, usually the most recent one.
• Fatal error: Allowed memory size of X bytes exhausted is a resource limit, not a bug.
• Fatal error: Uncaught Error: Call to undefined function ... or Class '...' not found usually means a version mismatch or a half-installed plugin.

An update that stopped halfway

An auto-update that timed out leaves a plugin with a mix of old and new files. Symptoms include a site stuck on “Briefly unavailable for scheduled maintenance”, or database errors such as Table 'wp_xxx' doesn't exist and Unknown column ... in 'field list' after a plugin that migrates its own tables was interrupted mid-migration.

For the maintenance message, WordPress.org’s troubleshooting FAQ covers the fix: delete the .maintenance file in the site root. For a half-finished migration, restore the pre-update database backup. Re-running the update on a half-migrated database tends to make it worse.

The isolation test, run so the answer means something

Everyone knows the method. Most people run it in a way that cannot produce a reliable answer. The rule is one change, one test, on the exact surface that failed.

1. Take a backup. The test is only aggressive enough to be useful if you can undo it.
2. Deactivate all plugins. Test the failing action, not the homepage. If it still fails, plugins are not your cause and you can move to the theme.
3. Reactivate one plugin. Clear the cache. Test again. Repeat, one at a time. Reactivating in batches to save time destroys the only thing the test produces.
4. If plugins come back clean, switch to a default theme such as Twenty Twenty-Five and retest. Users blame plugins for theme faults more often than the reverse.
5. Open the browser console on the failing page and look for TypeError: ... is not a function or ReferenceError: ... is not defined. A JavaScript error names the file that failed to load.

On a live site you do not want to take the public offline while you do this. The Health Check & Troubleshooting plugin, published by WordPress.org, adds a troubleshooting mode that disables plugins for your session only, so visitors keep seeing the normal site. One honest caveat: its directory listing currently carries a notice that it has not been tested with the last three major WordPress releases, so read that before installing it on a store.

Two more cheap checks that solve a surprising share of cases. Resave Settings → Permalinks, which flushes rewrite rules and fixes plugin endpoints returning 404 or 500 after an update. And for any premium or connected plugin, confirm the licence is valid and the site can reach the vendor’s servers, because a plugin that cannot phone home fails silently and looks like a conflict.

Getting back in when wp-admin is gone

If a fatal error has taken the dashboard with it, stop trying to log in. Recovery happens at the file level, through SFTP, SSH or the host’s file manager.

Rename the folder of the plugin you suspect, from plugin-name to plugin-name.off. WordPress cannot load it, so it deactivates, and the settings in the database stay intact. If you do not know which one, rename the whole wp-content/plugins directory to plugins.deactivate to force everything off. WordPress.org’s troubleshooting FAQ documents this as the way to deactivate all plugins without admin access. Once you are back in, rename the folder back and reactivate one at a time.

Being able to log in again is a milestone, not a finished job. The site is now running without the plugins it needs, and the thing that caused the crash is still there. Do the isolation pass before you call it fixed, and retest the exact admin screen or checkout step that broke rather than the homepage.

Update, roll back, replace, or remove

Once you know which plugin is at fault, the next step is a judgment call, not more testing.

What you are looking at	The usual answer
Maintained plugin, a newer version fixes the reported bug	Update, on staging first if you have one
Broke the moment it updated, previous version was stable	Roll back and wait for the vendor patch
Files look corrupt or an update was interrupted	Reinstall the same version so the files match
Not updated in years, not tested with recent WordPress, fails on PHP 8	Replace it with something maintained
Known vulnerability, no patch, feature is business-critical	Remove it and solve the need another way

Rollback is a normal first response, not a last resort. WP Rollback, by Devin Walker, restores any plugin or theme from the WordPress.org directory to a previous version through the familiar updater flow, so you do not have to hunt for an old zip. It only works if you did not delete the plugin, which is the argument for diagnosing before deleting.

On the “replace it” line, check the plugin’s directory page for the last-updated date and the “tested up to” version before you reinstall hope. Patchstack publishes an annual State of WordPress Security whitepaper analysing the previous year’s vulnerability data, and the pattern it tracks is a plugin ecosystem problem more than a core one. An abandoned plugin is a maintenance decision, not a bug report.

The fixes that make it worse

• Reactivating in batches. Saves five minutes, costs you the answer.
• Deleting the plugin before diagnosing. You lose its configuration and the clean rollback.
• Setting permissions to 777. It is a security risk, many hardened hosts refuse it anyway, and it rarely was the problem. WordPress’s hardening handbook has a file permissions section worth reading instead.
• Leaving WP_DEBUG_DISPLAY on in production. It prints file paths and stack traces to visitors.
• Downgrading PHP permanently. It hides the incompatibility and drops you off security support. Use it as a bridge for a day, not a policy.
• Editing plugin or parent-theme files in place. The next update overwrites your fix and the bug comes back with no record of why.

When to stop and hand it over

Three signals that the cheap path has run out: the conflict reappears after a clean isolation pass, the failure involves custom code or a bespoke integration, or the breakage is in the database rather than the files. At that point you are choosing between a long evening and someone with server access.

That is the shape of work SiteSelf handles: you describe the symptom through chat, the agent reads the logs on the connected site, runs the isolation, applies the fix, then fetches the page and reports what it changed and what it checked. Content and settings work needs the SiteSelf Connector plugin; reading logs, renaming folders and rolling back files needs hosting access over SSH. More on handing WordPress troubleshooting to an agent, including what it refuses, such as pages owned by a visual page builder.

Frequently asked questions

Why does the plugin work for me but not for logged-out visitors?

Almost always cached output. Logged-in users usually bypass page cache, so you see the current version while visitors get the stored one. Clear the caching plugin, the host cache and the CDN, then test in a private window with minification and deferred JavaScript switched off.

Should I deactivate plugins first or switch the theme first?

Plugins first, because conflicts between plugins are the more frequent cause and the test is faster. But always run the default theme test before you conclude a plugin is guilty. A theme that overrides a template or throws an error in functions.php produces symptoms that look identical to a plugin bug.

Do I need to delete and reinstall the plugin?

Reinstalling the same version helps when the files are corrupt or an update was interrupted, and it keeps your settings because those live in the database. Deleting is different: it can remove configuration and it takes away the clean rollback. Diagnose first, delete last.

Why does it work on staging but not on live?

Look at what differs between the two environments rather than at the plugin. The usual differences are cache and CDN layers that only exist on live, a different PHP version, plugin or theme versions that drifted apart, a premium licence tied to the live domain, and firewall or IP rules that block outbound calls from one environment.

Is raising the PHP memory limit a real fix?

Sometimes. A one-off increase is reasonable when a heavy task such as an import or a security scan exhausts memory. Repeated exhaustion during ordinary page loads means the plugin stack is too heavy for the plan, and raising the number again just moves the failure. Reduce the stack or move to hosting sized for it.

What details should I give the plugin developer?

WordPress version, PHP version, the plugin version, the active theme, the full list of active plugins, the exact steps that reproduce the failure, and the relevant lines from debug.log. Check the changelog and support forum first, because version-specific breakages are often already reported with a workaround.