---
title: "WordPress Detector — Free WP Plugin & Theme Scanner"
description: "Free WordPress detector. Identify WP version, theme, and plugins of any public site instantly. Useful for competitive research, audits, and tech-stack…"
canonical: "https://lemwatch.com/tools/wordpress-detector"
source: "https://lemwatch.com"
---

# WordPress Detector

> Detect if a site runs WordPress. Identify the WordPress version, active theme, and visible plugins from the public HTML — no login required.

Identifying that a site runs WordPress is trivial; identifying *which* version, *which* theme, and *which* plugins is the actual value. Most WordPress sites leak this information freely in the HTML — and almost no one realises it. This tool surfaces it in a single click.

 ## Why anyone would want to know this

 **Agencies pitching for migration work**: walk into a prospect meeting knowing "you're running WordPress 5.8 with 14 plugins, three of which are abandoned." Instantly more credible than "so, tell me about your stack."

 **Security researchers**: outdated plugin versions are the #1 WordPress attack vector. Wordfence's 2024 report attributes 96% of WordPress hacks to plugin vulnerabilities. Knowing what's installed lets you cross-reference CVEs.

 **Competitive analysis**: see which page-builder a competitor uses, what their forms run on, what their analytics stack looks like, what membership plugin gates their content. All from the homepage HTML.

 **Developers evaluating a codebase**: "is this client site even WordPress, or is it Webflow with a /blog/ subfolder?" 30 seconds, settled.

 ## How WordPress leaks itself

 Most WP sites give themselves away in five places — usually all five:

 1. **`<meta name="generator" content="WordPress 6.4.2">`** — added by core unless removed. Tells you it's WP *and* the exact version.
2. **`/wp-content/` URLs** in CSS, JS, and image references — universal to every WP install.
3. **`/wp-includes/` URLs** — core scripts and styles ship with these paths.
4. **`/wp-json/`** — the REST API endpoint, usually returns a JSON document with the site name and namespaces unless explicitly blocked.
5. **`/readme.html`** — a static file that ships with WP and announces the exact version. Routinely forgotten when admins try to hide WP.

 ## Plugin and theme extraction

 Plugins live at `/wp-content/plugins/<slug>/` and themes at `/wp-content/themes/<slug>/`. Any plugin that enqueues scripts or styles (and that's almost all of them) appears in the HTML by its folder slug. We dedupe and surface up to 50 plugins and 10 themes. This is unauthenticated and uses zero special access — anyone viewing the page source can see the same data; we just parse it for you.

 ## What this tool cannot do

 It can't reveal plugins that load no frontend assets (admin-only plugins, some membership tools, server-side-only utilities). It can't reveal exact plugin versions unless the plugin embeds them in the asset URL (some do, most don't). It can't bypass hardening plugins that strip identifiers — if you scan a hardened site, you'll see 0 plugins and "unknown version" and that's correct, not a bug.

 ## If you're *defending* a WordPress site

 Don't panic. The information leak alone isn't a vulnerability — running outdated software is. Patch promptly, harden with a security plugin, and keep your /wp-content/plugins/ list short. A hardened, patched WP site whose plugins are visible is still secure. A neglected WP site whose plugins are hidden is still vulnerable. The hiding is theatre; the patching is the real defence.

## What this tool checks

- Whether the site runs WordPress (multiple signals: generator meta, wp-content paths, /wp-json availability)
- WordPress version (from generator meta or /readme.html)
- Active theme slug from /wp-content/themes/
- Visible plugin slugs from /wp-content/plugins/
- Whether the REST API (/wp-json/) is publicly reachable

## Why it matters

 Knowing what powers a site is the first step in every competitive analysis, vulnerability assessment, or technology audit. WordPress runs ~43% of the web, and most installations leak plugin and theme names directly in the HTML — useful for understanding what features a competitor uses, whether outdated software might be present, or whether a prospective client needs hosting migration help. This tool surfaces all of that with zero authentication required.

## How to fix what it finds

- If YOU run the site and don't want plugins leaking, install a hardening plugin (WP Hide & Security Enhancer, Hide My WP, iThemes Security)
- Remove the WordPress generator meta tag via your theme's functions.php: `remove_action('wp_head', 'wp_generator');`
- Block /readme.html and /wp-includes/version.php at the webserver level
- Disable the REST API for unauthenticated users if you don't need it publicly (filter `rest_authentication_errors`)
- Keep WordPress core, themes, and plugins fully updated — version disclosure is dangerous only if you're running outdated code

## Methodology

 We fetch the homepage with a 10-second timeout and `LemWatchWPDetect/1.0` user-agent. From the HTML we extract: the `<meta name="generator">` content, all `/wp-content/plugins/<slug>/` paths, all `/wp-content/themes/<slug>/` paths, and any references to `/wp-includes/`. We then try GET `/wp-json/` (6-second timeout) — if it returns JSON, the REST API is reachable and we extract the site name. If we still don't have a version, we fetch `/readme.html` (5-second timeout) and parse the version number. Plugins and themes are deduplicated. The `is_wordpress` verdict requires at least one signal: wp-content path, wp-includes path, generator meta containing "WordPress", or a reachable wp-json endpoint. Results are returned in a single response with all signals labeled so you can see exactly *why* we concluded the site is (or isn't) WP.

## Frequently asked questions

### Why does it say "is_wordpress: false" on a site I know runs WordPress?

 The site has been hardened — generator meta stripped, wp-content paths rewritten, /wp-json blocked, /readme.html removed. This is a sign of a security-conscious admin, not a bug in the tool.

### Can it detect WordPress.com vs self-hosted?

 Indirectly — WordPress.com sites usually return a *.wp.com domain for /wp-json/ and have specific tracking scripts. We don't explicitly flag this but the signals are visible in the raw output.

### Does this work on Wix, Squarespace, Webflow, Shopify?

 No — those use different paths and conventions. Use our hosting-detector tool to identify them instead.

### Why are some plugins missing from the list?

 Plugins that load no frontend assets (admin-only, server-side-only) are invisible to any HTML-based scanner. Only plugins that enqueue scripts, styles, or include `wp-content/plugins/` paths appear.

### Is this legal / ethical?

 Yes — we only read the public HTML that any visitor sees. Same information you'd find by right-click → View Source. No authentication, no fuzzing, no rate-busting.


## Related

- [All free tools](https://lemwatch.com/tools)
- [Hosting Detector](https://lemwatch.com/tools/hosting-detector)
- [Exposed Services Checker](https://lemwatch.com/tools/exposed-services-checker)
- [Check Site For Malware](https://lemwatch.com/tools/website-malware)
- [Website Uptime Checker](https://lemwatch.com/tools/website-uptime)
- [Lemwatch pricing](https://lemwatch.com/pricing)
- [All monitoring checks](https://lemwatch.com/features)
- [wordpress vulnerability scanner](https://lemwatch.com/tools/wp-vulnerability-scanner)