WordPress Plugin Conflict: How to Find Which Plugin Is Breaking Your Site

Did your WordPress site start acting strangely after you installed or updated a plugin?

Maybe a form stopped sending. Maybe the page editor will not load, a menu disappeared, or a white screen replaced your home page. When two pieces of code try to do the same job in different ways, they can clash. This is called a plugin conflict, and it is one of the most common reasons that a working WordPress site suddenly breaks.

The hard part is that WordPress rarely tells you which plugin is the cause. With thousands of plugins and themes available, any two can clash. The good news is that you can find the culprit with a clear method, and you can do it without taking your live site down.

In this guide, we’ll explain what a plugin conflict is and how to spot one. We’ll show how to prepare safely, and then go through several ways to find the plugin that is breaking your site. We’ll also cover what to do once you find it.

What Is a WordPress Plugin Conflict?

A plugin conflict happens when a plugin does not work properly with WordPress core, your theme, or another plugin. Each plugin adds code to your site. When two pieces of code change the same thing, or one needs something that the other removes, errors appear.

Common reasons conflicts happen

• Two plugins load different versions of the same code library.
• Two plugins try to do the same job, such as two caching or two security plugins.
• A plugin uses an old function that was removed in a new PHP or WordPress version.
• A plugin’s JavaScript clashes with another plugin’s JavaScript on the same page.
• A theme and a plugin both change the same part of the page.
• A recent update changed how a plugin works, and another plugin has not caught up.

A conflict can also come from a plugin and a server setting, such as a firewall rule or a low memory limit. These look like conflicts, but the fix is in the server.

Signs of a Plugin Conflict

A conflict often appears right after one of these events:

• You installed a new plugin.
• You updated a plugin, your theme, or WordPress.
• You changed your PHP version.
• You turned on a new setting in a caching or security plugin.

If the problem began right after one of these, you already have a strong clue.

Before You Start: Protect Your Site

Never test plugins on a live site without a safety net.

Take a full backup

Back up your files and your database. Store the copy off the server, for example on your computer or in cloud storage. Check that you can restore it.

Use a staging site if you can

A staging site is a private copy of your site. Many hosts offer one with a single click. Test on the copy, and the live site stays safe. If your host has no staging tool, a staging plugin can create one.

Choose a quiet time

If you must test on the live site, pick the hours when you have the fewest visitors. Plugin tests can change how the site looks for a short time.

Write down what you see

Note the exact error message, the page where it appears, and the steps that cause it. Take a screenshot. This helps you check later whether your fix worked.

Method 1: Check the Error Message and the Debug Log

The fastest way to find a culprit is often to read the error. WordPress can write errors to a log file, and these usually name the file and the plugin.

Turn on the debug log

Open the wp-config.php file in your site’s root folder, and add or change these lines above the line that says to stop editing:

• define( ‘WP_DEBUG’, true );
• define( ‘WP_DEBUG_LOG’, true );
• define( ‘WP_DEBUG_DISPLAY’, false );

The WordPress debugging guide explains each option. Reload the page that fails. WordPress then writes the errors to a file named debug.log in the wp-content folder.

Read the log

Open debug.log and look for the newest lines. A line like this points to the cause:

• PHP Fatal error: Uncaught Error in /wp-content/plugins/plugin-name/file.php

The folder name after plugins is the plugin that caused the error. It is not always the real culprit, because the error might come from a clash with another plugin, but it is the best clue you have.

Turn debugging off afterward

Set WP_DEBUG back to false when you finish, and delete the log file if it holds sensitive information. Leaving debug mode on a live site is a security and speed risk.

Method 2: Use the Health Check and Troubleshooting Plugin

The Health Check and Troubleshooting plugin from WordPress.org has a troubleshooting mode. In this mode, it turns off all plugins and switches to a default theme for you only. Other visitors still see the normal site.

How to use it

