Why the order matters

Most WordPress troubleshooting guides are a list of things to try: clear the cache, deactivate plugins, switch themes, increase the memory limit, contact your host. All of those are reasonable. The trouble is the order people try them in, which is usually whatever the first search result said.

Picture someone deactivating all 34 plugins on a live WooCommerce store at 3 p.m. on a Friday. The checkout breaks for real customers, the original bug is still there (it was in the theme), and now there are two problems. That’s how a one-problem afternoon becomes a two-problem weekend, and it’s why this guide is a sequence rather than a list.

A note on this post: the 2024 version was titled “11 WordPress troubleshooting techniques” and then listed twelve. That gives you a fair idea of how carefully it was put together. This is a rewrite from scratch.

The troubleshooting steps

Before you start. You need a fresh backup, wp-admin access or hosting file access (the file manager or SFTP), and ideally a staging copy of the site. If the site makes money, do Steps 5 and 6 on staging, not live.

Step 1: Write down the symptom exactly.
Note the exact error text, the URL where it happens, whether it happens logged in or logged out, which browser, and roughly when it started. “The site is broken” can’t be fixed. “The cart page shows a critical error for logged-out visitors since Tuesday” usually can.

Step 2: Find out what changed.
Ask what was updated, installed, or edited in the last 48 hours: plugins, the theme, WordPress core, PHP version, hosting plan, DNS, or a code snippet someone pasted into functions.php. Check the site admin’s inbox for WordPress auto-update emails, which list what was updated and when. Very often the answer to the whole problem is in this step.

Step 3: Turn on the debug log.
Open wp-config.php in the site root, find the line that sets WP_DEBUG, and replace it with these three lines. They write errors to a log file without showing them to visitors.

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

When this works, nothing visible changes on the site. That’s correct.

Step 4: Reproduce the problem.
Load the page or repeat the action that breaks, once or twice. This writes the error into the log.

Step 5: Read the log.
Open wp-content/debug.log. Read the newest lines at the bottom first. Look for PHP Fatal error or PHP Warning, then look at the file path in that line. A path containing /wp-content/plugins/plugin-name/ points at that plugin, and /wp-content/themes/theme-name/ points at the theme. Note the plugin or theme name, because Step 6 uses it.

Step 6: Isolate the cause.
If you can reach wp-admin, deactivate only the plugin named in the log, then retest. If you can’t reach wp-admin, use the recovery mode link that WordPress emails to the site admin after a fatal error (see the WordPress recovery mode documentation), or rename that plugin’s folder in wp-content/plugins using the file manager. Our post on the white screen after a plugin update walks through the folder rename in detail.

Step 7: If the log names nothing, test with plugins off for your session only.
The Health Check & Troubleshooting plugin has a Troubleshooting Mode that disables all plugins and switches to a default theme for your logged-in user only, until you turn it off or log out. Re-enable plugins one at a time inside that mode until the problem returns. (Its last update was about two years ago, so I’d run it on staging rather than on a live store.)

Step 8: Check the server.
If the problem survives with every plugin off and a default theme on, it isn’t WordPress code. Check the hosting error log, the PHP version in the hosting panel, the PHP memory limit, and the disk space. A full disk breaks uploads, caching, and database writes in ways that look like a dozen different bugs.

Step 9: Turn debugging off again.
Set WP_DEBUG back to false in wp-config.php, then delete wp-content/debug.log. The log can contain file paths and other details that are useful to attackers, and on many servers anyone can download it by URL. The WordPress debugging documentation also recommends against leaving debug tools on in production.

Check. The original symptom from Step 1 is gone, logged in and logged out, and debug.log no longer exists.

Common symptoms and where to look first

That last row is a long story of its own, and we wrote it up as a read-only audit case study on a slow WordPress admin.

Using AI to read the log, carefully

This part didn’t exist in 2024, and it’s genuinely useful. Pasting the last 30 or so lines of debug.log into an AI assistant and asking “which plugin is causing this, and what does the error mean?” gets you a plain-English explanation of a stack trace faster than any forum thread will. It’s very good at that.

Two cautions, though. First, read what you paste. A debug log can contain server paths, email addresses, and occasionally a database error that includes a query with customer data in it. Strip those out first. Second, don’t let the assistant’s fix go straight into the live site. A snippet from a chatbot, pasted into functions.php, is one of the easiest ways to cause the exact fatal error this guide started with. A function name that clashes with one the theme already declares is enough to take the site down.

There’s a better pattern for AI on a WordPress site, and it’s read-only. An AI agent that can look at the plugin list, versions, cron jobs, and autoloaded options, but can’t change anything, can do most of Step 2 and part of Step 8 (the PHP version and memory limits) without any risk. That’s why we built Auditra, our read-only WordPress inspection tool, the way we did.

