WordPress Theme Detector: How to Find Out Which Theme a Site Uses

A WordPress theme detector answers one question quickly: which theme is this site running. Because WordPress powers a large share of the web and exposes its theme in predictable, public ways, you can usually find out by hand in a minute, and a detector just reads those same signals faster. If you build sites, sell themes or plugins, or prospect businesses on WordPress, the theme is a fast read on how a site was built and how easy a rebuild or improvement conversation might be.

This guide walks through the real signals a WordPress theme detector reads, the tools that read them for you, the two things that most often throw a detector off, child themes and page builders, and the honest limits of the whole approach. As with any detection, the gaps a site shows often matter more for prospecting than the theme itself.

The signals a WordPress theme detector reads#

Everything below is public output WordPress serves to every visitor. None of it involves the admin area or anything private. These are the genuine tells.

The /wp-content/themes/ path#

This is the most direct signal. View the page source (Ctrl+U) and search (Ctrl+F) for /wp-content/themes/. WordPress loads the active theme’s stylesheets and scripts from a path like:

/wp-content/themes/your-theme-name/style.css

The folder name right after /wp-content/themes/ is the active theme’s directory. On a site running the Astra theme you will see /wp-content/themes/astra/; on a custom theme you will see whatever the developer named the folder. Seeing wp-content anywhere in the source also confirms the site is WordPress at all, which is the prerequisite for everything else here.

The style.css header#

The folder name is a hint; the theme’s style.css header is the authoritative name. Every WordPress theme ships a style.css whose top comment block declares the theme. Take the theme path from the previous step and open the stylesheet directly in the browser, for example https://example.com/wp-content/themes/astra/style.css. The header looks like this:

/*
Theme Name: Astra
Theme URI: https://wpastra.com/
Author: Brainstorm Force
Version: 4.x
Template: (present only on child themes)
*/

That Theme Name is the real, human-readable name, and Author tells you who made it. If a Template: line is present, you are looking at a child theme, and Template names the parent. This header is why a WordPress theme detector can give you a clean theme name and author rather than just a folder slug.

The meta generator tag and other WordPress tells#

Many WordPress sites also stamp a <meta name="generator" content="WordPress 6.x"> tag into the head, which confirms the platform and sometimes the version. Combined with /wp-content/ paths, the /wp-includes/ directory, and cookies prefixed with wordpress_ or wp-, these signals together make WordPress one of the more reliably detectable platforms. For the broader view-source method across any CMS, the guide on how to detect the CMS a website uses covers all of these signals in one place.

Child themes: why the detected name can surprise you#

Child themes are the first thing that makes a WordPress theme detector look wrong when it is actually right. A child theme is a small theme that inherits everything from a parent and overrides selected parts. The site you see is mostly the parent’s design, but the active theme, the one in the /wp-content/themes/ path, is the child.

So a detector might report astra-child or mycompany-child while the visible design is clearly Astra. Both are true: the child is active, the parent does the heavy lifting. The style.css header settles it, because a child theme’s header carries a Template: line naming the parent. When you want the underlying design system, read the parent from that line. When you want what is actually installed and active, the child is the answer. A good detector reports the active theme and, ideally, the parent it inherits from.

Page builders: the theme that is barely a theme#

The second thing that throws a WordPress theme detector is a page builder. Elementor, Divi, Beaver Builder and similar tools take over large parts of how a page is rendered, sometimes to the point where the underlying theme is almost cosmetic.

You can spot a builder the same way you spot a theme, in the source. An Elementor site carries elementor class names and stylesheet references throughout the markup. A Divi site loads assets from the Divi theme or the Divi Builder plugin and uses et_ prefixed classes. When a builder is present, the “theme” a detector reports may be a lightweight base theme like Hello Elementor, whose entire job is to get out of the builder’s way.

This matters for reading the result correctly. A site on Hello Elementor plus Elementor is not a site with a minimal design; it is a site whose design lives in the builder, not the theme. The theme name understates what is going on. When a detector surfaces a known builder alongside a near-empty base theme, the builder is the real answer to “how was this built”.

Reading the plugin stack alongside the theme#

WordPress sites are defined as much by their plugins as their theme, and plugins leave the same kind of public trail. While you have the source open, a second scan for plugin signals rounds out the picture, and for prospecting it is often the more useful half.

Plugins load their assets from /wp-content/plugins/, mirroring the theme path. Search the source for /wp-content/plugins/ and read the folder names that follow. A site loading from /wp-content/plugins/woocommerce/ is running WooCommerce; one loading /wp-content/plugins/contact-form-7/ has that form plugin; caching, SEO, security and page-builder plugins all announce themselves the same way. As with themes, the folder name is the slug, and it is usually descriptive enough to identify the plugin.

