How to Detect WordPress Plugins on Any Website

There are roughly 60,000 plugins in the WordPress plugin directory and probably another 10,000-30,000 commercial plugins distributed outside it. Almost all of them leave detectable traces in the front-end HTML of any page that activates them. The trick is knowing the five places those traces show up, because no single location catches every plugin.

Location one: the wp-content/plugins/ path

The most obvious location. Plugins that load CSS or JavaScript on the front-end include URLs like /wp-content/plugins/{plugin-slug}/assets/script.js. Search the page source for the literal string wp-content/plugins/ and you get a list of every plugin loading assets. The slug between /plugins/ and the next slash is the plugin's directory name, which almost always matches the WordPress.org slug.

This location is reliable for plugins that load front-end assets. It misses plugins that only run in the admin interface (Advanced Custom Fields registering fields, Redirection editing redirects, UpdraftPlus running backups). For admin-only plugins, the next four locations apply.

Location two: inline JavaScript variables

Many plugins inject a global JavaScript variable into the page for their front-end code to read. Yoast SEO sets window.wpseo. Elementor sets window.elementorFrontend. WPForms sets window.wpforms_settings. Searching the page source for these specific variable names confirms the plugin is active even when its asset path has been minified or rewritten through a CDN.

Location three: HTML class names

Plugins that render front-end markup use a class name prefix tied to the plugin slug. Yoast SEO output has yoast- classes. Contact Form 7 forms have wpcf7-. WooCommerce has woocommerce- everywhere. Elementor renders elementor-element, elementor-widget, and dozens of other prefixed classes.

Class-name detection catches plugins whose asset URLs have been bundled and renamed. The class names survive because they function as meaningful selectors in the plugin's CSS and JavaScript.

Location four: HTML comments

Some plugins leave comment-block fingerprints in the rendered HTML. WP Super Cache adds <!-- Cached page generated by WP-Super-Cache --> at the end of cached pages. W3 Total Cache leaves <!-- Performance optimized by W3 Total Cache. Learn more: https://www.w3-edge.com/products/ -->. LiteSpeed Cache leaves its own signature comment. These comments are explicit attribution and impossible to miss when present.

Location five: HTTP response headers

Plugins that modify the server response can leave headers visible in the browser's Network panel. WordFence adds X-Powered-By: WordFence sometimes. WP Rocket adds caching-related headers. Hostinger's built-in caching adds x-cache-status headers. These show up in DevTools' Network panel, not in View Source, so they're easy to miss if you only check the HTML.

Where detection accuracy actually lives

For the most-installed 200 plugins on WordPress, combining all five locations gets you to roughly 98% detection accuracy. The remaining ~2% are plugins that intentionally avoid leaving traces (some commercial security plugins, some admin-only utilities) or sites running heavy minification that strips even inline JavaScript variables.

Detection results vary by how the site is configured. A clean install with default settings exposes everything. A heavily optimized site running WP Rocket with Defer JavaScript, Combine CSS, and Remove Unused CSS enabled may strip enough fingerprints that only the wp-content path and HTTP headers remain detectable.

The most thorough public WordPress plugin detector runs through all five locations and cross-references results against the WordPress.org plugin directory to enrich each detected slug with the plugin's actual name, description, and author. For sites running plugins that aren't in the WordPress.org directory (premium plugins like Gravity Forms, Advanced Custom Fields Pro, MemberPress), the slug is detected but not enriched, and you'll see the directory name as the result.

The natural next topic is reading the metadata once you've found the plugin slug. Each plugin's readme.txt file in its directory contains the version, author, and tested-up-to WordPress version, all of which are useful for figuring out whether a site is running an old vulnerable version of a plugin.