A white screen, a fatal error, or a site that suddenly breaks after one plugin update is one of the most common WordPress support threads there is. The advice people get is almost always the same: deactivate everything, then turn plugins back on one at a time. It works, but it’s slow, and there’s a faster way to narrow it down first.
Quick Verdict
Before you deactivate anything, check your site’s debug log — WordPress usually names the exact plugin or function that caused the error, which skips most of the guesswork. If the log doesn’t point to a clear cause, the one-at-a-time deactivation method still works, but do it in a staging copy of your site first if you have one, since testing live risks extending the downtime you’re trying to fix.
Step One: Check the Debug Log First
Turn on WP_DEBUG_LOG in wp-config.php (or ask your host to check it for you if you’re not comfortable editing config files) and reload the broken page. The resulting log almost always names the specific plugin file where the fatal error happened. This single step resolves a large share of plugin-conflict cases without any trial-and-error deactivation at all.
If the Log Doesn’t Point to a Clear Cause
| Step | What it tells you |
|---|---|
| 1. Deactivate all plugins via FTP or your host’s file manager (renaming the plugins folder works if you can’t reach wp-admin) | Confirms whether a plugin is the cause at all, versus a theme or core issue. |
| 2. Reactivate plugins in small batches, not one at a time, to save time | Narrows the problem to a group faster — you only switch to one-at-a-time once you’ve isolated the batch. |
| 3. Within the suspect batch, reactivate one plugin at a time | Identifies the exact plugin causing the conflict. |
| 4. Check the plugin’s changelog for the version that broke it | Tells you whether this is a known issue (worth checking the support forum before doing anything else) or something specific to your setup. |
What Usually Causes This
- Two plugins modifying the same core function. This is the classic conflict — both plugins work fine alone, but break when active together because they’re competing for the same hook.
- A plugin update that changed its own requirements. A plugin bumping its minimum PHP version, or changing how it loads a library, can suddenly conflict with something that worked fine the day before.
- Caching plugins serving a stale, broken version of a page. Sometimes the “conflict” isn’t a conflict at all — clearing cache first rules this out before you start deactivating anything.
If your investigation turns up signs of an actual compromise rather than a plain conflict (unexpected admin users, unfamiliar files, redirect loops to spam sites), stop here and see our hacked WordPress cleanup guide instead — the fix is different. And if everything’s stable again but the site still feels slow, that’s a separate diagnosis covered in why your WordPress site is slow.
Frequently Asked Questions
Do I need a staging site to do this safely?
It’s strongly recommended if you have one, but not required — many hosts include a one-click staging feature specifically for this kind of testing. Without staging, doing this during low-traffic hours reduces the impact of the downtime.
What if reactivating plugins one at a time doesn’t reproduce the error?
This usually means the conflict is intermittent (triggered by a specific page, user role, or piece of content) rather than a straightforward activation conflict — check your debug log again with that page specifically loaded.
Should I just avoid using many plugins together to prevent this?
No — plugin count isn’t the real risk factor here, specific incompatible combinations are. A well-maintained set of 20 plugins is generally safer than a poorly-maintained set of 5, since maintenance and update frequency matter more than raw count.
How We Assessed This
This reflects standard WordPress debugging practice as commonly recommended in WordPress support communities. Disclosure: this page contains no affiliate links currently.
Related