Cookies and inline scripts add to this. Many plugins and the third-party tools they integrate set named cookies or inject recognizable script tags, so the developer-tools cookie list and a scan of the script URLs together reveal tools that the plugin paths alone might miss. Analytics, chat widgets and CRM integrations frequently show up this way even when they are loaded by a plugin rather than added directly.

What you are reading for, again, is presence and absence. Does the site have an SEO plugin at all, is there any caching layer, is there a form or capture tool, is there a CRM integration. The exact plugin matters less than whether the function exists, because the gaps are what turn a detected stack into a reason to reach out.

Tools that read the signals for you#

If you would rather not open style.css on every site, several tools automate it.

• General technology detectors like Wappalyzer and WhatRuns run as browser extensions, confirm a site is on WordPress, and frequently name the theme and detected plugins or builders alongside the rest of the stack.
• Dedicated WordPress theme detector tools focus on the theme and plugin question specifically, parsing the /wp-content/themes/ paths and the style.css headers, and often listing the plugins they can see.
• A broader stack checker reads the theme as one signal among many, which is closer to what you need when you are qualifying the site rather than just identifying its theme.

For a side-by-side of the general detectors and where each one fits, the comparison of BuiltWith and Wappalyzer alternatives covers the free tiers and the paid lines without overselling any of them.

Reading the result on a real site#

Walking the signals in order makes the child-theme and page-builder traps obvious rather than confusing. Open a WordPress site and view the source. First, Ctrl+F for /wp-content/themes/ and read the folder name. That is your candidate. If it ends in -child, you already know to expect a parent.

Second, open that theme’s style.css directly in the browser and read the header. The Theme Name is the real name, Author tells you the origin, and a Template: line, if present, names the parent the child inherits from. This single step resolves the most common source of confusion, because the visible design might be the parent while the active theme is the child, and the header makes that relationship explicit.

Third, if the theme name looks too minimal to explain the design you are seeing, scan for builder tells: elementor classes and stylesheets, et_ prefixes and Divi asset paths, or other builder signatures. A near-empty base theme plus a builder means the design lives in the builder, and reporting only the base theme would understate the build.

The order matters because each step either confirms or redirects the previous one. The folder name proposes a theme, the style.css header confirms it and reveals any parent, and the builder scan catches the case where the theme is almost beside the point. Done in sequence, you rarely misread a WordPress site.

The honest limits#

No WordPress theme detector sees everything, and reading a blank result correctly keeps you from over-claiming.

• A site can rename or obfuscate the theme folder, which hides the slug even though the theme is there.
• Aggressive caching and CDNs can flatten or rewrite the markup, stripping the usual paths.
• A headless WordPress setup runs the CMS as a backend and renders the frontend with a separate framework, so the visitor never sees /wp-content/themes/ at all.
• A fully custom theme has a real name but no marketplace lineage, so the detector names it without being able to tell you anything about its origin.

In all of these, the right answer is “not detected”, not a confident guess. A tool that invents a theme to look complete is worse than one that admits the signal is not there.

From theme to the gaps that matter#

If you detect WordPress themes for prospecting, the theme is the opening read, not the pitch. The pitch is usually in what the site is missing, and WordPress sites make those gaps easy to read.

• A WordPress site with no detectable CRM is probably handling enquiries in an inbox, which is an automation and systems conversation.
• A lead-generating site with no form or capture tool is leaking interest, which is a conversion pitch.
• A site running ads with no Meta pixel or Google tag is spending money it cannot measure, a paid-media pitch with the problem already proven.
• A content-heavy site with no caching or performance layer is a speed-and-SEO conversation you can demonstrate.

The theme tells you how the site was built; the gaps tell you what to say. That is the lens Website Technology Checker is built around, reading the same public signals any detector does, then leading with what is absent and scoring those gaps for how clearly they signal an opportunity. To find the sites in the first place, a lead scraper pairs naturally with a stack-and-gaps read, and where outreach runs on Instagram, Inflowave handles that follow-up once a gap check flags a site worth contacting.

A fast routine#

For one site: open the page source, search for /wp-content/themes/, note the folder name, then open that theme’s style.css to read the real Theme Name, Author, and any Template: line that reveals a parent. Check the markup for elementor, et_ or other builder tells if the theme name looks too minimal to explain the design. That settles the theme in a minute.

For many sites, the manual route does not scale and you lean on a detector, ideally one that reads the plugins and the gaps and not just the theme. Detection is the easy half; the value is in reading the build to understand the site and reading the gaps to know what to offer. If you want the gap-first piece of that workflow the moment it ships, the waitlist is the place to start, free at launch.