Website Tech-Stack Detector — Find Any Site's Technologies

Find out exactly what technology stack any website runs — ecommerce platform, CMS, JavaScript framework, analytics, ad pixels, CDN, payments, marketing automation, and more — with live detection, per-technology confidence scores, and zero API keys required.

Features

• Live detection, not a cached database. The actor visits the target domain right now and fingerprints what is actually deployed today — not what a commercial directory last indexed weeks or months ago.
• Confidence score per technology. Every technology in the output carries a confidence value (0–1) derived from the signal type that matched. Headers and cookies are high-confidence; inline HTML body matches are lower.
• Evidence field. Each detected technology tells you which signal fired: header, cookie, meta, scriptSrc, js, or html. No other public tech-lookup tool exposes this.
• No API key. No BuiltWith.com subscription, no Wappalyzer API token, no external credentials of any kind. Just paste in domains and run.
• Runs on a residential proxy for reliable access. Every request exits through a residential IP, so rate limits and lightweight bot-mitigation on the target site do not block the actor.
• Flexible domain input. Pass bare domains (shopify.com), full URLs (https://www.example.com/path), or a mix — the actor normalises everything automatically and de-duplicates.
• Scales to 10,000 domains per run. Process a single domain or a bulk list in one job.
• Pay-per-result, not per-run. You are charged only for domains that return a record — failed fetches are not billed.

What data you get

One JSON record is returned per domain. All nine top-level fields are populated on every successful fetch.

Field	Type	Description
domain	string	Normalised domain (no www., no protocol)
url	string	URL requested
final_url	string	Final URL after any redirects
status_code	integer	HTTP status code received
techs	array	Detected technologies (see sub-fields below)
tech_count	integer	Total number of technologies detected
categories	array	Union of all category labels across detected technologies
parse_confidence	float	Average confidence across all detected technologies (0–1)
scraped_at	string	ISO-8601 UTC timestamp of the run

techs[] sub-fields

Each object inside techs describes one detected technology:

Field	Type	Description
name	string	Display name (e.g. "Shopify", "Google Analytics 4")
tag	string	Primary category tag (e.g. "Ecommerce", "Analytics")
categories	array	Full list of category labels for this technology
link	string	Reference URL for this technology
confidence	float	Detection confidence for this specific technology (0–1)
evidence	string	Signal type that matched: header, cookie, meta, scriptSrc, js, or html

The evidence field is particularly useful for verifying detections programmatically. A header-based match (confidence ≥ 0.95) is extremely reliable; an html-based match (confidence 0.72) means a body pattern matched and may warrant a manual check.

Input

{
  "startDomains": [
    "shopify.com",
    "wordpress.org",
    "stripe.com"
  ],
  "maxItems": 0,
  "proxyConfiguration": {
    "useApifyProxy": true,
    "apifyProxyGroups": ["RESIDENTIAL"]
  }
}

• startDomains (required): List of domains or URLs to analyse.
• maxItems (optional, default 0): Cap the number of domains processed. 0 means no cap.
• proxyConfiguration (optional): Defaults to Apify RESIDENTIAL — the recommended setting for reliable access to most target sites.

Pricing

Pay-per-result. The charge event is domain-result — one charge per domain record delivered to the dataset. The price is $0.0015 per domain (roughly $1.50 per 1,000 domains), which is approximately 25% less than the comparable pay-per-result competitor.

You are never charged for domains that fail to fetch or return an error.

FAQ

Do I need an API key or any external account?

No. The actor uses Apify's built-in residential proxy, which is included in your Apify platform usage. There is no BuiltWith.com API key, no Wappalyzer subscription, no external proxy account, and no external credentials of any kind required. Simply run the actor.

How is this different from BuiltWith.com?

BuiltWith.com queries a pre-built database of technology signatures collected in the past. That database is large — covering tens of thousands of technologies — but the data can be days, weeks, or even months old. Our actor fetches the target domain right now and detects what is actually live today. We also expose a confidence score and an evidence field for every technology row, which BuiltWith's export does not provide.

The honest trade-off: our in-house ruleset covers approximately 89 high-precision technology signatures, which is narrower than a giant commercial database. If you need raw breadth across thousands of obscure technologies, a commercial subscription may be a better fit. If you need freshness (what the site runs today), confidence scores (how certain is the detection), evidence transparency (which signal fired), and price ($0 setup + pay-per-result), this actor wins.

What technologies does the detector cover?

The ruleset focuses on the technologies buyers most commonly care about for lead generation and competitive intelligence: ecommerce platforms (Shopify, WooCommerce, Magento, BigCommerce, Salesforce Commerce Cloud, PrestaShop, and more), CMS (WordPress, Drupal, Joomla, Webflow, Squarespace, Wix), JavaScript frameworks (React, Vue, Angular, Next.js, Nuxt), analytics (Google Analytics 4, Segment, Mixpanel, Heap), ad pixels (Meta Pixel, TikTok Pixel, Google Ads), CDN providers, payment processors (Stripe, Braintree, PayPal), marketing automation (HubSpot, Mailchimp, Klaviyo), live chat and support tools, web servers, and font services.

What happens if a domain is unreachable or returns an error?

The record is still written to the dataset with a populated error field (e.g. fetch_failed, access_challenge) and status_code if available — so you get a full picture of your domain list. You are not charged for records where the fetch failed entirely.

Use cases

Lead generation and sales prospecting. Feed a list of company domains from a CRM or prospecting tool, filter for techs[].name == "Shopify" or categories containing "Ecommerce", and build a segmented outreach list in minutes. Identify which prospects run legacy Magento and are ripe for a migration pitch.

Competitive intelligence. Monitor a set of competitor domains on a schedule to detect when a rival switches CDN, adopts a new marketing automation platform, adds a live chat widget, or migrates their ecommerce stack. The scraped_at timestamp makes change-detection trivial when you diff two runs.

Technology-stack analytics. Analyse the tech distribution across an industry vertical. Which analytics tools dominate fintech startups? What CMS is most common among D2C brands above $10M revenue? Combine this actor with a company-list scraper to answer those questions at scale without a BuiltWith Enterprise subscription.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Additional fields (Phase 2)

This Actor also records your Apify user ID, whether Apify marks the account as paying, the size range of list inputs, the selected country when the input offers a fixed list of countries, and one category from a fixed Actor taxonomy. We use these fields only for aggregate reliability, repeat-use and cross-Actor analysis; reports suppress any cell with fewer than five distinct users.

The same disableUsageStats: true input flag turns these fields off too. The user ID is removed after 13 months; we do not export, sell, share, or attempt to re-identify this data.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.

Repeat-run fingerprint (v2)

When your Apify user ID is recorded (see above), the record also holds an 8-character one-way code made from your input (proxy settings left out) and this Actor's name. It only lets us see that the same account ran the same input again soon after an unsatisfying run; we never see the input itself. It is stored only in the database, never published, and reports use it in aggregate with the same five-user minimum. It is the one exception to the statement above that no hashes are collected, and disableUsageStats: true turns it off.