Website Tech Stack Detector

Server assisted New Website & HTTP Diagnostics

Fetches one page through the Mutqan server and matches its response headers, cookie names, script URLs, meta tags and HTML against more than 200 hand-written signatures. Every row names the markers that were seen; a technology loaded later by a script, used on another page or hidden by the server cannot be seen, so a missing row proves nothing.

Privacy: The Mutqan server sends the small, fixed test requests described on this page to the host you name, and nothing is stored. Use it only against systems you are authorised to test.

How can you tell what a website is built with?

A site's software leaves observable markers in what it sends: Server and X-Powered-By response headers, session cookie names such as PHPSESSID or JSESSIONID, script paths, a generator meta tag and characteristic markup. Fingerprinting matches those markers against known signatures. It shows what the page reveals about itself, not what is certainly installed, because markers can be removed, faked or added only after JavaScript runs.

Security note: Version numbers in response headers make it easy to match a site to published vulnerabilities. Remove or shorten Server and X-Powered-By values, and keep the software patched whatever the headers say.

How to use Website Tech Stack Detector

  1. Enter the address of a public page, for example the home page of the site.
  2. Keep the default profile, or choose the mobile browser or Googlebot User-Agent to see whether the site serves those clients a different page.
  3. Press Detect technologies and read the table: each row names the technology, its category, a version when one was visible, the signal strength and the evidence.
  4. Check the evidence of the rows you rely on, and read "What the signals say" for version disclosures and the limits of a one-page check.

Website Tech Stack Detector features

  • Fetches one page through the Mutqan server with a fixed header profile (the Mutqan checker, a mobile browser or the Googlebot User-Agent) and follows up to five redirects
  • Matches response headers, cookie names, script URLs, generator meta tags and HTML fragments against more than 200 hand-written signatures in 15 categories, from CMS and e-commerce platforms to CDNs, analytics and tag managers
  • Shows the evidence behind every row — the header, cookie, script or markup that matched — so each detection can be checked rather than trusted
  • Grades each row as Strong, Moderate, Weak or Implied from how specific and how many independent markers were seen, and reports a version when a marker carries one
  • Lists the response headers that name software (Server, X-Powered-By, X-AspNet-Version, X-Generator, Via) and flags those that disclose a version number
  • Says plainly when the page could not be read in full: an error status, a non-HTML response, a body cut at 512 KiB or more than 5,000 tags
  • Downloads the technology table as CSV for an inventory or a security review

Inputs and outputs

Inputs

  • Website URL — any public http:// or https:// page; a bare host name gets https:// added.
  • Fetch as — the request profile: the Mutqan checker User-Agent, a current mobile Chrome User-Agent, or Googlebot's User-Agent (self-declared, not a real Google request).

Outputs

  • Summary — technologies with signals, strong signals (score 90 or more), categories, HTTP status, scripts scanned and cookies seen.
  • Technologies with signals — name, category, version when visible, signal strength, score and the evidence that matched; downloadable as CSV.
  • By category — the same technologies grouped by category.
  • What the signals say — what the result means, version disclosures and notes about Cloudflare and implied rows.
  • Headers that name software, Fetch details and the redirect chain when the page redirected.

Website Tech Stack Detector example

A WooCommerce shop behind Cloudflare

Input:

Website URL: https://shop.example.com/ · Fetch as: Mutqan checker (default)

Output:

Technologies 5 · Strong signals 3 · Categories 5 · HTTP status 200 · Scripts scanned 1 · Cookies seen 1
Cloudflare — CDN / edge network — Strong (100): Header cf-ray: 8d2f1a2b3c4d5e6f-FRA · Header server: cloudflare
WordPress 6.6.2 — CMS / site builder — Strong (100): Script /wp-includes/js/jquery/jquery.min.js?ver=3.7.1 · Meta tag generator: WordPress 6.6.2 · HTML: /wp-content/plugins/ · HTML: /wp-includes/ · Implied by WooCommerce
WooCommerce — E-commerce — Strong (95): Cookie wp_woocommerce_session_abc · HTML: /wp-content/plugins/woocommerce/
jQuery 3.7.1 — JavaScript library — Moderate (85): Script /wp-includes/js/jquery/jquery.min.js?ver=3.7.1
PHP 8.2.24 — Programming language — Moderate (85): Header x-powered-by: PHP/8.2.24 · Implied by WordPress
The x-powered-by header discloses a software version (PHP/8.2.24).

How to read the Website Tech Stack Detector results

Strong means a score of 90 or more: a highly specific marker (a generator tag, a vendor header) or several independent markers agree. Moderate (70–89) is usually one good marker; Weak (below 70) is a single generic marker worth checking by hand.

Implied rows were not seen directly: they follow from another detection, such as PHP behind WordPress. When a product is both seen and implied, its own markers decide its score.