When to stop and call someone

Some problems are a bad idea to fix yourself, however good the guide is. Stop and get help if any of these are true:

• You see files, admin users, or redirects that nobody on your team created, because that points to a compromise rather than a bug.
• The database connection error persists after the host confirms the database server is running.
• The checkout or payment flow is broken on a live store and customers are affected right now.
• Nobody can find a recent backup, so any change you make can’t be undone.
• The debug log is empty, the server logs are empty, and the problem is still there.

Checklist

• Take a fresh backup before changing anything.
• Write the symptom down exactly, including the URL and whether you’re logged in.
• List everything that changed in the last 48 hours.
• Turn on the debug log with display off, reproduce the problem, and read the newest lines.
• Deactivate only the plugin or theme the log names.
• Use per-user troubleshooting on staging when the log names nothing.
• Check the server’s error log, PHP version, memory, and disk space.
• Turn debugging off and delete debug.log when you’re done.

FAQ

That’s the order we follow. If yours is different and it works, I’d honestly like to hear it in the comments.

Addendum: checking your site the 2026 way

Added October 2026. We first wrote this guide in 2024, and the steps above still hold. What’s changed is how much of the looking you can hand to an AI assistant without giving it the keys. Before you start deactivating anything, try one of these two free tools we built. Both are read-only, so neither can change your site.

• Auditra is a WordPress plugin that lets Claude or any MCP-compatible AI assistant inspect your plugins, known vulnerabilities, cron jobs, and autoloaded data, and then explain what it finds in plain English.
• The WordPress Security Audit skill is a Claude skill that checks plugin and theme versions against vulnerability databases, core files, wp-config settings, and signs of malware, which is the right first move when a bug might really be a hack.

Run either one before Step 6 and you’ll usually know which plugin to look at before you touch a single setting.

The post WordPress Troubleshooting: How to Find and Fix the Bug, in the Right Order first appeared on Macronimous Blog.

A white screen right after a plugin update is almost always that plugin throwing a PHP fatal error. The fix is to deactivate it without going through wp-admin (which you can’t reach anyway): click the recovery mode link WordPress emailed you, or rename the plugin’s folder over FTP. The site comes back. Then you decide what to do about the plugin.

So your site is a blank white page, wp-admin is a blank white page too, and the last thing you did was click Update on a plugin. I’m going to assume that’s you, because that’s who searches for this. You did not break anything permanent, and this is roughly a ten-minute job if you have hosting-panel or FTP access (or can get it from whoever set the site up).

Make sure it’s actually the plugin

It usually is. But “usually” has cost people an afternoon, so spend two minutes checking.

Look in the site admin’s inbox for an email from WordPress with a subject like “Your Site is Experiencing a Technical Issue.” WordPress has sent these since version 5.2 (that’s 2019, so unless your site is a museum piece, you have it). The email names the plugin that failed and includes a special login link. If it names the plugin you just updated, you’re done diagnosing. Skip to the fix.

No email? Check spam, then check the hosting error log. cPanel calls it “Errors”; on Hostinger it’s under the site’s PHP settings; on InMotion it’s a file called error_log sitting in your site root or in wp-admin. You’re looking for a line that starts with PHP Fatal error and contains a path with /wp-content/plugins/ in it. The folder name after that is your culprit.

If the log points at /wp-content/themes/ instead, it’s the theme (same fix, rename the theme folder). If it says “Allowed memory size exhausted,” the update tipped a tight PHP memory limit over the edge, and raising it in wp-config.php fixes that. Those are the other two suspects. This post is about the plugin case, which is by far the most common as far as I can tell from the tickets that reach us.

The fix, three ways, easiest first

Pick the first one you can do. You don’t need all three.

Way 1: the recovery mode link

This is the one WordPress built for exactly this situation, and almost nobody uses it, which I think is because the email goes to whatever address was typed into Settings, General back when the site was built, which was often the developer’s address, or a mailbox that was created for the launch and never opened again, so the link sits there unread while the owner is on a forum reading about FTP.

• Find the “technical issue” email and click the recovery mode link. It’s valid for 24 hours by default, so don’t sit on it.
• Log in as normal. You’ll see a “Recovery Mode Initialized” notice, and the broken plugin will be listed as paused.
• Go to Plugins, deactivate the paused one, then click “Exit Recovery Mode” in the admin bar.

The WordPress.org recovery mode page has screenshots if the admin screen looks unfamiliar.

Way 2: rename the plugin folder

No email, or the link expired. This is what I’d do anyway; it takes a minute and it’s hard to get wrong.

