Tech Stack Detector

Find out what a website is built with: CMS, JavaScript framework, analytics tools, CDN, server software, e-commerce platform, and more — using only plain HTTP requests (no browser), so it stays fast and cheap even on long lists of sites.

What it does

For each URL, this Actor sends a normal HTTP GET request (the same request any browser would send) and inspects the response: HTTP headers, cookies set, <meta> tags, and script tags. It compares what it finds against a built-in database of 170+ technology signatures and reports every match, with a confidence score and — when detectable — a version number.

How detection works

Detection is entirely signature-based, using self-authored rules (not Wappalyzer's or any other third-party fingerprint database, nor its data): every rule in this Actor encodes a publicly documented, independently observable fact about how a given technology exposes itself over plain HTTP — a default response header, a <meta name="generator"> tag, a static-asset path pattern, a cookie name it sets, or a snippet of its own loader script URL. No proprietary fingerprint dataset is bundled or reused.

What you get (output fields)

One dataset row per URL:

• url — the URL that was requested.
• finalUrl — URL after following redirects (null on error).
• technologies — array of { name, category, version, confidence } for every match. version is null when it could not be determined. confidence is 0-100.
• error — set only if the site could not be reached at all; null on success.

Categories used: cms, ecommerce, javascript-framework, javascript-library, analytics, tag-manager, cdn, server, web-framework, hosting, chat, marketing-automation, forms, video, reviews, maps, payment, fonts, security, search.

Who it's for

• Sales/lead qualification — see what a prospect's site already runs (e.g. "still on WordPress", "already using Shopify") before a call.
• Competitive research — compare the tech stack across a list of competitor sites.
• Agencies/consultants — audit a client site's current stack before a migration or redesign.

How to use

1. URLs — paste the sites you want analyzed (a bare domain like example.com also works).
2. Include categories (optional) — restrict the report to specific categories (e.g. ["cms", "analytics"]). Leave empty to report everything detected.
3. Run the Actor. Each site becomes one dataset row.

Input example (JSON)

{
  "urls": ["https://example.com", "https://apify.com"],
  "includeCategories": []
}

Output example (JSON)

{
  "url": "https://apify.com",
  "finalUrl": "https://apify.com",
  "technologies": [
    { "name": "Amazon CloudFront", "category": "cdn", "version": null, "confidence": 95 },
    { "name": "Google Tag Manager", "category": "tag-manager", "version": null, "confidence": 95 },
    { "name": "HubSpot", "category": "marketing-automation", "version": null, "confidence": 90 },
    { "name": "Intercom", "category": "chat", "version": null, "confidence": 90 }
  ],
  "error": null
}

If a site cannot be reached

A site that is completely unreachable (DNS failure, connection refused, timeout) is a row with error set: the rest of the list keeps running, the run does not fail, and you are not charged for that URL.

A site that responds with an HTTP error status (404, 500, ...) is not treated as an error: the server did respond, and its headers and HTML still reveal its technology stack, so that row is analyzed normally (and charged, like any other successful analysis) — its technologies array may simply be shorter.

Pricing

Pay only for sites actually reached and analyzed — nothing charged for sites that could not be reached at all. Pricing model: pay-per-event.

Event	When it's charged	Price
site-analyzed	a site was reached and analyzed, regardless of how many technologies were found	0.003 USD

Limitations

• HTTP-only: it does not run a browser, so it will not detect technologies that only reveal themselves after JavaScript execution (e.g. content injected client-side with no trace in the initial HTML or scripts).
• Detects what the page's first HTML response, headers and cookies expose — not what is running behind an authenticated area.
• Version numbers are reported only when a signature's pattern captures one; many technologies do not expose a version over plain HTTP and are reported with version: null.
• Signature coverage is broad (170+ technologies) but not exhaustive; niche or in-house-built tools will not be recognized.
• No login, no CAPTCHA solving, no bypass of any site protection.

FAQ

Does this use a headless browser like Playwright/Puppeteer?

No, by design — it uses plain HTTP requests only, which keeps runs fast and cheap. This means JavaScript-only signals (nothing visible in the raw HTML/headers/cookies) are not detected.

Why is a site's stack incomplete or empty?

Either the technology is not in the 170+ signature database, or it only reveals itself via client-side JavaScript execution, which this Actor does not run.

Am I charged if a site is unreachable?

No. You are only charged for sites that were actually reached and analyzed — including sites that return an HTTP error page, since that page was still fetched and analyzed.

Can I filter to only certain categories?

Yes, use the includeCategories input field (e.g. ["cms", "ecommerce"]).

Is this based on Wappalyzer?

No. The signature database is self-authored for this Actor; see "How detection works" above.

Is this a Wappalyzer or BuiltWith replacement?

Partial. It covers the main categories (CMS, JS frameworks, analytics, CDN, server, e-commerce, and more) with its own 170+ signatures, but it isn't a drop-in superset of a database with thousands of entries. If your site uses something niche or in-house-built, it may not be recognized.

Why are your signatures self-authored instead of using Wappalyzer's database?

No third-party fingerprint dataset examined had a license clearly compatible with reuse here, so every rule was written from scratch against publicly documented, independently observable facts (an HTTP header, a <meta name="generator"> tag, a cookie name, a script URL pattern) — see "How detection works" above.

Can I use this through the Apify API or an MCP server?

Yes. Like any Apify Actor, you can run it and read results through the standard Apify API, or through the Apify MCP server if you use Claude, Cursor, or another MCP-enabled client.

Export

Results can be downloaded from the Apify dataset as JSON, CSV, or Excel, or accessed via the Apify API.