How to Find Which Plugin Is Breaking Your WordPress Site

Something broke. Maybe it was a button that stopped working, a blank page, or the “There has been a critical error on this website” message. Most of the time it happened right after an update, and most of the time the cause is two plugins, or a plugin and your theme, that no longer get along.

Tracking down plugin conflicts is part of our everyday work across the WordPress sites we look after. This guide covers the order we do it in: read the error, test safely, narrow it down fast, and then fix it so it stays fixed.

What a plugin conflict looks like

A plugin conflict is when a plugin breaks because of something else on the site: another plugin, your theme, your WordPress version or your server’s PHP version. Each piece may work fine on its own. Together, they fail. The signs we see most:

• “There has been a critical error on this website,” or a white screen with nothing on it.
• Something stops working with no error at all: a menu that will not open, an add-to-cart button that does nothing, a form that never sends.
• Checkout or payment failures, often only for some customers or some payment methods.
• Admin screens that hang or break, like the Updates screen or the page builder.
• Blank pages that still load as “working.” Uptime monitors can miss these completely.

The biggest clue is timing. If it broke right after updates ran, start with whatever was updated.

Before you start

• Take a fresh backup. If testing makes things worse, you can put the site back.
• Write down what changed. Plugin updates, a new plugin, a theme update or a host change. Your host’s or update tool’s log often shows exactly what updated and when.
• Clear every cache. Caching plugins, your host and Cloudflare can keep showing an old, working copy of a page, or an old broken one. Test with caches cleared or bypassed, or you will chase the wrong thing.
• Do not delete plugins to test. Deactivating a plugin keeps its settings. Deleting it can remove them.

Step 1: Read the error first

Guessing is slow. An error message often names the plugin straight away.

• The critical error email. Since WordPress 5.2, a fatal error sends an email to the site’s admin address with a link to recovery mode. The link lets you log in with the broken plugin paused for you only, so you can see which plugin failed and deactivate it. Visitors still see the error until it is fixed. Check spam if you did not get it.
• The debug log. It records the error with the file path, and the path tells you the plugin: wp-content/plugins/plugin-name/.... Our guide to the WordPress debug log shows how to turn it on safely and read it.
• The browser console. When a button or menu stops working with no error on the page, the problem is often JavaScript. Right-click the page, choose Inspect, then open the Console tab and look for red errors. They often name a plugin’s script file.

If the error names one plugin, you may already have your answer. If it names nothing, or nothing errors at all, move on to testing.

Step 2: Test without breaking the live site

Turning plugins off on a live site turns off features for your visitors and customers while you test. There are two safer ways to do it.

A staging site (our default)

A staging site is a private copy of your site. Many hosts create one in a click. Copy the live site to staging, check the problem shows up there too, and do all your testing on the copy. On a store, staging also means test orders never touch real customers.

The Health Check & Troubleshooting plugin

This free plugin from the WordPress.org community has a Troubleshooting mode that turns off all plugins and switches to a default theme for your login only. Visitors keep seeing the normal site. You then turn plugins back on one at a time, still only for yourself.

It is handy, but go in knowing that its last update was July 2024 and WordPress.org warns it has not been tested with the last three major WordPress versions. Try it on staging first, and do not lean on it for a store’s checkout.

Step 3: Find the plugin in a few rounds

Most guides say to turn plugins off one at a time. With 40 plugins, that can mean 40 rounds of testing. We split the list in half instead:

1. Switch to a default theme, such as Twenty Twenty-Five, and test. If the problem goes away, the theme is part of it. Switch back and keep going.
2. Deactivate half of your plugins (leave WooCommerce on if the problem is in your store) and test.
3. If the problem is gone, the cause is in the half you turned off. If it is still there, it is in the half that is still on.
4. Split the suspect half in half again and test. Keep going until one plugin is left.
5. Confirm it. Turn everything back on except that plugin. If the problem stays away, you found it. If it only breaks when two certain plugins are both on, you found the pair.

Splitting in half finds one plugin in about as many rounds as it takes to halve the list down to one. Add a round or two if two plugins clash only with each other.

If you are locked out of wp-admin

When the error takes down the dashboard too, you can still turn plugins off from outside WordPress:

