Technology Lookup

About the technology lookup

A technology lookup fetches one page and reports which products the response gives away: the CMS or ecommerce platform, the JavaScript framework or static site generator, the web server and language runtime, the CDN, reverse proxy or WAF in front of it, and the analytics and tag managers loaded into the page. It is a read of what the site chose to disclose, not an inventory of what it runs — and the difference matters enough that the result says so on every run.

Detection compares the response against 141 fingerprints written in-house, across CMS and ecommerce platforms, JavaScript frameworks and generators, hosting and CDN providers, web servers, language runtimes, WAFs, analytics and tag managers. Five kinds of signal are used: a named response header matching a pattern, the mere presence of a header only one vendor emits, the name of a cookie the site sets, the content of the generator meta tag, and a string in the HTML body such as a script host. Cookie values are never inspected — only the name — and no JavaScript is executed, so anything a page assembles in the browser is invisible here.

Every detection carries a confidence level, and the levels mean specific things. **Confirmed** means the vendor documents the signal and the signal names the product; it is only ever reached from a documented header, cookie or generator tag, never from a page-body match, because a tutorial or a changelog can quote a vendor's script host without the site using the product. **High** means a marker only one vendor emits that does not name the product. **Medium** means a marker the product emits which others plausibly emit too. **Low** means a build artefact or a widely copied convention — a hint, not an identification. A confidence is never promoted: two low signals stay low, and a low match is shown as a guess rather than hidden or rounded up.

Versions are reported where a signal carries one, such as a server header or a generator tag. There is no vulnerability matching: we report the disclosure of a version, not a verdict on it. A separate warning fires only when the exact version of a CMS or ecommerce platform is published in the page document itself, and the advice attached to it is deliberately ordered — update first, then hide the version, because a hidden version on an unpatched install is worse than a visible one. A version disclosed only in a response header is reported by the security headers check instead, which is why a platform that publishes in both places legitimately produces two findings: two places to remove it, two fixes.

Every fingerprint dotvitals uses was written from a primary source — the vendor's own documentation, a standards document, or a direct observation of a named live site on a named date with the exact bytes recorded — and a fingerprint without complete provenance fails our build. No third-party fingerprint dataset is consulted, which is both a licensing position and a quality one: it is why each detection here can say which signal it came from and why that signal is trusted at the level it is.

Identifying a technology is never treated as a fault, and this check deducts nothing from a report's score: running WordPress is not a problem. An empty result is not a clean bill of health either. A CDN that strips origin headers, a page assembled in the browser, and a very large document cut off at the 256 KiB read cap will all hide real technologies, and the result states the body size and whether it was truncated so the answer can be read for what it is.

Where every fingerprint came from

Common questions

How does it identify a technology?

By matching one page's response headers, cookie names, generator meta tag and HTML body against 141 in-house fingerprints. Each match reports the signal it came from and how much confidence that signal supports.

What do the confidence levels mean?

Confirmed: the vendor documents the signal and it names the product. High: a marker only one vendor emits. Medium: a marker the product emits that others plausibly emit too. Low: a build artefact or common convention, shown as a hint rather than an identification.

Nothing was detected. Does that mean the site is simple?

No. A CDN that rewrites headers, a page built in the browser, or a document cut off at the read cap all hide technologies. The result reports the body size and whether it was truncated so you can tell what was actually examined.

Does it run JavaScript?

No. It reads one HTML response. Anything a page assembles in the browser — including many analytics tags injected by a tag manager — is out of reach.

Does it tell me whether a detected version is vulnerable?

No. It reports that a version is disclosed, not a verdict on it. Matching versions against vulnerability data is a different product with a different failure mode, and getting it wrong is worse than not doing it.

Should I hide my CMS version?

Update first, then hide it. Removing the banner takes you off the cheap mass-exploitation target lists, but a hidden version on an unpatched install is worse than a visible one, because it can be mistaken for a fix.

Why is a version reported twice?

Because it is published in two places. A version in the page document is reported here; a version in a response header is reported by the security headers check. Both need removing, and they are removed differently.

Does a detected technology cost me points?

No. Technology detection deducts nothing. The only points at stake are for publishing an exact CMS version in the page, and that finding is filed under web security rather than here.