Every WordPress support thread ends up at the same advice: "Deactivate all your plugins, then turn them back on one by one until it breaks."

It works. It is also slow, and on a live site it is risky. With 30 plugins you can be toggling for an hour while real visitors watch the site break and un-break. And there is one kind of bug it can miss completely.

This post covers a faster method you can do by hand, and the case that one-by-one testing gets wrong.

The problem with one-by-one

One-by-one testing is a linear search. With 30 plugins, the worst case is 30 rounds of "turn one on, reload, check."

Each round is not just a click. You reload the page, maybe clear a cache, maybe go through checkout again. Multiply that by 30.

Halve the suspects instead

Binary search is the same idea as the "guess my number" game. Every test should cut the list of suspects in half.

  1. Write down your active plugins. Make a backup first.
  2. Turn off half of them.
  3. Check the problem.
    • Problem gone? The culprit is in the half you turned off.
    • Problem still there? The culprit is in the half that is still on.
  4. Throw away the innocent half. Repeat with the suspects that are left.

With 30 plugins, the suspects go 30 → 15 → 8 → 4 → 2 → 1. That is about five tests instead of up to thirty.

A few practical tips:

  • Keep a written list. After the third round it is very easy to lose track of which plugins are "on" for which reason.
  • Test the same thing every time. Same page, same steps, same logged-in or logged-out state. If the bug only shows at checkout, go through checkout every round.
  • Clear caches between rounds. A page cache can show you the old result and send you down the wrong half.
  • Leave dependencies together. If an add-on needs its parent plugin (a WooCommerce extension needs WooCommerce), turn them off and on as a group.

The case one-by-one testing misses

Sometimes no single plugin is broken. Plugin A works alone. Plugin B works alone. Turn both on and checkout fails.

Look at what one-by-one testing does here. You turn everything off, then turn plugins back on one at a time. The site only breaks when the second plugin of the pair comes back. So you blame that plugin, report a bug to its author, and they cannot reproduce it, because it only fails next to the other one.

Plain binary search can trip on this too. Split the plugins in half and the pair may land on different sides. Then both halves work on their own, but the full set breaks. That result is the clue.

When you see "half A alone works, half B alone works, all together breaks," you know the culprit is a pair split across the two halves. To find it:

  1. Keep half A fully on. Binary-search half B (turn half of B off, check, and so on). The plugin in B that brings the problem back is the first member of the pair.
  2. Now keep that one plugin from B on. Binary-search half A the same way. That finds the second member.

It is still a handful of tests, and you end up with the real answer: "A and B conflict," not "B is broken."

Doing this on a live site

All of the above assumes you can switch plugins off. On a real store, every round means customers might see a broken checkout, missing features, or a broken layout.

The usual options:

  • A staging copy. The safest choice, if you have one and it really matches production (same PHP version, same plugin versions).
  • The Health Check & Troubleshooting plugin. Its troubleshooting mode disables plugins only for your session, so visitors keep the normal site. You still choose which plugins to enable yourself.
  • Recovery mode. For fatal errors, WordPress emails the admin a link to log in with the broken plugin paused.

I built a small open-source plugin, Culprit Finder, that runs the binary search above for you (disclosure: I'm the author). It switches plugins off only for your own logged-in browser, so visitors, search engines and other admins keep seeing the full site, and the active plugin list never changes. You answer "is the problem still there?" and it picks the next half. For a 30-plugin site that is usually around 7 answers, and it also catches two-plugin conflicts like the one above. When it is done, it gives you a plain-text report you can paste into a plugin's support forum.

It has exits in case something goes wrong: an Exit button, an emergency link that works even when you are logged out, and it stops by itself after 60 idle minutes (3 hours max). It is free, GPL, and makes no external requests. It cannot test your theme, must-use plugins, drop-ins, or server settings, so if the problem survives with every plugin off, look there next.

Summary

  • Don't toggle 30 plugins one at a time. Halve the suspects each round.
  • If both halves work alone but the full set breaks, you have a two-plugin conflict. Search one half while keeping the other on.
  • Report conflicts as pairs. "B breaks only when A is active" is a bug report a developer can act on.
  • On a live site, test in a way that does not change what visitors see.

What is the worst plugin conflict you have had to track down? I'm collecting real cases for the next post.