• Use the recovery mode link from the critical error email first. It is the easiest way back in.
• Rename one plugin’s folder. In your host’s file manager or an SFTP app, go to wp-content/plugins and rename the suspect folder (add -off to the end). WordPress deactivates a plugin it cannot find.
• Rename the whole plugins folder to turn every plugin off at once, log in, then rename it back. Plugins come back deactivated, ready for you to turn on half at a time.
• Check for must-use plugins. Files in wp-content/mu-plugins run on every page and cannot be turned off from the dashboard. Hosts often add them. Rename them the same way if everything else checks out.
• Use WP-CLI if your host has it. wp plugin deactivate plugin-name turns off one plugin, and wp plugin list --skip-plugins works even when a plugin crashes every page.

Expect more than one error sometimes. On one site we look after, running PHP 8.4, the whole site and dashboard showed raw PHP errors. Fixing the first error, an old Twitter feed plugin, just uncovered the next: add-ons for a membership plugin were loading before the plugin they depended on. Behind that sat a third, a leftover file from the site’s pre-WordPress days. Each error hid the next one. Keep going until the site loads clean.

Fixing it once you know which plugin

Finding the plugin is half the job. The fix depends on why it broke:

• It broke after an update: roll back to the version that worked. For plugins from WordPress.org, the free WP Rollback plugin does this in a few clicks. For paid plugins, download the earlier version from your account with the developer. Then wait for a fixed update before updating again.
• An update did not finish cleanly: reinstall a fresh copy of the same plugin version. A half-written update can look exactly like a conflict.
• A free plugin and its Pro version do not match: update both to the latest versions together.
• Add-ons load before the plugin they need: update everything, and if it still fails, ask the developer. This is a bug on their side.
• An old plugin fails on a newer PHP version: update it if there is an update. If the plugin is abandoned, replace it.
• Two plugins do the same job: two caching plugins, two SEO plugins or two security plugins often fight. Keep one.

Whatever you do, tell the plugin’s developer. Send the error message, your WordPress and PHP versions, and the other plugin involved. Good developers fix conflicts fast when they can reproduce them.

Plugin conflicts on a WooCommerce store

Stores break in more expensive ways, because a conflict can stop people paying without showing an error to anyone. The method is the same, with a few changes:

• Keep WooCommerce and the extensions involved switched on while you split the rest. WooCommerce’s own conflict test works the same way.
• Test the whole path, not just the page. Many store conflicts only show up partway through: adding to cart, applying a coupon, choosing shipping, paying. Repeat the exact steps where it broke.
• Check WooCommerce > Status. The Templates section lists theme files that override WooCommerce’s own and flags any that are out of date. An outdated override after a WooCommerce update is a classic cause of broken cart and checkout pages.
• Look at payment and checkout plugins first when checkout fails. Gateways, checkout page builders and anything that changes the checkout fields clash most often.
• Prove it with a real order. After the fix, place a real $1 order and refund it, as we explain in our PayPal setup guide. Test mode proves the settings work; a real order proves customers can pay.

We built our free Plugin Conflict Detector for exactly this. It runs on WooCommerce stores, logs errors as they happen, and runs conflict scans that test your store with different groups of plugins turned off while customers keep the normal site.

When it is not a plugin at all

If no plugin makes a difference, look at what sits around WordPress:

• The theme or page builder. The default theme test in Step 3 catches this.
• The PHP version. A host upgrading PHP can break old plugins and themes overnight, with no plugin changed.
• Script “optimization.” Settings that delay, combine or reorder JavaScript, in a speed plugin or in Cloudflare’s Rocket Loader, break buttons, menus and checkouts. On one store, this kind of script reordering cost about three quarters of its orders over three days.
• Caching. A cached page can show an empty cart or an old form to logged-in customers. Clear the cache and test logged out and logged in.
• Server security rules. A firewall can block a plugin’s requests, which looks just like a conflict.

Preventing the next one

• Update in order and check after. Our guide to updating WordPress safely covers the order we use and what to check after each round.
• Update free and Pro versions of a plugin together.
• Keep fewer plugins. Every plugin you remove is one less thing that can clash. Remove the ones you are not using rather than leaving them deactivated.
• Watch what matters, not just “is it up.” A blank page or a broken checkout can return “200 OK” all day.
• On a WooCommerce store, test updates before you install them. Plugin Conflict Detector has an Update Checker that tests a plugin update first.

Questions people ask

Sources

1. WordPress.org, Health Check & Troubleshooting plugin.
2. Make WordPress Core, Fatal error recovery mode in 5.2.
3. WordPress Developer Resources, Debugging in WordPress.
4. WP-CLI, wp plugin deactivate.
5. WordPress.org, WP Rollback plugin.
6. WooCommerce, How to test for plugin and theme conflicts.