1. Install and activate the Health Check and Troubleshooting plugin.
2. Go to Tools, then Site Health, then the Troubleshooting tab.
3. Click Enable Troubleshooting Mode.
4. Check whether the problem is gone. If it is, a plugin or the theme is the cause.
5. Turn on one plugin at a time from the admin bar menu. Test the problem after each one.
6. When the problem returns, the last plugin that you turned on is involved.
7. Click Disable Troubleshooting Mode when you finish.

This is the safest manual method for a live site, because visitors do not see the changes.

Method 3: Deactivate All Plugins and Turn Them On One by One

If you cannot use a helper plugin, you can do the same test by hand. Do it on staging if possible.

The basic process

1. Take a backup.
2. Go to Plugins, and select all of them.
3. Choose Deactivate from the bulk actions menu.
4. Check whether the problem is gone.
5. If it is gone, activate the plugins one at a time. Test the problem after each one.
6. When the problem comes back, you have found the plugin.
7. If the problem stays with all plugins off, the cause is probably your theme, a server setting, or WordPress core.

What to expect

Deactivating plugins can change how your site looks. Forms, shop features, and page builder content may stop working until you turn the plugins back on. Do this only on a live site if you accept a short disruption.

Method 4: The Binary Search for Sites With Many Plugins

If you have 40 plugins, turning each one on takes a long time. A binary search is faster.

1. Deactivate half of your plugins.
2. Test. If the problem is gone, the cause is in the half that you turned off. If it remains, the cause is in the half that is still active.
3. Take the half that holds the cause, and split it again.
4. Repeat until you are down to one plugin, or to two plugins that clash with each other.

With 40 plugins, you find the answer in about six rounds, not forty.

Method 5: Switch to a Default Theme

Sometimes the theme is the other half of the conflict.

1. Back up your site.
2. Go to Appearance, then Themes.
3. Activate a default WordPress theme, such as a recent Twenty theme.
4. Test the problem.

If the problem is gone, your theme or its settings are involved. Check for a theme update, and ask the theme’s support team about the clash.

Method 6: Use the Browser Console for Script Errors

When a page loads but a button, menu, or editor does not work, the cause is often a JavaScript error.

1. Open the page that fails.
2. Open your browser’s developer tools, and go to the Console tab.
3. Reload the page, and look for red error lines.
4. Each error shows the file name and line. A path with /wp-content/plugins/ in it names the plugin.

You can also open the Network tab and look for failed requests, shown in red. A failed request to admin-ajax.php or to the REST API often points to a security plugin or a firewall that blocks it.

Method 7: Recover When You Cannot Log In

If the conflict locks you out of the dashboard, you can still turn off plugins from outside WordPress.

Check your email for recovery mode

When WordPress catches a fatal error, it sends an email to the site’s admin address with a special link. The link opens recovery mode, in which the plugin that caused the error is paused, so you can log in and deactivate it.

Rename the plugin folder

If you have no email link, use your host’s file manager or an FTP client.

1. Go to the wp-content folder, and open the plugins folder.
2. Rename the folder of the suspected plugin, for example by adding -off to the end.
3. Reload your site. WordPress cannot find the plugin, so it turns it off.
4. If you do not know which plugin it is, rename the whole plugins folder to plugins-off. This turns off all of them. Then rename it back, and turn the plugins on one at a time from the dashboard.

Use WP-CLI if you have it

If your host provides command-line access, WP-CLI lets you list and turn off plugins in seconds. You can run a command to deactivate all plugins, then activate them one by one.

Comparing the Methods

What to Do After You Find the Plugin

Finding the plugin is the first half. Now you have to decide what to do.

Update everything

Check that the plugin, the other plugin involved, your theme, and WordPress are all up to date. Many conflicts are fixed in a later version.

Check the support forum

Search the plugin’s support forum on WordPress.org or the vendor’s site for your error message. Another user may have found the same problem and a fix.

Contact the developer

