How to Tell Which Theme and Plugins a WordPress Site Uses, and What 29 Real Sites Gave Away

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

You can find out which theme a WordPress site uses in about ten seconds, and a few of its plugins in about a minute, because both leave their folder names in the page itself. When I read the home pages of 67 well-known sites on 21 October 2026, 29 turned out to be WordPress with a visible theme folder, and every one of those 29 named its theme. The plugin picture was different: the median site showed three plugins, and on this site, which runs 24 active plugins, a visitor’s page source shows only four. A remote malware scanner reads the same page source and could not name a single plugin on the two sites I tested, which is covered in How to Scan a Website for Malware, and What 69 Remote Scans Showed.

This guide shows how to read a theme and plugin list by hand, what the free detector tools are really doing, and how much a detector can and cannot tell you, using measurements from those 29 sites and from my own two.

What a theme or plugin detector actually reads

A detector does not see inside the site. It downloads the same public page your browser gets and looks for file paths. WordPress loads a theme’s styles from /wp-content/themes/theme-name/ and a plugin’s scripts and styles from /wp-content/plugins/plugin-name/, so the folder name sitting in those paths is the theme or plugin slug. Everything else a tool shows, such as a pretty name, an author and a version, comes from one of two places: a lookup in the tool’s own database, or a header inside the theme’s style.css file.

That header is documented in the WordPress theme handbook. It holds the theme name, author, description and version, and a child theme adds a Template: line naming its parent. Because the file is public, anyone can open it. On this site the address /wp-content/themes/generatepress/style.css opens a text file whose first lines say Theme Name: GeneratePress and name its author.

Find a theme by hand in ten seconds

1. Open the site, press Ctrl+U (or Cmd+Option+U on a Mac) to view the page source.
2. Search for wp-content/themes/.
3. Read the folder name straight after it. That is the theme.
4. If a second theme folder appears, one of them is usually a child theme layered on a parent. Open /wp-content/themes/that-folder/style.css and look for the Template: line, which names the parent.

From a command line the same check is one line, and it also works when the site hides its source from the right-click menu:

curl -s https://example.com/ | grep -o 'wp-content/themes/[a-z0-9_.-]*' | sort -u

Replace example.com with the address you want to check. The result is a short list of theme slugs, one per line.

Find plugins the same way, and know what you are missing

Swap the search term for wp-content/plugins/ and you get every plugin that loads at least one file on that page. The command is the same with the folder name changed:

curl -s https://example.com/ | grep -o 'wp-content/plugins/[a-z0-9_.-]*' | sort -u

The catch is in the phrase “loads a file on that page”. A plugin that only works in the admin area, runs in the background or changes how the server answers adds nothing to the page source, so no page-source tool can see it. A security plugin, a redirect manager, a comment switch-off and a cache plugin can all be running without leaving a trace in the page. That is the real reason detector tools report fewer plugins than a site actually uses, and why two different detector tools can disagree about the same site.

What 29 real WordPress sites gave away

On 21 October 2026 I fetched the home page of 67 sites once each, from the Netherlands, following redirects and reading the HTML as received. Nine refused the request (bot protection or a timeout) and 26 of the remaining 58 were not WordPress at all, mostly large shops, publishers and software companies on custom platforms. Three more mentioned a WordPress path only in passing, such as an image hosted on another subdomain, and showed no theme or plugin folder, so I left them out. That leaves 29 sites to count.

What the page source showed	Sites (of 29)
A named theme folder	29
More than one theme folder (parent and child, or extra design layers)	11
No plugin folder at all	2
One to three plugin folders	15
Four or more plugin folders	12 (the most on one page was 16)
A generator tag naming WordPress and its version number	14
A generator tag of any kind	23
A version number (?ver=) on scripts and styles	28
A REST API discovery link in the page head	20

Three things stand out. First, the theme is almost never hidden: even sites with an in-house theme show its folder name, such as tc-24, vice-2024 or source-theme. Second, plugins are far less visible, with a median of three per site. Third, the generator tag is not always WordPress. Seven of the 23 tags named a plugin instead, such as All in One SEO, Site Kit by Google, WPML or Easy Digital Downloads, and two said WordPress.com, so a quick look at that one tag can mislead you about both the version and the software.

The ground truth: this site’s 24 plugins versus what a visitor sees

The only way to know how much a detector misses is to check a site whose plugin list you can read. I can read two. Through the WordPress admin I counted 25 installed plugins on this site and on repairpicks.com, with 24 active on each. Then I looked at what an outsider can see:

Method	This site	repairpicks.com
Active plugins (admin view, the real answer)	24	24
Plugin folders in the page source of a post	4	7
Plugins whose readme.txt file opens in a browser	22	22

The page source of a post on this site names four plugins: Site Kit by Google, Image Prioritizer, Optimization Detective and Web Worker Offloading. The other twenty never load a file for visitors. The second row is the surprise. Most plugins ship a readme.txt in its folder, and on both sites 22 of the 24 active plugins return that file to anyone who asks for it at /wp-content/plugins/plugin-name/readme.txt. A person can confirm that a specific plugin is installed this way even when it shows nothing in the page. The two exceptions, Easy Table of Contents and Instant Images, returned a not-found error for the readme, even though Easy Table of Contents does appear in the page source of a repairpicks post. So the two methods catch different plugins, and no single check gives a full list.

One honest limit on that second method: you need to know the plugin name to ask for its file, so it confirms a guess rather than producing a list. I only tested it against my own two sites. Running guesses against sites you do not own is the behaviour security scanners are built for, and it is not something to do to someone else’s site.

Is it a problem that anyone can see this?

Mostly no. A theme name and a handful of plugin folders are the same information a visitor’s browser has to download anyway, and it cannot be switched off without breaking the site. Hiding it is also weak protection. A vulnerable plugin is just as vulnerable when it is not listed anywhere, and an attacker does not need a page-source list to test for a famous plugin. The protection that matters is keeping the theme, the plugins and WordPress itself updated and deleting what you do not use.

The one piece you can remove cleanly is the generator tag. If you want it gone, add this to a code-snippets plugin:

remove_action( 'wp_head', 'wp_generator' );

Know what that buys you before you bother. In the survey, 28 of 29 sites also put version numbers on their script and style addresses, and many of those numbers belong to the theme or plugin itself, so removing the tag hides one version string and leaves the others. I have not changed this on my own sites for this guide: the home page of this site still carries WordPress 7.1.3 in its generator tag, which is simply how a default install behaves, and this site runs on Hostinger with its theme and plugins left readable. If you are checking more than the theme, my guides to checking your security headers and to finding out who hosts a website cover the response side and the server side of the same public information.

Using this to research a site you admire

The most common reason to run these checks is plain curiosity: what is that site built with? Two warnings keep you from wrong conclusions. Many large sites run a custom theme built in-house, and in my sample names like source-theme or whitehouse point to code you cannot download or buy. And a page-builder or block-heavy design comes from the plugin plus the theme together, so a theme name on its own rarely explains how a page looks. Check the plugin folders for a builder, then check whether the layout needs the paid version, before you decide the theme is the reason you like the site.

Checked for accuracy on 21 October 2026. The survey made one GET request per site and read only the HTML of the home page, from the Netherlands, so a different page, country or day can show different plugins; nine sites that refused automated requests are not counted. The plugin counts for this site and repairpicks.com come from the WordPress admin plugin list and from reading each plugin’s public readme file on those two sites only. Theme header fields were checked against the WordPress theme handbook.