How to identify the theme a WordPress site is using

Background

Every WordPress theme lives in its own folder under `wp-content/themes/`. When a site activates a theme, WordPress serves its assets — `style.css`, JavaScript files, template-specific stylesheets, image assets — from that folder, and the URLs of those assets are visible in the rendered HTML. The folder name is the theme's slug, which for themes published on wordpress.org/themes maps directly to the public listing. For premium themes (Divi, Avada, Astra Pro, Kadence Pro, GeneratePress Premium, Bricks, Blocksy Pro) the slug is usually the theme name lowercased with hyphens, although some vendors use a shortened or branded slug that you have to translate manually.

There is a second wrinkle that comes up on serious WordPress builds: child themes. A child theme is a thin overlay that sits on top of a parent theme and contains only the changes the site needs (custom CSS, template overrides, additional functions). When a child theme is active, WordPress loads both the parent theme's assets and the child theme's assets, which means you will see two different `/wp-content/themes/<slug>/` paths in the page source. Identifying both is part of the work — the parent tells you the underlying engine and feature set, the child tells you which agency or developer customized it. A quick look at the network tab, or specifically at each theme's `style.css` header comment, is enough to tell the two apart.

The last layer is page-builder pairings. Many WordPress themes are designed to work hand-in-glove with a specific page builder (Elementor, Bricks, Divi, Beaver Builder, Cwicly), and the theme slug often telegraphs which builder is involved. `hello-elementor` is the official Elementor companion theme; `bricks` is paired with the Bricks builder; `generatepress` and `astra` are frequent choices for builder-agnostic but builder-friendly stacks. Recognising those pairings early speeds up the rest of a WordPress audit.

Why this matters

The theme dictates page-builder compatibility, performance characteristics, and a lot of the visual primitives used across the site. 'Elementor-based' sites behave differently from 'Bricks-based' sites, which behave differently from full-site-edited block themes, which behave differently from classic themes layered with Advanced Custom Fields. Identifying the theme is the second step of any serious WordPress audit, right after listing plugins, because so many of the choices that follow depend on it: which CSS architecture is in play, where the overrides live, whether you can ship visual changes through the customizer or have to drop into the file system, how performance work has to be approached.

For agencies the theme name carries marketing weight too. 'Built on Astra Pro with custom Elementor templates' is shorthand for a specific budget tier and a specific set of capabilities. 'Built as a custom block theme on top of Twenty Twenty-Four' tells a procurement person something different. Theme detection lets you place a site in the right tier of the WordPress universe in one glance, which is genuinely useful for competitive intelligence, vendor evaluation, and understanding what the engineering investment looked like.

For performance work the theme is often the single largest line item in the page weight. Heavy themes (Avada, Divi, BeTheme) ship hundreds of kilobytes of CSS and JavaScript regardless of which features the site actually uses, while lightweight themes (GeneratePress, Astra without Pro modules, the default block themes) keep the baseline tiny. Knowing which family the site is in tells you within seconds where the easy performance wins are likely to be hiding.

Prerequisites

• A Chrome-based browser, with developer tools available — the workflow uses View Source and the Network tab, neither of which require any installs.
• Confirmation that the site is actually WordPress. If you are not sure, run the [identify-the-cms-behind-any-site](/how-to/identify-the-cms-behind-any-site) guide first; it takes thirty seconds.
• Optional: the Sourcemap Explorer extension installed, which will surface the theme slug automatically in the popup's Stack tab and save you the manual View Source pass.
• Optional: a tab open on wordpress.org/themes/ — useful for quickly mapping an unfamiliar slug to its public listing, license, and last-update date.

Step-by-step

1. 1

   View page source and search for /wp-content/themes/

   Press `Ctrl+U` (or `Cmd+Option+U` on macOS) to open the raw HTML, then `Ctrl+F` to search for `/wp-content/themes/`. The first match is almost always the active theme: `/wp-content/themes/<slug>/style.css`, often loaded via `<link rel="stylesheet">` near the top of the head. The slug between the second and third slashes is the theme's directory name and, for almost every site that uses a public theme, the slug you would also see on wordpress.org/themes/. Note any other matches you see — additional theme paths usually mean a parent + child setup, which is normal and which the next step will clarify.

   Tip: Pro sites sometimes have two theme folders in the source — a child theme overriding a parent. Both will show up. Sites running a custom child theme usually load the parent's `style.css` plus the child's, so two distinct slugs is the expected shape, not a bug.

