How to Find Which WordPress Plugin Is Causing a Problem

Your WordPress site was fine yesterday. Today it’s showing a white screen, a broken layout, or some feature that just stopped working. Nine times out of ten, a plugin did it, and a WordPress plugin conflict is one of the most common reasons a working site suddenly breaks after an update. The good news is that finding the culprit doesn’t require guesswork or a developer on retainer, just a methodical process you can run in about 15 minutes.

After 10+ years building WordPress sites and running 950+ Fiverr client projects, plugin conflicts are one of the most frequent “my site is broken” messages that come in. This guide walks through exactly how to isolate the plugin causing the problem, without breaking anything further in the process.

What Causes a WordPress Plugin Conflict?

A WordPress plugin conflict happens when two plugins try to use the same function, script, or database resource in incompatible ways, or when a plugin update introduces code that isn’t compatible with the current WordPress or PHP version. The result is usually a white screen, a fatal error message, a broken layout, or a feature that silently stops working. It’s rarely one plugin being “bad” on its own; it’s usually two pieces of code stepping on each other.

The most common triggers are outdated plugins that haven’t been tested against the latest WordPress core update, two plugins loading the same JavaScript library in conflicting versions, and plugins that both try to modify the same database table or hook into the same action at the same priority. According to WPBeginner, business websites commonly run 20 to 30 plugins at once, and that volume is exactly why isolating a single conflicting plugin gets harder as a site grows.

How Do You Know If a Plugin Is Causing the Problem?

You know a plugin is causing the problem if deactivating all plugins fixes the issue, and reactivating them one at a time brings the problem back the moment you switch on the culprit. This is the single most reliable diagnostic test in WordPress, and it works whether the symptom is a white screen, a JavaScript error, or a layout that’s suddenly falling apart.

Timing is the other big clue. If the site broke right after a plugin update, a theme update, or installing something new, that’s almost always where the conflict started. Check the WordPress dashboard under Plugins to see the “Recently Active” list, since it shows what changed most recently even if you don’t remember doing it yourself.

The Safest Way to Find a Conflicting Plugin

The deactivate-and-reactivate method is the safest and most direct way to find a conflicting plugin: turn every plugin off, confirm the site works again, then turn plugins back on one at a time until the problem reappears. Before touching anything, take a full backup, since undoing a bad change is much easier with a fresh restore point available.

1. Back up the site fully, including the database, before deactivating anything.
2. Go to Plugins in the WordPress dashboard, select all plugins, and choose Deactivate from the Bulk Actions dropdown.
3. Reload the site’s front end. If the problem is gone, the cause was a plugin, not the theme or a server issue.
4. Reactivate plugins one at a time, starting with the ones installed or updated most recently, reloading the site after each one.
5. The moment the problem comes back, the plugin you just reactivated is the conflicting one.
6. Check that plugin’s changelog for known issues, update it if an update is available, or replace it with an alternative if the conflict persists.

This method is disruptive on a live site since visitors will see the site with no plugins running while you test. For a site that gets real traffic, running this same process on a staging copy first is worth the extra ten minutes, and it avoids showing a broken checkout or missing forms to actual visitors.

Using Health Check & Troubleshooting Mode Without Affecting Visitors

The free Health Check & Troubleshooting plugin lets you test for a plugin conflict without affecting anyone browsing the live site. It creates a troubleshooting mode that’s only active for the logged-in admin running the test, switching to a default theme and disabling plugins in that private session while every regular visitor keeps seeing the site exactly as it normally looks.

Install Health Check & Troubleshooting from the WordPress plugin directory, activate it, and open the new Tools > Site Health > Troubleshooting tab. From there, enable troubleshooting mode and reactivate plugins one by one exactly like the manual method, just without the downtime risk. This is the better option for any site that can’t afford to look broken for even a few minutes.

What to Do When You Can’t Access wp-admin

When a plugin conflict blocks access to wp-admin entirely, the fix is to rename the plugins folder using FTP or your host’s File Manager, which force-deactivates every plugin at once. WordPress treats a renamed plugins folder as missing, so it automatically switches every plugin off and the dashboard should load again.

Connect via FTP or your hosting File Manager, navigate to wp-content, and rename the plugins folder to something like plugins-disabled. Once the dashboard loads again, rename the folder back to plugins, then reactivate plugins individually from inside wp-admin using the same one-at-a-time approach described above. This is also the fastest fix for a WordPress critical error when a plugin is the cause.

Why Does My WordPress Site Show a White Screen After Updating a Plugin?

A white screen after a plugin update usually means the update pushed the site’s memory usage past the PHP memory limit, or introduced a fatal PHP error that WordPress can’t recover from on its own. The screen stays blank because WordPress has nothing safe to display once a fatal error interrupts the page from loading.

Turning on debug mode makes the real error visible instead of a blank page. Add these two lines to wp-config.php above the line that says “That’s all, stop editing”:

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

The error message and the file it points to almost always name the plugin responsible directly. Check the log at wp-content/debug.log, find the plugin folder named in the error, and deactivate that plugin specifically rather than guessing. Turn debug mode back off once the issue is resolved, since leaving it on exposes error details to anyone who can view the page source.

How to Prevent Plugin Conflicts Before They Happen

The most effective way to prevent plugin conflicts is to update plugins on a staging site first and confirm nothing breaks before pushing the same update to the live site. Staging environments exist for exactly this reason, and most managed WordPress hosts now include one-click staging as a standard feature.

• Keep the total plugin count as low as realistically possible, and remove any plugin that’s inactive rather than leaving it installed.
• Update plugins one at a time on staging rather than bulk-updating everything at once, so a broken update is easy to trace.
• Avoid plugins that haven’t been updated in over a year, since compatibility with current WordPress versions is the first thing to break.
• Take a full backup before any update, so a conflict is a five-minute restore instead of an emergency.

A solid WordPress backup plugin makes this whole process lower-stakes, since a bad update becomes a quick rollback instead of a scramble. Pair that with a habit of never bulk-updating everything at once, and most plugin conflicts get caught on staging before a single visitor sees them.

A plugin conflict is rarely a mystery once you isolate it correctly, it just takes a systematic process instead of randomly deactivating things and hoping. Use the Health Check plugin for a live site with real traffic, use the manual method on a low-traffic or staging site, and always check the debug log before assuming which plugin is guilty. The same deactivate-and-test logic also applies to diagnosing a stubborn WordPress 404 error that started after a plugin update.

Frequently Asked Questions