Website Tech Stack Detector avatar

Website Tech Stack Detector

Pricing

from $10.00 / 1,000 tech stack detecteds

Go to Apify Store
Website Tech Stack Detector

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

Khadin Akbar

Maintained by Community

Actor stats

0

Bookmarked

1

Total users

0

Monthly active users

4 days ago

Last modified

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 maxUrls for 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

FieldTypeWhat it controls
websiteUrlsstring[]Public website URLs or bare domains to fingerprint. Prefill: https://www.shopify.com. Cap 50.
startUrlsrequest listOptional alias for websiteUrls using Apify request-list objects. Prefer websiteUrls for agents.
maxUrlsintegerHard cap on unique URLs after dedupe, 1–50. Default 25. Prefill 3.
includeEvidencebooleanWhen true, each technology includes a short public-signal evidence excerpt. Default true.
requestTimeoutSecsintegerPer-URL HTTP timeout, 5–60 seconds. Default 25. Prefill 20.
proxyConfigurationobjectOptional 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
}
FieldMeaning
inputUrl / finalUrlRequested URL and post-redirect URL
technologyNamesFlat list of matched technologies
categoriesGrouped map such as CMS, Analytics, CDN, Ecommerce
technologiesName, category, confidence, optional evidence excerpt
technologyCountCount of matches
detectionMethodAlways owned_http_fingerprinting
routedirect or apify-proxy
statusCodeFinal 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 run
  • tech-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 https URLs when you already have them, and keep maxUrls tight while you confirm the output shape.
  • Start with the Shopify Console prefill, inspect technologyNames and 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.outcome and itemsPushed before 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.