Most WordPress problems trace back to plugins. A blank page, a broken layout, an error message, a feature that suddenly stops working — a plugin conflict is the most likely culprit, and also one of the easier problems to confirm and fix methodically, once you know the sequence.
A plugin conflict happens when two or more plugins try to do the same thing in incompatible ways, or when a plugin is incompatible with your WordPress version or active theme. The result ranges from a minor visual glitch to a completely inaccessible site. You don’t need developer skills to work through it — isolate the problem by deactivating plugins, then narrow it down by reintroducing them one at a time. If you’re setting up a new site from scratch, the step-by-step guide to building a WordPress website covers plugin installation as part of the full launch process.
Recognising a Plugin Conflict
The signs are fairly consistent: a white screen of death or PHP error on the front end, a broken or inaccessible dashboard, a layout issue that appeared right after installing or updating a plugin, a feature that stopped working with no deliberate change on your part, or a sudden drop in site speed that lines up with a new plugin. Many site owners assume the problem is their hosting or WordPress core and spend time investigating the wrong area first — the deactivation test below takes a few minutes and either confirms or rules out plugins before you look anywhere else.
The Deactivate-and-Reintroduce Method
Before making any changes, take a complete backup of your site. If troubleshooting makes things worse, a backup gives you a safe restore point.
Go to Plugins → Installed Plugins, select all, and choose Deactivate from the bulk actions dropdown. Visit your site immediately after. If the problem disappears, you’ve confirmed a plugin conflict; if it persists with everything deactivated, the issue is in your theme or WordPress core itself.
Reactivate your plugins one at a time, checking the site after each one. When the problem reappears, you’ve found the conflicting plugin — or at least one side of it. Check whether a newer version is available and update it; if the problem persists, try deactivating only that plugin while everything else stays active, since sometimes two specific plugins only conflict with each other rather than either one being broadly broken.
If deactivating every plugin doesn’t resolve it, switch to a default theme such as Twenty Twenty-Five via Appearance → Themes. If the problem disappears there, your active theme is involved, either on its own or combined with a plugin.
If your dashboard is completely inaccessible, you can still run this test remotely. Connect via FTP or your host’s File Manager, navigate to wp-content, and rename the plugins folder to something like plugins-disabled. This deactivates everything without deleting anything or losing settings. Once you regain access, rename it back and reactivate plugins one at a time.
Using Query Monitor to Skip the Guesswork
The deactivate-and-reintroduce method works, but it’s slow if you’re managing a site with thirty active plugins. Query Monitor — a free, actively maintained plugin (updated within weeks of this review, tested against current WordPress core) — gives you a faster path for a lot of conflicts. Install it, and it adds a debug bar showing PHP errors, deprecated function warnings, and exactly which plugin fired which hook, with a stack trace pointing at the responsible file. For a fatal error or a PHP warning specifically, this often names the conflicting plugin directly, without a single deactivation cycle. It won’t replace the full test for conflicts that only manifest as a subtle layout or behaviour change rather than an error, but for anything that throws a PHP notice, it’s the faster route.
For a specific PHP error rather than a complete site failure, WordPress’s own debug mode surfaces more detail even without Query Monitor installed. Add the following to wp-config.php, 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 errors to a debug.log file inside wp-content/ rather than displaying them publicly. Remove these lines, or set each constant to false, once the conflict is resolved. The WordPress debugging documentation covers every available debug constant in detail.
A typical Query Monitor entry for a fatal error shows the exact function call that failed, the file and line number, and a call stack tracing back through whichever plugin triggered it — for example, a caching plugin calling a function a security plugin has since removed or renamed after an update. That’s the specific pattern the manual deactivation test is designed to catch eventually, but Query Monitor often surfaces it in the time it takes to load one page.
Where Conflicts Actually Come From
In practice, conflicts most often appear between security plugins and caching plugins, or between two plugins that both try to manage the same feature — SEO or form handling, for instance. If you’re adding a second plugin in an area already covered by an existing one, test thoroughly before going live. Many conflicts are also compatibility issues introduced by an update to one plugin that another developer hasn’t caught up with yet, which is why keeping all plugins updated is one of the most effective ways to prevent conflicts in the first place — you’re more likely to already have the fix.
Testing on a WordPress staging site is the cleanest way to run any of this — you can deactivate and reactivate plugins freely without affecting your live site or visitors. And once you’ve identified the conflicting plugin, check its support forum on WordPress.org before contacting the developer directly; many specific conflict combinations are already reported and resolved there.
Mistakes That Slow Down the Process
Testing the theme before the plugins. Plugins are responsible for the majority of WordPress conflicts, so test them first. Reactivating several plugins at once means repeating the whole process if the problem reappears — one at a time, always. Assuming the newest plugin is automatically the cause — it’s a reasonable starting point, but an older plugin can become incompatible after a WordPress core update or after a different plugin updates around it. And skipping the backup because the site is “already broken” — the troubleshooting process itself can occasionally cause a secondary issue, so back up first regardless.
When It’s Not a Plugin at All
If you’ve tested every plugin and the theme and the problem persists, it’s likely in WordPress core files or your server configuration. A complete white screen with no dashboard access is where the debug log approach above is fastest — the PHP error message typically names the specific file and plugin responsible. For conflicts that appear only inside the block editor but not on the front end, check browser console errors while in the editor; they usually point directly at the responsible plugin without a full deactivation test.
Plugin conflicts are also one of the more common causes of a sluggish dashboard — if the steps above didn’t turn up a culprit, see our guide on how to fix a slow WordPress admin dashboard for the other usual causes, including database bloat and the Heartbeat API.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.