• Open your hosting file manager (cPanel, hPanel, whatever your host calls it) or connect with an FTP client like FileZilla.
• Go to wp-content/plugins/ and find the folder named after the plugin. It’s usually obvious: woocommerce, elementor, wordfence.
• Rename it. Add -off to the end, so elementor becomes elementor-off. Reload the site.

WordPress can’t find the plugin’s main file anymore, so it quietly deactivates it and carries on. Your site is back. Once you’ve sorted the plugin out, rename the folder back and reactivate.

Way 3: WP-CLI

Only if you have SSH access and that sentence made sense to you. If it did:

cd /path/to/your/wordpress   # the folder that contains wp-config.php
wp plugin list --status=active
wp plugin deactivate the-plugin-slug

It’s back. Don’t walk away yet.

Clear every cache you have, in this order: the caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache), then the hosting cache (most managed hosts have a purge button in the panel), then Cloudflare if the site runs through it. Skip this and you’ll get a call in an hour from someone still seeing the white page while you’re looking at a working site. Been there.

Then click three things. The homepage. One inner page that matters, a product page or a services page. The contact form, and actually send it. A site that renders but can’t take an inquiry is still down as far as your business is concerned.

Now the plugin. You have three options, and I’d rank them like this:

1. Roll it back to the version that worked. The WP Rollback plugin does this from the Plugins screen for anything on WordPress.org. For a premium plugin, download the previous version from the vendor’s account area and upload it over FTP.
2. Leave it deactivated and wait. If the update broke you, it broke a few hundred other people too, and there’s often a patch within days.
3. Replace it. If this is the second or third time the same plugin has done this, that’s your answer.

When you shouldn’t do this yourself

This is the part I’d rather write honestly than write well. Everything above assumes a simple case: one plugin, one update, one error. Some white screens aren’t simple, and the DIY route makes them worse.

The last one is a different problem wearing the same symptom. Renaming a plugin folder won’t help, and poking around in the file system while a site is compromised can destroy the evidence someone needs to clean it properly. That’s a security cleanup, not a maintenance job, and it’s the one case where I’d say close the FTP window and pick up the phone.

On the WooCommerce one, I’ll admit I’m more cautious than most Reddit answers. A store that stays white for twenty more minutes while a developer checks the order tables is cheaper than a store that comes back with a broken checkout nobody notices until Monday.

So it doesn’t happen again

Three habits. Nothing clever. Test the update on a staging copy first; most hosts give you one for free now. Take a backup right before you click Update, not the nightly one from twelve hours ago. And update one plugin at a time, so when something breaks you know which one did it. That’s the whole prevention plan.

Quick questions

The post WordPress White Screen After a Plugin Update: How to Fix It in 10 Minutes (and When Not To) first appeared on Macronimous Blog.

Why the order matters

Most WordPress troubleshooting guides are a list of things to try: clear the cache, deactivate plugins, switch themes, increase the memory limit, contact your host. All of those are reasonable. The trouble is the order people try them in, which is usually whatever the first search result said.

Picture someone deactivating all 34 plugins on a live WooCommerce store at 3 p.m. on a Friday. The checkout breaks for real customers, the original bug is still there (it was in the theme), and now there are two problems. That’s how a one-problem afternoon becomes a two-problem weekend, and it’s why this guide is a sequence rather than a list.

A note on this post: the 2024 version was titled “11 WordPress troubleshooting techniques” and then listed twelve. That gives you a fair idea of how carefully it was put together. This is a rewrite from scratch.

The troubleshooting steps

Before you start. You need a fresh backup, wp-admin access or hosting file access (the file manager or SFTP), and ideally a staging copy of the site. If the site makes money, do Steps 5 and 6 on staging, not live.

Step 1: Write down the symptom exactly.
Note the exact error text, the URL where it happens, whether it happens logged in or logged out, which browser, and roughly when it started. “The site is broken” can’t be fixed. “The cart page shows a critical error for logged-out visitors since Tuesday” usually can.

Step 2: Find out what changed.
Ask what was updated, installed, or edited in the last 48 hours: plugins, the theme, WordPress core, PHP version, hosting plan, DNS, or a code snippet someone pasted into functions.php. Check the site admin’s inbox for WordPress auto-update emails, which list what was updated and when. Very often the answer to the whole problem is in this step.

Step 3: Turn on the debug log.
Open wp-config.php in the site root, find the line that sets WP_DEBUG, and replace it with these three lines. They write errors to a log file without showing them to visitors.

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

When this works, nothing visible changes on the site. That’s correct.

Step 4: Reproduce the problem.
Load the page or repeat the action that breaks, once or twice. This writes the error into the log.

