Tech Stack Detector — CMS, Frameworks & Analytics
Pricing
from $3.00 / 1,000 results
Tech Stack Detector — CMS, Frameworks & Analytics
Detect the technology stack of any website: CMS, frameworks, JavaScript libraries, analytics, web servers and CDN - with versions where detectable and the evidence for every match. 7,500+ fingerprints (community Wappalyzer DB), one GET per URL, no crawling. No credentials needed.
Pricing
from $3.00 / 1,000 results
Rating
0.0
(0)
Developer
kuon
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
5 days ago
Last modified
Categories
Share
Detect what any website is built with: CMS, frameworks, JavaScript libraries, analytics, web servers, CDN and hosting — from 7,500+ community-maintained fingerprints, with versions where detectable and the evidence for every match (which header, cookie, meta tag or script gave it away). One GET per URL, no crawling, no credentials.
What it does
Give it a list of website URLs (bare domains work — https:// is assumed).
For each site you get one dataset item with:
technologies[]— every detected technology:nameandcategories(CMS, JavaScript libraries, Analytics, …)versionwhen the fingerprint can extract one (e.g.jQuery 3.6.0,WordPress 6.4)evidence[]— exactly what matched:headers:server,cookies:phpsessid,meta:generator,scriptSrc,html,url, orimplied by WordPress
byCategory—{"CMS": ["WordPress"], "Web servers": ["Nginx"]}summarytechnologyCount,finalUrl,httpStatus,checkedAt
Implied technologies are expanded transitively (WordPress ⇒ PHP ⇒ MySQL). Failed pages (404, non-HTML, timeouts) produce a failed item with a clear error — batch jobs always finish.
Input
| Field | Type | Default | Description |
|---|---|---|---|
urls | array | — | Websites to analyze (only these are fetched; no crawling) |
timeoutSecs | integer | 20 | Download timeout per page |
maxFileSizeMb | integer | 5 | Larger pages are skipped with a failed item |
Example output (abridged)
{"url": "https://github.blog","status": "success","technologies": [{"name": "Nginx", "categories": ["Web servers", "Reverse proxies"], "version": null, "evidence": ["headers:server"]},{"name": "WordPress", "categories": ["CMS", "Blogs"], "version": "7.0.4", "evidence": ["meta:generator", "html"]},{"name": "MySQL", "categories": ["Databases"], "version": null, "evidence": ["implied by WordPress"]},{"name": "Yoast SEO", "categories": ["SEO"], "version": "28.2", "evidence": ["html"]}],"technologyCount": 13,"byCategory": {"CMS": ["WordPress"], "Databases": ["MySQL"], "Web servers": ["Nginx"]},"checkedAt": "2026-08-18T09:30:00Z"}
Typical uses
- Sales/market research: segment prospect lists by CMS, e-commerce platform or analytics stack
- Competitive analysis: what are competitors built on, did they migrate
- Security/IT inventory: find sites still running outdated library versions
- Enrich domain datasets with technology columns
Fingerprint database: license & updates
- The detection rules are a compact compilation of
enthec/webappanalyzer — the
community-maintained continuation of the Wappalyzer technology database —
used under its GPL-3.0 license. The compiled snapshot
(
src/data/fingerprints.json) keeps the license notice plus provenance metadata (source repo, upstream commit hash, retrieval date) in its_metablock, and remains under GPL-3.0. The detection engine reads it as data. - Updating: run
python scripts/update_fingerprints.py(fetches the latest upstream DB, recompiles the snapshot, prints the new commit hash), then rebuild the Actor. We refresh the snapshot periodically.
Limitations
- Static analysis of the served HTML: technologies only visible after
client-side JavaScript execution may be missed (
js/domfingerprints are out of scope by design) - Sites behind aggressive bot protection may fail or reveal only their CDN
- Version extraction depends on the site exposing it (headers, generator tags,
asset paths) —
versionis null when it doesn't
Development (local)
cd actors/tech-stack-detectoruv venv --python 3.13 .venv && uv pip install -p .venv/bin/python -r requirements.txt.venv/bin/python tests/run_local_test.py # end-to-end test (apify run equivalent), exit 0 = ALL PASS../../node_modules/.bin/apify run # real apify CLI local run (input: storage/key_value_stores/default/INPUT.json)
The test runs a mock WordPress-behind-Nginx site against the real bundled DB
(headers/cookies/meta/scriptSrc/html matching, version extraction, implies
expansion read from the DB itself); expected results live in
tests/expected_output.json. Publishing → ../../docs/publishing.md.