How to Find Which Plugin Is Breaking Your WordPress Site

The short answer

The fastest way to find a conflicting plugin is to deactivate all plugins at once, confirm the problem disappears, then reactivate them one by one until the problem returns — that last reactivated plugin is your culprit. If you can't reach the WordPress admin at all, you can do the same thing by renaming the plugins folder via FTP or your host's file manager.

What a plugin conflict actually looks like

Plugin conflicts rarely announce themselves politely. The symptoms span a wide range, which is why they get misdiagnosed as hosting problems, theme bugs, or WordPress core issues. Common signs include:

• A white screen or a "There has been a critical error" message after activating a new plugin
• A broken layout — buttons missing, menus not opening, page builders rendering blank sections
• JavaScript errors in the browser console (right-click → Inspect → Console tab)
• A specific page, post, or feature that stopped working after a recent update
• Checkout or form submissions failing without any obvious error message
• The admin dashboard loading slowly or timing out
• Two plugins offering the same feature (caching, SEO, forms) fighting over the same hook or database table

The important thing to recognise is that a conflict doesn't always mean a plugin is poorly coded. Perfectly well-written plugins can conflict if they both modify the same part of WordPress — the same JavaScript library, the same REST API endpoint, or the same database option. The conflict is situational, not necessarily a sign of bad code.

Before you start: take a backup

You're going to be toggling plugins on and off. On a well-configured site that's a safe operation, but if your database is already in a fragile state — say, a WooCommerce store mid-transaction — deactivating the wrong plugin at the wrong moment can cause data loss. Take a full backup (files and database) before you begin. Your host's control panel almost certainly offers a one-click backup; use it.

Method 1: Deactivate all plugins from the WordPress admin (site is still accessible)

This is the cleanest approach when you can still log in to wp-admin.

1. Go to Plugins → Installed Plugins.
2. Check the box at the top of the list to select all plugins.
3. In the Bulk Actions dropdown, choose Deactivate and click Apply.
4. Check whether your problem has disappeared. If it has, you've confirmed a plugin is responsible. If it hasn't, the issue is elsewhere — your theme, WordPress core, or the server itself.
5. Now reactivate plugins one at a time, checking your site after each activation. The moment the problem returns, the plugin you just activated is involved in the conflict.
6. Don't stop there. Note that plugin, then continue reactivating the remaining plugins. Sometimes a conflict requires two specific plugins to be active simultaneously — Plugin A is harmless alone, and Plugin B is harmless alone, but together they break something. If your problem reappears again later in the sequence, you've found the pair.

This process can take 10–30 minutes depending on how many plugins you have. Move methodically. Refreshing your site in an incognito window as you go avoids browser-cache confusion.

Method 2: Rename the plugins folder via FTP or File Manager (site is inaccessible)

If a plugin has caused a white screen of death or a fatal error that locks you out of wp-admin, you need a back-door approach.

1. Connect to your server via FTP (FileZilla works well) or open the File Manager in cPanel/Plesk.
2. Navigate to wp-content/.
3. Rename the folder called plugins to something like plugins_disabled. WordPress will fail to find any plugins and silently deactivate them all — no data is deleted.
4. Reload your site. If it comes back, a plugin was the cause. If it's still broken, move on to checking your theme or wp-config.php.
5. Rename the folder back to plugins.
6. Now go into wp-content/plugins/ and rename individual plugin folders one at a time, reloading your site each time. When renaming a specific plugin folder makes the site work, that's your culprit. Rename it back to its original name but leave it deactivated from the admin panel while you decide next steps.

A useful shortcut if you have a strong suspicion: rename only recently updated or recently installed plugins first. Check your plugin list's Update column or think back — "what changed right before this broke?" Start there.

Method 3: Binary search (large plugin lists, faster diagnosis)

If you have 40 plugins, reactivating them one at a time is tedious. Use a binary search instead:

1. Divide your plugins into two groups of 20.
2. Activate group one. Does the problem appear? If yes, the culprit is in group one. If no, it's in group two.
3. Take the guilty group, split it in half again. Repeat until you're down to a single plugin.

This approach finds the offender in 5–6 steps instead of 40. It works especially well with the FTP/File Manager method, where you can move plugin folders in bulk between a staging sub-folder and the live plugins folder.

Ruling out your theme

Once you've identified a plugin conflict, you should also check whether your theme is a participant. Switch to a default WordPress theme (Twenty Twenty-Four is current) and test with only your suspected plugin active. If the problem disappears with the default theme, the conflict is between the plugin and your theme, not between two plugins. That distinction matters when you go to report it or seek a fix.

What to do once you've found the conflicting plugin

Finding the culprit is half the job. Here's what to do with the information:

• Check the plugin's support forum on WordPress.org. Search for your exact symptom. Chances are someone has already reported it, and there may be a workaround or a patched version available.
• Check for updates. The conflict may have already been fixed in a newer version. Update the plugin in a safe environment first if possible.
• Report the conflict. If it's a free plugin, open a thread on the WordPress.org support forum with precise details: WordPress version, PHP version, which two plugins conflict, and exactly what breaks. Plugin authors genuinely appreciate specific bug reports.
• Evaluate whether you need both plugins. Sometimes the fix is simply removing the plugin you can live without. Two caching plugins, two SEO plugins, or two security plugins rarely coexist cleanly — pick one. For more on this, see our piece on the real performance cost of too many plugins.
• If a recent update caused the conflict, consider rolling back to the previous version while you wait for a fix. Our guide on sites broke after an update walks through that process safely.

Preventing plugin conflicts in future

You can't eliminate the possibility entirely, but you can reduce it significantly:

• Test updates on a staging site before applying them to production. Most managed hosts offer one-click staging environments. If yours doesn't, ask — or consider a host that does.
• Update one plugin at a time, not all at once via bulk update. When something breaks after a bulk update, you have no idea which plugin caused it.
• Keep your plugin list lean. Every additional plugin is another potential conflict surface. If a plugin hasn't been updated in two years or has fewer than a few hundred active installs, think carefully before installing it on a production site.
• Enable WP_DEBUG in a staging environment. PHP errors and warnings that are silently swallowed in production are printed clearly in debug mode, making conflicts far easier to spot before they reach your live site.

When to call a professional

The method above works in the vast majority of cases. But occasionally you run into situations where it doesn't cleanly resolve things: the conflict only appears under specific conditions (logged-in users only, on mobile only, at checkout only), the error is deep inside a PHP stack trace you don't recognise, or deactivating the conflicting plugin breaks something else you rely on.

If you've followed these steps and you're still stuck, that's exactly what Mend is built for. A senior engineer will triage your site, identify the root cause precisely, and fix it — usually the same day — with a plain-English explanation of what happened and what changed. There's a free Diagnosis if you're not sure what you're dealing with, or you can go straight to a Quick Fix for $129 with a money-back guarantee if it isn't resolved.

A quick note on debug logging

If you want more precision than the toggle method provides, enable WordPress's debug log. Add these lines to your wp-config.php file, just above the line that reads /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

This writes PHP errors silently to wp-content/debug.log without displaying them to site visitors. After triggering the problem, open that file and look for the most recent error lines — they'll include the plugin filename and line number causing the issue. This is often faster than the toggle method when you're dealing with intermittent errors rather than consistent ones. Remember to remove or set WP_DEBUG back to false when you're done; leaving it on in production can expose sensitive path information.