What Is a WordPress Must-Use Plugin?
A WordPress must-use plugin, or MU-plugin, is a plugin that loads automatically on every request and cannot be deactivated from the normal Plugins screen. You install one by placing a PHP file in the wp-content/mu-plugins folder. Because they always run and are hard to switch off accidentally, hosts and agencies use MU-plugins to enforce security rules, add critical functions, or apply platform-wide settings that must never be turned off. The tradeoff is less visibility, since MU-plugins do not appear in the usual plugin list.
- Definition
- Plugins in wp-content/mu-plugins that load automatically and always run (WordPress Developer docs)
- Cannot deactivate
- They have no activation toggle and cannot be disabled from the Plugins screen (WordPress Developer docs)
- Load order
- MU-plugins load before regular plugins, in alphabetical order, on every page load
- Files only
- Only top-level PHP files in mu-plugins run automatically; subfolders need a loader file
- Common users
- Managed hosts and agencies use them for security, must-keep functions, and platform settings
What a must-use plugin is #
A must-use plugin is a special kind of WordPress plugin that runs on every page load and cannot be switched off through the normal dashboard. Instead of installing and activating it on the Plugins screen, you place its PHP file directly into a folder called wp-content/mu-plugins, and WordPress loads it automatically. The must-use in the name reflects the intent: this code is meant to always be active, no exceptions. Because there is no activation toggle, an editor or client cannot accidentally deactivate critical functionality, and a compromised admin account cannot as easily disable protective code. This makes MU-plugins a favorite tool of managed hosts and agencies who need certain rules to hold no matter what. They are a core part of professional /services/managed-hosting setups. The tradeoff is transparency: because MU-plugins do not appear in the standard plugin list, someone unfamiliar with the site may not realize they exist, which can puzzle future developers. For an owner, the practical takeaway is to know the folder exists and to check it whenever a site behaves in ways the plugin list cannot explain.
How WordPress loads MU-plugins #
WordPress treats the mu-plugins folder specially. On every request it scans that folder for top-level PHP files and includes each one automatically, before any regular activated plugins run. This early, guaranteed loading is what makes MU-plugins reliable for foundational tasks. The ordering is alphabetical by filename, so if load sequence matters you can prefix filenames with numbers to control it. One important quirk trips people up: only PHP files sitting directly in mu-plugins are auto-loaded. If a plugin ships as a folder with subfiles, dropping that folder in does nothing on its own; you need a small loader file at the top level that includes the folder's main file. This design keeps MU-plugins simple but occasionally surprising. Because they run so early and always, MU-plugins are ideal for the kind of platform-level guarantees that /services/website-security work depends on, such as enforcing headers or blocking risky requests before the rest of WordPress even initializes for the visitor.
Creating a simple must-use plugin #
Building an MU-plugin is straightforward: write a normal PHP file with your code and place it in wp-content/mu-plugins. There is no activation step, it simply runs. The example below creates a small MU-plugin that disables the theme and plugin file editors in the dashboard, a common security hardening step you never want a client to reverse. Because it lives in mu-plugins, no one can deactivate it from the Plugins screen, and it takes effect on every request. A short comment header is optional but helpful, since WordPress does show MU-plugins in a separate Must-Use tab within the Plugins area, giving at least some visibility. Keeping MU-plugin files small, focused, and well-commented is good practice, because their invisibility means the next person may not expect them. Agencies delivering ongoing /services/care-plans often ship a single MU-plugin bundling a handful of must-keep tweaks, so essential behavior travels with the site and cannot be undone by accident.
<?php
/*
* Plugin Name: LWA Must-Use Hardening
* Description: Always-on security tweaks. Cannot be deactivated.
*/
// Disable the built-in theme/plugin file editors
if (!defined('DISALLOW_FILE_EDIT')) {
define('DISALLOW_FILE_EDIT', true);
}
// Hide the WordPress version from the page head
remove_action('wp_head', 'wp_generator');Why hosts and agencies use them #
Managed hosts and agencies rely on MU-plugins to enforce behavior that must never be turned off, whatever a site owner or a rogue login might do. A host might use one to apply object caching, set security headers, restrict certain dangerous functions, or inject platform-specific optimizations across thousands of sites at once. An agency might use one to keep a client's essential customizations, like analytics tracking or a critical redirect, permanently active even if the client experiments with plugins. Because MU-plugins load first and cannot be casually disabled, they provide guarantees that ordinary plugins cannot. This reliability is why they underpin serious /services/managed-hosting and /services/website-security offerings. The flip side is that MU-plugins can also hide vendor lock-in or surprising behavior; a host's MU-plugin might do things you did not expect, which becomes relevant during a move. Knowing they exist and checking the mu-plugins folder is an essential step whenever you inherit or audit a WordPress site.
MU-plugins versus regular plugins #
The core differences come down to control and visibility. Regular plugins are installed and activated in the dashboard, appear in the Plugins list, can be turned on or off, and update through the normal system. MU-plugins are placed in a folder, load automatically, cannot be deactivated from the standard screen, and do not auto-update, meaning you must maintain them manually. This makes MU-plugins right for code that should always run and wrong for anything you might want to toggle or that ships regular updates. Using an MU-plugin for a normal feature plugin would strip away update notifications and the ability to disable it for troubleshooting. The rule of thumb: reserve MU-plugins for small, foundational, must-always-run snippets, and keep everything else as standard plugins. Getting this boundary right is part of disciplined /services/wordpress-development. Misusing MU-plugins, such as dropping a large third-party plugin into the folder to force it on, tends to create maintenance headaches later that outweigh the convenience. If you would ever want to toggle it off to troubleshoot, it should be a regular plugin, not an MU-plugin.
The visibility tradeoff #
The biggest practical drawback of MU-plugins is that they are easy to overlook. They do not appear in the main Plugins list, so a new developer, a client, or an auditor scanning installed plugins might miss significant code entirely. WordPress does provide a Must-Use tab in the Plugins area listing top-level MU-plugin files, but code loaded indirectly through a loader file can stay hidden even there. This invisibility is a double-edged sword: it protects critical code from being disabled, but it also conceals behavior that could be causing mysterious effects. When a site behaves strangely and nothing in the plugin list explains it, the mu-plugins folder is one of the first places an experienced developer checks. This is a routine part of /services/website-rescue investigations. The lesson for anyone building MU-plugins is to document them clearly, keep them minimal, and note their existence in any handover, so the next person is not blindsided by code they cannot see in the usual place.
MU-plugins during migrations and audits #
Because MU-plugins load automatically and often carry host-specific or agency-specific behavior, they demand attention during moves and audits. When migrating a site, the mu-plugins folder must be examined, not just copied blindly, because a host's MU-plugin may reference infrastructure that does not exist on the new server, causing errors, or may enforce settings you no longer want. Conversely, forgetting to bring over a legitimate MU-plugin can silently drop essential functionality like tracking or security rules. A careful /services/website-migrations process inventories every MU-plugin, decides which to keep, adapt, or discard, and tests the site with and without them. During a security or performance audit, MU-plugins are checked for outdated or risky code, since they run with full privileges on every request and never auto-update. Treating the mu-plugins folder as a first-class part of the site, rather than an obscure corner, is what separates a thorough migration or audit from one that leaves surprises waiting to surface later.
When you should use a must-use plugin #
Reach for an MU-plugin when a small piece of code must run on every request and must never be accidentally disabled, and when you accept responsibility for updating it manually. Good candidates include a handful of security hardening lines, a critical redirect that cannot be lost, or a platform-level tweak an agency wants to guarantee across a client's site. Avoid MU-plugins for anything you might want to toggle for troubleshooting, for large third-party plugins that ship updates, or for code a non-technical owner should be able to manage. When used with discipline, and documented so the next person can find them, MU-plugins are a clean way to lock in essentials, which is why they feature in mature /services/care-plans and /services/managed-hosting. If you are unsure whether a customization belongs in an MU-plugin, a regular plugin, or the theme, a brief review through /contact can help you choose the option that stays maintainable as the site grows. Documenting each MU-plugin in a simple readme note, so the next developer knows what runs and why, prevents hours of confused investigation later.
FAQ
Where is the mu-plugins folder?
It lives at wp-content/mu-plugins, alongside the regular plugins and themes folders. WordPress does not create it by default, so you may need to add it yourself. Any top-level PHP file you place there loads automatically on every request, with no activation needed. Subfolders require a small loader file to run.
Can I deactivate a must-use plugin?
Not from the normal Plugins screen, since MU-plugins have no activation toggle. To disable one you remove or rename its file in the wp-content/mu-plugins folder using a file manager, FTP, or SSH. That is precisely why hosts and agencies use them, to keep critical code active even if someone tries to turn it off.
Do must-use plugins update automatically?
No. Unlike regular plugins, MU-plugins do not receive automatic updates and are not tracked by the update system. You must maintain and update their code manually. This is a key reason to reserve MU-plugins for small, stable snippets rather than large third-party plugins that depend on frequent security and feature updates.
Why can't I see a must-use plugin in the plugin list?
MU-plugins do not appear in the main Plugins list because they cannot be activated or deactivated there. WordPress shows top-level MU-plugin files under a separate Must-Use tab in the Plugins area. Code loaded indirectly through a loader file may not show even there, which is why developers check the mu-plugins folder directly.
Are must-use plugins a security risk?
They can be, because they run with full privileges on every request and do not auto-update, so outdated or malicious code there is dangerous and easy to overlook. Used well, though, they improve security by locking in protections that cannot be disabled. The key is knowing they exist, keeping them minimal, and auditing them regularly.
Should I move my plugins to mu-plugins for speed?
Generally no. MU-plugins load slightly earlier but offer no meaningful speed advantage over well-built regular plugins, and moving normal plugins there strips away updates and the ability to disable them for troubleshooting. For real performance gains, focus on caching, image optimization, and hosting rather than relocating plugins into the mu-plugins folder.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?