Must-use plugins load automatically on every single request and never show up in the regular Plugins screen at all, which means whoever currently manages the site may not even know they exist, let alone understand what they do — a state that’s harmless right up until something needs debugging and nobody realises there’s an entire invisible layer of code also running behind the scenes. This isn’t a design flaw in WordPress so much as a deliberate tradeoff — mu-plugins exist precisely because certain code needs to be guaranteed active no matter what, which is a genuinely useful property that just happens to come at the cost of visibility for whoever inherits the site later without full context.
Look in the mu-plugins folder directly
Since these plugins don’t appear in wp-admin at all, seeing them requires FTP or file manager access to the wp-content/mu-plugins folder, where each file or subfolder represents one piece of always-active code.
Finding files there you don’t recognise, or that a previous developer added without documentation, is a reasonable early sign this audit has real value for your site specifically.
It’s also worth thinking about how many people have managed the site’s technical side over the years, since each transition between developers or agencies is a point where this kind of undocumented, invisible addition tends to accumulate. None of that history is essential to have ready, but it does help set expectations for how much we’re likely to find. A site with a long list of past contributors tends to yield more surprises than one with a single, consistent steward.
mu-plugins audit & documentation
Must-use plugins load on every request without ever appearing in your regular plugin list. We catalogue what's actually running and why.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- FTP or file access, since these plugins aren’t visible from the WordPress admin
- Any documentation you already have, even informal, about why specific mu-plugins were added
- Whether you want a recommendation on removing anything found to be unnecessary
This or something else?
| You want mu-plugins catalogued and explained, since nobody currently knows what’s there | This fix covers it |
| You want your regular, visible plugin list audited instead | Plugin audit & rationale report, a different service |
| A specific mu-plugin is actively causing a problem right now | A different, more urgent diagnosis |
| You want custom code snippets relocated, not mu-plugins documented | Custom snippet audit & relocation, a different service |
| You’re confident no mu-plugins exist on your site at all | Worth a quick look first; they’re easy to overlook entirely |
What we do
- Access the mu-plugins directory and identify every file or folder present
- Determine what each one actually does and how it affects the site
- Trace the likely origin of each, whether from your host, a plugin, or custom development
- Flag anything genuinely unnecessary or safe to remove, without removing it ourselves unprompted
- Document each mu-plugin in plain language for future reference
- Deliver a written report so this layer is no longer invisible to whoever manages the site next
What is included
- A full catalogue of every mu-plugin currently active on the site
- A plain-language explanation of what each one does and where it likely came from
- Flagging of anything that looks safe to remove, without acting on it unprompted
- A written report for ongoing reference
Not included
- Removing any mu-plugin, which is a separate, explicitly confirmed action
- Auditing your regular, visible plugin list, which is a separate service
- Debugging a specific active problem caused by a mu-plugin, which is more urgent
- Re-auditing after someone adds a new mu-plugin outside this process — that’s a fresh, separate audit
Questions about this fix
Why would anyone add a plugin this way instead of normally?
Hosts often use mu-plugins for things they want guaranteed active, such as certain security or performance features, and developers sometimes use them for code that should never be accidentally deactivated.
Is it safe to just delete files I don't recognise?
Not without checking first — some are genuinely load-bearing, added by your host or a past developer for good reason, which is exactly why we investigate before flagging anything as removable.
Will this slow down my site if there are a lot of them?
Possibly, since every mu-plugin runs on every single request regardless of whether a page actually needs it, which is one of the things worth knowing from this audit.
Could my host have added some of these without telling me?
Yes, this is common, particularly for certain managed hosting features, and we note where that appears to be the case.
Does every WordPress site have mu-plugins, or only some?
Only some — many sites have none at all, so finding an empty folder is a perfectly normal, if slightly anticlimactic, result.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.