WordPress
WordPress Theme Detector
Find out which theme and plugins a WordPress site runs, read straight from its public HTML — and told plainly when the answer cannot be determined.
What This Tool Does
WordPress serves theme and plugin assets from predictable paths — /wp-content/themes/{name}/ and /wp-content/plugins/{slug}/. Reading the stylesheet and script URLs in a page’s HTML gives those directory names directly.
A directory name is not always the published name, so the tool then fetches the theme’s own style.css and reads its header block. WordPress requires every theme to declare Theme Name, Version and Author there. That is what makes this reliable rather than guesswork: the theme identifies itself. Plugin slugs are looked up in the public WordPress.org directory for the same reason.
No private endpoint is touched. Everything read here is served to every visitor, and robots.txt is checked before the page is fetched.
How to Read Your Results
Platform
Whether the site runs WordPress, and what the evidence was. Four independent signals are checked: wp-content asset paths, wp-includes core scripts, the generator meta tag, and a link to the /wp-json/ REST API. Any one of them is conclusive.
Where the generator tag publishes a version number, that is reported — it is public information worth knowing is public.
Theme
The active theme, with whatever its style.css header declares. If a parent theme is named, this is a child theme and most of the visible design comes from the parent.
Plugins
Plugins that loaded CSS or JavaScript on the page you checked. Ones listed in the WordPress.org directory show their real name, version and last update date. Anything not found there is usually premium or custom-built — that absence is reported rather than hidden.
Detection coverage
Appears when asset URLs look merged or minified. This is the honest caveat: a caching plugin makes the results incomplete, and you should read the lists as a floor rather than an inventory.
Common Problems and Fixes
The theme could not be identified
Almost always a caching plugin merging stylesheets into one combined file. Check the site’s page source for a path containing cache, wp-rocket, litespeed or autoptimize.
If it is your own site and you want to identify the theme, look in the admin under Appearance, or check wp-content/themes/ over FTP.
It says not WordPress but I know it is
Most likely a headless install: WordPress manages the content, but a separate front end serves the pages and leaves none of the usual traces. Aggressive security configuration can also rewrite asset paths and strip the generator tag.
The check was blocked
The site’s robots.txt asks automated tools not to fetch that path, and we honour it. That is the correct outcome — see how we measure for what our crawler does and does not do.
A plugin has not been updated in years
The last update date comes from WordPress.org. A plugin untouched for two years or more is worth reviewing on any site you control: abandoned plugins do not receive security fixes, and they are a common route into WordPress installs.
What This Tool Cannot Tell You
- Every plugin. Only those loading front-end assets on the page you checked are visible. Server-side plugins are invisible by design.
- Anything behind a caching plugin. Merged assets remove the paths detection depends on.
- Whether a theme is premium or free. Only what the theme declares about itself is reported.
- Anything about headless WordPress. No traces are served, so there is nothing to read.
- Whether the site is secure. Knowing a version is not a vulnerability assessment.
Frequently Asked Questions
How does theme detection actually work?
WordPress serves theme assets from a predictable path: /wp-content/themes/{name}/. Reading the page's stylesheet and script URLs gives the theme's directory name directly.
The directory name is not always the published name, so the tool then fetches that theme's style.css and reads its header block. WordPress requires every theme to publish Theme Name, Version and Author there, which is what makes this reliable rather than guesswork — the theme identifies itself.
Why can't it detect the theme on some sites?
Caching and optimisation plugins are the usual reason. Plugins like WP Rocket, LiteSpeed Cache and Autoptimize merge several stylesheets into one combined file served from a cache directory, which removes the individual paths that name the theme and plugins.
When that happens the tool says the theme could not be identified rather than guessing. A CDN rewriting asset paths has the same effect. This is a genuine limitation of HTML-based detection, not a bug.
Does it find every plugin?
No, and no HTML-based tool can. Only plugins that load their own CSS or JavaScript on the page you check are visible.
That excludes anything working purely server-side — SEO plugins, backup tools, security plugins, most caching plugins — and anything that only loads on other pages. A plugin list from this tool is a floor, not a complete inventory.
What is a child theme, and why does it matter?
A child theme inherits everything from a parent theme and overrides selected parts. It is the correct way to customise a theme, because the parent can then be updated without losing your changes.
Both appear in asset URLs, so this tool reads each candidate's style.css and prefers whichever declares a Template — that field names the parent, which is what identifies the child as the active theme. Where a child theme is found, both are reported: most of the visible design usually comes from the parent.
It says the site is not WordPress. Could it be wrong?
Occasionally, in one specific case. A headless WordPress install stores content in WordPress but serves pages through a separate front end, which leaves none of the usual traces — no wp-content paths, no generator tag, no REST link.
Otherwise a negative result is reliable. The tool checks four independent signals, and a normal WordPress install exposes at least one of them.
Is it legal to check what someone else's site uses?
This reads the same publicly served HTML your browser downloads when you visit the page, plus a stylesheet the site serves to every visitor. Nothing private is accessed and no authentication is attempted.
Our crawler identifies itself honestly and checks robots.txt before fetching, so a site that asks automated tools not to read it will be respected — and the tool will say it was blocked rather than returning an empty result.
Why does it tell me the WordPress version?
Because the site publishes it, in a generator meta tag WordPress adds by default. It is worth knowing that it is public: anyone can check that version against a list of known vulnerabilities.
Removing the tag is not a security measure in itself — a determined attacker has other ways to fingerprint a version — but it does remove the site from trivial automated scans looking for specific vulnerable releases. Most security plugins can strip it.