WordPress Theme & Plugin Detector

How the WordPress Detector Works

This WordPress checker inspects public front-end evidence. It does not log in, execute the site's JavaScript, or inspect its server:

1. Follow the submitted page, including safe public redirects, and analyze the final response rather than assuming the original domain or homepage.
2. Check WordPress signals, including exact public core, theme and plugin asset URLs, generator metadata, and REST API discovery links. Each signal is shown with its confidence.
3. Collect theme candidates from exact /wp-content/themes/ URLs. A linked stylesheet is read when safe; a canonical style.css probe is clearly labeled as derived evidence.
4. Fall back to inline references when no theme asset is linked. Theme paths inside inline CSS or JSON, such as aggregated or page-builder CSS, are listed only after their style.css header is read.
5. Resolve child and parent themes when a linked child stylesheet exposes a valid Template header. The named parent stylesheet is then checked explicitly, even if the parent had no asset in the page HTML.
6. Report plugin directory slugs from exact /wp-content/plugins/ asset paths without pretending the slug is a verified product name or version.

Why Use a WordPress Theme Detector?

Public WordPress asset paths can reveal useful implementation clues. Results remain partial because custom paths, caching, security controls and server-only plugins can hide them:

• Competitive research, collect evidence about publicly exposed theme and plugin directories before doing deeper product research.
• Design research, identify possible theme directories behind a site you like, while keeping parent, child, legacy and cached assets in mind.
• Client discovery, give an agency or freelancer a fast, evidence-backed starting point before an authenticated technical audit.
• Security triage, an exposed version can justify a closer authenticated review, but this detector cannot prove what is installed, active, current or vulnerable.

If you're evaluating a WordPress site's technical health, pair this with the PHP Version Checker to check whether the public response exposes a PHP version clue. Theme compatibility and PHP version compatibility go hand in hand. For other public platform, CDN, analytics and marketing clues, use the Website Technology Checker. You can assess a separate part of the site's public posture with the Security Headers Checker; missing headers do not identify a plugin or its maintenance status.

A count of exposed plugin directories is not a performance, bloat or security score. If an authenticated audit shows that WordPress no longer fits the project, a WordPress to Astro migration can replace the runtime with a static Astro site designed around the site's actual requirements.

Understanding Your Detection Results

When the scan completes, here's what each piece of information means:

• Scanned URL, the final public page after redirects. Relative asset links are resolved against this URL, not the address originally entered.
• WordPress evidence, the precise public signals used for the result, with high, medium or low confidence.
• Theme candidate, a directory slug and exact asset URLs. A readable stylesheet header can add a name, author and version, but ordinary asset evidence cannot prove which theme is active.
• Likely active theme, the only linked theme on the page whose style.css header was read. Its Requires PHP and Tested up to headers are shown when the theme declares them.
• Likely active child theme, a stronger (but still public-only) inference based on a linked stylesheet whose header names a parent with Template.
• Parent theme, a theme checked explicitly from that child Template header. Its evidence explains whether the parent stylesheet was readable.
• Plugin directory signal, an exposed slug plus exact asset URL. It is not a verified plugin name, version, active-state check, vulnerability finding, or complete inventory.