Step 5: Read the log.
Open wp-content/debug.log. Read the newest lines at the bottom first. Look for PHP Fatal error or PHP Warning, then look at the file path in that line. A path containing /wp-content/plugins/plugin-name/ points at that plugin, and /wp-content/themes/theme-name/ points at the theme. Note the plugin or theme name, because Step 6 uses it.

Step 6: Isolate the cause.
If you can reach wp-admin, deactivate only the plugin named in the log, then retest. If you can’t reach wp-admin, use the recovery mode link that WordPress emails to the site admin after a fatal error (see the WordPress recovery mode documentation), or rename that plugin’s folder in wp-content/plugins using the file manager. Our post on the white screen after a plugin update walks through the folder rename in detail.

Step 7: If the log names nothing, test with plugins off for your session only.
The Health Check & Troubleshooting plugin has a Troubleshooting Mode that disables all plugins and switches to a default theme for your logged-in user only, until you turn it off or log out. Re-enable plugins one at a time inside that mode until the problem returns. (Its last update was about two years ago, so I’d run it on staging rather than on a live store.)

Step 8: Check the server.
If the problem survives with every plugin off and a default theme on, it isn’t WordPress code. Check the hosting error log, the PHP version in the hosting panel, the PHP memory limit, and the disk space. A full disk breaks uploads, caching, and database writes in ways that look like a dozen different bugs.

Step 9: Turn debugging off again.
Set WP_DEBUG back to false in wp-config.php, then delete wp-content/debug.log. The log can contain file paths and other details that are useful to attackers, and on many servers anyone can download it by URL. The WordPress debugging documentation also recommends against leaving debug tools on in production.

Check. The original symptom from Step 1 is gone, logged in and logged out, and debug.log no longer exists.

Common symptoms and where to look first

That last row is a long story of its own, and we wrote it up as a read-only audit case study on a slow WordPress admin.

Using AI to read the log, carefully

This part didn’t exist in 2024, and it’s genuinely useful. Pasting the last 30 or so lines of debug.log into an AI assistant and asking “which plugin is causing this, and what does the error mean?” gets you a plain-English explanation of a stack trace faster than any forum thread will. It’s very good at that.

Two cautions, though. First, read what you paste. A debug log can contain server paths, email addresses, and occasionally a database error that includes a query with customer data in it. Strip those out first. Second, don’t let the assistant’s fix go straight into the live site. A snippet from a chatbot, pasted into functions.php, is one of the easiest ways to cause the exact fatal error this guide started with. A function name that clashes with one the theme already declares is enough to take the site down.

There’s a better pattern for AI on a WordPress site, and it’s read-only. An AI agent that can look at the plugin list, versions, cron jobs, and autoloaded options, but can’t change anything, can do most of Step 2 and part of Step 8 (the PHP version and memory limits) without any risk. That’s why we built Auditra, our read-only WordPress inspection tool, the way we did.

When to stop and call someone

Some problems are a bad idea to fix yourself, however good the guide is. Stop and get help if any of these are true:

• You see files, admin users, or redirects that nobody on your team created, because that points to a compromise rather than a bug.
• The database connection error persists after the host confirms the database server is running.
• The checkout or payment flow is broken on a live store and customers are affected right now.
• Nobody can find a recent backup, so any change you make can’t be undone.
• The debug log is empty, the server logs are empty, and the problem is still there.

Checklist

• Take a fresh backup before changing anything.
• Write the symptom down exactly, including the URL and whether you’re logged in.
• List everything that changed in the last 48 hours.
• Turn on the debug log with display off, reproduce the problem, and read the newest lines.
• Deactivate only the plugin or theme the log names.
• Use per-user troubleshooting on staging when the log names nothing.
• Check the server’s error log, PHP version, memory, and disk space.
• Turn debugging off and delete debug.log when you’re done.

FAQ

That’s the order we follow. If yours is different and it works, I’d honestly like to hear it in the comments.

Addendum: checking your site the 2026 way

Added October 2026. We first wrote this guide in 2024, and the steps above still hold. What’s changed is how much of the looking you can hand to an AI assistant without giving it the keys. Before you start deactivating anything, try one of these two free tools we built. Both are read-only, so neither can change your site.

• Auditra is a WordPress plugin that lets Claude or any MCP-compatible AI assistant inspect your plugins, known vulnerabilities, cron jobs, and autoloaded data, and then explain what it finds in plain English.
• The WordPress Security Audit skill is a Claude skill that checks plugin and theme versions against vulnerability databases, core files, wp-config settings, and signs of malware, which is the right first move when a bug might really be a hack.

Run either one before Step 6 and you’ll usually know which plugin to look at before you touch a single setting.

The post WordPress Troubleshooting: How to Find and Fix the Bug, in the Right Order first appeared on Macronimous Blog.