White Screen or 500 After an Update: 10-Minute Diagnosis

Symptoms and Fast Location Commands

A white screen (WSOD) means PHP died before sending HTML; a 500 is the server’s generic wrapper for the same crash. Do not guess. First, find where logs live. On Nginx with PHP-FPM in 2026 the common paths are /var/log/nginx/error.log and /var/log/php8.3-fpm.log (adjust for PHP 8.2/8.4 depending on your stack). On cPanel or Plesk, use the dashboard’s “Errors” icon or ~/logs/.

Tail the log while you reload the broken page in another tab:

sudo tail -f /var/log/nginx/error.log /var/log/php8.3-fpm.log

If you have WP-CLI 2.11 or newer installed, enable debugging without editing files by running wp config set WP_DEBUG true --raw and wp config set WP_DEBUG_LOG true --raw, then reproduce the error and run wp shell or simply read wp-content/debug.log. Turn WP_DEBUG back to false after diagnosis.

The 10-Minute Triage Process

1. Read the error log and note the fatal error file and line number.
2. Disable all plugins by renaming the plugins directory.
3. Switch the active theme to a default theme such as Twenty Twenty-Six.
4. Restore file permissions and replace corrupted core files.
5. Re-enable plugins one by one and watch the log after each activation.
6. Verify the front end loads and the log stays clean for five minutes.

1. Read Logs Before Guessing

Never start renaming things before you read the log. The log tells you whether the crash is a PHP fatal (memory, undefined function, class not found), a database connection error, or a permission denied on a file include. In 2026 most managed hosts expose logs via SSH or a control panel; if you are on a plain VPS, confirm your PHP version with php -v because log paths embed the version.

How to read the fatal

A typical PHP 8.3 fatal looks like PHP Fatal error: Uncaught Error: Call to undefined function my_old_hook() in /var/www/html/wp-content/plugins/bad-plugin/bad-plugin.php:42. The path after “in” is your culprit. If the path is inside wp-content/themes/your-theme/, the theme is at fault. If it is inside wp-includes/ or wp-admin/, core files are corrupted.

Enable WordPress-level logging

If the server log is empty, force WordPress to talk. Add these above the /* That's all, stop editing! */ line in wp-config.php:

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

Then reload the page and read wp-content/debug.log. Common pitfall: leaving WP_DEBUG_DISPLAY true on a live site leaks paths to visitors; always set it false. Rollback: delete those three lines or set them back to false when done.

For teams that need guaranteed response times when this happens in production, see our Website Downtime Emergency Response: 2026 Vendor Guide, which documents escalation paths for exactly this failure mode.

2. Disable Plugins by Directory

When the log points to a plugin, or even when it does not, the fastest way to rule out plugin conflicts is to rename the whole plugins directory. WordPress will then find no plugins and fall back to no active plugins, which usually clears WSOD.

The command

Over SSH, from the site root:

mv wp-content/plugins wp-content/plugins_off
mkdir wp-content/plugins

Reload the front end. If it loads, a plugin was the cause. To find which one, move them back in batches:

mv wp-content/plugins_off/akismet wp-content/plugins/ && tail -5 /var/log/php8.3-fpm.log

Repeat per plugin. Pitfall: some plugins store cache in wp-content/plugins_off/ paths written into the database; if a specific plugin’s options break the site even when inactive, clear its options via wp option delete plugin_settings with WP-CLI. Rollback: rename plugins back to plugins_off and plugins_off back to plugins to restore the original state.

If you lack SSH, use your host’s file manager to rename the folder, or use Custom WordPress Development support to script this safely on your stack.

3. Switch to a Default Theme

If disabling plugins changes nothing, the active theme is the next suspect. In 2026 the bundled default is Twenty Twenty-Six. You cannot use the admin dashboard if the screen is white, so switch via database or filesystem.

Via WP-CLI (preferred)

wp theme list
wp theme activate twentytwentysix

Via direct SQL

If WP-CLI is unavailable, use mysql:

UPDATE wp_options SET option_value = 'twentytwentysix' WHERE option_name = 'template' OR option_name = 'stylesheet';

Also rename the theme folder to force fallback: mv wp-content/themes/your-child wp-content/themes/your-child_off. WordPress will then use the default. Verify by loading the homepage; you should see the Twenty Twenty-Six layout. Pitfall: if you use a child theme, both template (parent) and stylesheet (child) must be updated, or you get a broken hybrid. Rollback: reverse the UPDATE with the original theme slug from a backup, or rename the folder back.

Teams planning structural changes often pair this step with the checklist in our WordPress Site Migration Process: Vendor Guide 2026 to avoid repeat outages.

4. Restoring Permissions and Files

Update scripts sometimes write files as root or leave wrong ownership, causing 500s from permission denied. Standard WordPress ownership on Ubuntu 2026 is www-data:www-data (or your PHP-FPM user). Fix recursively:

chown -R www-data:www-data /var/www/html
find /var/www/html -type d -exec chmod 755 {} ;
find /var/www/html -type f -exec chmod 644 {} ;
chmod 600 /var/www/html/wp-config.php

If core files are missing or truncated, replace them without touching your content. Download the same version you updated to from wordpress.org, unzip, and copy only wp-admin and wp-includes:

rsync -av wordpress/wp-admin/ /var/www/html/wp-admin/
rsync -av wordpress/wp-includes/ /var/www/html/wp-includes/

Do not overwrite wp-content or wp-config.php. Verify with wp core verify-checksums (WP-CLI 2.11+); it reports “Success: WordPress installation verifies against checksums” when correct. Pitfall: chmod 777 is never the answer and creates security holes. Rollback: you cannot easily “un-restore” core, so keep the downloaded clean copy aside and diff with diff -r if something looks off.

For agencies standardizing this step, the maintenance playbook in Choosing WordPress Website Maintenance Services in 2026 covers permission baselines per host.

Frequently asked questions

Why did I get a white screen right after updating a plugin?

The updated plugin likely called a function removed in your PHP version or conflicted with another active plugin. The error log names the file and line; disabling the plugins directory confirms it within two minutes.

Can I fix this without SSH access?

Yes. Use your host’s file manager to rename wp-content/plugins, edit wp-config.php to enable WP_DEBUG_LOG, and use phpMyAdmin to run the theme-switch SQL above.

How do I know the repair is complete?

Load the site in a private window with the default theme and zero plugins; then reactivate one plugin at a time and tail the log. Clean rendering plus no new fatals for five minutes means done.

Action Checklist

• Tail PHP and Nginx logs to capture the exact fatal error path.
• Rename wp-content/plugins to isolate plugin conflicts.
• Activate Twenty Twenty-Six via WP-CLI or SQL.
• Reset ownership to www-data and permissions to 755/644.
• Replace core wp-admin and wp-includes from a clean download and run wp core verify-checksums.

Need this handled by engineers who do it daily? Explore our WordPress development services for update-safe builds and rapid recovery. More guides await in the technical articles index.

References & further reading

• WordPress Developer Documentation
• WordPress Theme Handbook
• WordPress Plugin Handbook