Paste any WordPress site below to see which theme and plugins it runs, what version of WordPress it is on, and which of those plugins have been removed from the WordPress.org directory. That last part is the bit most detectors leave out, and it is the part that matters.
- Detection works by reading the CSS and JavaScript a site loads publicly. Plugin and theme folder names sit right there in the page source.
- This scanner also checks every plugin it finds against the WordPress.org API, so you see which ones are closed, abandoned or simply stale.
- A plugin that has been closed for a security issue will never be patched. That is the finding worth acting on.
- Only plugins that load front-end files can be detected. Admin-only plugins are invisible to any scanner, including this one.
- A site that hides its WordPress version is not being difficult, it is following a reasonable hardening practice.
How a WordPress theme and plugin detector actually works
There is no magic to it. WordPress serves theme and plugin assets from predictable paths, and those paths contain the folder name of whatever produced them.
Open any WordPress site, view source, and search for wp-content. You will find lines like these:
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/style.css?ver=3.4.5">
<script src="/wp-content/plugins/wp-rocket/assets/js/lazyload.min.js"></script>The theme is hello-elementor. The plugin is wp-rocket. The ?ver= parameter often gives away the version too. A detector automates that reading and then looks each name up.
This is also why detection has a hard ceiling. A plugin that only runs in the admin, or one that never enqueues a front-end file, leaves no trace in the public page. No detector can see it, and any tool claiming a complete plugin list is overstating what is possible.
Why the risk column matters more than the plugin list
Knowing a site runs Yoast is mildly interesting. Knowing it runs a plugin that WordPress.org pulled from the directory in 2021 over a security issue is genuinely useful, because that plugin will never receive another update.
When WordPress.org removes a plugin, the listing stays up but downloads stop, and the page states the date and often the reason. Sites already running it keep running it. Nothing warns the owner. The plugin simply sits there, frozen at its last version, indefinitely.
We found exactly that while auditing this site: two plugins recommended in an old roundup here had been closed for security issues years earlier, and were still being recommended to readers. Nothing in WordPress flagged it. That is the gap this scanner is built to close.
The scanner sorts what it finds into four states:
- Closed. Removed from the WordPress.org directory. Where a reason is published, you will see it. Replace these.
- Abandoned. No release in over two years. Usually still works, but nobody is watching it for vulnerabilities.
- Stale. No release in over a year. Worth a look, not an emergency.
- Not listed. Not in the directory at all, which is completely normal for premium plugins like Elementor Pro or WP Rocket. This is deliberately kept separate from “closed” so a paid plugin never looks like a removed one.
If the scanner turns up something closed or abandoned on your own site, the next question is what to move to. Our plugin replacement finder takes a slug and suggests maintained alternatives, checking each suggestion is still live before showing it.
What the WordPress version tells you
The scanner reports core version when it can find one, and says so plainly when it cannot.
Version numbers usually come from the generator meta tag, the RSS feed, or the version query string on core’s own stylesheets. Many sites strip these, and stripping them is a reasonable hardening step rather than a problem. If the scanner says the version is hidden, that site is doing something sensible.
One trap worth knowing, because it catches a lot of home-made detectors: the file wp-includes/js/jquery/jquery.min.js?ver=3.7.1 is jQuery’s version, not WordPress’s. A tool that reads any versioned file under wp-includes will confidently tell you a site is running WordPress 3.7.1. This scanner only trusts files that core versions with the release number.
To check the version of a site you control, and for the seven manual methods including WP-CLI and the RSS feed, see how to check your WordPress version.
Good reasons to scan a site
- You are taking over a site you did not build and need to know what is on it before touching anything.
- You are quoting on maintenance and want to see how much technical debt you are inheriting.
- You liked something on a competitor’s site and want to know which plugin does it.
- You are auditing your own site and want an outside view of what is publicly visible.
- A client says they have “just a few plugins” and you would like to verify that.
The scan is read-only. It requests pages the same way any visitor would, changes nothing, and never attempts a login. Private IP addresses and internal hostnames are refused outright.
Frequently Asked Questions
Why did it miss a plugin I know is installed?
Because that plugin does not load anything on the front end. Detection reads the CSS and JavaScript a page serves publicly, so admin-only plugins, most backup and migration tools, and anything that only runs on a schedule are invisible. Caching and file-combining plugins can also merge asset paths so the original folder names disappear, which hides plugins that would otherwise show up.
Is it legal to scan someone else’s site?
This tool only requests pages that the site already serves to the public, which is exactly what your browser does when you visit. It does not attempt logins, does not probe for vulnerabilities, and does not try to access anything that is not already published. That is ordinary browsing, automated.
It says my site is not WordPress, but it is.
A few setups hide the usual signals. Headless WordPress serves a front end built with something else entirely, so the WordPress paths never appear. Some security plugins rewrite wp-content to a custom path. Aggressive caching layers and full-page CDNs can also strip or rewrite asset URLs. In those cases the site really is WordPress, but there is nothing public left to detect it by.
A plugin shows as “not listed”. Is that bad?
No. It means the plugin is not in the WordPress.org directory, which is normal for every commercial plugin: Elementor Pro, WP Rocket, Gravity Forms and Advanced Custom Fields Pro all sit outside it. We keep this state separate from “closed” on purpose, because reporting a paid plugin as removed would be both wrong and alarming. Check the vendor’s own site for update status on those.
How do I hide my own plugins from tools like this?
You can reduce what is visible, but you cannot eliminate it, and it is worth being honest about how much this buys you. Removing the generator tag, stripping version query strings, and combining assets all make fingerprinting harder. None of it makes an outdated plugin safe. Obscurity slows down casual scanning; updates are what actually protect you. Spend the effort on keeping things current first.
Other free tools we have built: a WordPress version checker, an uptime checker, a salt generator, and a child theme generator.
Browse all our free WordPress tools, all free and none of them asking for an email address.
