Website Tech Stack Detector & Change Monitor

Check a list of websites for supported CMS, ecommerce, analytics and other tools. Export the detected technologies with evidence, then repeat the same watchlist to see additions, version changes and confirmed removals.

The Actor analyzes each target website directly. It does not scrape BuiltWith or Wappalyzer, does not require an account with either service, and is not affiliated with them. The detector uses a small independently authored set of high-confidence signatures rather than a large third-party fingerprint dump.

First useful result and recurring cost

Start with the sales-lead example below and replace the public sample domains. For each SUCCESS record, upsert the detected technologies by external_id in your CRM; preserve the evidence and observation time. A successful empty stack means no supported signature matched, not that the website uses no technology. Blocked or partial results need review and must not clear a populated CRM field.

Three successful sample checks cost $0.003. A quiet daily watchlist of 100 domains for 30 days costs $3 in domain-check events at the current tariff, including platform usage. Reuse the same monitor state and require confirmed removal events before clearing an existing technology. In n8n or Sheets, keep the status and source timestamp next to the technology values. The Actor does not contact prospects or write to the CRM itself.

Exact detector coverage and evidence

The current curated detector supports 47 technologies. Confidence scores describe matched rule strength, not a calibrated probability of installation. A vendor script/header is evidence of a public integration; it does not prove a paid subscription or company-wide adoption. Next.js implies React, Nuxt.js implies Vue.js, and WooCommerce implies WordPress.

Technology	Category	Observable evidence
Adobe Analytics	Analytics	html, script_src
Adyen	Payment provider	script_src
Akamai	CDN / infrastructure	header (server), header (x-akamai-transformed)
Amazon CloudFront	CDN / infrastructure	header (x-amz-cf-id), header (x-cache)
Angular	JavaScript framework	html
BigCommerce	Ecommerce	html, script_src
Cloudflare	CDN / infrastructure	cookie, header (cf-ray)
Cookiebot	Consent management	html, script_src
Crisp	Live chat	html, script_src
Drift	Live chat	html, script_src
Drupal	CMS	header (x-generator), html, meta (generator)
Fastly	CDN / infrastructure	header (fastly-debug-digest), header (x-fastly-request-id), header (x-served-by)
Ghost	CMS	meta (generator), script_src
Google Analytics	Analytics	html, script_src
Google Tag Manager	Tag manager	html, script_src
Hotjar	Analytics	html, script_src
HubSpot	CRM / marketing automation	cookie, script_src
Intercom	Live chat	html, script_src
Joomla	CMS	html, meta (generator)
Klarna	Payment provider	html, script_src
Klaviyo	CRM / marketing automation	html, script_src
Magento	Ecommerce	cookie, header (x-magento-tags-pattern), script_src
Mailchimp	CRM / marketing automation	html, script_src
Marketo	CRM / marketing automation	cookie, script_src
Matomo	Analytics	html, script_src
Meta Pixel	Advertising	html, script_src
Netlify	Hosting / infrastructure	header (server), header (x-nf-request-id)
Next.js	Web framework	header (x-nextjs-cache), html, script_src
Nuxt.js	Web framework	html, script_src
OneTrust	Consent management	html, script_src
PayPal	Payment provider	script_src
Plausible Analytics	Analytics	script_src
React	JavaScript framework	html, script_src
Segment	Analytics	html, script_src
Shopify	Ecommerce	header (x-shopid), html, script_src
Squarespace	CMS	html, script_src
Stripe	Payment provider	html, script_src
Svelte	JavaScript framework	html
Tawk.to	Live chat	script_src
TikTok Pixel	Advertising	html, script_src
Vercel	Hosting / infrastructure	header (server), header (x-vercel-id)
Vue.js	JavaScript framework	html, script_src
Webflow	CMS	html, script_src
Wix	CMS	header (x-wix-request-id), script_src
WooCommerce	Ecommerce	cookie, html, script_src
WordPress	CMS	link_href, meta (generator), script_src
Zendesk	Live chat	script_src

