How to tell which WordPress theme and plugins a site is using

WordPress runs a large share of the web, and it’s unusually open about how a site is assembled. Themes and plugins load their files from predictable folders, and those folder names usually match the names the theme or plugin is published under. With a few minutes and a browser, you can often identify both.

Here’s the manual method, the reasons it sometimes falls short, and how to use what you find responsibly.

First, confirm the site runs WordPress

View the page source (Ctrl + U, or Cmd + Option + U on a Mac) and search for wp-content. If stylesheets, scripts or images load from /wp-content/ or /wp-includes/, the site is almost certainly WordPress.

Two further checks help when paths have been disguised:

• A <link rel="https://api.w.org/"> tag in the page head points to the WordPress REST API.
• Visiting /wp-json/ on the domain usually returns a JSON description of the site’s API, unless the owner has restricted it.

Find the theme

Search the source for /wp-content/themes/. The segment that follows is the theme’s folder name:

https://example.com/wp-content/themes/twentytwentyfive/style.css

Every WordPress theme has a style.css file whose header describes it. Open /wp-content/themes/<folder>/style.css in your browser and read the comment at the top. It typically lists the Theme Name, Author, Theme URI and Version.

Look for a Template line as well. If it’s present, you’re looking at a child theme, and the value names the parent theme it builds on. Agencies often customise a commercial parent theme this way, so the parent is usually the answer people are really after.

If the theme name is something like “Company Theme” with no public author, the site most likely uses a custom theme built for that business. There’s nothing to download in that case.

Find the plugins

Plugins that change the front end of a site usually load their own files from /wp-content/plugins/<slug>/. Search the source for /wp-content/plugins/ and note each distinct slug. For plugins published on WordPress.org, the slug normally matches the directory address, so /wp-content/plugins/contact-form-7/ corresponds to wordpress.org/plugins/contact-form-7/.

Other clues are worth checking too:

• HTML comments. Some plugins sign their output. Yoast SEO, for example, adds a comment around its meta tags naming the plugin.
• Class names. Page builders and common plugins use recognisable prefixes, such as elementor- for Elementor, wpcf7 for Contact Form 7 and woocommerce body classes for WooCommerce.
• REST API namespaces. The /wp-json/ response includes a list of namespaces registered by plugins, such as contact-form-7/v1 or yoast/v1.

Why you won’t see every plugin

A front-end inspection only finds plugins that leave front-end traces. Expect gaps for these reasons:

• Admin-only plugins such as backup, security and editorial tools usually produce no public output at all.
• Optimisation plugins combine and minify CSS and JavaScript into new files, often under a cache folder, which hides the original plugin paths.
• Hardening can rename folders, remove version strings or restrict the REST API.
• Custom code in a theme can do what a plugin would otherwise do, with no plugin involved.

So a list of detected plugins is a minimum, not a complete inventory.

Doing it faster

Theme detector websites and browser extensions automate these checks. TechScan AI detects WordPress themes and plugins where a site exposes them and shows the file path or marker each detection is based on. That lets you confirm a match yourself, which is useful when a child theme, a renamed folder or a bundled asset makes the answer less obvious. Like any external tool, it can only report what the site makes visible.

Using what you find responsibly

Identifying a theme or plugin is useful for learning, compatibility checks and planning a migration. If you want to use the same theme, get it from its author or from WordPress.org, so you receive updates and support. WordPress code is generally GPL-licensed, but logos, photographs and other design assets often aren’t, and a site’s content belongs to its owner. Inspect politely, too: reading public pages is fine, but scanning a site for vulnerabilities or hammering it with requests is not.

Checklist

1. Confirm WordPress: /wp-content/ paths, the REST API link, /wp-json/.
2. Find the theme folder under /wp-content/themes/ and read its style.css header.
3. Check for a Template line to find a parent theme.
4. List plugin slugs under /wp-content/plugins/, then check comments, class names and REST namespaces.
5. Assume some plugins are invisible, and record what you couldn’t confirm.