WordPress Plugin Conflicts: How to Find and Fix Them Safely

On this page

1. Common symptoms of a plugin conflict
2. First, protect the live site
3. Reproduce it on a staging site
4. Use Health Check troubleshooting mode
5. Disable plugins one at a time
6. Read the logs and the browser console
7. Report it to the plugin developers
8. Choosing a replacement and preventing future conflicts

A plugin conflict happens when two plugins, or a plugin and your theme, interfere with each other. Each works fine on its own, but together something breaks: a form stops sending, a layout falls apart or the site shows a critical error. Conflicts are among the most common WordPress problems, and the good news is that they can be tracked down methodically without putting your live site at risk.

Common symptoms of a plugin conflict

• A "critical error" message or white screen right after installing or updating a plugin
• Buttons, sliders, pop-ups or menus that stop responding, often a sign of a JavaScript conflict
• Layouts or styling that suddenly look wrong on some pages
• Forms that won't submit, or a checkout that hangs
• A page builder editor that won't load
• Duplicate output, such as two sets of meta tags from two SEO plugins, or images that never appear because two plugins both lazy-load them
• An admin area that becomes slow, or settings screens that go missing

Not every problem is a conflict. Hosting limits, a hack or stale caching can look very similar, so keep an open mind while you investigate.

If all you see is a completely blank page with no message, start with fixing the WordPress white screen of death.

First, protect the live site

1. Take a fresh backup of files and database before changing anything; see the backup and restore guide
2. Write down what changed recently: a new plugin, an update, a theme change or a PHP upgrade
3. Clear every cache (plugin, hosting and CDN) and check again in a private browser window, because sometimes the "problem" is an old cached page
4. If the site is down or a store can't take orders, roll back the last update or restore the backup first, then investigate

Reproduce it on a staging site

Switching plugins on and off on a live site can break things for real visitors, especially on stores and booking sites. A staging copy lets you test freely, and many hosts create one in a few clicks; see staging sites explained.

Confirm the problem appears on staging too. If it doesn't, the cause may be specific to the live environment, such as server caching, a CDN rule or different PHP settings.

Use Health Check troubleshooting mode

When staging isn't available, the free Health Check & Troubleshooting plugin from the WordPress.org community offers a safer option. Its troubleshooting mode disables all plugins and switches to a default theme only for your logged-in session, while visitors keep seeing the normal site.

From there you can enable plugins one at a time from the admin bar and watch for the moment the problem returns. It isn't perfect, since anything that depends on server-level caching or scheduled tasks may behave differently, but it's a useful first step for many conflicts.

Disable plugins one at a time

The classic method still works best:

1. Switch to a default WordPress theme (one of the "Twenty" themes). If the problem disappears, your theme is involved
2. Deactivate all plugins except the one showing the problem. If it now works, a conflict is confirmed
3. Reactivate the other plugins one by one, checking after each, until the problem returns
4. On sites with many plugins, reactivate them in halves to narrow down the culprit faster
5. Once you've found the pair, test them together on their own to be sure

Deactivate, don't delete: deleting some plugins also removes their settings and data. If you're locked out of the admin, a developer can disable plugins by renaming their folders through hosting file access; see how to fix the critical error.

Read the logs and the browser console

• PHP error log: ask your host for it, or enable WordPress debug logging on staging (WP_DEBUG and WP_DEBUG_LOG in wp-config.php) so errors are written to a log file instead of being shown to visitors. The log usually names the plugin file involved
• Browser console: open your browser's developer tools on the broken page; red JavaScript errors often name the script that failed
• Query Monitor: a free plugin that shows PHP errors, database queries and the scripts loaded on each page, handy on staging

Switch debugging off when you're done, and never leave error messages displaying on a live site.

Report it to the plugin developers

Once you know which plugins clash, tell their developers. A useful report includes:

• Your WordPress, PHP and theme versions, plus both plugin versions (Tools → Site Health → Info lists most of this)
• Exact steps to reproduce the problem
• Any error messages from the log or console
• Confirmation that it still happens with a default theme and only those two plugins active

Use the plugin's support forum on WordPress.org, or the developer's own support channel for premium plugins. Many conflicts are fixed in the next release. Meanwhile, roll back to the last working version if that's safe, or keep the less important plugin switched off.

Choosing a replacement and preventing future conflicts

If a developer doesn't respond or the plugin looks abandoned, replace it:

• Choose plugins that are actively maintained, tested with recent WordPress versions and well reviewed
• Avoid overlapping plugins: one SEO plugin, one caching plugin, one security plugin
• Prefer a few well-built plugins over many small ones; sometimes a little custom code is cleaner
• Never use nulled copies of premium plugins
• Update important plugins one at a time and test key pages afterwards

Would you rather not chase conflicts yourself? My WordPress maintenance plans include tested updates, backups and troubleshooting when something breaks.