How to Disable WordPress Plugins Without Admin Access

Quick fix: if you know which plugin broke the site, rename only its directory inside wp-content/plugins. If the culprit is unknown and SSH is available, use WP-CLI to deactivate all standard plugins. Do not delete plugin files or database records while diagnosing.

Take a backup first, especially on ecommerce or membership sites where plugins process live data.

Method 1: Disable one plugin through SFTP or File Manager

Connect through SFTP or open the host’s file manager. Navigate to:

wp-content/plugins/

Find the suspected plugin directory and rename it:

example-plugin
example-plugin.disabled

Reload the failed page or /wp-admin/. If access returns, the plugin—or its interaction with another component—caused the failure.

Keep it disabled while you:

• read the PHP/server log;
• check its update and PHP requirements;
• compare the failure time with its last update;
• test a clean or rolled-back version on staging;
• contact the plugin vendor with the exact fatal error.

Rename the directory back only when you are ready to test. WordPress may keep it deactivated because the original plugin file was missing.

Method 2: Disable all plugins with WP-CLI

From the WordPress root:

wp plugin deactivate --all --skip-plugins --skip-themes

The skip flags prevent plugin and theme code from loading into the WP-CLI command. List the result:

wp plugin list --skip-plugins --skip-themes

If the site works, reactivate one plugin at a time on staging:

wp plugin activate plugin-slug --skip-plugins --skip-themes

Reload the original failing action after each activation. The most recently activated plugin is not automatically defective; it may conflict with an earlier plugin, so record the combination.

Method 3: Reset the standard plugins directory

When WP-CLI is unavailable and the culprit is unknown, rename the entire directory:

wp-content/plugins
wp-content/plugins.hold

Create an empty plugins directory only if your host/application requires it, then try to access wp-admin. Open the Plugins screen so WordPress records the missing standard plugins as deactivated.

Restore the original directory name:

wp-content/plugins.hold
wp-content/plugins

The files return, but plugins that WordPress marked missing should remain inactive. Reactivate carefully after reviewing the site.

This procedure follows WordPress’s official troubleshooting guidance. It preserves plugin directories and settings; it is not an uninstall.

What this does not disable

Standard plugin deactivation does not necessarily stop:

• wp-content/mu-plugins/ must-use plugins;
• wp-content/advanced-cache.php;
• wp-content/object-cache.php;
• wp-content/db.php;
• host-level caching, firewall or monitoring agents;
• network-activated plugins on Multisite.

Inspect these only when logs or the host point to them. Renaming a database or object-cache drop-in can affect availability and performance, so follow its provider’s removal procedure.

Multisite warning

On WordPress Multisite, network-active plugins affect multiple sites. Use network-aware WP-CLI commands and understand the scope before deactivation. Coordinate changes with every site owner and test shared functionality.

Do not edit the serialized active_sitewide_plugins option manually unless recovery has no safer route and a verified database backup exists.

Find the plugin instead of leaving everything off

Read wp-content/debug.log and the PHP error log. A path such as:

/wp-content/plugins/example-plugin/includes/file.php

is stronger evidence than activation order alone.

If no fatal appears, reactivate plugins in small groups on staging, then split the failing group. This binary-search approach is faster than testing dozens sequentially.

Verify business-critical functions

Disabling plugins can stop forms, payment gateways, security controls, backups, redirects and caching. After recovery, test:

• login and password reset;
• contact and transactional email;
• cart, checkout and webhooks;
• bookings or memberships;
• scheduled tasks;
• backups and security events.

If the failure was a blank page, continue with the White Screen guide. For a server response, use the 500 error checklist.