Must-use plugins are WordPress extensions that load automatically from a special directory. They can explain why a problem survives after ordinary plugins are deactivated. They are also often part of the hosting platform, so deleting the whole directory is a risky troubleshooting shortcut.
Find the Files and Their Owner
In wp-admin, look for the separate Must-Use section on the Plugins screen. Then inspect the site's configured must-use directory through the host's file tools or authorized shell access. The default is wp-content/mu-plugins, but configuration can change it.
The official must-use plugin handbook explains that top-level PHP files load automatically before normal plugins. A small loader may include a larger subdirectory, so one visible file can represent more code than its size suggests.
Do not assume an unfamiliar file is malware. Record its path, header, maintainer, modification context, and the repository or host package that supplies it. Ask the host about files it manages before changing them.
Classify the Behavior You Are Investigating
| Symptom |
What to inspect in custom code |
| Redirect remains with plugins off |
Redirect hooks, host routing, theme behavior |
| Email goes to a test inbox |
Mail filters or environment-specific routing |
| API returns an unexpected denial |
Authentication and capability filters |
| Cache behavior persists |
Host integration and cache-related files |
These are investigation leads, not proof that an mu-plugin caused the issue. Match the request, error, and affected hook to the code before deciding what to disable.
Remember the Other Always-Loaded Components
Must-use plugins are not the same as drop-ins such as object-cache.php, a child theme, a server rewrite rule, or a snippet stored by another plugin. Make a short inventory of each layer so “all plugins disabled” has a precise meaning.
A WordPress command run with normal plugins skipped may still load must-use code. Do not treat a successful or failed command as a complete isolation test without checking what that execution path loads.
Test sheet for wordpress must-use plugins. Record your own evidence.
Test One Component in an Isolated Copy
Capture the original file and configuration before a controlled change. On staging, reproduce the failing URL and record the response. Change only the suspected, clearly owned component, then repeat the same request. Keep an independent file-access path available in case WordPress no longer starts.
If a loader depends on another file, moving only the dependency can create a fatal error rather than a useful test. Have the maintainer disable its functionality intentionally. Host-managed authentication, cache, and security components should be reviewed with the host.
For a live outage that started with an update, use the plugin recovery procedure first. Do not extend an outage by removing unrelated infrastructure code merely to make the plugin list smaller.
Give Must-Use Code a Maintenance Record
Record why the component exists, where its source lives, how it is deployed, and who checks for updates. Normal plugin update notices and activation hooks do not apply in the same way. A successful upload is not proof that setup routines or dependencies ran.
Include these files in the agency handoff. If you cannot identify the owner or safely reproduce the fault, request a scoped investigation with the file paths and redacted error rather than deleting unknown files.
References checked September 28, 2026. Diagrams and worked examples are explanatory, not customer measurements.