How to Identify a WordPress Theme and Its Plugins
Once you know a site runs WordPress, here is how to find its theme and its plugins — from the source, the style.css header and asset paths to detectors.
Once you have established that a site runs WordPress, the natural next question is which theme and which plugins it uses. The good news: WordPress is unusually transparent about both. The theme name is almost always sitting in the page source under a /wp-content/themes/<name>/ path, and you can confirm it by reading the theme's style.css header block. Plugins announce themselves through /wp-content/plugins/<name>/ asset URLs, distinctive markup and generator tags. This guide shows you exactly where to look — by hand and with dedicated detector tools — plus the limits of what is detectable and why any of it matters.
If you are not yet sure the site is WordPress at all, start with how to tell if a website is built with WordPress; this guide picks up where that one leaves off.
Why identify the theme and plugins?
There are several practical reasons to dig into a WordPress site's theme and plugins. Design inspiration: if a site's layout is exactly what you want, knowing the theme means you can evaluate, buy or adopt the same foundation rather than rebuilding from scratch. Competitive research: the theme and plugin stack reveals how a competitor built their site, what it can do, and roughly what they invested. Security awareness: WordPress vulnerabilities overwhelmingly come from outdated themes and plugins, so spotting a known plugin running an old version flags a genuine risk. And client onboarding: when you inherit a site to maintain or redesign, identifying its stack tells you what you are walking into. Because WordPress exposes so much in the page source, all of this is quick to establish.
Finding the theme in the page source
The single fastest method is to read the source. Right-click the page, choose View Source (or Ctrl+U / Cmd+Option+U), and search the HTML for /wp-content/themes/. WordPress loads the active theme's stylesheet and scripts from a folder named after the theme, so you will see paths like:
/wp-content/themes/astra/style.css
/wp-content/themes/generatepress/assets/...
/wp-content/themes/Divi/style.css
The folder name immediately after themes/ is the active theme. This works because WordPress has to load the theme's assets by their real path; even when other things are obscured, the theme folder usually remains visible. If you see two theme folders, one is likely a parent theme and the other a child theme that customises it — both are worth noting.
Confirming with the style.css header
To verify the theme and learn more about it, open its stylesheet directly in the browser by visiting /wp-content/themes/<name>/style.css. Every proper WordPress theme begins this file with a header comment block that names the theme, like so:
/*
Theme Name: Astra
Theme URI: https://wpastra.com/
Author: Brainstorm Force
Version: 4.6.2
*/
This header is definitive: it gives you the theme's real name, author, version and homepage. Reading it is the surest single confirmation, and the version number is especially useful for security and currency checks. If the file is missing or returns an error, the site may be blocking direct file access, in which case you fall back to the asset paths and detector tools.
Body CSS classes as a secondary tell
WordPress automatically adds a set of classes to the <body> element, and many themes contribute their own. Inspect the <body> tag (Elements panel or View Source) and you may see a class like theme-astra, et_pb_* classes (Divi's Page Builder), or elementor-* classes (the Elementor builder plugin). These do not always name the theme cleanly, but they often hint at the theme or, just as usefully, the page builder in use — Elementor, Divi, Beaver Builder — which shapes how the site was assembled even more than the underlying theme does.
Detecting plugins from the source
Plugins follow the same pattern as themes. Search the page source for /wp-content/plugins/ and read the folder names that follow — each unique one is an active plugin loading a front-end asset:
/wp-content/plugins/woocommerce/→ WooCommerce (the e-commerce plugin)./wp-content/plugins/wordpress-seo/→ Yoast SEO./wp-content/plugins/elementor/→ Elementor (page builder)./wp-content/plugins/contact-form-7/→ Contact Form 7./wp-content/plugins/wp-rocket/→ WP Rocket (caching).
Beyond asset paths, some plugins leave other traces: generator meta tags (Yoast adds an HTML comment block around its meta tags; many SEO and builder plugins identify themselves), distinctive markup and CSS class prefixes, and dedicated script handles in the source. Searching the source for a few common plugin names is a fast way to profile the stack.
A table of common theme and plugin fingerprints
The signatures below cover much of what you will meet on real WordPress sites.
| Component | Where it appears | Signature |
|---|---|---|
| Active theme | source, asset URLs | /wp-content/themes/<name>/ |
| Theme details | direct file | /wp-content/themes/<name>/style.css header block |
| Divi theme/builder | body classes, markup | et_pb_* classes, Divi folder |
| Elementor (plugin) | body classes, assets | elementor-* classes, /plugins/elementor/ |
| WooCommerce | body class, assets | woocommerce body class, /plugins/woocommerce/ |
| Yoast SEO | source comments | /plugins/wordpress-seo/, Yoast HTML comment block |
| WP Rocket | source comments | /plugins/wp-rocket/, optimisation comment |
| Contact Form 7 | assets | /plugins/contact-form-7/, wpcf7 markup |
One matching signature usually confirms each component. The theme is the most reliably detectable; plugins are hit-and-miss depending on whether they load anything on the public page.
Dedicated detector tools
If you would rather not read source, several tools automate the lookup:
- WPThemeDetector — a free web app built specifically for this: enter a URL and it reports the active theme (with its style.css details) and the plugins it can detect.
- Wappalyzer — the general technology detector also recognises many WordPress themes, page builders and popular plugins.
- BuiltWith — profiles the full stack including WordPress components, with historical data on paid tiers.
- View Source and DevTools — the manual tools behind all of the above, and the way to confirm any automated claim by reading the actual asset paths and
style.css. - StackOptic — a full website audit that reports WordPress and its detectable components alongside performance, SEO and security in a single pass.
These tools are convenient and fast, but they read the same /wp-content/ paths and style.css headers you can read yourself, so confirm an important result manually.
The limits: what you cannot detect
It is important to be honest about the ceiling here. You can reliably detect anything that loads a front-end asset, adds markup, or emits a generator tag — that covers themes, page builders, and most visitor-facing plugins. But many plugins work purely in the admin or on the server: backup tools, some security plugins, certain SEO and migration utilities, and anything that runs in the dashboard without touching the public page. Those load nothing on the front end and stay invisible to outside detection. So a plugin scan finds the front-facing plugins, never the complete installed list. Likewise, a heavily customised child theme may show its parent in the source while its bespoke changes remain opaque. Treat the result as "what the site reveals", not "everything it runs".
Why caching and optimisation can obscure things
Performance plugins complicate detection in a useful-to-know way. Tools like WP Rocket, Autoptimize or a CDN's optimisation layer combine and minify CSS and JavaScript, which can merge many plugins' assets into a single file with a hashed name — erasing the individual /wp-content/plugins/<name>/ paths you would otherwise read. When the source looks suspiciously clean for a WordPress site, aggressive optimisation is often why. In that case, lean on the theme's style.css (frequently still served separately), on body classes, on generator tags that survive optimisation, and on detector tools that use additional heuristics. This is the same dynamic that affects JavaScript-library detection — see how to check what JavaScript libraries a website uses for the general version of the bundling problem.
Common mistakes
A few traps recur. Reporting the parent theme when a child theme is active — note both folders and check which style.css carries the Template: line that points to a parent. Claiming a complete plugin list — you only ever see front-facing plugins, so never present the visible ones as the whole set. Confusing a page builder with the theme — Elementor and Divi's builder are plugins/features layered on a theme, not the theme itself, though they dominate the look. And ignoring versions — for security work especially, the plugin's version (often in its asset URL's query string, like ?ver=3.1.2) matters as much as its name.
Why this matters for design and security
Two motivations dominate in practice, and they pull in the same direction. For design and competitive work, identifying the theme and page builder tells you how a site was assembled and how to replicate or better it — and pairs naturally with reading its visual choices, covered in how to find what fonts and colours a website uses. For security, the WordPress ecosystem's biggest risk is outdated components, so spotting a recognisable plugin running an old version is a concrete, actionable finding. The same source you read to admire a design is the source that reveals an unpatched plugin — which is why theme-and-plugin identification sits at the intersection of design research and security awareness.
The fast, reliable workflow
- View Source and search for
/wp-content/themes/to find the active theme folder. - Open
/wp-content/themes/<name>/style.cssto read the theme's header block. - Search for
/wp-content/plugins/and list the unique plugin folder names. - Check body classes for page builders (
elementor-*,et_pb_*) and theme hints. - Run WPThemeDetector or Wappalyzer and confirm the theme against
style.css. - Note versions in
?ver=query strings, and remember you see only front-facing plugins.
Go deeper
- Confirm the platform first: how to tell if a website is built with WordPress.
- Step up a level: how to tell what CMS a website is using.
- Read the design too: how to find what fonts and colours a website uses.
- The complete method: how to find out what a website is built with.
Want the theme, the visible plugins and the full stack in one pass? Analyse any website with StackOptic — one report, free, no sign-up.
Frequently asked questions
How do I find out what WordPress theme a site uses?
Open the page source (View Source) and search for /wp-content/themes/ — the folder name that follows is the active theme, for example /wp-content/themes/astra/. Confirm it by opening that theme's style.css file directly (/wp-content/themes/astra/style.css), whose header block names the theme, author and version. A tool like WPThemeDetector does the same lookup automatically if you prefer one click.
How can I see which plugins a WordPress site uses?
Search the page source for /wp-content/plugins/ — each unique folder name there is an active plugin loading a script or stylesheet, such as /wp-content/plugins/woocommerce/ or /wp-content/plugins/yoast-seo/. Some plugins also add a generator meta tag or distinctive markup. You will not see every plugin (those that load no front-end assets stay hidden), but you will catch the visible, front-facing ones.
Can I detect every plugin a site uses?
No. You can reliably detect plugins that load front-end CSS or JavaScript, add markup, or emit a generator tag, because those leave traces in the page. Plugins that work purely in the admin or on the server — backup, security or some SEO tools — often load nothing on the public page and stay invisible. Detection therefore finds the front-facing plugins, not the complete back-end list.
Why would I want to identify a theme or plugins?
Several reasons. For design inspiration, knowing the theme lets you evaluate or buy the same starting point. For competitive research, the theme and plugin stack reveals how a competitor built their site and what it can do. For security, spotting a known plugin running an outdated version highlights a real risk. And for client work, identifying the stack of a site you are about to take over tells you what you are inheriting.
Are WordPress theme detectors accurate?
For standard, self-hosted themes they are very accurate, because the theme folder name and style.css header are right there in the source. Accuracy drops for heavily customised child themes (where the parent shows but the customisations do not), for sites behind aggressive caching or optimisation plugins that rename or combine assets, and for custom-built themes that match no public name. Confirming the style.css header is the surest check.
Analyse any website with StackOptic
Get the full technology stack, performance, security and SEO report in seconds — free.
Analyse a websiteRelated articles
How to Tell if a Website Uses Progressive Web App (PWA) Features
A web app manifest, a registered service worker, installability and a theme-color tag are the PWA signals. Here is how to detect them in Chrome DevTools.
How to Tell if a Website Uses Akamai, Fastly, or CloudFront
Each major CDN leaves distinct header fingerprints — Fastly's x-served-by, Akamai's ghost markers, CloudFront's x-amz-cf-pop. Here is how to tell them apart.
How to Tell if a Website Uses Google reCAPTCHA
Google reCAPTCHA leaves signals: a recaptcha/api.js script, a grecaptcha global and a g-recaptcha data-sitekey. Here is how to detect it and tell v2 from v3.