CMS Detector
and the proof behind every answer

What a CMS Detector Actually Looks At

The question people actually type is what CMS is this website using, and a CMS detector answers it from the outside, with exactly what your browser gets: one HTTP response. That response carries headers, a set of cookies, and a body of HTML full of links to scripts, stylesheets and images. A content management system leaves fingerprints in all three, because it has to serve its own files from somewhere and it has to keep track of a session. Read those traces carefully and you can usually name the platform without ever seeing the server.

Nothing here involves access to the site: no login, no file listing, no database query, no port scanning. The tool above requests the address you give it, the same way a visitor would, and reads what comes back. That is also why the answer is bounded: a platform that hides its traces well is hard to identify from outside at all.

The signals themselves fall into five kinds, and they are not equally trustworthy. Structural signals are paths and endpoints the platform needs in order to function — WordPress serving its own JavaScript from /wp-includes/, or answering with a list of API routes at /wp-json/. Cookies are the named values a platform sets. Response headers are tags a server or a proxy adds. An exact URL is a third-party script the vendor pins to one address, which Cloudflare does with Turnstile in so many words: the file "must be fetched from the exact URL shown above". And a generator tag is the site simply declaring itself in its own markup. The first kind is hard to remove without breaking the site. The last kind takes one line of configuration, which is why a result labels each signal with the kind it is.

One more layer matters before you read a result. Between you and the application there is usually a proxy or a CDN, and that machine can add headers, remove headers and answer on the origin's behalf. If you have not met that architecture before, our guide to the role of proxy servers in networking explains what sits where. It matters here because a proxy is entirely capable of stripping the very header a detector was hoping to read.

How to Read Your Detection Result

Any website technology checker worth using has to separate its findings rather than pouring them into one list, so the four tiles at the top of a result answer four different questions. Platform is the content management system or storefront. Framework is the front-end build, which on a modern site is often a different thing entirely. CDN or proxy is whatever answered on the site's behalf. Server is copied straight out of the Server response header, with no interpretation added — and if that header is what you came for, our HTTP Headers Analyzer takes the whole set apart properly.

Each technology then gets a confidence label, and the rule behind it is published rather than implied.

A version number is never a measurement

When a generator tag carries a version, the tile shows it and labels it as declared by the site. That wording is doing real work. A version string in a meta tag is whatever the site chose to publish there: it can be stale, edited, or left over from a build replaced weeks ago. Treating it as a measurement is how people end up reporting a vulnerability against a version nobody is running.

The CDN tile and what it does not tell you

A Cloudflare signal means the response passed through Cloudflare. It says nothing at all about what is behind it, because that is the entire point of a reverse proxy. There is one case where the tool goes further and suppresses the reading: on a confirmed Shopify store, Shopify's own documentation describes its CDN as backed by Cloudflare, so reporting Cloudflare as the merchant's separate choice would be misleading. To identify the network a site actually sits on, our Cloud IP Check answers that question directly instead.

Why This Tool Shows You the Evidence

Thirteen ranking pages for this kind of query were opened and read during the research for this tool. They range from databases with six-figure technology counts to single-purpose pages with no article at all, and they share one thing: not one of them shows you why it reached its answer. Three describe their method in a paragraph somewhere on the page. None puts the signal next to the result.

That gap matters more than it sounds. A technology detector makes a claim about somebody else's property, and usually to inform a decision: whether to pitch an agency's services, whether a migration is feasible, whether a suspicious site is what it appears to be. A claim you cannot check is worth much less than one you can.

Checking this one takes seconds. View the page source, search for the string shown in the evidence box, and you are looking at the same bytes the tool looked at. If it is not there, the tool is wrong and you will know immediately — which is a standard the rest of this category has quietly avoided.

Where a signal has to appear before it counts

There is a second half to showing your working, and it is the part that stops this page telling you something untrue. A path like /wp-content/ only counts when it appears in something the page actually loads — a stylesheet, a script, an image, a url() reference. It does not count when it appears in a sentence, in an HTML comment, inside a code sample, or in a string in an inline script. A guide about WordPress is not a WordPress site, and a detector that cannot tell the difference will confidently tell you it is.

Host matters too, and less simply. If an asset sits on the site's own domain, the signal is worth its full weight. If it sits on a different host, that is still real — every one of these platforms can legitimately serve its files from a CDN — but it is also exactly what a page linking to somebody else's site looks like from outside. So a match on another host is reported at one step lower, the evidence line says where it was found, and it can never confirm a platform on its own.

What "checked and not found" is for

The other half of showing your working is admitting what you did not find. Most tools print nothing on an empty result, or an unexplained dash, leaving the reader unable to tell "well hardened" from "not in our list" from "our fetch failed". The list on a result here names every signal tested and absent. On a site with its traces stripped, that list is the answer.

Live read, not a stored record

Two of the largest tools in this space serve results out of a crawl database, and one of them charges several times as much for a live check. That makes their answers a different kind of thing from this one. Every result here is a request made when you asked for it, timestamped in the request record at the bottom, and held on our server only briefly so that a site is not asked twice in a row for the same answer.

Which Signals Are Reliable, and Which the Vendors Themselves Remove

This is the part that explains almost every disagreement between two detectors, and the research found it published nowhere else. Several of the most widely used signals are documented by their own vendors as optional, movable or removable. Not rumoured — documented.

Drupal and Joomla are worth calling out together here, because both ship a generator tag and both document ways of removing it, which means a site running either can look like nothing at all. The same applies in reverse to a framework: Next.js is identified by a path that survives a change of host, so it is found more reliably than either of them. That is why the tool ranks signals rather than counting them, and why it will not call a platform confirmed on a generator tag alone no matter how confident that tag sounds. It is also why some technologies are deliberately missing: where a vendor documents no identifying signal at all, there is nothing honest to match on, and a guess in a results table looks exactly like a fact.