2. 2

   Open style.css for the theme metadata

   Navigate to `<site>/wp-content/themes/<slug>/style.css` directly in a new tab. The first thing in the file is a header comment with the canonical theme metadata: `Theme Name:`, `Theme URI:`, `Author:`, `Author URI:`, `Description:`, `Version:` and (importantly for child themes) `Template:`. If `Template:` is present and points at another slug, you are looking at the child theme; if it is absent, you are looking at the parent. The `Theme Name:` line is the human-readable name that maps to wordpress.org listings or a vendor's product page, even when the folder slug has been renamed.

   /*
   Theme Name: My Agency Child Theme
   Theme URI: https://example.com/
   Author: Example Agency
   Author URI: https://exampleagency.com/
   Description: Customizations on top of Astra for the marketing site.
   Template: astra
   Version: 1.4.2
   Text Domain: my-agency-child
   */

3. 3

   Check for a child theme

   If you saw two different theme slugs in the source, you are looking at a parent + child setup. The child theme's `style.css` will have `Template: <parent-slug>`, which is the line that ties the two together. Child themes are a WordPress best practice: they let an agency or in-house team customize a theme without losing those changes when the parent theme updates. The presence of a child theme tells you that someone took WordPress development seriously on this site, and is also a good place to look for site-specific design tokens, custom template files, and `functions.php` extensions that change the runtime behavior.

4. 4

   Look for builder-specific themes

   Some themes are built to pair with a specific page builder. Elementor's default pairing is `hello-elementor`, the deliberately bare theme that Elementor recommends as a base. Bricks ships with its own theme by the same name. GeneratePress and Astra are frequent picks for builder-friendly stacks because they expose hooks and CSS variables that page builders can target cleanly. Seeing the theme slug often tells you the likely page builder before you enumerate plugins, which speeds up the rest of the audit. If the theme is `hello-elementor`, expect Elementor and probably Elementor Pro in the plugin list; if the theme is `astra` or `generatepress`, expect either Elementor or Beaver Builder; if the theme slug is `bricks`, expect the Bricks builder doing the heavy lifting and very few traditional WordPress plugins.

5. 5

   Inspect the network tab for asset weight

   Open DevTools, switch to the Network tab, filter by 'CSS', and reload the page. The CSS bundle a theme ships is the single fastest way to place it in the right family. Heavy multi-purpose themes (Avada, Divi, BeTheme, Enfold) ship 200-400 KB of CSS regardless of which features the site uses; lightweight themes (GeneratePress, Astra without Pro, Twenty Twenty-Four) keep the baseline under 50 KB; full-site-editing block themes route most of their visual logic through the global styles JSON and ship surprisingly little CSS. The shape of the network tab tells you which family you are in even before you read the slug.

   Tip: The Network tab also tells you when the theme is loading from a CDN that masks the original folder. If the CSS file is being served from `cdn.<vendor>.com` rather than `<site>.com/wp-content/themes/<slug>/`, that is your clue that the theme is being optimized through a service like Kinsta CDN, WP Rocket Cloud or Cloudflare Pages — useful context for a performance audit.

6. 6

   Let the extension surface it automatically

   Sourcemap Explorer's Stack tab lists every WordPress theme it spots in the page's assets, with the slug, the human-readable name from `style.css`, and the parent/child relationship when both are present. Click the row and you go straight to the relevant asset URL. This is the path of least resistance for everyday work: the popup is one click away from whatever page you are already on, the answer is pre-categorized, and you do not have to remember whether you needed View Source or DevTools or both.

Real-world example

Alternative methods

Troubleshooting

Caveats

What to do next

With the theme identified you have placed the site in the right WordPress neighbourhood. The natural next move is the plugin enumeration via [find-wordpress-plugins-used-by-a-site](/how-to/find-wordpress-plugins-used-by-a-site), which together with the theme tells you essentially everything user-facing about the WordPress install: visual engine, page builder, optimization layer, e-commerce stack, form handler, security plugins. After that, three follow-ups are usually worth a few minutes each. First, check whether the site is actually being served from WordPress directly or sitting behind a static cache or an edge cache (the `Server` and `X-Cache` headers in DevTools usually tell you in one read). Second, if you suspect a headless setup, run [check-if-a-site-is-built-with-nextjs](/how-to/check-if-a-site-is-built-with-nextjs) to confirm — many modern WordPress agencies are shipping the frontend as Next.js while keeping WP as a CMS, which changes the entire architectural picture. Third, scan for the broader JavaScript stack via [see-every-javascript-library-a-site-uses](/how-to/see-every-javascript-library-a-site-uses) to surface anything the theme/plugin layer pulls in (jQuery vendor bundles, Slick sliders, third-party form widgets, analytics pixels) that is worth knowing for performance and security purposes.

FAQ

Related