How to Detect WordPress Plugins on Any Website

Every WordPress site is built out of plugins, and almost none of them are invisible. The moment a plugin enqueues a stylesheet, prints a form, or modifies the server response, it leaves something behind that a curious visitor can read. The question is rarely whether you can detect a site's plugins — it's how thoroughly, how quickly, and whether you can get from "this plugin exists" all the way to "this plugin is running an outdated, exploitable version." This guide walks through the detection methods in the order a practitioner actually reaches for them, from the one-click extension to a full vulnerability check.

Why anyone bothers detecting plugins

There are a few legitimate reasons. Competitive research: you see a slick membership flow on a competitor's site and want to know if they built it with MemberPress or rolled their own. Pre-sales scoping: a prospective client hands you a URL and you need to estimate the rebuild before quoting. Security auditing: you're checking your own stack — or a client's — for plugins with known CVEs. And straightforward curiosity: you liked how a quiz or a pricing table behaved and want the name of the tool.

Whatever the motive, the techniques are the same, and they form a clear hierarchy. Spend thirty seconds for a rough answer, or thirty minutes for a near-complete one.

The thirty-second answer: browser extensions

The fastest tool is a fingerprinting extension. Wappalyzer, WhatRuns, and BuiltWith all install as browser add-ons, run automatically on every page you load, and surface a panel listing detected technologies — CMS, theme, analytics, and a handful of recognizable plugins like WooCommerce, Yoast, or Elementor.

They're excellent for confirming "yes, this is WordPress" and catching the few dozen heavyweight plugins they explicitly maintain signatures for. Their weakness is coverage. These tools match against a curated rule set, so they reliably miss the long tail — the small utility plugin nobody wrote a fingerprint for, and anything that doesn't announce itself with a well-known marker. Treat the extension result as a floor, not a ceiling. Whatever it found is real; plenty more is usually present that it didn't.

Reading the page source yourself

The single most productive manual move is to open the page source (Ctrl+U / Cmd+Option+U) and search for the literal string wp-content/plugins/. Every plugin that loads a front-end asset prints a URL like:

/wp-content/plugins/contact-form-7/includes/css/styles.css?ver=5.9

The directory name between /plugins/ and the next slash — here contact-form-7 — is the plugin's slug, and for anything hosted on WordPress.org it matches the directory listing exactly. Pasting that slug into https://wordpress.org/plugins/{slug}/ gives you the plugin's real name, author, and active-install count in one step.

This pass catches everything that loads CSS or JavaScript on the front end, which is most of what shapes the visible site. It systematically misses admin-only plugins — backup tools, redirect managers, custom-field engines like Advanced Custom Fields that do their work in the editor and leave no front-end footprint. Those require the deeper methods below.

The ?ver= query string is your version oracle

Look again at that asset URL. The ?ver=5.9 on the end is the detail most casual detection skips, and it's often the most valuable thing on the page. WordPress appends a version string to enqueued scripts and styles for cache-busting, and plugins often pass their own version number into it. So the source doesn't just tell you Contact Form 7 is installed — it frequently tells you exactly which version is installed.

That turns presence detection into vulnerability detection. If the query string reads ?ver=5.7.1 and a publicly disclosed flaw was patched in 5.7.2, you've found an exposed site without touching a security scanner. The signal isn't bulletproof, though, and one failure mode trips people up constantly: when a plugin doesn't set its own version, WordPress falls back to the core release number, so a string like ?ver=6.5 that matches the site's WordPress version tells you nothing plugin-specific. Performance plugins also sometimes strip or normalize the string, and a few developers hardcode a static value. But when the number is present and clearly plugin-specific, it's gold.

What View Source can't show: the Network panel

Plenty of plugin activity lives in the HTTP response rather than the HTML body, and you'll never see it in View Source. Open your browser's DevTools, switch to the Network tab, reload the page, and click the top document request to inspect its response headers.

Caching and security plugins are the usual contributors here. Page caches commonly attach a status header such as x-cache or x-cache-status indicating a hit or miss, and some optimization and security layers add their own identifying or modified headers. The exact header names vary by plugin and by host — some hosts run their own server-level cache that emits similar headers with no plugin involved — so treat headers as corroborating evidence rather than a definitive plugin ID. Still, they're the only place certain server-side plugins reveal themselves at all, which makes the Network tab a mandatory stop for a thorough audit.

Inline markup and comment signatures

While you're in the source, two more patterns are worth scanning for. First, CSS class prefixes: plugins that render front-end markup namespace their classes to their slug — wpcf7- on Contact Form 7 forms, woocommerce- across a store, elementor- on a page built with Elementor. These survive even when asset URLs are bundled and renamed by an optimizer, because the classes are load-bearing selectors the plugin's own CSS depends on.

Second, some plugins print an explicit HTML comment near the end of the document — caching plugins in particular like to sign their work with a "generated by" or "optimized by" attribution line. When present, it's unambiguous. It's just not something you can rely on every plugin to leave.

Querying the site like an API: /wp-json/

Modern WordPress exposes a REST API at /wp-json/. Visiting that root returns a JSON document whose namespaces array lists every registered API namespace — and many plugins register their own. Spotting contact-form-7/v1 or a WooCommerce namespace there confirms an active plugin even when it loads no front-end asset on the page you happened to view. It's a quick, low-effort check that catches a class of plugins the HTML pass alone won't, though plenty of plugins register no REST routes and stay invisible to it.

The exhaustive method: WPScan

For a genuinely complete enumeration — including the admin-only plugins that leave no front-end trace — the tool of record is WPScan, a command-line scanner built specifically for WordPress. Its plugin enumeration runs in two broad modes. Passive detection parses the rendered HTML much as you would by hand. Aggressive enumeration goes further, probing for plugin directories and reading each plugin's readme.txt directly, which is how it finds plugins that never appear in the page source.

The headline command is wpscan --url https://example.com --enumerate p to enumerate all plugins, or vp to focus on only those with known vulnerabilities. Supply a free WPScan API token and the scanner cross-references each detected plugin and version against its vulnerability database, returning the actual CVEs. That readme.txt it reads also carries the version, author, and "tested up to" WordPress release — the same metadata you'd want for judging whether an install is stale.

One important caveat: aggressive enumeration sends a burst of requests and is detectable in server logs. Run it only against sites you own or are explicitly authorized to test. Scanning someone else's site aggressively is, at minimum, rude, and depending on jurisdiction and intent can cross legal lines.

Putting it together

No single method is complete, and the right one depends on how much you need to know. For a quick "what is this," a fingerprinting extension answers in seconds. For a solid manual inventory, search the source for wp-content/plugins/, harvest the slugs and their ?ver= strings, then check the Network panel and /wp-json/ for what the HTML missed. For an exhaustive, authorized security audit that names actual vulnerabilities, reach for WPScan. The footprints are everywhere — the skill is knowing which surface to read for the answer you actually need.