Tech Stack Detector

Fingerprint what technology a website actually runs — CMS, ecommerce platform, analytics, ad tech, CDN, payment provider, hosting, JS framework and marketing automation — with a confidence score and the exact evidence that fired for every detection.

This is the tool behind "find me sites running Shopify + Klaviyo" or "which of our leads are still on WordPress" — sales prospecting and competitive research where you need real signal on hundreds of domains, not a manual "view source" per site.

How detection works

The moat is the signature library in src/signatures.js — 148 technologies, each with several independent detection rules drawn from six kinds of evidence:

Rule kind	What it checks
header	Response headers set by the platform itself (cf-ray, x-shopid, x-powered-by)
cookie	Cookie names the platform sets (_shopify_s, __hstc, ak_bmsc)
script	<script src> / <link href> URLs naming the vendor's own CDN
meta	<meta name="generator"> and other named meta tags
dom	Class/id/data-attribute naming conventions in the markup
global	Inline (non-src) <script> text — JS globals and config objects

A technology is reported only if at least one rule fires. Confidence is not a raw count of matches — it's a noisy-OR combination of each matched rule's weight (meta/global strongest, dom weakest alone), so five independent weak signals compound toward certainty while a single strong signal still reports honestly on its own, and confidence visibly rises as more independent rules agree. Version hints are extracted from capture groups where the signature exposes one (e.g. meta generator: WordPress 6.4.2, jQuery's own filename).

What it does per run

For each site: fetches the homepage (redirects followed, failures reported per-site rather than crashing the run), optionally fetches one more page of the same site for extra coverage (a discovered product/shop/pricing link, or a fixed path you specify), runs the full signature library against the combined signals, and outputs technologies grouped by category with confidence + evidence, plus a flat name list for filtering (flatTechList).

Because it only ever reads the target's own public pages — the same thing a browser does — there's nothing on the other end trying to block it.

Input

websites (required) — URLs or bare domains. fetchSecondaryPage (default on) — check a second page too. secondaryPagePath — force which page. minConfidence (default 20) — drop low-confidence noise. concurrency, proxyConfiguration — standard run tuning.

Output

One dataset row per site: technologies (full detail with confidence/version/evidence), categories (grouped), flatTechList (names only, for contains filtering), plus secondaryUrlChecked. Unreachable or errored sites get { type: "error", url, error } instead of stopping the run.

Honest limitations

• Client-rendered stacks can hide. A JS-framework SPA that builds its entire DOM (and injects its own script tags) after hydration may under-report if the initial HTML response is nearly empty. Server-rendered and static-generated sites fingerprint far more reliably.
• Version detection is best-effort. Only signatures with an explicit capture group (generator tags, versioned filenames) report a version; most report presence only.
• Confidence is evidence-based, not certainty. A single dom match (weight ~20) is a plausible lead, not proof — pair minConfidence with your own review for anything decision-critical (e.g. before a sales outreach claim).
• Shared infrastructure looks like the vendor. A site behind a reseller's Cloudflare or a WAF may report the WAF's CDN rather than the origin's true host.
• Detection quality depends on what the site's first response actually contains — a page that 403s a scraper UA, or requires JS execution to render anything, yields fewer or no detections rather than a false one.