How to Find Which WordPress Plugin Is Causing a Problem

Fifteen-plus years of WordPress work has taught me “it’s probably a plugin conflict” is right more often than wrong, and that guessing which one almost never works. Our troubleshooting hub covers the short version; this is the method I run on a client site when that’s not enough. Deactivating things at random gets there eventually, but it wastes time and means troubleshooting in front of your client on a live site. Here’s the order I work in.

What should you check before deactivating a single plugin?

Read what’s already in front of you: the exact error text, the debug log, your browser’s console, and whatever changed on the site in the last day or two. Nine times out of ten, one of those four already points at a plugin by name. A “critical error” message and a blank white screen are different failure modes with different trails, and if you’ve read our guide to the WordPress critical error, you know its admin email often names the exact plugin file.

If nothing on the page tells you anything, turn on logging. Add these three lines to wp-config.php, above the line that says “That’s all, stop editing”:

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

WP_DEBUG_LOG only works once WP_DEBUG is on, and it writes to wp-content/debug.log. Reload the page, then check that file; the last few lines almost always name a plugin’s folder.

For anything visual, open your browser’s console (F12, then Console). A JavaScript error naming a plugin’s file is a plugin conflict; no error but a broken layout points more at CSS, usually a theme or caching issue. Last, check what changed, via the Updates screen or file timestamps over SFTP. A plugin that updated right before the break is your first suspect.

How do you test plugins without breaking the site for visitors?

Use a staging copy if you have one; nothing a visitor sees changes there. Without staging, use the free Health Check & Troubleshooting plugin’s troubleshooting mode: a clean session, plugins off and a default theme on, for your logged-in user only. Log out and it ends; visitors saw the normal site the entire time. Run the halving method below inside that session.

Source: Health Check & Troubleshooting plugin page, WordPress.org (checked 2026); WordPress.org developer documentation on debugging WordPress.

What’s the fastest way to narrow down the exact plugin?

Halve the list, don’t walk it one at a time. Deactivate half your plugins, test, then work only inside whichever half still has the problem, cutting it in half again each round until one plugin is left. One-at-a-time is fine on a five-plugin site, not one running 40 or 60; you could be on plugin 35 before you find it.

A round works like this: deactivate the first half of your plugin list, reload the broken page. Problem gone? The culprit is in the half you just switched off, so bring back a quarter and repeat. Still there? The culprit is in the half still active, so deactivate half of that and repeat.

Sixty plugins sounds like a long afternoon. With halving, it’s six tests.

What if the conflict has locked you out of wp-admin entirely?

You don’t need wp-admin to deactivate plugins. Over SFTP, rename wp-content/plugins to plugins_old. WordPress can’t find any of them, deactivates them all, and the site should load again; rename the folder back and every plugin returns to its previous state, nothing lost.

With SSH and WP-CLI, it’s cleaner and reversible one plugin at a time:

wp plugin deactivate --all
wp plugin list
wp plugin activate [plugin-slug]

The first line turns everything off, the second shows the full list with slugs so you’re not guessing at names, and the third reactivates one at a time, exactly like halving, from a terminal instead of a broken admin screen.

Once you’ve found the plugin, what’s actually conflicting?

Isolating “which plugin” only tells you half the story. Confirm whether it’s fighting another plugin, your theme, or your PHP version; that decides whether you update, roll back, replace, or hand it to the developer.

Plugin versus plugin. Reactivate the culprit alone. Fine on its own? Bring the rest back one at a time until it breaks again; that second plugin is the other half of the conflict.

Plugin versus theme. Switch to a default theme like Twenty Twenty-Four with the plugin active. Fine there but broken on your real theme means the theme needs the fix.

Plugin versus PHP version. Check the plugin’s “Requires PHP” line against your host’s actual version under Tools > Site Health. A plugin built for a newer PHP version fails in ways that look exactly like a plugin conflict but aren’t one.

What you do next follows from which it is: update if it’s behind, roll back if a fresh update broke it, replace it if it’s abandoned, or send the developer your debug log and reproduction steps if none of that clears it.

Could caching or minification be faking a plugin conflict?

Yes, often. A cached copy of a broken page, or a minifier combining scripts in the wrong order, can look exactly like a plugin conflict even after the real cause is already fixed, or when there was never a real conflict at all.

Clear every layer first: browser cache, server-side or plugin cache, any CDN, then retest in a private window. Problem gone for a logged-out visitor but not for you? Cache is the real variable, not a plugin. Most optimization plugins let you exclude specific scripts from combining or deferring, so exclude what broke instead of deactivating the plugin for good. Chasing this inside the Elementor editor itself is a different failure mode, covered in our guide to the Elementor editor not loading.

Symptom to likely conflict type, at a glance

A fast lookup once you’ve read the evidence. It won’t replace the isolation test, but it shows where to start it.

How do you stop plugin conflicts from happening as often?

Keep the plugin count down to what earns its place, update on a schedule instead of in one big batch, and test anything major off the live site first. Every plugin is one more thing that can fight another plugin, your theme, or your host’s PHP version, so audit what’s active periodically and remove what you can’t name a use for.

Some plugin conflicts are a five-minute fix once isolated. Others are a client site that keeps breaking on a stack nobody’s kept notes on. When that’s what you’re facing and nobody can pin down why, that’s exactly what our WordPress project rescue service is for: a senior developer diagnoses the real cause and fixes it.

If disabling plugins doesn’t explain the behavior and you’re seeing unfamiliar files or admin users, treat it as a security issue and follow our hacked WordPress site cleanup walkthrough.

Frequently asked questions