Only the fetched public HTTP response is inspected. Consent-gated, logged-in or later JavaScript-injected integrations may be invisible. Unsupported products cannot be detected. Header/cookie names and markup can be customized; even a high-confidence match should be checked before a commercial decision.

Controlled-fixture validation results cover 49 synthetic cases, including two negatives and all 47 supported names: 50 true-positive labels, zero extra labels and zero missed labels. Precision and recall are 100% on these fixtures only. This checks detector regressions; it is not a real-world accuracy claim or a comparison with BuiltWith/Wappalyzer.

Public-site coverage check - September 13, 2026

The production HTTP client and detector were checked on eight deliberately varied public homepages, without proxy or DNS/TLS enrichment. All eight fetched successfully. Observed signals included:

Homepage	Supported technologies observed
wordpress.org	Google Tag Manager, WordPress
shopify.com	Cloudflare
ghost.org	Netlify
webflow.com	Cloudflare, Google Tag Manager, Marketo, Webflow
nextjs.org	Next.js, React, Vercel
wix.com	Fastly, React, Wix
apify.com	Amazon CloudFront, Intercom, Next.js, React
example.com	Cloudflare

This small sample checks practical output, not precision or recall against a complete installed-stack inventory. A vendor's marketing site need not expose its own product's signature; a successful CDN-only result is not a full stack. Before CRM enrichment, test a small sample of your own account list and review the evidence. JavaScript-rendered and consent-gated integrations can be absent.

CRM mapping that preserves good data

Actor field or event	CRM action
external_id	Match your existing company/account ID
technologies, scraped_at, fingerprint on a verified success	Store observed stack, checked time and evidence version
TECH_ADDED / TECH_VERSION_CHANGED	Queue an account-review signal
MISSING_PENDING	Keep the previous confirmed technology pending another check
TECH_REMOVED_CONFIRMED	Remove that confirmed technology from the tracked field
BLOCKED, PARTIAL, FAILED	Record the error separately; keep the last good CRM values

Do not clear an installed-tech field merely because one successful response has an empty supported stack. Keep observed data separate from confirmed monitoring state. Export the rows to your CRM through your own integration; no outreach or CRM write is performed by the Actor.

What it returns

Every requested domain gets exactly one record, including invalid, blocked, and failed inputs. A successful record contains:

• the normalized current technology stack with category, version when explicit, confidence, and evidence surface names;
• optional normalized MX/nameserver providers and TLS certificate metadata;
• a deterministic semantic fingerprint and versioned detector metadata;
• BASELINE, UNCHANGED, TECH_ADDED, MISSING_PENDING, TECH_REMOVED_CONFIRMED, or TECH_VERSION_CHANGED events;
• your own external_id for CRM/account/watchlist joins.

technologies: [] with SUCCESS means a complete public page was fetched and none of the supported high-confidence signatures matched. A timeout, 403, challenge page, invalid response, or truncated page is never converted into that answer; it is FAILED, BLOCKED, or PARTIAL. If a pay-per-event run reaches the user's maximum charge, untouched inputs receive SKIPPED_BILLING_LIMIT and their monitor state is retained.

Pricing

The Actor costs $0.001 per distinct complete SUCCESS domain check - $1 per 1,000 successful websites. Platform usage is included and there is no start fee. Snapshot and monitor checks have the same predictable price, including an UNCHANGED result because a fresh live verification was performed.

Duplicate aliases, retries, PARTIAL, FAILED, BLOCKED, INVALID_DOMAIN, and SKIPPED_BILLING_LIMIT are free. DNS queries, TLS enrichment and emitted change events are not separate billable events. The Actor charges while the successful row is stored; monitor state advances only after that row was delivered and billed.

Ready-to-run examples