Send a clear report. Include your WordPress, PHP, and plugin versions, the exact error, and the steps that cause it. A good report gets a fast answer.

Look at your settings

Some conflicts come from one setting, such as minify or combine options in a caching plugin. Turn off the setting, and test again.

Replace the plugin

If the plugin is not maintained, or the developer does not respond, find a different plugin that does the same job. A plugin that has not been updated for a long time is also a security risk.

Remove duplicates

If two plugins do the same job, keep only one. Two caching plugins, two security plugins, or two SEO plugins are a common source of trouble.

How to Prevent Plugin Conflicts

• Keep plugins, themes, and WordPress updated, but test large updates on staging first.
• Install only plugins that you need, from sources that you trust.
• Check the “last updated” date and the “tested up to” version on the plugin page.
• Avoid installing several plugins that do the same job.
• Add one plugin at a time, and test after each.
• Take a backup before each update.
• Keep notes on what you changed and when.
• Use a staging site for tests.

If your site was fine until an update and you are not sure what happened, read our guide on what to do when your WordPress website breaks after an update.

Conflicts That Slow Your Site Down

Not every conflict causes a visible error. Some make the site slower, because two plugins repeat the same work, or one plugin loads scripts that another plugin already loads. If your site feels slow and you suspect a plugin, our guide on why your WordPress website is so slow lists the common causes and shows how to test them.

Conflicts With Page Builders

Page builders such as Elementor are large plugins that depend on many other pieces of code. They are often the plugin that appears to fail when another plugin is the real cause. If the builder will not load, stays on the loading screen, or shows a blank editor, test with all other plugins off. Our guide on Elementor not loading or stuck on the loading screen covers the builder-specific steps.

A Worked Example: Finding a Conflict Step by Step

Here is a realistic case, to show how the methods fit together.

A site owner updates a contact form plugin on Monday morning. By lunchtime, a customer reports that the form button does nothing. The owner follows this path.

1. The owner takes a backup, then opens the form page and the browser console. A red error says that a script from the form plugin could not read a value that is not defined.
2. The owner sees that the same page also loads a script from a caching plugin that combines JavaScript files. The error appears in the combined file.
3. The owner turns off the combine option in the caching plugin and clears the cache. The button works again.
4. The owner writes to both developers, with the error text and the versions, and keeps the combine option off until a fix arrives.

The lesson is that the “broken” plugin was not the real cause. The form plugin was fine, and the clash was a setting in another plugin. This is why you should test with evidence and not guess from the symptom.

Quick Fixes to Try Before a Full Test

A full test takes time. These quick steps solve a large share of conflicts, so try them first.

• Clear all caches: your caching plugin, your host’s cache, your CDN, and your browser.
• Hard refresh the page, or open it in a private window, to rule out stored files.
• Log out and log in again.
• Re-save your permalinks by going to Settings, then Permalinks, and clicking Save Changes. This fixes many broken page and REST API problems.
• Update every plugin, your theme, and WordPress to current versions.
• Check your PHP version in Site Health. If it changed recently, the change may be the cause.
• Check your memory limit. A plugin that runs out of memory can look like a conflict.

If none of these helps, move on to the methods above.

Reading Site Health for Clues

WordPress has a built-in Site Health screen under Tools. It shows a status tab with problems and suggested actions, and an info tab with your versions and settings. The official Site Health documentation explains each part.

Look at these items first:

• The PHP version and the memory limit.
• Plugins that are inactive, which you can remove.
• Plugins and themes that need an update.
• Whether the REST API and loopback requests work. If they fail, a security plugin or a server rule may block them, and that causes editor and scheduled task errors.
• Whether the site uses a persistent object cache, and whether it is working.

Copy the info tab into a text file before and after your test. It gives you a record of what changed.

Server Settings That Look Like Plugin Conflicts

Some problems look like conflicts, but no plugin is at fault. If you have turned off every plugin and the problem remains, check these.

