How to find every WordPress plugin a site is using
Every asset a WordPress plugin ships — CSS, JavaScript, images — is served from `/wp-content/plugins/<plugin-slug>/`. The plugin slug is the folder name from the WordPress plugin directory (e.g. `elementor`, `woocommerce`, `yoast-seo`). If you can collect every such URL the page loads, you have the plugin list. Same for themes, under `/wp-content/themes/<slug>/`.
Background
WordPress's plugin architecture has a really clean consequence: every plugin that ships frontend assets does so from a deterministic URL path. `/wp-content/plugins/woocommerce/assets/js/frontend/cart.min.js` could only come from the WooCommerce plugin; the path structure is part of the WordPress file convention, not something each plugin gets to choose. The same applies to themes via `/wp-content/themes/<slug>/`. This means that — for any WordPress site you visit — you can extract the full list of plugins loading assets on the current page just by filtering the network tab for `/wp-content/plugins/` URLs and collapsing to unique slugs. Wappalyzer and similar detectors don't do this generically; they only report plugins that have an explicit fingerprint rule in their database. That covers the top 50 or so popular plugins and misses the long tail. Enumeration by slug catches them all.
Why this matters
On a WordPress site, the plugin stack often tells you more than the CMS itself. Is this site on WooCommerce (e-commerce, PHP-heavy) or Easy Digital Downloads (DD-focused)? Does it use Elementor (page builder, huge runtime) or plain Gutenberg (block-native, lighter)? Is there a caching plugin in play (WP Rocket, W3 Total Cache, LiteSpeed Cache)? A security plugin (Wordfence, Sucuri)? A form builder (Gravity Forms, WPForms, Formidable)? Each of those choices constrains the site's performance profile, security posture and maintenance model. Enumerating plugins is the fastest way to go from 'it's WordPress' to 'it's a specific kind of WordPress stack'.
Prerequisites
- A Chrome-based browser with DevTools.
- The target site must actually be on WordPress. If it isn't, there are no `/wp-content/plugins/` URLs to find.
Step-by-step
- 1
Confirm the site is on WordPress
View source and look for `<meta name="generator" content="WordPress ...">`, `/wp-content/` in asset URLs, `/wp-includes/` in script URLs, or a `wp-` prefixed script name. If none of those appear, the site isn't on WordPress and there are no plugins to enumerate.
Tip: `curl -s -L https://target/ | grep -o '/wp-content/[^"]*' | head` is a fast terminal check.
- 2
Collect every /wp-content/plugins/ URL
Open DevTools → Network → 'All', reload, then sort by URL and look for anything under `/wp-content/plugins/<slug>/`. The slug between `plugins/` and the next `/` is the plugin name. Keep a unique list of slugs. Watch for lazy-loaded assets — scroll the page, interact with forms, open menus. More routes may trigger more plugins.
Tip: In the Network tab, use the filter input with `wp-content/plugins` to narrow immediately. Chrome also lets you right-click → 'Copy all as HAR' and parse the JSON offline if you're studying many sites.
- 3
Do the same for themes
Under `/wp-content/themes/<slug>/`. Most sites have exactly one active theme plus an optional child theme, so you'll see one or two slugs. Check the `style.css` in each theme folder — its header comment lists `Theme Name`, `Author`, `Version` and optional `Template` (parent theme).
- 4
Resolve slugs to plugin names
Most slugs map 1:1 to the plugin title on wordpress.org/plugins/<slug>/. Paste the slug into the URL to see the public plugin listing, version, last update, active install count and reviews. For premium plugins not on wordpress.org (WP Rocket, Elementor Pro, Advanced Custom Fields Pro), Google the slug — the results are immediate.
- 5
Check plugin versions
Most plugin asset URLs append `?ver=1.2.3` as a cache-buster — that `ver` query parameter is the plugin version. Collect it from any asset URL for each plugin; it survives across assets because WordPress derives it from the plugin header.
Tip: `?ver=6.4.2` on a jQuery asset is almost always the WordPress core version, not a plugin version. The `ver` on `/wp-content/plugins/<slug>/...` is specifically the plugin's version.
- 6
Let the extension enumerate automatically
Sourcemap Explorer's Stack tab scans every asset URL on the page for `/wp-content/plugins/<slug>/` and `/wp-content/themes/<slug>/`, cross-references known slugs against the built-in fingerprint DB, and lists everything it finds — known plugins under their real name, unknown ones as 'WordPress plugin: <slug>'. No manual scrolling required. Versions from `?ver=` query parameters are extracted and displayed.
Real-world example
Alternative methods
WPScan
Security-oriented CLI that enumerates plugins/themes and correlates with CVEs. Heavier workflow; more for pentest than casual research. Requires an API token for advanced features.
BuiltWith / WhatRuns
Both detect a few top plugins but don't enumerate the long tail. Sourcemap Explorer sees whatever actually ships assets on the page.
RPC and feed endpoints
WordPress exposes REST endpoints (`/wp-json/wp/v2/plugins` when authenticated) and XML feeds. Most are gated behind authentication; they're not a practical enumeration path for external research.
Troubleshooting
I see plugin assets but no version.
Some sites strip `?ver=` query parameters to improve caching. The plugin is still identified by slug; version has to be inferred from file contents or not at all.
A plugin I can see in the admin doesn't show up.
Admin-only plugins don't enqueue frontend assets. Enumeration by slug only catches plugins that ship assets to the current page. Different page, different admin → different results.
The site uses a CDN and I see `cdn.example.com/assets/` instead of `/wp-content/`.
CDNs and asset-rewriting plugins can remap `/wp-content/` to another prefix. Look at the original server `Link:` header or the HTML source for the unrewritten paths; or just follow the remap — the slugs are usually preserved (`cdn.example.com/wp-content/plugins/woocommerce/...`).
I see `/wp-content/uploads/` but no plugins.
Uploads directory is media, not plugins. You're on a WordPress site but this specific page loads no plugin assets — try visiting another page with forms, shop, or interactive elements.
Caveats
What to do next
Once you have the plugin list, the usual follow-up is identifying the active theme (short guide linked below), and from there understanding the overall WordPress stack. For sites with performance concerns the plugin list directly informs which caching/optimization choices are in play.
FAQ
Is enumerating WordPress plugins legal?
You're reading URLs your browser already fetched. You're not authenticating as admin or probing hidden endpoints. It's equivalent to looking at the network tab — which is inherent to running any website in a browser.
Why doesn't Wappalyzer show every plugin?
Wappalyzer only reports plugins that have an explicit fingerprint rule. Sourcemap Explorer complements that by generically enumerating any `/wp-content/plugins/<slug>/` it sees, covering the long tail.
Can I get a list of plugins without visiting the site?
Only with a crawler-based service (BuiltWith, WPScan). The 'visit the page' method sees exactly what the page loads; a crawler can request many pages and aggregate.
Can I see inactive / deactivated plugins?
No. Deactivated plugins don't load assets and aren't visible from the outside. Only active, asset-enqueuing plugins show up.
Related
Skip the manual steps.
Sourcemap Explorer automates every workflow in this guide — free, local, no sign-up.