Sometimes a WordPress site crashes without you changing anything recently, or you have so many plugins you can’t tell which one is to blame. The goal is to move from “something is broken” to “this plugin is broken” as fast as possible. Here are three methods, from fastest to most thorough.
Method 1: Let the error tell you – read the stack trace
First, turn on logging. In wp-config.php, add define( 'WP_DEBUG', true ); and define( 'WP_DEBUG_LOG', true ); and set WP_DEBUG_DISPLAY to false. Reload the page that crashes and open wp-content/debug.log.
A fatal error almost always names a file path. If it says /wp-content/plugins/superslider/superslider.php, the plugin superslider is where the error originated. For a PHP fatal, the plugin on the trace’s originating line is your prime suspect – strong evidence, but not yet proof. Confirm it by deactivating or rolling back that one plugin; if the error stops, you have your answer and can skip to the fix. If it’s missing, or points at WordPress core, continue with isolation.
Method 2: The bisect (deactivate-half) method
When the log isn’t enough, isolate by stepping. Instead of deactivating one plugin at a time – which is slow with 40 plugins – you halve:
- Deactivate half of all plugins.
- Is the error gone? Then the culprit is in the disabled half. Does it remain? Then it’s in the active half.
- Take the suspect half and halve it again.
- Repeat until one plugin remains.
With 40 plugins you find the culprit in roughly six steps instead of up to forty. Locked out of wp-admin? Rename the whole wp-content/plugins folder to plugins.off over FTP – that deactivates everything – then rename it back and step forward.
Method 3: Health Check’s troubleshooting mode
The bisect method has a downside: you’re disabling plugins for all visitors while you test. The official Health Check & Troubleshooting plugin solves that. Its Troubleshooting Mode deactivates all plugins and switches to a default theme – but only for your own logged-in session. Visitors see the site as normal.
Enable troubleshooting mode, verify the error disappears, then turn plugins back on one at a time from the toolbar until the error returns. The plugin that triggers the error is your culprit. This is a safe isolation test – you experiment without taking down the public site.
Switch to a default theme
Not a plugin? Switch to a default theme like Twenty Twenty-Four. If the error disappears, the cause is in your theme or a child theme, not among the plugins.
Common traps
- Cache. Clear page, object and CDN cache between each test, or you’re testing a stale version.
- Must-use plugins. Check
wp-content/mu-pluginstoo – they don’t appear in the normal plugin list and aren’t disabled by troubleshooting mode. - PHP version. A plugin may work on PHP 7.4 but crash on PHP 8.2. Check it in Site Health.
When isolation should be one click
Bisecting and troubleshooting mode work, but they’re manual and time-consuming – and you often have to do it on a site that’s already in trouble. Ravnsight’s Detective groups identical errors so a hundred log lines become one clear case, and attributes each group to the right plugin, theme or core based on the stack trace. Instead of guessing which half to disable, you see immediately “312 occurrences, attributed to superslider.”
When you need to confirm, Detective offers a safe isolation test in the same spirit as Health Check – so you can verify the hypothesis without fumbling in FTP. You keep the scientific method, but skip the tedious manual labor.
