I scanned a client's shop for plugins and got back three. The site was running twenty-six. Nothing was broken and nothing was hidden on purpose: their optimisation plugin had merged every script into one combined file, and a merged file has no plugin folders in its name. The scan was accurate about what the page loaded and useless as an inventory, which is the distinction this guide is about.
Detecting plugins from outside a site is genuinely useful and genuinely limited, and most tools only tell you the first half. Here is how the detection works, what each result can and cannot mean, and how to read a short list without drawing the wrong conclusion. The WordPress Plugin Detector reports both halves on purpose.
TL;DR: Plugin detection works by finding files loaded from
/wp-content/plugins/<slug>/in a page. Anything that does not load a front-end file is invisible: admin-only plugins, plugins that fire on other pages, and anything whose assets a caching plugin merged into one combined file. Treat the result as a floor, never a total. Scanning an interior page instead of the homepage reliably finds more.
How does plugin detection actually work?
A plugin that does anything visible has to load something from its own folder. WordPress serves plugin files from a fixed path, /wp-content/plugins/<slug>/, so any stylesheet, script or image loaded from there names the plugin that owns it:
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css?ver=5.9.3" />
<script src="/wp-content/plugins/woocommerce/assets/js/frontend/cart-fragments.min.js?ver=9.2.3"></script>
That is contact-form-7 and woocommerce, stated by the page rather than inferred from how it behaves. A few plugins announce themselves more plainly still: a body class, a REST namespace under /wp-json/, a meta tag, an HTML comment, a cookie name.
The version usually rides along in the query string. ?ver=5.9.3 is what WordPress appends for cache-busting, and on most installs it is the plugin's real version. Sites that strip version query strings for caching reasons, or that hard-code a value, will report nothing or something stale.
| Evidence | Example | Confidence |
|---|---|---|
| Asset path | /wp-content/plugins/woocommerce/... |
The plugin loaded a file on this page |
| Version query string | ?ver=9.2.3 |
Usually the installed version |
| REST namespace | /wp-json/wc/v3 |
The plugin registered API routes |
| Body class | woocommerce-page |
The plugin is active on this page type |
Why do so many plugins stay invisible?
Four ordinary setups hide plugins, and none of them mean the site is doing anything wrong.
Admin-only plugins load nothing for a visitor. Backup schedulers, SEO editors, migration tools, user role managers, staging utilities: they do their work inside wp-admin and add nothing to the front end. A large share of any real site's plugin list is in this category and is invisible from outside by design.
Plugins fire on the pages they are for. A checkout plugin loads on the checkout. A form plugin loads where the form is. Scanning a homepage and concluding the site has three plugins is like reading the first page of a book and reporting its word count.
Optimisation plugins erase folder names. This is the big one. A plugin that concatenates every script and stylesheet into one file under a cache folder removes the plugin folder names of everything it merged, including its own. The code is all still there. The evidence is not.
Hosts and CDNs rewrite asset paths. Some managed hosts proxy every static file through a path that no longer contains /wp-content/plugins/. Same effect, applied to the whole site at once.
So an empty result has at least five meanings: no plugins are active, none load front-end assets, an optimiser merged them, the host rewrote the paths, or the site is not WordPress. A tool that reports "0 plugins" without separating those is not reporting a finding, it is reporting its own blind spot.
What does a folder name without a real name mean?
Detection gives you a slug. Turning that slug into a published name, a current version and an install count requires matching it against the plugin directory, and not every plugin is in one.
A bare slug with no matching entry almost always means one of three things. It is a premium plugin sold outside WordPress.org, which describes most commercial page builders, form plugins and membership systems. It is custom, written for that one site by whoever built it. Or the folder has simply been renamed, which some site owners do deliberately.
That is itself a useful signal. A site whose plugin list is mostly unmatched slugs is running commercial or bespoke software, and that tells you something about the budget behind it before you have asked anyone a question.
How do you get a more complete picture?
Scan more than one page. This is the single highest-value habit, and it costs nothing:
- The homepage, for the site-wide furniture: analytics, consent banners, page builders, sliders.
- A blog post, for content-side plugins: related posts, table of contents, social sharing, comment systems.
- A product or pricing page, for commerce: the shop plugin, payment gateways, currency switchers.
- A contact page, for forms, maps and spam protection.
Take the union. Even then it is a floor, but a much higher one than any single page gives.
The /wp-json/ index is worth a look too, when it is enabled. Plugins that register REST routes appear there by namespace regardless of what the front end loaded, so it catches some of what asset paths miss:
curl -s https://example.com/wp-json/ | grep -o '"namespace":"[^"]*"' | sort -u
Is scanning someone's site acceptable?
Reading a public page is an ordinary request. It appears in the site's access log exactly like a visit from a browser, and it does not log in, submit anything or touch the admin area. The WordPress security documentation is concerned with what an authenticated or probing request can do, not with what a page voluntarily publishes to every visitor.
Where it gets sharper is intent. A plugin list is reconnaissance if you use it as one: an outdated version of a plugin with a known vulnerability is exactly what an attacker looks for. That is a reason to keep your own plugins updated rather than a reason to pretend the information is secret, since anyone can read the same page. If you are auditing a site you do not own, stick to what the page tells you and leave it there.
What the result is good for
Used within its limits, an outside plugin scan answers real questions quickly. Which page builder is this site using, so I can quote for changes. Is this shop on WooCommerce or something hosted. What is the form plugin, so I can match it. Is this competitor running the same SEO stack we are. Is my own staging site accidentally loading a plugin I disabled locally.
What it cannot do is produce an inventory. For that you need the admin, wp plugin list over WP-CLI, or someone who has the login.
If the question is what is rendering the page rather than what is loading on it, that is the WordPress Theme Detector, which reads the theme's own style.css for the name, version and parent. And when you are the one publishing a plugin, the readme generator writes the readme.txt that decides how your plugin's own directory listing reads.
