Website Technology Stack Detector
Pricing
from $5.00 / 1,000 basic scans
Website Technology Stack Detector
Detect the CMS (WordPress, Shopify), CDN, hosting, DNS provider, analytics, payment and chat tools of each website in a list. One JSON row per domain, with evidence and a confidence score per detection. For lead-list enrichment, audits and AI agents (API, MCP). Pay only for successful scans.
Pricing
from $5.00 / 1,000 basic scans
Rating
0.0
(0)
Developer
Seisuke Nagahara
Maintained by CommunityActor stats
0
Bookmarked
3
Total users
2
Monthly active users
6 days ago
Last modified
Categories
Share
A bulk website technology detector for lists of domains. Give it a list of websites and it returns one JSON row per site with the CMS (WordPress, Wix, Squarespace and others), the e-commerce platform (Shopify, WooCommerce), JavaScript frameworks, analytics and tag managers, advertising tags, CDN, hosting, DNS provider, e-mail provider, payment providers and live-chat tools. It works as a tech stack detector and website technology scanner for lead lists, agency audits and AI agents. Every detection comes with its evidence (the response header, meta tag, script URL, cookie name or DNS record that triggered it) and a confidence score, so you can check why something was reported.
It is an independent technology detection engine with its own rule set (148 technologies in 24 categories), written from vendor documentation and public observation of vendors' own sites. Each rule stores its source URL, source type, confidence and last-verified date.
What you get in one run
One flat row per website, with the fields below. Every detection carries a confidence score and the evidence that triggered it, so a sales or audit team can see why a technology was reported and filter out weak guesses with minConfidence.
| You want to know | Read this field |
|---|---|
| Which CMS the site runs (WordPress, Wix, Webflow, …) | cms |
| Whether it is a Shopify or WooCommerce store | ecommercePlatform |
| Which CDN, hosting platform and DNS provider it uses | cdn, hosting, dnsProvider |
| Which payment providers and live-chat tools it uses | paymentProviders, chatSupport |
| Analytics, tag managers and advertising tags | analytics, tagManagers, advertising |
| JavaScript frameworks and libraries | frameworks, javascriptLibraries |
| Every detection with its confidence (1–99) and evidence | technologies[]: name, category, confidence, evidenceStrength, evidence[] |
Typical uses
- Lead qualification (bulk technology analysis): from a list of company domains, keep the ones that run Shopify with Klaviyo, use OneTrust, or have no tag manager. Sort and filter on the flat summary columns.
- Lead-list enrichment: add the CMS, e-commerce platform, CDN, hosting and DNS provider of each company to a list of domains, then download the dataset as CSV, JSON or Excel from Apify.
- Agency and consultant audits: which analytics, tag-manager, consent, CDN and hosting tools a client or competitor list uses, in one run.
- Sales-trigger research: which sites use a given CMS, framework, hosting or e-mail provider, so you can target a migration or integration offer.
- AI agents and pipelines: a structured answer to "what is this site built with?" with verifiable evidence, through the API or MCP.
Quick start
{ "urls": ["python.org", "kubernetes.io", "nodejs.org"], "minConfidence": 65 }
Start the Actor with that input (or paste your own list, one domain per line). A run of a few dozen domains takes seconds. You pay only for sites that were scanned successfully.
Where this Actor fits
It is a curated detector: 148 technologies chosen for lead and audit work, each rule with a recorded source. It does not try to be an encyclopedia. If you need the longest possible technology catalogue, pick a tool that advertises thousands of signatures; if you need results you can check, with evidence and honest blocked/failed rows that are not billed, this Actor is built for that.
HTTP scan and Full scan
| HTTP scan (default) | Full scan (optional) | |
|---|---|---|
| How | One page request, plus DNS and TLS lookups. No browser. | The page is rendered in headless Chromium. |
| Input setting | default | browserFallback: true (only pages that return a thin JavaScript shell) or alwaysUseBrowser: true (every page) |
| Speed | about 2–4 seconds per site on average | about 10–30 seconds per page, at most 2 pages at a time |
| Sees | HTML, response headers, cookies set by the server, script/link URLs, DNS, TLS | Everything above plus technologies loaded by JavaScript at runtime (for example analytics loaded through a tag manager) |
| Billing | Basic scan event | Full scan event, only for pages that were actually rendered |
Use the HTTP scan for large lists. Switch on the browser only where you need runtime-loaded technologies: it is slower and costs more per page. If the browser step fails on a site, you get the plain-HTTP result, billed as a Basic scan, and browserError says why.
Input
| Field | Default | Description |
|---|---|---|
urls | – | Bulk input: one domain or URL per line, up to 10,000. https:// is assumed when missing. Duplicates are removed. |
browserFallback | false | Render pages that return only a thin JavaScript shell. Slower, Full scan price for those pages. |
alwaysUseBrowser | false | Render every reachable page. Slowest, Full scan price for every rendered page. |
respectRobotsTxt | true | Skip pages the site's robots.txt disallows for this Actor (user agent TechStackDetector) or for all bots. See below. |
minConfidence | 0 | Drop detections below this confidence (1–99). Values of 65–70 keep only detections backed by direct evidence. |
includeEvidence | true | Return the signal behind each detection. |
includeDns / includeTls | true | DNS records (name servers, MX, SPF) and the TLS certificate issuer/expiry. |
maxConcurrency | 10 | Sites scanned in parallel (never two requests to the same host at once). |
timeoutSecs | 20 | Time limit per site. |
Output
One dataset row per input URL:
| Field group | Examples |
|---|---|
| Status | scanStatus (ok / blocked / error / skipped_robots), statusCode, errorType, blockReason, scanMode, browserUsed, browserError |
| Page | finalUrl, title, description, language, redirects |
| Detections | technologies[] with name, category, confidence (1–99), evidenceStrength (strong / weak), optional version, and evidence[] |
| Flat summary | cms, ecommercePlatform, frameworks, javascriptLibraries, analytics, advertising, tagManagers, cdn, hosting, paymentProviders, marketingTools, chatSupport, emailInfrastructure, emailServices, dnsProvider, securityTools, consentManagement, fonts, maps, video, abTesting |
| Infrastructure | server, poweredBy, tlsIssuer, tlsValidTo, dns, headers, cookies (names only), scripts |
Example row (shortened):
{"url": "https://example-shop.com","scanStatus": "ok","ecommercePlatform": "Shopify","analytics": ["Google Analytics"],"tagManagers": ["Google Tag Manager"],"technologyCount": 6,"technologies": [{"name": "Shopify", "category": "Ecommerce", "confidence": 90, "evidenceStrength": "strong","evidence": [{ "method": "cookie", "rule": "shopify#2", "value": "(cookie name)", "confidence": 90, "strength": "strong" }]},{"name": "Mailgun", "category": "Email service", "confidence": 60, "evidenceStrength": "weak","evidence": [{ "method": "dns_txt", "rule": "mailgun#1", "confidence": 60, "strength": "weak", "note": "SPF include shows a sender is authorized for the domain; it does not prove the service is currently used" }]}]}
Confidence and evidence strength
strongevidence is a direct signal: a vendor-specific response header, ageneratormeta tag, a script or stylesheet actually loaded from a vendor host, an MX record of a mailbox provider.weakevidence is an inference: an SPFinclude:(a sender is authorized, not necessarily used), apreconnecthint, a URL that appears only inside inline script text, or a cookie name on its own. A detection that rests only on weak evidence is never reported above confidence 60 (75 with two independent weak signals).- Confidence is a signal-strength score, not a probability.
Blocked pages, robots.txt and what cannot be detected
- Some sites cannot be scanned. Pages behind bot protection (Cloudflare challenge, Akamai, DataDome, Imperva, HTTP 403/429) are reported as
blockedwith the reason. The Actor does not try to get past them: no CAPTCHA solving, no stealth or evasion techniques, no proxy rotation. On a list of large, well-known brand sites, about 28 of every 100 rows came backblocked, timed out, failed to resolve or were skipped, so expect gaps on such lists. - robots.txt is respected by default. The Actor reads a host's
/robots.txtonce and skips a page if the rules disallow it for the user agentTechStackDetectoror for all bots. Skipped pages are returned asskipped_robots. A missing robots.txt (4xx) allows scanning; a server error (5xx) is treated as disallow (RFC 9309). You can switchrespectRobotsTxtoff, but only do so for sites you own or have permission to scan; that choice and its consequences are yours. - Not billed:
blocked,skipped_robotsanderrorrows. Only successfully scanned pages are billed. - Absence is not proof of absence. The HTTP scan cannot see technologies that are only loaded by JavaScript after the page renders, that run purely on the server without any public trace, or that a site loads only after you accept cookies. Sites can also remove generator tags and hide asset paths.
- Coverage is limited to the 148 technologies listed below. A technology that is not in the list will not be reported.
- Bare domains: if a bare domain fails at the network level (no DNS record, connection refused or TLS failure), the Actor tries the
www.host once.
Accuracy check
We compared results with facts that site owners and service providers publish themselves (privacy/cookie policies, developer documentation, public source repositories, customer case studies) for 31 sites and 44 documented facts. Every detection that could be checked this way was correct (27 of 27 with the HTTP scan, 32 of 32 with the Full scan), and the scans found 65% (HTTP) and 78% (Full scan) of the documented technologies; the misses were mostly technologies that load at runtime, load only after cookie consent, or leave no public trace. Only about one detection in five could be checked against an official statement, so read this as a sanity check on a small, non-random sample, not as a benchmark or a guarantee.
Use it from the API
Run a scan and get the results in one call (synchronous calls time out after 300 seconds, so send batches of about 100–200 domains for the HTTP scan and fewer than 40 for browser modes, or start an asynchronous run for larger lists):
curl -X POST "https://api.apify.com/v2/acts/asunoki~tech-stack-detector/run-sync-get-dataset-items" \-H "Authorization: Bearer <YOUR_APIFY_TOKEN>" -H "Content-Type: application/json" \-d '{"urls": ["python.org", "kubernetes.io"], "minConfidence": 65}'
from apify_client import ApifyClientclient = ApifyClient("<YOUR_APIFY_TOKEN>")run = client.actor("asunoki/tech-stack-detector").call(run_input={"urls": ["python.org", "nodejs.org"]})for row in client.dataset(run["defaultDatasetId"]).iterate_items():print(row["url"], row["scanStatus"], row["frameworks"], row["hosting"])
Use it from AI agents (MCP)
The Actor can be exposed as a tool through the Apify MCP server. Connect your client to https://mcp.apify.com?tools=asunoki/tech-stack-detector (OAuth sign-in, or an Authorization: Bearer <token> header) and ask, for example, "Which CMS, CDN, hosting provider and payment tools does example.com use? Include the evidence and confidence." The structured output and the evidence per detection make the answer easy to verify.
Pricing
Pay per event, per successfully scanned website: a Basic scan for an HTTP scan and a Full scan for a page rendered in a browser. Blocked, robots-skipped and failed rows are not billed. Platform usage is included in the event price; there is no separate compute bill. Price per successfully scanned website: Basic scan $0.005, Full scan $0.015 (the Pricing tab is authoritative). A small per-run start event applies as well. Set a maximum cost per run to cap spend; the Actor stops when the limit is reached.
Supported technologies (148)
| Category | Technologies | Examples |
|---|---|---|
| A/B testing | 3 | Optimizely, VWO, LaunchDarkly |
| Advertising | 12 | Google Ads, Criteo, Taboola, Outbrain, … |
| Analytics | 15 | Google Analytics, Mixpanel, Amplitude, Hotjar, PostHog, Matomo, … |
| CDN | 9 | Cloudflare, Fastly, jsDelivr, Bunny CDN, … |
| CMS | 11 | WordPress, Wix, Squarespace, Webflow, Joomla, TYPO3, … |
| Consent management | 3 | OneTrust, Cookiebot, Usercentrics |
| Customer support / chat | 8 | Intercom, Zendesk, Crisp, Tawk.to, Gorgias, … |
| DNS provider | 4 | Cloudflare DNS, Google Cloud DNS, Vercel DNS, DigitalOcean DNS |
| Ecommerce | 2 | Shopify, WooCommerce |
| Email infrastructure | 4 | Google Workspace (Gmail), Microsoft 365 (Exchange Online), Zoho Mail, Fastmail |
| Email service | 4 | SendGrid, Mailgun, Postmark, … |
| Fonts | 4 | Google Fonts, Adobe Fonts, … |
| Hosting | 9 | Vercel, Netlify, WP Engine, Kinsta, Heroku, … |
| JavaScript framework | 10 | Next.js, Nuxt, Gatsby, Angular, Astro, … |
| JavaScript library | 4 | jQuery, Bootstrap, Alpine.js, htmx |
| Maps | 3 | map SDKs and embeds |
| Marketing automation | 7 | HubSpot, Marketo, Klaviyo, Braze, … |
| Payment | 8 | Stripe, PayPal, Klarna, Afterpay, Affirm, … |
| Programming language | 1 | PHP |
| Security | 8 | reCAPTCHA, hCaptcha, Cloudflare Turnstile, … |
| Tag manager | 4 | Google Tag Manager, Tealium iQ, … |
| Video | 4 | Vimeo, Wistia, JW Player, … |
| Web framework | 4 | Express, Django, Ruby on Rails, ASP.NET |
| Web server | 7 | nginx, Apache HTTP Server, LiteSpeed, Caddy, … |
The complete list of all 148 technology names is published at https://asunoki.jp/apps/tech-stack-detector/#supported-technologies.
How the rules are made
Every rule comes from vendor documentation or from public observation of vendors' own sites (HTTP headers, HTML, script and link URLs, cookie names, DNS, TLS), and stores its technology, category, detection method, pattern, source URL, source type, confidence and last-verified date. Rules whose source could not be re-verified are excluded. The engine does not use, copy or derive from any third-party or commercial technology-fingerprint database. An LLM helped write the rules; the source-first process and mechanical re-verification are the safeguards, and they cannot prove that no influence from training data exists.
Support
Questions or a wrong detection? Open an issue on the Actor's Issues tab or write to support@asunoki.jp with the URL and the run link.
Responsible use
The Actor requests publicly served pages the way a browser would, at low rate, does not log in or submit forms, and never stores cookie values. You are responsible for using the results in line with applicable laws, the terms of the sites you analyze and your own data-protection obligations. Technology and company names are trademarks of their respective owners; this Actor is not affiliated with or endorsed by any of them.