The standard advice is "deactivate all your plugins, then reactivate them one by one."
On a site nobody visits, fine. On a site taking orders, that advice means turning off your shopping cart, your forms, your caching, and your security plugin — during business hours — while you work through thirty reactivations.
There's a better way, and it's built into WordPress. Most people don't know it exists.
The short version
Best: test on staging, a copy of your live site. Zero risk.
Nearly as good: Health Check & Troubleshooting, which disables plugins for your session only — visitors keep seeing the working site.
Emergency only: rename the plugins folder via FTP. Takes the site's functionality down, but works when you're locked out.
And read the debug log first, because it often names the culprit outright and saves you the whole process.
Start with the log, not the testing
Before any method below, check whether WordPress has already told you the answer.
In wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reproduce the problem, then read /wp-content/debug.log. Fatal errors name the file:
PHP Fatal error: ... in /wp-content/plugins/some-plugin/includes/thing.php on line 214
That's your plugin. No testing required.
The log won't help with everything — a layout that's broken but not erroring, or two plugins loading conflicting scripts, may produce no PHP error at all. But it's thirty seconds and it frequently ends the investigation.
Method 1 — Staging (the right way)
A staging site is a copy of your live site on a separate URL where you can break things freely.
Most decent hosts include it free. Look for "Staging" in your hosting dashboard — SiteGround, Kinsta, WP Engine, Cloudways, and many others offer one-click creation. If yours doesn't, WP Staging and similar plugins create a local copy.
The process: create or refresh staging so it matches live, reproduce the problem there, then test freely. Deactivate everything, reactivate one at a time, break things — none of it touches your visitors or your revenue.
Once you've found it, apply the fix to live.
The one thing to watch: staging copies can drift from live. If your staging site is three months old, it doesn't have the same plugin versions and may not reproduce the problem. Refresh it before testing.
Never push staging to live after testing unless you know exactly what you're doing — that can overwrite orders, comments, and posts created since the copy was made.
Method 2 — Health Check & Troubleshooting
The best option when you don't have staging, and genuinely underused.
Health Check & Troubleshooting is a free plugin from the WordPress core contributors. Its troubleshooting mode disables all plugins and switches to a default theme for your logged-in session only. Every other visitor continues seeing the site exactly as it was.
How to use it:
- Install and activate Health Check & Troubleshooting from the plugin directory
- Go to Tools → Site Health → Troubleshooting
- Click Enable Troubleshooting Mode
- Your session now runs with everything disabled — check whether the problem persists
- Use the admin bar menu to re-enable plugins one at a time, checking after each
- When the problem returns, the last plugin you enabled is the culprit
- Disable Troubleshooting Mode when finished
Nothing is deactivated in the database, so no settings are lost and no visitor is affected. This is the method to use on any site with traffic.
Its limitation: it only tests the admin-side and front-end as you see it. Some conflicts only appear for logged-out visitors or under specific conditions. If troubleshooting mode shows no problem but visitors still report one, test in a private window or on staging instead.
Method 3 — FTP (when you're locked out)
If you can't reach wp-admin at all, this is the route back.
Rename /wp-content/plugins to plugins-off via FTP or your host's file manager. WordPress can't find the directory and deactivates everything.
If the site returns: rename the folder back to plugins. Your plugins remain deactivated in the database, so you can now log in and reactivate them one at a time from wp-admin.
To test individually without admin access: rename individual plugin folders one at a time — akismet to akismet-off — and check the site after each.
Important: this genuinely takes your site's functionality down while it's in effect. Use it when you have no alternative, and get back in quickly.
Does deactivating lose my settings?
Almost never, and the fear stops people testing when they should.
Plugin settings live in the database, not in the plugin files. Deactivating a plugin leaves its settings intact — reactivate and everything returns.
What does lose data: deleting a plugin. Many plugins remove their database tables and options on deletion, and some do it silently. Deactivate to test; only delete when you're sure.
The exception worth knowing: a few plugins run cleanup routines on deactivation, and some caching or security plugins leave configuration files behind that need manual removal. Rare, but worth a quick search for the specific plugin before deactivating something critical on a live site.
The two-plugin problem
Occasionally no single plugin is at fault.
You deactivate everything and the problem goes. You reactivate one at a time and it never comes back — until everything's on again, at which point it returns.
That's two plugins that work fine alone and conflict together. Usually both trying to modify the same thing: two SEO plugins writing meta tags, two caching layers, two form handlers loading incompatible jQuery versions.
How to find it: reactivate in pairs rather than singly. Or, faster, work by category — if you have two plugins doing similar jobs, test those together first. That's where the conflict almost always is.
And the underlying fix is usually to remove one of them. Two plugins doing the same job is a problem waiting to recur.
How many plugins is too many?
The wrong question, and it gets asked constantly.
Quality matters far more than count. Twenty well-coded, actively maintained plugins from reputable developers will outperform eight bloated ones that each load scripts on every page.
What actually matters:
Is each one maintained? No update in over a year is a break risk and a security risk.
Is each one used? Deactivated plugins sitting in your install are still files on your server. Delete what you don't use.
Are any duplicating each other? Two SEO plugins, two caching plugins, two security plugins — pick one.
What does each cost in performance? Query Monitor shows you which plugins are generating the slow queries and loading the most assets.
The honest heuristic: if you can't say what each plugin does and why it's there, you have too many — whatever the number is.
Frequently asked questions
How do I test plugins without breaking my live site?
Use a staging site if your host provides one — it's a full copy where you can break things freely. Otherwise install Health Check & Troubleshooting, whose troubleshooting mode disables plugins for your logged-in session only, leaving every visitor seeing the working site. Renaming the plugins folder via FTP works but genuinely takes functionality down, so save it for when you're locked out of wp-admin.
What is troubleshooting mode?
A feature of the free Health Check & Troubleshooting plugin that disables all plugins and switches to a default theme for your session alone. Visitors continue seeing the normal site. You then re-enable plugins one at a time from the admin bar until the problem reappears, which identifies the culprit. Nothing is deactivated in the database, so no settings are lost.
How many plugins is too many?
There's no number — quality and maintenance matter far more than count. Twenty well-coded, actively maintained plugins outperform eight bloated ones. What matters is whether each is maintained, whether each is actually used, whether any duplicate each other, and what each costs in performance. If you can't explain what a plugin does and why it's installed, that's the real signal.
What to do next
Enable WP_DEBUG_LOG and read the log before testing anything. It names the culprit often enough to be worth the thirty seconds.
If the log is silent, install Health Check & Troubleshooting. It's free, it's from the core team, and it lets you test on a live site without a single visitor noticing — which is exactly what the standard advice fails to offer.
Free: The WordPress maintenance checklist.
Related guides
- When WordPress breaks: a diagnostic order — the wider diagnostic
- Blank page after an update — when the timing points at an update
- WordPress plugin audit — reducing conflicts before they happen
- WordPress speed — when plugins are slowing you rather than breaking you
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
Transactional Email Services Compared for WordPress
Every one of these services will deliver your password resets. That's not the differentiator. What differs is setup difficulty, what the free tier covers, how good the logs are when something goes wrong, and — the one people never consider until it bites them — whether the service also handles marketing mail, and whether you […]
Contact Form Notifications Not Arriving: Every Cause
Here's the version of this problem that costs the most: it's been happening for months and you don't know. The form says "thank you." The visitor believes they've reached you. You believe nobody's been in touch. There's no error, no bounce, no alert — just an absence, and absences are invisible. Most of the time […]
WooCommerce Order Emails Going to Spam: The Fix
"I never got a confirmation. Did my order go through?" Every store owner gets this message. And when it arrives often enough, you stop treating it as customer confusion and start realising your receipts genuinely aren't landing. This costs more than most email problems, because a missing order confirmation doesn't just annoy someone — it […]