Short answer: the fastest check is to open the page source and search for
/wp-content/
. Almost every WordPress site loads its CSS, JavaScript, and images from that path, so a single match is a strong signal. Two more give you near-certainty: a
<meta name="generator" content="WordPress 6.x">
tag in the
<head>
, and a JSON response at
https://example.com/wp-json/
. To find the theme, look at the stylesheet URL under
/wp-content/themes/<theme-name>/
or read the header comment at the top of that theme’s
style.css
. When manual checks are awkward, a browser extension like Wappalyzer or a dedicated WordPress theme detector tells you both in one click.
Knowing whether a site runs WordPress is useful for a few honest reasons. You might be quoting a redesign and want to know what you are inheriting. You might be researching how a competitor built something. You might have inherited a site with no documentation and need to know what you are looking at before you touch it. Whatever the reason, WordPress leaves a consistent set of fingerprints, and almost none of them require anything more than your browser.
This article walks through every reliable detection method from fastest to most thorough, how to identify the specific theme a site is running, the tools that automate all of it, and why the common attempts to hide that a site runs WordPress mostly do not work.
Detection methods at a glance#
| Method | Where to look | Confidence | Can it be hidden? |
|---|---|---|---|
/wp-content/
in source | Page source (Ctrl+U) | High | Rarely, and partially |
| Generator meta tag |
<head>
of the page source | High | Yes, easily |
/wp-json/
REST API | Visit
example.com/wp-json/
| Very high | Sometimes |
/wp-login.php
| Visit
example.com/wp-login.php
| Very high | Yes, by renaming |
/wp-admin/
redirect | Visit
example.com/wp-admin/
| High | Yes, by renaming |
| Theme path in source |
/wp-content/themes/<name>/
| High (theme name) | Rarely |
| Browser extension | Wappalyzer, BuiltWith | High | Mostly no |
No single check is bulletproof on a site that has deliberately covered its tracks, but you almost never need more than two of them to agree. Start at the top of the table and stop as soon as you have a clear answer.
Method 1: search the page source for wp-content#
This is the single most reliable manual check, and it works on the vast majority of WordPress sites with no special tools.
Open the site, then view the page source. In Chrome, Firefox, or Edge that is Ctrl+U (Cmd+Option+U on a Mac), or right-click and choose “View page source.” Then search the source with Ctrl+F for:
/wp-content/WordPress serves themes, plugin assets, and uploaded media out of the
wp-content
directory, so a typical page references it many times – in
<link>
tags for stylesheets,
<script>
tags for JavaScript, and
<img>
tags for media. One match is a good signal. A dozen matches is effectively a confirmation.
While you are in the source, search for
/wp-includes/
as well. That directory holds WordPress core’s own scripts and styles, and seeing it alongside
wp-content
is about as definitive as a manual check gets.
A caveat worth knowing: a small number of sites rename these directories or serve assets through a CDN that masks the original path. That is uncommon, and even then the other methods below usually still give the site away.
Method 2: check the generator meta tag#
WordPress, like most CMS platforms, advertises itself in a generator meta tag. View the page source and search for:
<meta name="generator" content="WordPress 6.5.2" />If it is there, you have your answer and often the exact version number too. Many other platforms do the same thing, so the same check identifies Drupal, Joomla, Shopify, Wix, and others by their own generator strings – the same fingerprinting logic that drives platform comparisons like WordPress vs Joomla vs Drupal.
The catch is that this is the easiest fingerprint to remove. A one-line snippet in a theme’s
functions.php
strips it, and several security and SEO plugins remove it by default precisely because broadcasting the exact WordPress version is a small information leak. So the generator tag being present is a strong yes, but its absence is not a no. Fall back to
wp-content
or the REST API.
Method 3: hit the wp-json REST API#
Every modern WordPress install (4.7 and later) exposes a REST API at a predictable path. Visit:
https://example.com/wp-json/If the site runs WordPress and has not blocked the endpoint, you get a JSON document describing the site – its name, description, the namespaces the API exposes (
wp/v2
,
oembed/1.0
, and so on), and a list of routes. No other platform produces this exact structure, which makes it one of the highest-confidence checks available.
You can go further.
https://example.com/wp-json/wp/v2/users
often returns the list of author accounts, and
https://example.com/wp-json/wp/v2/types
lists the registered post types. This is also why the REST API matters from a security angle: the same user enumeration that confirms WordPress for you confirms valid usernames for an attacker building a brute-force list. Locking it down is part of a normal hardening pass, covered in is WordPress secure and how to harden it.
Method 4: try the login and admin URLs#
WordPress ships with two well-known entry points:
https://example.com/wp-login.php
https://example.com/wp-admin/On a default install, the first shows the WordPress login form and the second redirects you to it (because you are not logged in). Either result is a near-certain confirmation.
Plenty of site owners rename or restrict these paths – it is one of the first things a hardening guide recommends, and the reasoning is in how to secure WordPress login. So a 404 here does not rule WordPress out; it might just mean the owner moved the login page. Treat a working
/wp-login.php
as a yes and a missing one as inconclusive.
How to identify the theme a site is using#
Once you know a site runs WordPress, finding the active theme is usually a two-minute job.
Read the theme path in the source#
The most direct route is the stylesheet URL. View the page source and search for
/wp-content/themes/
. You will find something like:
<link rel="stylesheet" href="https://example.com/wp-content/themes/astra/style.css" />The folder name right after
themes/
is the theme’s directory name – here,
astra
. That is frequently the same as the theme’s public name, or close enough to search for.
Open the theme's style.css header#
Every WordPress theme is required to carry a header comment at the top of its
style.css
file. Open it directly:
https://example.com/wp-content/themes/astra/style.cssThe first block tells you exactly what you are looking at:
/*
Theme Name: Astra
Theme URI: https://wpastra.com/
Author: Brainstorm Force
Version: 4.6.0
*/That is the canonical source of truth – the theme name, author, and version straight from the theme itself. If the site uses a child theme, the header will also list a
Template:
field pointing at the parent theme it is built on.
Check the footer and look for a parent theme#
Many themes leave a credit line in the footer (“Powered by Astra,” “Built on Divi,” and so on). It is a quick hint, though owners often remove it, so treat it as a starting point rather than proof.
One more thing to watch for: a lot of production sites run a child theme on top of a popular parent like Astra, GeneratePress, Kadence, or Divi. The detector tools and the
style.css
header both expose the parent relationship, which is what you actually want if you are sizing up the underlying framework. If you are evaluating a stack you may have to work on, knowing the parent theme matters more than the child’s custom name – it tells you what you can rebuild against. The wider context on themes, child themes, and how they fit together is in how to install, change, and customize a WordPress theme.
Tools that automate all of this#
Manual checks are reliable, but a few tools roll every fingerprint into a single result.
- Wappalyzer – a browser extension (Chrome, Firefox, Edge) and a website. Click it on any page and it reports the CMS, the theme, page-builder plugins it can detect, the web server, analytics, and more. The fastest single-click answer for both questions at once.
- BuiltWith – a web-based profiler. Paste a URL and it returns a full technology stack, including the CMS and often the theme, plus historical data on what the site used to run. Good for research where you want more than a yes or no.
- WordPress theme detectors – sites like WPBeginner’s WordPress Theme Detector, “What WordPress Theme Is That?”, and Scanwp take a URL and report the active theme, the parent theme if it is a child theme, and any plugins they can fingerprint. Useful when the source is minified or the theme folder name is not obviously the theme’s real name.
These tools read the same public signals you would check by hand – the source, the headers, the REST API – so they are subject to the same limits. When a site has genuinely hidden its fingerprints, the tools come up empty too. They are a convenience, not magic.
When a site hides that it runs WordPress#
You will occasionally hit a site that runs WordPress but does not obviously look like it. This is usually deliberate. Owners do it by removing the generator tag, renaming the login URL, blocking
/wp-json/
, and sometimes routing assets through a CDN that masks the
wp-content
path.
It is worth being clear about what this does and does not buy them. Hiding the fingerprints is security through obscurity: it makes casual identification slower, but it does not make the site meaningfully harder to compromise. Automated scanners do not read the generator tag and politely move on – they probe known paths regardless, and a site that is actually patched, rate-limited, and running a web application firewall is protected whether or not a curious visitor can tell it runs WordPress. The real defenses are the ones in is WordPress secure and how to harden it and how to secure WordPress login, not the cosmetic ones.
So if your manual checks come up empty, cross-reference two or three methods before concluding the site is not WordPress. A missing generator tag plus a renamed login page can fool a quick glance, but a
/wp-content/
reference buried in the source, or a
/wp-json/
endpoint that the owner forgot to block, usually settles it.
How Hostney fits in#
If you run WordPress sites on Hostney, the same fingerprints apply – WordPress is WordPress wherever it is hosted, and the detection methods above work identically. What changes is that the things that actually matter for security are handled at the platform level rather than left to obscurity. Sites get automatic SSL, per-account container isolation, behavioral bot protection that filters automated scanners before they ever reach the login page, and per-site PHP version control, so the question stops being “can someone tell this is WordPress” and becomes “does it matter if they can.” For most well-run sites, it does not.
Quick reference#
- Is it WordPress? Search the page source (Ctrl+U) for
/wp-content/. One match is a strong signal; pair it with/wp-includes/for near-certainty. - Confirm it. Check for a
<meta name="generator" content="WordPress ...">tag, or visitexample.com/wp-json/for the REST API response. - Login check. A working
example.com/wp-login.phpis a confirmation; a missing one is inconclusive, not a no. - Which theme? Find
/wp-content/themes/<name>/in the source, then open that theme’sstyle.cssto read the Theme Name, author, version, and parent theme. - Automate it. Wappalyzer or BuiltWith for the full stack; a WordPress theme detector for the theme and its parent.
- Hidden sites. Removing the generator tag or renaming the login page only slows casual identification – it is not real security. Cross-check two or three methods before ruling WordPress out.