• Website Tech Stack Detector for Sales Leads enriches prospect domains and preserves CRM IDs.
• Competitor Technology Stack Change Monitor creates a reusable baseline and emits confirmed change events.
• Shopify & Ecommerce Platform Migration Monitor watches supported commerce and CMS platform changes.
• Website SaaS Adoption Signals for Sales Teams turns supported public SaaS additions into sales signals.
• Email Hosting & DNS Provider Checker for Domains resolves normalized MX and nameserver provider signals.

Quick start: one-domain lookup

{
  "domains": [{ "domain": "apify.com" }],
  "mode": "snapshot",
  "outputMode": "all",
  "includeDns": true,
  "includeTls": false
}

Run from the CLI after the Actor is deployed:

$apify call automa-flow/website-tech-stack-monitor --input-file input.json

The full input and representative output are in examples/.

CRM domain batch

{
  "domains": [
    { "domain": "prospect-a.com", "externalId": "salesforce-001" },
    { "domain": "prospect-b.com", "externalId": "salesforce-002" },
    { "domain": "prospect-c.com", "externalId": "salesforce-003" }
  ],
  "mode": "snapshot",
  "outputMode": "all"
}

The Actor fetches duplicate normalized domains once, but still emits one row per input so every external ID receives an answer.

Competitor watchlist

{
  "domains": [
    { "domain": "competitor-a.com", "externalId": "competitor-a" },
    { "domain": "competitor-b.com", "externalId": "competitor-b" }
  ],
  "mode": "monitor",
  "outputMode": "changesOnly",
  "watchTechnologies": ["Shopify", "WooCommerce", "Magento", "HubSpot", "Klaviyo"],
  "includeDns": true
}

The current stack is always present because the per-domain status row must remain unambiguous. changesOnly suppresses the redundant UNCHANGED object inside events, while keeping the main row with change_type: UNCHANGED; it never suppresses failure or invalid-domain rows. This preserves the batch invariant: 100 inputs produce 100 explicit statuses. all includes the explicit UNCHANGED event as well.

Sales and competitive signals

Shopify migration

A switch from Shopify to another platform is reported as exact raw events, not an invented intent score:

[
  { "type": "TECH_ADDED", "technology": "Magento", "before": null, "after": { "name": "Magento" } },
  { "type": "TECH_REMOVED_CONFIRMED", "technology": "Shopify", "before": { "name": "Shopify" }, "after": null, "missing_successful_scans": 2 }
]

The events may arrive on different runs: addition is immediate on strong evidence, while removal needs two independent complete successful missing scans. Once a domain is confirmed on Shopify, export or monitor its public catalogue with the Shopify Products Scraper, Price & Stock Monitor.

HubSpot or Klaviyo adoption

Use watchTechnologies: ["HubSpot", "Klaviyo"]. A new strong vendor-script or cookie signal produces TECH_ADDED with exact after technology data. That row can go directly to a CRM webhook as an adoption trigger.

Safe change semantics

Monitor state lives only in Apify KVS and is keyed by normalized domain plus the relevant scan configuration. It stores the last confirmed technology set, compact evidence/confidence, missing counters, fingerprint, detector versions, and observation time.

present -> first complete successful scan missing -> MISSING_PENDING
        -> second complete successful scan missing -> TECH_REMOVED_CONFIRMED

FAILED, BLOCKED, and PARTIAL scans never increment the counter and never overwrite good state. If the detector or signature database version changes, the first complete run emits DETECTOR_REBASELINE and adopts a fresh baseline; it does not manufacture a wave of additions/removals.

Daily schedule

First save the monitor input as an Apify Task and test it. Then create a daily 08:00 schedule with the API (replace placeholders; keep the token in an environment variable, never in source control):

curl -X POST "https://api.apify.com/v2/schedules" \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Daily website technology watchlist",
    "isEnabled": true,
    "isExclusive": true,
    "cronExpression": "0 8 * * *",
    "timezone": "UTC",
    "actions": [{ "type": "RUN_ACTOR_TASK", "actorTaskId": "YOUR_TASK_ID" }]
  }'