The score ranks evidence; it is not a probability. A site can include a library it never uses, keep an old generator tag after moving, or send a misleading Server header.

An empty or short list does not mean the site uses nothing. Single-page applications, tag-manager loaded scripts and servers that strip headers leave few markers in the HTML the server sends.

When to use Website Tech Stack Detector

  • Before a security assessment or a penetration test, inventory the visible software of an in-scope site and note any version numbers its headers disclose.
  • Check that a migration really happened: after moving to a new CMS, CDN or analytics product, confirm the old markers are gone and the new ones appear.
  • Find out what a competitor's or a client's site is built with before scoping a redesign, an integration or a test plan.
  • Confirm that a privacy review is complete: see which analytics, tag managers and marketing pixels a page loads directly.

Troubleshooting

  • Only "Cloudflare" (or another CDN) appears: the CDN replaces the Server header and hides the origin. The CMS and frameworks can still show in cookies and HTML; if the page is a JavaScript shell, little else is visible.
  • The page answered 403 or 503 with a challenge page: some sites block automated clients or show a bot check to them. The rows then describe the challenge page, not the site; try the mobile profile or another page of the site.
  • The response is JSON or a file, not HTML: point the detector at an HTML page such as the home page; only headers and cookies are checked otherwise.
  • A refusal such as "This address cannot be reached from the Mutqan server": the host resolves to a private or reserved address, or uses a port the server does not connect to. Only public sites can be checked.

Frequently asked questions about Website Tech Stack Detector

How does the detector know which technologies a site uses?

It looks for markers each product leaves in a page: a Server or X-Powered-By header, a cookie name such as PHPSESSID or wordpress_logged_in, a script path such as /wp-includes/js/, a generator meta tag, or a fragment of markup. Each row lists the markers that matched, so you can check the evidence yourself instead of trusting a label.

What do the signal strength and score mean?

The score starts from how specific the first marker is (a generator tag naming WordPress counts more than a generic script path) and gains ten points for every further independent marker, up to 100. Implied rows (PHP implied by WordPress, for example) score ten points below the technology that implies them. It ranks the evidence; it is not a probability that the site runs that product.

Why is a technology I know the site uses missing?

Only one page is read, as the server sends it, without running JavaScript. Libraries injected by a tag manager, a framework that leaves no marker in server-rendered HTML, software behind a proxy that rewrites headers, or tools used only on other pages do not appear. Absence of a signal is not evidence that the technology is absent.

Can a site fake or hide these signals?

Yes. Headers can be removed or rewritten, a page can include a library it never uses, and some sites deliberately send misleading Server values. Treat the results as what the page says about itself, and confirm anything important with the site owner.

Why does the result say Cloudflare for so many sites?

Many sites sit behind Cloudflare, which adds cf-ray and server: cloudflare headers to every response. That is the CDN in front of the site; the origin server behind it is usually hidden, so the web server row may be missing or name the CDN.

Technical notes

The page is requested by POST /api/v1/internet/http/fetch: the Mutqan server resolves the host through DNS over HTTPS, refuses private and reserved addresses, sends one of four fixed header sets and follows at most five redirects, each re-validated. It returns the status, headers (several Set-Cookie values joined) and the first 512 KiB of the body; the matching then runs in your browser.

Detection is signature matching, not inference. A signature lists header patterns, cookie names, script-URL patterns, meta-tag patterns, HTML patterns and URL patterns written from each product's documentation or embed snippet; the score is the signature's base for the first marker plus ten for each further distinct marker, capped at 100, and a product implied by another (WooCommerce implies WordPress, WordPress implies PHP) scores ten below it. The Server and Via header fields are defined in RFC 9110 §10.2.4 and §7.6.3.

The HTML is scanned once, as text, for up to 2 MB and 5,000 tags; patterns use bounded quantifiers, so a large or hostile page cannot make the scan slow. Nothing is executed, so a framework that only appears after JavaScript runs is invisible here.

Limitations and methodology

One page is read once, from the Mutqan server on Cloudflare's network, without running JavaScript. Software used only on other pages, loaded later by scripts or rendered in the browser is not seen.

The signature list is hand-written and covers widely used products; a niche or custom technology has no signature and cannot be named. Headers, cookies and markup can be removed or forged by the site.

At most 512 KiB of HTML is read; markers further down a very large page are missed, and the result says so.

Security and privacy

Only the URL you enter is sent to the Mutqan server, which requests that page once with a fixed set of headers and none of your cookies, and passes the answer back without keeping it. The matching runs in your browser and the fetched HTML is never rendered.

References

  • OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
  • Server header — MDNMDN Web Docs (Mozilla)The Server response header names the software that produced the response; MDN warns that fine-grained version details in it can make known vulnerabilities easier to find.
  • RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.