How to Find a WordPress Plugin Conflict on a Fan Site

Your fan site worked fine last night, and this morning the tier list page is blank, the menu has stopped opening on mobile, or the editor spins forever. Nine times out of ten the cause is a WordPress plugin conflict: two plugins, or a plugin and your theme, trying to do the same job in incompatible ways.

The good news is that finding the culprit is a methodical job, not a guessing game. I have walked volunteer admins through this process on guild sites with 40 plugins and on tiny wikis with six, and the same steps work on both.

Signs you have a WordPress plugin conflict

Conflicts rarely announce themselves by name. They show up as symptoms that look like something else entirely:

A white screen or the message "There has been a critical error on this website."
A page builder or the block editor that loads but will not save.
Sliders, tabs, spoiler toggles or lightboxes that stop responding to clicks.
Layout that breaks only on certain pages, often the ones using a specific shortcode.
Problems that started right after an update, even if you only updated one thing.

That last point matters most. Write down what changed in the past 48 hours, including automatic updates. WordPress lists recent plugin updates on the Updates screen, and many hosts keep an activity log in their control panel.

Before you touch anything, make a safe copy

Deactivating plugins on a live site is usually harmless, but some plugins delete their settings when switched off, and a few security plugins lock you out if they misbehave. Take a fresh backup first. If you are not sure your current backups would actually restore, our guide to backing up a WordPress site the right way covers what to check.

Better still, test on a copy. Many hosts offer one click staging, which clones the site to a private address where you can switch things off freely. If your host does not, a free plugin such as WP Staging can create one in about 10 minutes on a site under 1 GB.

Step by step: finding the plugin that breaks things

The classic method is to deactivate everything and switch plugins back on one at a time. It works, but on a site with 30 plugins it can take an hour. A faster approach is to split the list in half.

Turn on debugging. In wp-config.php, set WP_DEBUG and WP_DEBUG_LOG to true, just above the line that says "That's all, stop editing." Errors will be written to wp-content/debug.log. Often the log names the exact plugin folder, and you are done in two minutes.
Use Health Check troubleshooting mode. The free Health Check and Troubleshooting plugin lets you disable all plugins and switch to a default theme for your own login only. Visitors keep seeing the normal site while you test.
Confirm the problem disappears. With everything off and a default theme like Twenty Twenty-Four active, reload the broken page. If it works, you have a conflict. If it still fails, the issue is in WordPress core, your server or the database.
Bring back your theme alone. If the bug returns with only your theme active, the theme is the problem, not a plugin.
Enable half the plugins. If the bug returns, the culprit is in that half. If not, it is in the other half. Keep halving. With 32 plugins you will find it in five rounds.
Find its partner. Once you have one suspect, enable it alongside each remaining plugin to see which combination breaks. Conflicts need two parties.

If you cannot reach the dashboard at all, rename the wp-content/plugins folder over FTP or your host's file manager. WordPress will deactivate everything, and you can rename it back and test plugins one by one by renaming their individual folders.

Check the browser console too

Front end conflicts, like a menu that will not open, are often JavaScript errors. Open your browser's developer tools with F12, go to the Console tab and reload. A red line mentioning a file inside /wp-content/plugins/name-of-plugin/ tells you where to look. Two plugins loading different versions of the same script library, such as two copies of a slider script, is a very common cause.

Why "just delete the newest plugin" is bad advice

You will see forum replies telling people to remove whatever they installed or updated last. It sounds sensible, but it points at the wrong plugin surprisingly often.

The plugin that changed is the trigger, not always the fault. If a caching or optimisation plugin combines scripts and an update to your spoiler plugin adds a new script, the optimiser may be the one handling it badly. Delete the spoiler plugin and the symptom goes, but so does a feature your readers use, and the real problem returns with the next plugin that adds a script. I have seen admins on a Destiny clan site remove three perfectly good plugins in a month before anyone checked the minify settings.

Caching deserves special suspicion. If the bug appears only for logged out visitors, clear every cache layer, including the plugin, the host and any CDN, before testing anything else. Our article on why caching plugins hide your own updates explains how stale files fool you during testing.

Fixing the conflict once you find it

Finding the pair is half the job. You then have a few options, roughly in order of preference:

Option	When to use it	Effort
Update both plugins	One is behind on version	2 minutes
Change a setting	Optimiser or lazy load is involved	10 minutes
Report to the developer	Both are current and still clash	Wait a few days
Roll back one plugin	A recent update caused it	5 minutes with a rollback plugin
Replace one plugin	The developer is unresponsive	An evening

When you report a conflict, include your WordPress version, PHP version, both plugin versions and the exact error from debug.log. Developers fix detailed reports far faster than "your plugin broke my site."

Finally, turn WP_DEBUG back off. Leaving it on can print file paths to visitors, which is not something a public site should show.

Frequently asked questions

How do I know if a plugin is causing a problem in WordPress?

Switch every plugin off, or use Health Check troubleshooting mode, and see whether the problem disappears. If it does, a plugin is involved. Turn them back on in halves until the problem returns, and you will narrow it down to one.

Can two plugins that do different things still conflict?

Yes. A gallery plugin and a security plugin have nothing in common on paper, but both may load the same script library or hook into the same part of the page. Conflicts are about shared code and timing, not shared features.

Will deactivating a plugin delete its settings?

Usually not. Most plugins keep their settings when deactivated and only remove data when you delete them, and some never clean up at all. A few do wipe options on deactivation, so take a backup before testing on a live site.