How to Find Which Plugin Is Breaking Your WordPress Site

When a site breaks after an update, people tend to guess at the culprit based on which plugin "feels" related. That is usually wrong, because conflicts happen between plugins that seem unrelated — a caching plugin and a form plugin, a translation plugin and a page builder.

The conflict test is boring and takes ten minutes, but it produces a definite answer.

The basic test

1. Deactivate all plugins. Select all in Plugins → Installed Plugins and choose Bulk actions → Deactivate.
2. Check whether the problem is gone. If it is not, plugins are not the cause — move on to the theme.
3. Reactivate plugins one at a time, checking the problem after each.
4. The plugin that brings the problem back is your culprit.

Two details matter. Reactivate one at a time, not in groups — a group tells you which group, which is not much of an answer. And test the specific broken thing each time, not just whether the home page loads.

When you cannot log in

Do it from the filesystem instead. Over SFTP, rename wp-content/plugins to wp-content/plugins-off. WordPress deactivates everything because it can no longer find any of it. Log in, rename the folder back, and you will find all plugins deactivated but still installed — now reactivate them one at a time from the dashboard.

When you cannot take the live site down

Three options, in order of preference:

• Staging. Clone the site, test there, apply the fix to production. Always the right answer if available.
• A health-check plugin with troubleshooting mode. The official Health Check & Troubleshooting plugin disables plugins for your session only — visitors see the site untouched while you test. This is the single most useful tool for this job on a live site.
• Off-peak testing. A last resort. Announce it, keep it short.

Narrow it down before you start

You can often skip most of the test:

• Read the debug log. With WP_DEBUG_LOG on, a fatal error names the file, which names the plugin. That is the whole answer in one line.
• Check the browser console. A JavaScript error naming a plugin's script points straight at it — this is how most "the editor will not save" and "the slider does not move" problems resolve.
• Ask what changed. Which plugin updated most recently? Start there.
• Look for duplicated function. Two caching plugins, two SEO plugins or two security plugins will conflict. Run one of each.

Once you have found it

Do not just leave it deactivated if you need what it does:

1. Check whether an update is available — the conflict may already be fixed.
2. Read the plugin's support forum. Someone else has almost certainly reported it, often with a workaround.
3. Report it, with specifics: WordPress version, PHP version, the other plugin, and the exact error.
4. If it is abandoned — no update in two years, unanswered support threads — replace it. That is a maintenance decision, not a failure.

Reducing how often this happens

• Run fewer plugins. Every one is a dependency you did not write.
• Prefer actively maintained ones with a recent "tested up to" version.
• Update on staging first.
• Update in small batches so you always know what changed.
• Avoid two plugins doing the same job.