You landed on a WordPress site with a layout, typography, and header you wish you could reproduce, and now you want a name. The good news: WordPress is structurally talkative about its theme. The slug almost always sits in plain sight, and most of the time you can extract it faster than it takes a detector website to load its ads. This guide walks through the methods in the order a practitioner actually uses them — from a five-second source peek to the cases where every shortcut fails and you have to reason about what you're seeing.

Why the theme is almost always visible

WordPress loads a theme's stylesheet and scripts from a fixed path: /wp-content/themes/<slug>/. That <slug> is the folder name on the server, and it gets stamped into the HTML every time the page links to the theme's CSS or JavaScript. There is no privacy toggle for this — it is a consequence of how WordPress builds asset URLs, not a setting someone forgot to flip. So the real task is rarely "can I find the theme" and almost always "which of several signals do I trust, and what do I do when the obvious one is hidden."

One caveat worth internalizing up front: the folder slug is not always the marketing name. A site running the premium theme "Kadence" shows /themes/kadence/, which is friendly. But a heavily built site might show /themes/acme-co-2025/, which tells you the developer's naming convention and nothing about a downloadable product. Knowing the difference is most of the skill.

Method 1: Read the page source

This is the fastest reliable approach and it needs nothing but a browser.

Load the page, then press Ctrl+U (Windows/Linux) or Cmd+Option+U (Safari) — or right-click and choose "View Page Source."
Use the in-page find (Ctrl+F / Cmd+F) and search for themes/.
Read the word that follows /themes/ up to the next slash. That's your slug.

You'll usually find it on a <link rel="stylesheet"> tag pointing at style.css or a built CSS bundle. If you want the theme's self-declared identity rather than just the folder name, open https://example.com/wp-content/themes/<slug>/style.css directly in a new tab. Every legitimate theme begins that file with a header comment containing Theme Name, Theme URI, Author, and Version — the official metadata WordPress reads to populate the Appearance screen. That header is the closest thing a theme has to a passport.

Block themes muddy the signal slightly

Since WordPress shifted toward full site editing, block-based themes (Twenty Twenty-Four, Twenty Twenty-Five, Ollie, Frost, and others) lean less on a giant enqueued style.css and more on inline styles and theme.json-driven CSS. The /wp-content/themes/<slug>/ path is still present — it just may appear on a smaller asset, a font preload, or a block-specific stylesheet rather than one obvious master file. Search for themes/ rather than style.css and you'll still catch it.

Method 2: The Network and Sources tabs in DevTools

When the raw HTML is minified into one unreadable line, or when JavaScript injects content after load, DevTools is cleaner than squinting at source. Open it with F12, reload the page with the Network tab open, and filter by CSS. Every theme stylesheet's request URL exposes the /themes/<slug>/ path. The Sources panel gives you the same thing as a navigable file tree, which is handy when a site loads several stylesheets and you want to see the whole theme directory structure at a glance.

DevTools also helps you separate the theme from its plugins. Paths under /wp-content/plugins/ are page builders, SEO tools, and form handlers — not the theme. It's common to mistake an elementor/ path for the theme; Elementor is a builder that runs on top of a theme (frequently the minimal "Hello Elementor" theme), so check for the actual /themes/ entry separately.

Method 3: Detector tools — and when they earn their keep

Services like WPThemeDetector, IsItWP, and Scanwp fetch the URL server-side, parse the same source you could read yourself, and then add a layer of value: they cross-reference the slug against known theme databases and frequently surface the active plugins and the parent/child theme relationship in one view. That cross-referencing is the genuine reason to use them. If you see /themes/astra-child/, a good detector will tell you the parent is Astra and link you to the product, which saves a lookup.

Two honest limitations. First, these tools fetch from their own servers, so they submit the URL you typed to a third party — fine for any public page, but think twice before pasting a staging URL, a client's pre-launch site, or anything behind login. Second, they fail on sites protected by full Cloudflare challenge pages or bot management, because their fetcher gets the interstitial instead of the real HTML. In exactly those cases, your own browser — which passes the challenge as a normal human session — succeeds where the tool can't. Method 1 has no such blind spot.

When the slug is hidden or rewritten

A few real-world setups deliberately or incidentally bury the theme path:

Aggressive caching and optimization. Plugins such as WP Rocket, LiteSpeed Cache, and Perfmatters can combine, rename, or move CSS into a cache directory like /wp-content/cache/ or /wp-content/litespeed/. The merged file no longer carries the theme slug in its name. Fall back to DevTools and look for any remaining asset — a font, an image in the theme folder, or an unminified inline reference — that still points at /themes/.
CDN rewriting. Some setups serve static assets from a separate CDN hostname, replacing example.com/wp-content/themes/... with cdn.example.net/themes/.... The slug usually survives the swap; only the domain changed.
Starter frameworks. If the first slug you find is understrap, _s (Underscores), sage, or genesis, you've likely found a development foundation, not the finished look. Sage in particular compiles a bespoke design that won't resemble any stock theme. The slug is accurate; it just isn't a product you can buy and get the same site.

When there's no theme path at all

If a thorough search turns up nothing under /wp-content/themes/, consider these possibilities in order:

It isn't WordPress. The site may run Webflow, Squarespace, Wix, Ghost, or a headless React/Next.js front end. Check for tell-tale paths like /_next/, assets.squarespace.com, or a generator <meta> tag. A quick Ctrl+F for wp-content anywhere in the source settles the WordPress question fast.
Headless WordPress. WordPress can serve only an API while a separate framework renders the front end. The dashboard is WordPress, but the public HTML has no theme folder because the theme isn't doing the rendering. There's nothing to detect on the front end here.
WordPress.com. Hosted WordPress.com sites use a different asset structure (often s0.wp.com and obfuscated paths), so the classic slug hunt comes up empty even though it genuinely is WordPress.

Confirming what you found

Once you have a slug, verify it. Search the WordPress.org theme directory for the name — a match there means it's free and downloadable. If it's absent, cross-check against the well-known commercial themes: Astra, GeneratePress, Kadence, Blocksy, Divi, Avada, OceanWP, Neve, and Hello Elementor cover a large share of real-world sites. A slug that matches none of these and doesn't appear on WordPress.org is almost certainly a custom or agency-built theme — you've correctly identified what powers the site, but the answer is "bespoke," and no download will reproduce it. That's not a failure of method; it's the honest answer, and recognizing it saves you from chasing a product that doesn't exist.

How to Find Out What WordPress Theme a Website is Using