A WordPress site can work perfectly one day and break the next. Often the trigger is a plugin update, a new plugin or a theme change. Two pieces of code that worked fine alone start clashing with each other. Finding which two is mostly a matter of patience and a clear method.
This post sets out a calm process for finding a plugin conflict. It uses tools that come with WordPress and steps from the official documentation. You do not need to be a developer to follow most of it. A fresh backup before you start is still a good idea.
Signs that a plugin conflict is the cause
Conflicts show up in different ways. The WordPress guide to common WordPress errors covers the White Screen of Death, internal server errors and connection timeouts. For each of these, deactivating plugins is one of the suggested checks. Smaller symptoms count too, such as a contact form built with Gravity Forms that suddenly stops sending.
Think about what changed just before the problem started. A plugin that updated overnight is a strong suspect. So is anything you installed or activated that week. Write these down before you touch anything, because it saves guesswork later.
Start with the Site Health screen
WordPress includes a Site Health screen under the Tools menu. It has two tabs, Status and Info. The Status tab groups items into critical issues, recommended improvements and passed tests. Critical issues can include an outdated PHP version or errors being displayed to visitors.
The Info tab is a read only view of how your site is set up. It lists active and inactive plugins with their versions and auto update status. It also shows the active theme, its parent theme and details about the server and database. You can copy all of it to the clipboard, which is useful when asking a plugin author for help.
Be careful where you paste that information. It includes details about your server and configuration. Share it with a trusted support contact rather than a public forum thread. Remove anything you are unsure about first.
Turn on error logging
An error log often points straight at the plugin involved. The WordPress debugging guide explains that WP_DEBUG is set in the wp-config.php file and is false by default. When you also turn on WP_DEBUG_LOG, errors are saved to a debug.log file, usually in the wp-content folder. Setting WP_DEBUG_DISPLAY to false keeps those errors off the page itself. One small detail matters here, as the guide notes that a false value wrapped in quotes is treated as true.
The guide says these tools are meant for local testing and staging, not live sites. The Site Health documentation also warns that displaying or logging errors on a public site can expose them. If you must test on a live site, keep debugging on only briefly. Turn it off again and delete the log once you have what you need.
Deactivate plugins and bring them back one at a time
This is the core test. The common errors guide says to deactivate all plugins, then reactivate them one at a time to find the culprit. Check for the problem after each one. When the fault returns, the last plugin you switched on is involved.
That plugin may not be the only one at fault. A conflict needs two parties, so try it again with the others switched off. Then add the rest back slowly. A short written record of what you tested and in what order helps a lot.
- Note every active plugin before you begin.
- Deactivate them all from the Plugins screen.
- Check whether the fault has gone.
- Reactivate plugins one at a time and test after each.
- Stop when the fault returns and note that plugin.
When you are locked out of the dashboard
Sometimes a conflict stops you reaching the admin screens at all. The documentation covers this case too. Connect to your site with FTP and rename the plugins folder to plugins_old, which deactivates everything at once. Once you can log in again, restore the folder name and work through the plugins from the dashboard.
Your hosting control panel may have a file manager that does the same job. Either way, take care to rename only the folder you mean to. Leave the rest of the files exactly as they are. A wrong rename can create a second problem on top of the first.
Rule out the theme
Themes can clash with plugins as well. The common errors guide suggests activating a default theme such as Twenty Twenty-One to rule the theme out. If you are locked out, you can rename the active theme’s folder over FTP instead. If the fault disappears with a default theme, the clash involves your theme.
This step matters most on sites with heavily customised themes. If you use a child theme, check your own custom code as well as the parent. Recent edits to functions.php are worth a close look. Undo them one at a time in the same way you tested the plugins.
Memory limits and other causes
Not every problem that looks like a conflict is one. The documentation says an “Allowed memory size exhausted” error calls for a higher memory limit. You can raise it in wp-config.php or php.ini, or ask your host if you are unsure. For more on keeping a site lean, see our tips to speed up your WordPress website.
Internal server errors can also come from a damaged .htaccess file. The guide suggests renaming it to .htaccess_old over FTP, then resetting your permalinks to create a new one. Try this if deactivating plugins and switching themes changes nothing. It is quick and easy to undo.
Fixing the conflict once you find it
Once you know which plugins clash, you have a few options. Check whether either plugin has a newer version, as the author may already know about the problem. Contact the plugin author with the details from the Site Health Info tab. If the two plugins do the same job, you may only need one of them.
Overlap is common with plugins that handle similar tasks. Running two SEO plugins for WordPress side by side is one example worth avoiding. Pick one and remove the other properly. Then check that your settings still match your plan for WordPress SEO.
Frequently asked questions
Will deactivating plugins delete my settings?
Deactivating switches a plugin off but leaves it installed. Deleting removes its files, and some plugins also clear their data when deleted. Check the plugin’s own notes before you delete anything. During troubleshooting, stick to deactivating.
Will visitors see my site break while I test?
Yes, deactivating plugins on a live site affects everyone who visits. Features like forms or sliders may vanish while you test. Work at a quiet time or use a staging copy if your host provides one. Keep the testing window as short as you can.
Should I leave debugging switched on?
No. The WordPress debugging guide says these tools are meant for local and staging sites. Site Health also flags error display and logging on a public site. Switch them off as soon as you have found the problem.
How do I know which plugin updated recently?
Check the Plugins screen for version numbers and compare them with your notes. The Site Health Info tab also lists each plugin’s version and auto update status. If auto updates are on, a plugin may have changed without you noticing. A simple record of updates makes the next problem easier to trace.
Plugin conflicts feel stressful, but the method is simple. Check Site Health, read the error log, then switch plugins off and back on one at a time. Rule out the theme and memory limits along the way and you will usually find the cause.