Something is broken, thirty plugins are installed, and one of them is responsible. The usual approach, switch one off, check, switch it back on, can take thirty rounds and changes the live site every time.
First, make it reproducible
Before touching anything, find the exact sequence that produces the fault. Which page, logged in or out, which browser, which action.
If it happens sometimes, you cannot test anything, because a disabled plugin that appears to fix it may simply be a quiet moment. Intermittent faults are usually caching or a scheduled task instead of a plugin at all: understanding WordPress caching layers and WP-Cron cover those.
Work on a copy
Do this on a staging site. Visitors then never see a site missing half its features, and you can be as destructive as the search requires.
There is a second reason: some plugins run cleanup on deactivation, and a few remove settings. Doing that repeatedly on a live site occasionally costs configuration nobody wrote down.
Setting up a WordPress staging site goes into making one.
Halve, do not iterate
Deactivate half the plugins at once. Check.
Still broken. The cause is in the half still running. Fixed; it is in the half you just disabled. Either way you have eliminated fifteen plugins with one check.
Repeat on whichever half contains it. Thirty plugins resolve to one in about five checks rather than thirty.
Keep a written list of what is off at each step. This is where the method actually fails in practice: losing track and having to start again.
When all plugins off does not fix it
Switch to a default theme, Twenty Twenty-Four or similar. If the fault disappears, it is the theme, and no amount of plugin testing was going to find it.
If it persists with every plugin disabled and a default theme, the problem is not in the site's code. Look at the server: PHP version, memory, a `.htaccess` rule, a security module. The error logs will usually name it.
Doing it without the dashboard
When the fault locks you out of wp-admin, the dashboard is not available to disable anything with. Two routes.
Over SSH, WP-CLI is quickest:
wp plugin list --status=active wp plugin deactivate --all wp plugin activate akismet woocommerce
Without SSH, rename the plugins directory in File Manager. WordPress finds no plugins and deactivates all of them, which usually restores admin access. Rename it back and they return, deactivated, to be re-enabled in groups.
Recovering when you are locked out of wp-admin goes into the rest of that situation, and using WP-CLI explains the tool.
When two plugins are the problem
Occasionally no single plugin causes it. Two conflict, and the fault only appears with both active.
The symptom is confusing: disabling either one fixes it, so both look guilty. If halving gives inconsistent results, this is usually why.
Identify the pair, then decide which you actually need. Reporting it to both authors is worth doing and is not a fix on any useful timescale.
After you find it
Do not simply leave it deactivated and move on, unless you did not need it.
Check whether the plugin is current, whether the fault is known, and when it was last updated. A plugin untouched for two years against a current WordPress is a problem waiting to recur regardless of this particular fault. Choosing and vetting WordPress plugins walks through judging that.
Then write down what you found. The next occurrence, months later, will otherwise start from the beginning.
Rule out the environment first
Before halving anything, establish that the fault is in the site at all. Three checks that take a minute and occasionally end the investigation.
A different browser, and a private window. An extension or a cached script explains a surprising share of "the admin is broken" reports.
A different network. A block on the visitor's address produces symptoms that look like a site fault.
The server's error log. A memory limit or a timeout appears there and not in any plugin.
Each of these produces a fault that no amount of plugin testing will find, and each is cheaper to check than one round of halving. Debugging with WP_DEBUG and logs explains the logging half.
Halving with WP-CLI, deterministically
Doing this by hand loses track. Doing it from the command line does not, and it is considerably faster.
wp plugin list --status=active --field=name > all.txt head -n $(( $(wc -l < all.txt) / 2 )) all.txt > half.txt wp plugin deactivate $(tr '\n' ' ' < half.txt) # test, then either: wp plugin activate $(tr '\n' ' ' < half.txt)
Keeping the current state in files means an interrupted session can be resumed rather than restarted, and it makes reactivating everything at the end a single command.
Record which half failed at each step. Five lines of notes is what separates a five-round search from starting again. Using WP-CLI explains reaching these commands, including confirming which site you are pointed at.
Restore everything, verifiably
The end of the search is the step people get wrong: plugins reactivated from memory, one missed, and a feature quietly missing for weeks.
wp plugin list --status=active --field=name | sort > after.txt diff <(sort all.txt) after.txt
Capturing the original list before starting and diffing against it at the end makes that impossible to get wrong.
Note also that deactivating and reactivating is not always neutral: some plugins run setup on activation and can reset settings. That is a further argument for doing this on a copy rather than on the live site.
When it is the theme or the host
If the fault survives every plugin being off, two candidates remain.
Switching to a default theme tests one of them in thirty seconds. Where the theme is the cause, the child theme's functions.php is the usual location. A snippet added years ago that a WordPress or PHP update has now broken.
If a default theme with no plugins still fails, the site is not the problem: PHP version, memory, an .htaccess rule or a security module is. Upgrading the PHP version goes into the commonest of those.