Website Tech Stack Detector
Pricing
from $10.00 / 1,000 tech stack detecteds
Website Tech Stack Detector
Detect CMS, frameworks, analytics, CDNs, ecommerce platforms and JS libraries on public website URLs through HTTP fingerprinting, one row per URL. No paid catalog APIs or login needed.
Pricing
from $10.00 / 1,000 tech stack detecteds
Rating
0.0
(0)
Developer
Khadin Akbar
Maintained by CommunityActor stats
0
Bookmarked
1
Total users
0
Monthly active users
4 days ago
Last modified
Categories
Share
What is Website Tech Stack Detector?
Turn public website URLs into one structured technology-stack dataset row per URL for sales researchers, SEO operators, and AI agents. Each row returns categorized CMS, framework, analytics, CDN, ecommerce, JS library, and server signals with technology names, confidence, and optional evidence excerpts taken from the current public HTML and response headers.
Best fit for this Actor
- Use this Actor when you already have https URLs and need a cheap, MCP-ready stack snapshot before enrichment, migration planning, or competitor research.
- Designed for lean owned HTTP fingerprinting: predictable Pay per event pricing, Apify platform usage included, and no paid catalog API balance to maintain.
- Start with a single public storefront URL such as the Shopify Console prefill, then raise
maxUrlsfor a bounded batch. - Continue with Website Stack Evidence Audit when the next step is a multi-page source-evidenced audit.
- For a managed Domain Technologies catalog hybrid, then use Wappalyzer Alternative.
Practical scenario
A B2B SDR collects a short competitor domain list, runs this Actor once with maxUrls set to three, and keeps rows where Ecommerce or CMS matches Shopify or WordPress. The fingerprint pass returns technologyNames, categories, and short evidence snippets the SDR can trust from current public pages, then the team continues into an enrichment Actor.
Quick start input
{"websiteUrls": ["https://www.shopify.com"],"maxUrls": 3,"includeEvidence": true}
websiteUrls accepts full https URLs or bare domains. Prefer full https URLs. Duplicate URLs are deduped. maxUrls is the spend cap after dedupe.
Input reference
| Field | Type | What it controls |
|---|---|---|
websiteUrls | string[] | Public website URLs or bare domains to fingerprint. Prefill: https://www.shopify.com. Cap 50. |
startUrls | request list | Optional alias for websiteUrls using Apify request-list objects. Prefer websiteUrls for agents. |
maxUrls | integer | Hard cap on unique URLs after dedupe, 1–50. Default 25. Prefill 3. |
includeEvidence | boolean | When true, each technology includes a short public-signal evidence excerpt. Default true. |
requestTimeoutSecs | integer | Per-URL HTTP timeout, 5–60 seconds. Default 25. Prefill 20. |
proxyConfiguration | object | Optional Apify proxy. Leave off for the default direct HTTPS path; enable Residential when a target challenges direct fetch. |
What data you receive
Each dataset item is one public website fingerprint.
{"inputUrl": "https://www.shopify.com","finalUrl": "https://www.shopify.com/","statusCode": 200,"technologyCount": 4,"technologyNames": ["Cloudflare", "Google Tag Manager", "Shopify"],"categories": {"CDN": ["Cloudflare"],"Ecommerce": ["Shopify"],"Tag manager": ["Google Tag Manager"]},"detectionMethod": "owned_http_fingerprinting","outcome": "DETECTED","matchFound": true}
| Field | Meaning |
|---|---|
inputUrl / finalUrl | Requested URL and post-redirect URL |
technologyNames | Flat list of matched technologies |
categories | Grouped map such as CMS, Analytics, CDN, Ecommerce |
technologies | Name, category, confidence, optional evidence excerpt |
technologyCount | Count of matches |
detectionMethod | Always owned_http_fingerprinting |
route | direct or apify-proxy |
statusCode | Final HTTP status |
OUTPUT and RUN_SUMMARY in the default key-value store hold outcome, itemsPushed, and charged event counts. Download the dataset as JSON, CSV, Excel, or HTML.
Use through the API
curl -X POST "https://api.apify.com/v2/acts/khadinakbar~website-tech-stack-detector/runs" \-H "Authorization: Bearer $APIFY_TOKEN" \-H "Content-Type: application/json" \-d '{"websiteUrls":["https://www.shopify.com"],"maxUrls":1}'
Use with AI agents through Apify MCP
Detect the tech stack for https://www.shopify.com. Return technologyNames, categories, confidence, and evidence. Read the dataset overview view and OUTPUT.outcome after the run. Budget: one URL is about $0.01 event with Apify platform usage included. Scope: public HTML and headers only. Provenance: detectionMethod equals owned_http_fingerprinting with scrapedAt and route.
Connect via https://mcp.apify.com. Tell the agent to keep maxUrls small on the first call and preserve finalUrl as the observed source URL.
Pricing
This Actor uses Pay per event with Apify platform usage included. The live Pricing tab is the current source of truth for billing details.
apify-actor-start: $0.00005 per runtech-stack-detected(primary): $0.01 per successfully fingerprinted URL
A three-URL sample with three accepted rows is three tech-stack-detected events plus the start event, with Apify platform usage included. Detection uses public HTML and response headers. Invalid inputs and fully unreachable targets skip the primary event.
Best results
- Provide full
httpsURLs when you already have them, and keepmaxUrlstight while you confirm the output shape. - Start with the Shopify Console prefill, inspect
technologyNamesand evidence excerpts, then schedule the same input for a recurring competitor watch. - Pair Residential proxy only when a target challenges the direct HTTPS path; otherwise keep the default direct route for lower platform usage.
- Confirm
OUTPUT.outcomeanditemsPushedbefore treating an empty dataset as a finished fingerprint pass.
Builder's note
I found that paid catalog hybrids already cover Domain Technologies enrichment in sibling Actors, so I designed this SKU as owned HTML and header fingerprinting only. I also found that conservative evidence-backed fingerprints keep every billed row tied to a public signal agents can inspect, which is why includeEvidence defaults to true and why the primary event fires only after a validated dataset row is ready to persist.
Responsible use
Use this Actor for lawful collection and analysis of public website responses you are authorized to access. Follow applicable laws and site terms. Shopify and WordPress are trademarks of their respective owners. This independent Actor is not affiliated with, associated with, or endorsed by Shopify Inc. or the WordPress Foundation.
Call over HTTP
Use the actual URL in this Actor's Endpoints tab with an Apify bearer token. GET /detect?url=https%3A%2F%2Fexample.com supports a small lookup. POST /detect accepts existing input fields plus optional maxCostUsd, returning records and summary directly. Normal runs and their Dataset exports remain available for bulk work and stored results.
The existing price is unchanged: $0.01 per successfully analyzed public website, including a completed analysis with no recognized fingerprints. Platform usage remains included. The batch startup-event price and its existing semantics remain unchanged; no extra manual startup event is added per HTTP request. Existing free-user limits and paid options remain unchanged. URL aliases/deduplication, includeEvidence, requestTimeoutSecs, up to 50 URLs and optional proxy fallback remain supported. The detector reports public signals, not every installed technology.
Readiness and input/budget rejections do no source work and charge no result events. An unreachable or blocked source with no useful analysis is a failure, not a billed empty report. Complete validated result events are attributed to the platform request ID and charged before delivery. Unconfirmed billing withholds the results; do not automatically retry an uncertain charge or write. Useful partial responses use HTTP 206 with complete records and explicit counts. Batch billing retains the last accepted capped row and records unresolved effects without automatic write/charge replay.
maxCostUsd is checked against the maximum planned result count before source or proxy work (the accepted unique URL count after the existing maxUrls cap). It limits result events for this request and does not read or enforce a Console-wide spending allowance. Request-level caps do not provide a user/day quota.
Responses do not create a caller-specific run, export or history entry. Caller inputs, results, content and proxy credentials are not persisted in shared Dataset/KV or general service logs; only operational aggregates remain. Use normal runs for persistent exports.
The HTTP service accepts two active isolated request workers per instance, at most 1 MiB of JSON input, 2 MiB cumulative decoded source transfer and 2 MiB of complete output. Oversized output is withheld before result billing rather than truncating its fields. There is a 180-second soft admission window and a 240-second overall work deadline. Long and large workloads remain available through normal batch runs. A warm service avoids repeating full container startup, but idle instances can scale down and later calls may cold-start.
Only public HTTP(S) targets without URL credentials are accepted; DNS/IP checks also cover redirects and the actual source socket. The original direct-then-proxy fallback order remains. An unavailable requested proxy produces a structured error rather than silently changing its configuration. Native source work has bounded retries and transfer. No login, caller cookies, browser rendering or new paid data provider was added.