WordPress: Theme, Child Theme and Plugins

Most people arriving at a CMS checker already suspect the answer is WordPress, and what they actually want is the theme. That is where the honest answer diverges sharply from what most tools print, so it is worth being precise about what can and cannot be known.

This is also the ground held by the specialists. A dedicated WordPress theme detector, or a Shopify theme detector, does one job and does it in more depth than a general checker will. What follows is what any of them can see from outside, and where all of them run out of road.

A WordPress page loads its theme's stylesheet from a path shaped like /wp-content/themes/<folder>/style.css. The tool reads that folder name and shows it. A forum moderator on the official WordPress support site gives readers exactly the same instruction for doing it by hand: view the source and search for /themes/. There is no secret method; the difference is that this page shows you the line it read.

A folder name is not a theme name

The folder is what the installation calls the directory, and that is frequently not what the theme is called in public. A commercial theme often ships with a tidy folder matching its name; just as often a developer renames it, builds something bespoke, or wraps a commercial parent in a custom child. So the string a detector prints can be meaningless outside that one server. One merchant described this on their platform's own forum: the detectors all returned the name the file had been saved under, which told them nothing.

So when nothing public matches, "likely custom, or a child theme" is the truthful answer — and in the support threads where people ask this question, custom is usually what it turns out to be. That is a real answer to the underlying question, which is almost always can I buy this.

Two theme folders usually means a child theme

When a page loads assets from two different theme directories, the ordinary explanation is a child theme plus its parent, which is the pattern WordPress recommends for customising a commercial theme without losing the ability to update it. The tool flags that as likely rather than certain, because a plugin can also enqueue a file from another theme directory and produce the same appearance from the outside.

Plugins, and the limits of seeing them

Plugin folders show up the same way, in the paths of any script or stylesheet they load. That catches the plugins that affect the front end, which is most of the interesting ones — a shop, a page builder, a forms plugin, a caching layer. It does not catch anything that works only in the admin area or entirely server-side, and it never will, because those leave nothing for a visitor to see. An empty plugin list means "nothing visible from outside", not "nothing installed".

Why a Detector Says “Not WordPress” About a WordPress Site

This is the single most common complaint about tools in this category, and it is worth naming the causes because every one of them is fixable by the reader rather than mysterious. A user on the official WordPress forums put the frustration plainly: the site was obviously a WordPress theme, and every online tool they tried failed to identify it.

1. The generator tag was removed. One line of configuration, documented by WordPress itself. A tool that relies on it now has nothing.
2. The home page has pings closed, so X-Pingback is absent by design. A detector treating that header as a requirement will decide the site is not WordPress.
3. A proxy stripped the headers. The platform's traces never reach the tool, which then reports on the proxy instead.
4. The front end is headless. A separate application — commonly a Next.js or Nuxt front end — renders the pages, and WordPress only supplies the content through its API. The markup contains no WordPress traces at all, because WordPress did not write it.
5. A security plugin rewrote the asset paths, which some do specifically to defeat fingerprinting.
6. The page is a JavaScript shell. The server sent a near-empty document, so there is no markup to read at all.

The tool handles the fourth case by reporting both layers rather than picking one. If a site runs a modern front-end framework and still exposes a WordPress API, each gets its own tile and its own evidence — a more accurate description of that architecture than either answer alone. The sixth case is reported as a thin response, not as an absence of technology, because the two are different findings.

What This CMS Checker Cannot Tell You

Every honest diagnostic has an edge, and knowing where it is makes the results in the middle more useful rather than less.

• It reads one page, not a site. A large estate can run several platforms on different paths. Checking a second URL on the same domain is often informative for exactly that reason.
• It does not execute JavaScript. Anything a script loads after the page arrives is invisible here. That is a deliberate trade: it keeps the check fast, cheap and impossible to turn into something heavier.
• It cannot see behind a proxy that strips traces. Nothing reading from outside can. To work out where a site is actually hosted, our guide on how to find the IP address of any website server takes a different route to that question.
• It does not judge security. Whether a site's headers are configured well, whether its policies are strict enough, and whether anything important is missing are all separate questions with their own answers. The headers analyzer linked above grades that side of the same URL.
• It does not diagnose TLS. A certificate that has expired, a chain that is incomplete, or a handshake that fails outright will stop this tool reading the page at all, and when that happens it says so rather than reporting an empty result. Working out which of those went wrong is the job of our SSL Checker.
• It does not tell you whether a site is reachable from elsewhere. Plenty of sites are geo-blocked, and plenty serve a different response to a datacenter address than to a home broadband connection — a distinction our guide to residential versus datacenter IPs goes into properly.
• It checks from one place, over one route. Everything above was read from a single server on a single network path, which is the honest scope of any one-shot fetch. Testing the same address from a different vantage point is what our Proxy Checker is for.
• It cannot confirm a version. What a site declares in a meta tag is a claim, not a measurement.

Being blocked is a result too

Some sites refuse automated requests outright and answer with a 403. When that happens the tool says so and names the status, rather than reporting an empty result as though the site had no technology. If you are researching infrastructure at any scale, that refusal is itself useful information. It is also a pattern worth understanding before you start, and our guide to proxies for web scraping covers why a site treats some requests differently from others.

Every request this page makes identifies itself in its user agent, with a link back to this page, so any site owner reading their logs can see exactly what asked and why. At most two extra requests are ever made, and only when a first-pass signal already pointed at that platform. There is no sweep of speculative paths against a stranger's server.

CMS Detection Questions People Actually Ask