If you have ever stared at a beautiful WordPress site and thought "I need to know exactly what theme this is," you already know the trap. It looks like a two-minute job: run a detector, read the result, go buy the theme. Then two days later you have bought the wrong theme, rebuilt half a page from scratch, and discovered that the thing you were admiring was never really a theme at all. This is the article I wish someone had handed me before that happened.

What "theme detection" actually means in 2026

Detecting a WordPress theme means identifying the slug of the active theme folder and, ideally, its parent. Everything reliable flows from one fact: WordPress enqueues a theme's stylesheet from a predictable path, /wp-content/themes/<slug>/style.css. That slug in the URL is the single most trustworthy signal you will get. Detector tools, browser extensions, and your own eyeballs are all ultimately just reading that path and the header block inside that stylesheet.

The lesson that cost me time was not how to read that signal. It was understanding everything the signal does not tell you.

The fast, manual method that beats most tools

Before reaching for any service, do this in the browser. It takes thirty seconds and it is more honest than half the detectors out there.

Open the page, view source (Ctrl/Cmd+U), and search for wp-content/themes/. The folder name immediately after it is your slug.
Open that style.css directly in a new tab. The header comment at the top lists Theme Name, Author, Version, and — this is the field people skip — Template:. If Template: is present, you are looking at a child theme, and that field names the real parent.
Glance at the <body> classes and any <meta name="generator"> tag. These sometimes confirm the theme or the WordPress version, though plenty of sites strip the generator tag for security.

If you only learn one habit from this piece, make it reading the Template: field. The number of hours I have watched people waste buying a "child theme" they saw in a detector, when the thing they actually wanted was the freely available parent, is genuinely depressing.

The detectors worth using (and what they really report)

The dedicated tools — WPThemeDetector, IsItWP, ScanWP, WhatWPThemeIsThat — and the general-purpose tech profilers like Wappalyzer, BuiltWith, and WhatRuns all do roughly the same thing: fetch the page, parse the stylesheet path and header, and try to match plugins and frameworks. They are convenient because they also surface the plugin stack and the host. They are dangerous because they present a confident answer to a question that often has no clean answer.

Treat their output as a starting hypothesis, never a verdict. When a tool says "Astra" or "GeneratePress," your next question should always be: is that the theme I'm seeing, or just the frame the real work was built on?

The five lessons that actually cost me the two days

1. A page builder is not a theme

This is the big one, and it is responsible for most wasted afternoons. A site "built with Elementor," Divi, Bricks, or Breakdance still runs an underlying theme — frequently Hello Elementor, Astra, GeneratePress, or Kadence — but ninety percent of what you are admiring is the builder, a starter template, and custom CSS. The detector dutifully reports the lightweight framework theme. You go install Hello Elementor, open it on a fresh site, and get a blank white page with no styling whatsoever, because Hello Elementor is designed to be a near-empty canvas. The design lived in the Elementor template and the page-level CSS, none of which ships with the theme. If a detector returns one of these minimalist framework themes, assume a builder is doing the heavy lifting and look for builder-specific markers in the source before you buy anything.

2. Child themes mask their parent

When a detector returns something ending in -child — or a slug that returns a blank canvas on its own — you are seeing a child theme. The child usually contains nothing but a stylesheet, a few template overrides, and a functions.php. Everything visual comes from the parent named in Template:. Chasing the child slug gets you nowhere; the parent is what you want, and it is often a well-known commercial or free theme.

3. White-labeled and renamed themes lie to you

Agencies and theme shops rename theme folders all the time, either to white-label client work or to obscure a commercial theme they have customized heavily. When that happens, detectors return "unknown," a generic framework name, or a slug that matches nothing in any directory. Do not interpret "unknown" as "custom-coded from scratch." More often it means a commercial theme with the header block edited and the folder renamed. Comparing the enqueued CSS and JS filenames against known themes — a popular builder leaves very recognizable asset names — will usually unmask it.

4. Block themes and FSE weakened the old heuristics

Full Site Editing changed the detection game. Modern block themes — Twenty Twenty-Five, Ollie, and many others — drive their appearance through theme.json and global styles rather than one big enqueued stylesheet. The old trick of "find the largest theme stylesheet and read its header" gets thinner results because much of the styling is now inline global CSS generated from theme.json. The slug is still in the path, so detection itself survives, but do not expect a fat style.css to hand you the whole design. Check for the FSE template structure and the presence of theme.json to confirm you are dealing with a block theme before you assume a classic one.

5. Headless WordPress has no theme to detect

This is the one that will make you doubt your sanity. If a site runs headless WordPress — WordPress as the backend with a Next.js or Faust.js frontend — there is no theme rendering the pages you see. The frontend is a separate JavaScript application talking to WordPress over REST or GraphQL. You can scan the frontend forever and find nothing, because there is nothing to find. The tell is the absence of any wp-content/themes/ path combined with framework markers like Next.js build artifacts. (And no, do not reach for Frontity examples here — that project was discontinued and is no longer the way headless sites get built.)

A faster diagnostic order

Put the lessons together and theme detection becomes a quick triage rather than a guessing game:

Is there a wp-content/themes/ path at all? No path plus a JS-framework fingerprint means headless — stop looking for a theme.
Does the slug end in -child or render blank alone? Read Template: and chase the parent.
Is the theme a known minimal framework (Hello Elementor, Astra, GeneratePress, Kadence)? Assume a page builder and identify it from the source before buying.
Did the tool say "unknown" or return a no-match slug? Suspect a renamed or white-labeled commercial theme and compare asset filenames.
No fat stylesheet, but a theme.json present? It is a block/FSE theme; the design lives in global styles.

The honest bottom line

What I wish I had known is that "which theme is this?" is frequently the wrong question. The thing you fall in love with on a polished site is usually a combination — a lightweight theme plus a page builder plus a starter template plus custom CSS, or a heavily customized commercial theme wearing a renamed folder. Detecting the theme slug is the easy five percent. Understanding that the slug rarely equals the design is the part that saves you two days. Run the manual view-source check first, read the Template: field every single time, and treat every detector result as a hypothesis to disprove rather than an answer to act on. Do that, and theme detection goes back to being the two-minute job it always looked like.

What I Wish I Knew About Theme Detection Before I Wasted Two Days