Apify schedule syntax and timezone behavior are documented at https://docs.apify.com/actors/running/schedules.

Webhook sales trigger

Create a run-succeeded webhook on the saved Task. The payload carries the run and dataset IDs; your receiver then reads dataset rows whose events contain TECH_ADDED, TECH_REMOVED_CONFIRMED, or TECH_VERSION_CHANGED:

curl -X POST "https://api.apify.com/v2/webhooks" \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "requestUrl": "https://crm.example/webhooks/technology-change",
    "eventTypes": ["ACTOR.RUN.SUCCEEDED"],
    "condition": { "actorTaskId": "YOUR_TASK_ID" },
    "payloadTemplate": "{\"run_id\":\"{{resource.id}}\",\"dataset_id\":\"{{resource.defaultDatasetId}}\"}",
    "shouldInterpolateStrings": true,
    "description": "Website technology sales signals"
  }'

Webhook behavior is documented at https://docs.apify.com/integrations/webhooks.

Use with AI agents through Apify MCP

Expose the Actor as a typed MCP tool:

https://mcp.apify.com?tools=automa-flow/website-tech-stack-monitor

Example prompt:

Run automa-flow/website-tech-stack-monitor for these company domains. Return the
detected ecommerce, analytics, CRM, email, and infrastructure technologies,
separate FAILED or PARTIAL scans, and cite each source_url and evidence surface.

For recurring sales or competitor workflows, use mode: monitor and act only on confirmed TECH_ADDED, TECH_VERSION_CHANGED, and TECH_REMOVED_CONFIRMED events. A failed scan never confirms a removal.

Detection surfaces and supported scope

The default path is one public homepage fetch. The Actor inspects final URL, HTTP headers, Set-Cookie names, generator/meta values, script/link URLs, and a small number of explicit inline identifiers. Optional DNS makes two queries (MX and NS). TLS is off by default. Raw HTML, cookie values, arbitrary TXT records, personal contacts, and giant evidence snippets are never returned.

Every initial target and redirect hop is resolved once and the connection is made to that exact verified public IP while retaining the original HTTP Host and TLS SNI. The optional proxy CONNECT target is pinned the same way. Private, loopback, link-local, and other non-public addresses are rejected before any request bytes are sent; transient resolver failures remain explicit failures rather than being mislabeled as invalid input.

The curated MVP covers 40+ commercially important technologies across CMS, ecommerce, frameworks, analytics, advertising, CRM/marketing automation, payments, live chat, CDN/hosting, and consent management. The exact selectable names are listed in the Input Schema.

Limitations

• No JavaScript execution: runtime-only tools may be missed.
• Normally one page: technologies absent from the homepage are not discovered.
• Consent, geo/A-B variants, and personalized templates can hide scripts. This is why removals require confirmation.
• Confidence is a deterministic rule strength, not a machine-learning probability and not a claim of complete coverage.
• Direct HTTP is normal. An optional Apify datacenter proxy is attempted only after a failure/block when explicitly configured. Residential proxy, CAPTCHA solving, login, and access-control circumvention are out of scope.
• Fingerprints are intentionally curated for precision. This Actor will detect fewer obscure technologies than a multi-thousand-rule browser database.

Request limits

The Actor checks up to 10 domains concurrently using direct HTTP. Optional DNS adds two queries per successfully fetched domain; TLS checks are opt-in. Only complete successful domain checks are billed, with change events included.

Legal and responsible use

Each target website has its own terms. The Actor accesses only public homepage technical signals, normally once per check. It does not log in, visit admin/private paths, bypass access controls, collect personal contacts, or build a copy of target content. Users must ensure their domain list and schedule comply with applicable terms and law.

Output contract

Records are history-ready from the first run: stable source_id, UTC scraped_at, additive schema_version, semantic fingerprint, detector_version, and fingerprint_database_version. Datasets remain append-only observations. The Actor does not build a historical database; KVS holds only compact monitoring state.