Free tool
What is this site built with?
Only what the site says about itself gets read: its response headers, its generator tag, the paths of the files its pages pull in, the names of the cookies it sets. Every line of the result comes with the exact fragment that gave it away, so you can judge the call yourself — and where there is nothing to see, the page says so rather than guessing.
Why check this before you take over a site
Taking on a site without knowing what sits underneath means taking on a debt nobody has priced. A WordPress advertising the same version for two years, a store on a platform that will have to be migrated, an application framework nobody on the team has touched — every one of those changes the quote. Then, once the site is yours to answer for, the question stops being what it runs on and becomes what is going to break: the domain, the certificate, the DNS records, the sending reputation.
How the detection works
One ordinary request to the home page, the same request a browser would make. Four sources are then read: the response headers, the HTML generator tag, the paths of the files the page calls, and the names of the cookies it sets. Every match is printed with the exact fragment that triggered it. We run no scripts, test no vulnerabilities and guess at no URLs — what a site does not publish is not detected, and the page says so.
The response, up close
The site hides nothing, it publishes it
There is no detective work here: the headers and the first lines of the document announce the server, the language and the CMS. Click a highlighted line to see what it gives away, then look at the same page once the chatter is switched off.
HTTP/1.1 200 OK
content-type: text/html; charset=UTF-8
<!doctype html>
Lines you can read without forcing anything: 5
Click a highlighted line to see what it gives away.
Sample response, on a domain name reserved for documentation.
The scope of the measurement
Silence is not a verdict.
“Nothing detected” means “no known marker in what came back”, not “this site runs nothing”.
- 4sources read in the response
- 1page read: the home page
- 0scripts executed
Reading the result
Every line carries a name, a piece of evidence and sometimes a version. The evidence is there so you can judge for yourself — a detection tool that hides what made up its mind is asking for trust it has not earned.
- A technology and its evidence
- The name comes from a table of markers, the evidence from the site itself: a header, a tag, a file path, a cookie name. A platform-specific header is the strongest of them. An asset path is nearly as strong, since someone would have to rewrite it on purpose to make it lie.
- A version on display
- The site publishes a version number. That is not a vulnerability, it is information: when a flaw lands on that version, nobody has to go looking. One line of configuration drops a server version. Removing the generator tag drops a CMS version.
- Nothing detected
- The most misread result on this page. It means “no known marker in what came back”, not “this site runs nothing”. A server with its headers stripped, a site behind a cache, a purely static home page: three common cases where good configuration produces an empty result.
- No HTML
- The URL returned something other than a page — a redirect into an application, a file, an API response. Only the headers could be read.
- Read after a redirect
- The URL you gave pointed somewhere else, and that destination is what we read. The URL actually read appears at the bottom of the result — that is the one that counts, not the one you typed.
Four ways to misread a detection
A detection tool rarely gets what it sees wrong. The reading is what goes off the rails.
Reading an empty result as an empty stack
What causes it: An empty result looks like a verdict. It is not one: stripping the server header and the generator tag is good practice, so a well-configured site is hard to detect by design.
What fixes it: Read the result as what the site publishes, never as what the site runs. When you actually need to know, you ask whoever built it.
Taking the generator tag at face value
What causes it: The tag is the site talking about itself. A theme can leave a stale one behind, a plugin can rewrite it, and nothing requires anyone to keep it current.
What fixes it: Cross-check it with a second source: an asset path, a platform-specific header, a cookie name. That is why this tool shows where every line came from.
Confusing the host with the delivery network
What causes it: A site behind a delivery network only shows that network's headers. Cloudflare in front of a server says nothing about the server.
What fixes it: Read delivery network as what sits in front, not as what hosts. To find out where the site is really served from, look at the DNS zone — and often, ask.
Leaving the CMS version published
What causes it: That is the default: most content management systems write their version into the generator tag, and their core files carry it in a query parameter.
What fixes it: Remove the tag, and expect the number to survive somewhere else — which is exactly why this tool shows it. But the point is not hiding the version, it is keeping it current: an attacker running automated scans does not read tags, they just try.
Where we look, and what each source can say
Four sources, four degrees of reliability. The right-hand column is why none of them is enough on its own.
| Source | Example | What it proves | Its limit |
|---|---|---|---|
| server header | server: nginx/1.24.0 | The server software that answered, and its version when it publishes one. | Often stripped or replaced, and hidden altogether by a delivery network in front. |
| x-powered-by header | x-powered-by: PHP/8.2.12 | The language or application framework, and its version when published. | Switched off with one line of configuration. Its absence proves nothing. |
| Platform-specific header | cf-ray, x-drupal-cache, x-shopify-stage | The strongest evidence: these headers are set by the platform and exist nowhere else. | Only covers platforms that set one. |
| generator tag | meta name="generator" content="WordPress 6.5.2" | What the site declares about itself, with its version in the most common case. | A declaration: it can be stale, rewritten or removed. |
| Path of a file the page loads | /wp-content/, /_next/static/, cdn.shopify.com | Almost as strong as a platform header: the whole file tree would have to be rewritten to make it lie. | Missing from very light pages, or moved to a separate asset domain. |
| Version parameter on an asset | /wp-includes/js/…?ver=6.5.2 | The core version, when it is left in the parameter. It often outlives the generator tag. | Editable, and sometimes frozen on a value that stopped meaning anything. |
| Session cookie name | PHPSESSID, laravel_session, ASP.NET_SessionId | The language or application framework: these are their default names. | Renameable. We read the name, never the contents. |
What this tool cannot see
This list matters as much as the one above. A detection tool that keeps its blind spots to itself lets you take its silence for a verdict.
| What we don't see | Why |
|---|---|
| Libraries compiled into a single file | A modern build tool bundles and minifies everything. The library's name is gone from the file that ships, so there is nothing left to recognize. |
| CSS frameworks such as Tailwind or Bootstrap | Compiled, they leave nothing but class names — and those get copied by hand all the time. Detecting on that basis would produce false positives, and a false positive is worth less than a blank. |
| Anything that appears only after scripts run | This tool runs no JavaScript. A library that a script pulls in after render stays invisible. |
| The rest of the site | Only the home page is read. A store on a subdomain, a blog in a subfolder, a client area on another platform: none of that shows up. |
| The database, the operating system, internal versions | None of that travels in an HTTP response. A tool that shows it anyway is guessing. |
| Whatever the server deliberately hid | Headers stripped, generator tag removed, assets renamed: that is good practice, and it works against us too. |
We run no vulnerability scan: the tool makes an ordinary request, reads the answer, and stops there.
Frequently asked questions
How can I tell if a site runs WordPress?
Three markers say so, and this tool looks for all three: the generator tag when it hasn't been removed, the /wp-content/ and /wp-includes/ paths in the files the page calls, and the version parameter on core files. When none of them appears, the site may still run WordPress — it has simply been cleaned up.
Can I see the exact CMS version?
Only if the site publishes it, and many do by default — in the generator tag and in the version parameter on core files. This tool shows the version when it reads one, and shows nothing when there is none.
Should I hide my server and CMS version?
Stripping them is good hygiene: it takes away free information. It does not protect you, though — an attacker running automated scans does not read tags, they try known flaws on everyone. Updating protects. Hiding just takes down a signpost.
Why doesn't it detect React, Vue or Tailwind?
Because they leave no reliable marker in a served page: build tools bundle and minify them. We would rather show nothing than announce a technology on a coincidence of class names. Frameworks that leave an unambiguous fingerprint — a distinctive asset path, a markup attribute — are detected.
Why do two checks give different results?
A delivery network may answer from a cache for one request and from the server for the next, with different headers. Some sites also serve different pages depending on where the request comes from. The evidence shown under each line lets you see exactly what changed.
Is this scan intrusive?
No. The tool makes one ordinary request to the home page, exactly as a browser would, and reads what the server sends back. It tries no hidden URLs, tests no vulnerabilities, submits no forms, and never reads the contents of a cookie.
The evidence, as it comes
Six markers, and what each is worth
Every row of the result carries the exact fragment that triggered it. Here they are with their limits, which is what explains why none of them is enough on its own.
server- The server software that answered, and its version when it publishes one. Often removed, and hidden by a delivery network sitting in front.
x-powered-by- The language or application framework, with its version. Switched off in one line of configuration: its absence proves nothing.
cf-ray- A header specific to one platform — the most solid evidence there is, because those headers exist nowhere else.
generator- The tag a site declares itself with, carrying its version in the most common case. A declaration: it can be stale, rewritten or removed.
/wp-content/- A file path the page loads. Almost as solid as a platform header: you would have to rewrite the whole tree to make it lie.
PHPSESSID- The name of a session cookie, the language's default one. Renameable. We read the name, never the contents.
Where the reading goes wrong
What people conclude, what the result says
A detection tool rarely gets what it sees wrong. The reading goes off the rails instead, and always in the same four places.
What people conclude
What the result says
Nothing was detected, so this site runs nothing known.
Removing the server header and the generator tag is good practice. A well-configured site is hard to detect by design.
The tag announces a version, so that is the version installed.
That is the site talking about itself. A theme can leave a stale one behind, a plugin can rewrite it, and nothing requires anyone to keep it current.
The headers name a delivery network, so that is the host.
A delivery network only shows its own headers: it sits in front, it does not host. To find out where the site is actually served, look at the DNS zone.
The result changed since yesterday: the tool is unreliable.
A delivery network can answer from cache for one request and from the server for the next, with different headers.
Twenty checks, no sign-up
- Check when fifty domains expire, in one paste
- Who owns this domain, and since when?
- Where does this URL actually end up?
- Is this URL open to crawlers?
- Has my DNS change propagated yet?
- Build your SPF record
- Is this domain blacklisted?
- What security headers does this site send?
- A domain's full health report
- When does this domain expire?
- Is this SSL certificate valid, and when does it expire?
- Are your SPF, DKIM and DMARC set up right?
- Is this domain or its mail server blacklisted?
- Which servers receive mail for this domain?
- Which nameservers answer for this domain?
- What do this domain's TXT records do?
- Where does this CNAME end up?