When something breaks on a WordPress site and you don’t know which plugin caused it, the fastest safe method is WordPress core’s own Troubleshooting Mode (via the Health Check plugin), which disables every plugin and switches to a default theme for your logged-in session only — live visitors keep seeing the normal site the entire time. From there you reactivate plugins one at a time until the error comes back, which tells you exactly which one is responsible.
Why This Beats Just Deactivating Plugins
The obvious instinct — deactivate plugins directly from the Plugins screen until the problem goes away — takes the live site down for every visitor while you’re testing, not just for you. Troubleshooting Mode solves that: it creates a session-scoped version of the site with plugins off and the default theme active, visible only to the admin who enabled it. Everyone else continues browsing the real site, unaffected, while you diagnose.
The Process
- Back up the site first. Always, before touching anything, even a diagnostic step that’s supposed to be safe.
- Install Health Check & Troubleshooting (or use Site Health’s built-in Troubleshooting tab if your WordPress version includes it) and enable Troubleshooting Mode.
- Confirm the error is gone in your troubleshooting session with everything disabled. If it’s still there, the cause isn’t a plugin conflict at all — check the theme or a core issue instead.
- Reactivate plugins one at a time, refreshing after each, until the error reappears. The plugin you just turned on is the culprit — or at least one of them, if it’s an interaction between two.
- Check Query Monitor’s PHP errors panel alongside this process for a more specific stack trace pointing at the exact file and function.
When It’s Actually Two Plugins Interacting
| Symptom | Likely cause |
|---|---|
| Error appears only after reactivating a specific plugin | That plugin alone is the cause |
| Error only appears once several plugins are back on, not right after any single one | A conflict between two plugins — often both hooking the same action/filter |
| Error disappears with all plugins off but reappears with the theme back too | Theme and plugin interaction — check for a shared function name or hook priority clash |
Preventing the Next One
Plugin conflicts are far more likely when updates go straight to production untested. Testing every plugin update on staging first, and having a documented process for what to check before an update, closes off most of these issues before they ever reach visitors. We cover that process in How to Audit WordPress Plugins Safely and Plugin Compatibility Testing: A Better Way to Prevent Site Breaks.
If you’re stuck on a conflict you can’t isolate, get in touch.
Frequently Asked Questions
Will Troubleshooting Mode affect what visitors see on my site?
No — it only changes what you see in your own logged-in browser session. Everyone else continues to see the site exactly as it normally appears, plugins and theme included.
What if the error is still there with every plugin disabled?
Then it’s not a plugin conflict — check the active theme next, and if that’s also not it, the issue is more likely a core WordPress, hosting, or server-level problem.
Is there a faster way than reactivating plugins one at a time?
You can reactivate in batches (say, half at a time) to narrow the range faster, then switch to one-at-a-time once you’ve isolated a smaller group — useful on sites with a large number of active plugins.
Featured image: original illustration.