When you suspect the server, contact your host with your error message and the time it happened. Hosts can read server logs that you cannot reach.

How to Report a Conflict So It Gets Fixed

Developers are busy, and a short message that says “it does not work” rarely gets a fast answer. A good report includes:

• Your WordPress, PHP, and plugin versions.
• The name and version of the other plugin or theme involved.
• The exact error message, copied as text.
• The steps that cause the problem, written in order.
• What you expected, and what happened instead.
• What you already tried, such as turning off other plugins.
• A screenshot or a short screen recording.

Post it in the plugin’s official support forum, so that other users can find the answer later. Do not share passwords or private data in a public post.

Plugins That Need Extra Care

Some types of plugin touch many parts of your site, so they appear in conflicts more often.

• Caching and optimization plugins change how files load, so they can break scripts and styles.
• Security plugins and firewalls can block requests that other plugins need.
• Page builders and theme frameworks load many scripts, and they depend on a clean environment.
• SEO plugins can clash when two of them run together.
• Membership and shop plugins hook into logins, carts, and checkout, so a clash can cost you sales.
• Backup plugins can use a lot of memory and time on small servers.

After a change in any of these, test your most important pages: the home page, a post, the contact form, and, if you sell products, the checkout.

Keep a Plugin Log

A simple log saves hours when something breaks. Keep a note, in a spreadsheet or a text file, with these columns: the date, the plugin or theme, the old version, the new version, and what you tested after the change.

When a problem appears, you can look back and see what changed in the days before it. This often points to the cause at once. It also helps if you hire someone to fix the site, because they can see the history without guessing.

Add a line each time you install, update, remove, or change the settings of a plugin. It takes less than a minute, and it makes every method in this guide faster.

Frequently Asked Questions (FAQs)

How do I know if I have a plugin conflict?

A conflict usually shows up after you install or update something. Typical signs are a white screen, a fatal error notice, a broken layout, or a feature that stops working. If the problem goes away when you turn off plugins, you have a conflict.

Can a plugin conflict break my whole website?

Yes. A fatal error from a plugin can stop WordPress from loading the page or the dashboard. You can fix it by renaming the plugin folder or by using the recovery mode link that WordPress emails to you.

How do I find which plugin is causing the problem?

Use the debug log to read the error, or test with the Health Check troubleshooting mode. You can also turn off all plugins and turn them on one at a time. On large sites, use a binary search.

Is it safe to deactivate all plugins?

It is safe for your data, but your site may look and work differently until you turn them back on. Take a backup first, and test on a staging site if possible.

Will deactivating a plugin delete its data?

Deactivating does not delete the plugin’s data. Deleting a plugin can remove its data, depending on how the plugin was built, so deactivate first and delete only when you are sure.

What if the problem stays after I turn off all plugins?

Then the cause is likely your theme, a server setting, a caching layer, or WordPress core. Switch to a default theme, clear all caches, and check the debug log.

What if two plugins conflict and I need both?

Check for updates and settings. Contact both developers with a clear report. If there is no fix, look for an alternative to one of them.

Can my caching plugin cause conflicts?

Yes. Caching, minify, and combine options can break scripts and layouts. Clear the cache first, and then turn off the optimization options one at a time.

How do I avoid conflicts in the future?

Use fewer plugins, update on a schedule, test big updates on staging, and keep a backup before each change.

Can someone fix a plugin conflict for me?

Yes. If you would rather hand the problem to an experienced person, you can get WordPress management and troubleshooting help through this Fiverr gig.

Final Thoughts

A plugin conflict feels alarming, but it is almost always fixable. Start with a backup, work on a staging copy when you can, and let the evidence lead you. The debug log and the browser console often name the cause in minutes. When they do not, the troubleshooting mode or a binary search finds it in a short time.

Once you find the plugin, update it, check its settings, ask the developer, or replace it. Then build a few habits, such as fewer plugins, regular updates, and tests on staging, so that the next conflict is easier to handle.