The standard advice — deactivate every plugin, then reactivate one at a time — works and it takes your live site down while you do it. On a busy site that is an outage, and on an ecommerce site it is lost orders.
There are two better options, and most people have never been told about the first: WordPress ships with a troubleshooting mode that deactivates plugins for you only, leaving visitors on the working site.
Use Site Health troubleshooting mode first
WordPress's Site Health tool, extended by the Health Check & Troubleshooting plugin, includes a troubleshooting mode that changes the whole calculation.
What it does: disables all plugins and switches to a default theme in your session only. Every visitor continues to see the live site, fully working, while you test against a clean install in the same browser.
Why it matters: it removes the reason people avoid this diagnosis. There is no outage, so there is no reason to postpone it or rush it.
How it works in practice: activate troubleshooting mode, confirm the problem disappears, then re-enable plugins one at a time from the admin bar menu until it returns. The one that brings it back is your conflict.
Its limitation: you need to be able to log in. If you cannot, use the folder-rename method below.
When you cannot log in: the folder rename
Over FTP or your host's file manager, rename wp-content/plugins to wp-content/plugins-off.
WordPress deactivates every plugin it cannot find, and your admin should return.
Three things worth knowing:
- Settings are not lost. Plugin settings live in the database, not the folder. Renaming back restores everything.
- Rename, never delete. Deleting loses the files and turns a five-minute diagnosis into a reinstall.
- Rename the folder back before reactivating. Then reactivate individually from the admin, which is now reachable.
The isolation method
Seven steps. The halving in step four is what turns twenty reactivations into five.
Step 1 — Write down the exact symptom
"Checkout is broken" is not testable. "Clicking Place Order returns a 500 and the order is not created" is. You need something you can reproduce on demand, or you cannot tell when it is fixed.
Step 2 — Take a backup
Files and database. Non-negotiable before touching a live site.
Step 3 — Confirm it is a plugin at all
Switch to a default theme first, in troubleshooting mode or by renaming the theme folder. If the problem persists with a default theme and all plugins off, it is not a plugin conflict — it is core, the server, or the database, and you should go back to when WordPress breaks.
Step 4 — Halve, do not walk
The step everyone skips. With all plugins off and the problem gone:
- Reactivate half of them. Test.
- Problem returns — the culprit is in that half. Halve that half.
- Problem absent — it is in the other half. Halve that instead.
Twenty plugins takes about five rounds this way and twenty rounds the other way. On a large site this is the difference between an afternoon and ten minutes.
Step 5 — Confirm the culprit properly
When one plugin brings the problem back, deactivate it alone and confirm the problem goes away with everything else on. A conflict is often between two plugins rather than one being broken, and this step tells you which situation you are in.
Step 6 — Establish which pair conflicts
If the plugin works alone but breaks with others active, reactivate the rest one at a time until it fails. You are looking for a pair, and both halves matter when you report it.
Step 7 — Report it usefully
With the pair identified, open a support thread on both plugins' pages. Include: WordPress version, PHP version, both plugin versions, the exact reproduction steps, and the fatal error line from wp-content/debug.log if there is one.
A report with a log line gets a fix. A report saying "your plugin breaks my site" gets a template reply.
Reading the log while you do it
Turn logging on before you start, so each test produces evidence rather than an impression. In wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Errors go to wp-content/debug.log and visitors see nothing. The file path in a fatal error usually contains the plugin's own folder name, which sometimes identifies the culprit before you have deactivated anything.
Turn it off afterwards. WordPress's guidance is that debug tools belong on local and staging installs.
What causes conflicts
Worth knowing, because it tells you which plugins to suspect first.
Two plugins loading the same library at different versions. Common with charting, date-picker and PDF libraries. Whichever loads second loses.
Both hooking the same action with assumptions about order. Neither is wrong alone; together the sequence breaks.
Both modifying the same output — a caching plugin and an optimisation plugin both rewriting HTML, or two SEO plugins both emitting schema. Two plugins doing the same job is the single most predictable conflict there is, and the fix is choosing one.
One expecting a PHP version the site does not have. Looks like a conflict and is a compatibility fault.
A plugin conflicting with the theme rather than another plugin, which is why step three checks the theme first.
Preventing the next one
Do not run two plugins that do the same job. Two SEO plugins, two caching plugins, two security plugins. This is the most common self-inflicted conflict and the easiest to avoid.
Update on staging first. Most decent hosts include a staging environment, and it converts this entire article into a precaution.
Update in small batches, not all at once. Five plugins updated together and a broken site means five suspects.
Keep the plugin count honest. Every plugin is a dependency, a security surface and a potential conflict — the audit method is in WordPress plugin audit: what to remove and keep.
Fix your site email, so that when something does fail fatally, WordPress can actually reach you with the recovery link. Covered in WordPress email.
Frequently asked questions
How do I find which plugin is causing a problem?
Deactivate all plugins, confirm the problem disappears, then reactivate half at a time rather than one at a time. Halving finds the culprit among twenty plugins in about five rounds instead of twenty. Use Site Health troubleshooting mode so visitors keep seeing the working site.
Can I test plugin conflicts without taking my site down?
Yes. WordPress's Site Health troubleshooting mode, via the Health Check & Troubleshooting plugin, deactivates plugins and switches themes in your session only. Visitors continue seeing the live site normally while you test against a clean configuration.
How do I deactivate plugins without access to the admin?
Rename the wp-content/plugins folder over FTP or your host's file manager. WordPress deactivates every plugin it cannot find, which usually restores admin access. Rename it back afterwards and reactivate individually.
Will deactivating plugins lose my settings?
No. Plugin settings are stored in the database rather than the plugin folder, so deactivating and reactivating preserves them. Deleting a plugin may remove its data on uninstall, which is why you rename rather than delete.
What if the problem persists with all plugins deactivated?
Then it is not a plugin conflict. Switch to a default theme as well, and if it still persists the cause is core files, the server, or the database — a different diagnostic entirely.
How do I know if two plugins conflict rather than one being broken?
Deactivate the suspect alone with everything else active. If the problem disappears it may be that one plugin; if it only appears when a second plugin is also active, you have a genuine pair conflict and both need naming when you report it.
What information should I include in a plugin bug report?
WordPress version, PHP version, both plugin versions, exact reproduction steps, and the fatal error line from wp-content/debug.log. A report with a log line gets a fix; a report describing a symptom gets a template reply.
How do I stop plugin conflicts happening again?
Do not run two plugins that do the same job, update on staging first, update in small batches rather than all at once, and keep the total plugin count deliberate. Two plugins performing the same function is the most predictable conflict there is.
What to do next
Install the Health Check & Troubleshooting plugin before you need it. Troubleshooting mode is the difference between diagnosing a conflict during business hours and doing it at midnight to avoid an outage.
Then check whether you are running two plugins that do the same job. That single check resolves a surprising share of conflicts before any testing is required.
Related guides
- When WordPress breaks: a diagnostic order — the full symptom map
- Blank page after a WordPress update? Fix it — when there is no admin to work in
- Locked out of WordPress admin? How to get back in — when a plugin is blocking login
- Auditing WordPress plugins for security risk — deciding what to keep
- WordPress backups: what most people get wrong — before you start
The short version
- Write down the exact symptomSomething you can reproduce on demand, not a general complaint. Without it you cannot tell when the problem is fixed.
- Take a backupFiles and database, before touching a live site.
- Confirm it is a plugin at allSwitch to a default theme too. If the problem persists with a default theme and all plugins off, it is core, the server or the database rather than a conflict.
- Halve, do not walkReactivate half the plugins and test, then halve whichever half contains the problem. Twenty plugins takes about five rounds this way instead of twenty.
- Confirm the culprit properlyDeactivate the suspect alone with everything else active, to establish whether one plugin is broken or two are conflicting.
- Establish which pair conflictsIf it works alone but fails alongside others, reactivate the rest one at a time until it breaks. Both halves of the pair matter.
- Report it usefullyInclude WordPress version, PHP version, both plugin versions, reproduction steps, and the fatal error line from wp-content/debug.log.
The WordPress Email Delivery Checklist
Stop your WordPress emails from failing silently. Get the complete setup guide.
Muhammad Basim has worked in digital marketing since 2013, focused on email deliverability and AI-assisted content production. He is the author of The Email Deliverability Playbook and The Email Copywriting Playbook.
Related Articles
Choosing a WordPress SEO Plugin
This page names no winner, and the reason is that the choice matters far less than the category's marketing implies. The major WordPress SEO plugins do the same six things. They have converged, they will continue to converge, and the difference between them is interface preference and a small number of features most sites never […]
Two-Factor and Login Hardening for WordPress
Login attacks against WordPress are constant, automated and indiscriminate. Every public WordPress site receives them, regardless of size or traffic, because the cost of trying is near zero. They are also the least successful route into a WordPress site. Vulnerable plugins account for more compromises than password guessing, which is worth holding onto — login […]
WordPress Email: Why Your Site’s Emails Never Arrive
WordPress sends email in a way that fails modern authentication by default, and it reports success while doing it. That combination is why this problem is so persistent. The site is not broken. Nothing is logged. wp_mail() returns true, the order is placed, the form says thank you — and the message never reaches an […]