There are four places WordPress leaves its name in a page it serves. Any one of them can be removed by someone who wants it removed. Removing all four, and keeping them removed through every plugin update, is a project — which is why checking all four is reliable when checking one is not.
The quick way
Run the URL through the WordPress Theme Detector. It reports which of the four signals it found, in plain sentences, and names the site as WordPress if any of them matched.
The list of signals matters more than the verdict. A site with all four is a standard install. A site with one is someone who has been tidying up, and that tells you something about how the site is maintained before you have looked at anything else.
Signal 1: assets served from /wp-content/
The strongest and most common signal. Themes, plugins and uploaded media all live under one directory, and every one of them shows up in the page's own HTML:
<link rel="stylesheet" href="https://example.com/wp-content/themes/astra/style.css">
<script src="https://example.com/wp-content/plugins/contact-form-7/includes/js/index.js"></script>
<img src="https://example.com/wp-content/uploads/2026/03/header.jpg">
View the page source and search for wp-content. One match is enough.
This path is configurable — WP_CONTENT_DIR and WP_CONTENT_URL in wp-config.php will move it — but very few sites do, because a handful of older plugins hardcode the default and break when it moves.
Signal 2: core scripts from /wp-includes/
WordPress core ships its own JavaScript, and it is served from a separate directory to the one themes and plugins use:
<script src="https://example.com/wp-includes/js/dist/hooks.min.js"></script>
<script src="https://example.com/wp-includes/js/wp-emoji-release.min.js"></script>
The emoji script is the one you will see most often, because it loads by default on every page of a fresh install and most people never turn it off.
This signal is independent of the first in a useful way: wp-content tells you a theme or plugin is present, wp-includes tells you core itself is serving the page. On a site that has moved wp-content, this one usually still resolves.
Signal 3: the REST API link in the head
WordPress advertises its own API in the document head:
<link rel="https://api.w.org/" href="https://example.com/wp-json/">
You can also request https://example.com/wp-json/ directly. If it returns JSON describing routes and namespaces, the site is WordPress and you are done.
The head link is trivially removed with one line in a theme's functions.php. The endpoint behind it is harder to get rid of, because the block editor is built on it — disabling the REST API outright breaks the admin for everyone editing the site, so most people who disable it only restrict it to logged-in users. In that case the URL returns a 401 with a WordPress-shaped JSON error, which is still an answer.
Signal 4: the generator meta tag
The most direct and the most frequently removed:
<meta name="generator" content="WordPress 6.9.6" />
When it is present it gives you the platform and the exact version in one line. It is also the first thing every hardening guide tells people to strip, so its absence means nothing at all — see how to check what WordPress version a site is running for what to do when it has gone.
Why the answer needs all four
Each signal has a different removal cost, and that is the whole point of checking them together. In order, cheapest to strip first:
- The generator meta tag. One line in
functions.php. Every hardening guide lists it, so it is missing far more often than not. - The REST API head link. Also one line, and the endpoint behind it usually stays reachable anyway.
- The
/wp-content/paths. Awp-config.phpchange, plus fixing whatever hardcodes the default. - The
/wp-includes/scripts. Dequeued individually, one handle at a time, and re-checked after updates that add new ones.
A site that has removed the cheap two and kept the expensive two is the common case. It is also why a checker that only looks for the generator tag reports "not WordPress" on sites that plainly are.
When none of the four appear
Three quite different explanations, worth telling apart.
A caching or optimisation plugin has rewritten the asset paths
The usual cause of a false negative. Plugins that combine and minify stylesheets serve the result from their own cache directory:
<link rel="stylesheet" href="/wp-content/cache/min/1/a3f9c2.css">
Note that this example still contains wp-content, so the platform is still detectable — it is the theme that has been hidden, not WordPress. Detection of the platform survives caching far more often than theme detection does.
A CDN is serving the assets from another hostname
Same mechanism, stronger effect. If assets come from a separate domain with a restructured path, wp-content may genuinely never appear in the HTML. Check the page's own <head> for the REST API link, which is served by the origin and is unaffected by how assets are hosted.
It is headless WordPress
WordPress manages the content, and a separate front end — commonly a JavaScript framework — renders the pages. None of the four signals exist, because none of WordPress's own output is being served to the browser. This is genuinely undetectable from the front end, and no tool that claims otherwise is measuring anything.
It is also rare outside larger publishers and product companies. If you are looking at a small business site with none of the four signals, headless is not the explanation.
Can a site hide that it runs WordPress?
Mostly no, and the attempts are worth understanding because they are also what causes a "not detected" result on a site you know is WordPress.
You can strip the generator tag, remove the REST API head link, dequeue the emoji script, rename wp-content, and route everything through a CDN. What remains is behavioural rather than textual: the login path, the exact shape of the 404 page, the Disallow: /wp-admin/ line that WordPress writes into a virtual robots.txt, the ?ver= query strings appended to enqueued assets, and the class names WordPress puts on the <body> element. Closing those individually is possible and almost nobody does it.
The reason to know this is not to defeat it. It is that hiding the platform is not a security measure. Attacks on WordPress are automated and untargeted: a bot requests /wp-login.php on every address it has and acts on what answers. It does not read your meta tags first. Removing the version number protects you from nothing, and time spent on it is time not spent on the things that do work — updates, strong admin passwords, two-factor authentication, and removing plugins you stopped using.
Checking a site you own
Log in. The admin footer names the version, and Tools → Site Health reports the state of the install in more detail than any external check can.
The useful case for an external check on your own site is the opposite direction: seeing what you are publishing to everyone else. Run your own URL through the detector and read the evidence list as a description of your public surface. If it names a plugin you forgot you had installed, that is worth an afternoon.
It is not WordPress. So what is it?
The detector answers one question — is this WordPress — and does not identify other platforms. That is a deliberate scope rather than a gap, because a fingerprint is only trustworthy when someone has done the work to establish what each signal means.
If all four signals are absent and the site is not headless, the same view-source method still works. Hosted site builders and other content systems leave equally distinctive traces in asset paths and head tags; search the source for repeated hostnames and directory names and you will usually have the platform in under a minute.
Once you know it is WordPress, the next questions are which theme it uses, which version it runs, and which plugins are loaded.
Check any URL with the WordPress Theme Detector.