Website Tech Stack Detector

Find out what any public website is built with — CMS, ecommerce platform, JavaScript framework, analytics, CDN, and hosting — without opening a browser tab. Give it a list of domains or URLs and it returns one structured record per site: every technology it recognized, grouped by category, with a confidence score and version number where one is available. This actor is a lightweight technology-detection API you can run on a schedule, call from your own code, or use straight from the Apify Console.

Why use Website Tech Stack Detector?

Knowing a prospect's tech stack is a classic B2B signal: it tells you whether a company is a fit for your integration, migration, or replacement pitch before you ever pick up the phone. Main capabilities:

• Detects thousands of technologies — CMS (WordPress, Drupal, Shopify...), JS frameworks (React, Next.js, Vue, Angular...), analytics and tag managers, CDNs, web servers, ecommerce platforms, and more — from a single, fast HTTP request per site.
• Returns a confidence score (0–100) and, when the fingerprint supports it, a version number for each detected technology.
• Surfaces lightweight lead-gen signals alongside the stack: page title, meta description, and any public social profile links found on the page. It never collects personal data such as email addresses.
• Runs on the Apify platform, so you get scheduling, an API endpoint, dataset exports, and monitoring built in — no server to run yourself.

Typical use cases:

• Sales & marketing prospecting — filter a list of leads down to "companies still on Shopify" or "sites not yet using a modern JS framework."
• Competitive & market research — see which CDN, analytics, or ecommerce platform competitors in your space actually use.
• Migration & partnership targeting — find sites running a legacy CMS or a platform your product replaces.
• Portfolio audits — check what an agency's or investor's portfolio companies are built with, in bulk.

What data can Website Tech Stack Detector extract?

Field	Type	Description
domain	string	Hostname the site was actually served from (after redirects)
finalUrl	string	Full URL after following redirects
statusCode	integer	HTTP status code of the response
technologies	array	One entry per detected technology: name, categories, version (or null), confidence (0–100)
categoriesSummary	array	Unique category names across all detected technologies, e.g. ["CMS", "CDN", "Tag managers"]
title, metaDescription	string	Page <title> and meta description
socialLinks	array	Public social profile URLs found on the page (Facebook, X/Twitter, LinkedIn, Instagram, YouTube, TikTok, GitHub, Pinterest)

How to detect a website's tech stack

1. Click Try for free (or Run) on this actor's page.
2. Enter a list of domains — bare domains like example.com or full URLs like https://example.com/pricing. Leave it empty to try a handful of well-known public sites.
3. Click Start and wait for the run to finish (a single GET per domain, so it's fast).
4. Open the Dataset tab and export the results as JSON, CSV, or Excel, or pull them programmatically via the API tab.

How much will it cost to use Website Tech Stack Detector?

You pay per domain successfully analyzed — nothing is charged for a domain that failed to load.

Your Apify discount tier	Price per result	1,000 domains
Free	$0.004	$4
Bronze	$0.0036	$3.60
Silver	$0.0032	$3.20
Gold	$0.003	$3
Platinum / Diamond	$0.003	$3

Apify's free plan includes $5 of monthly platform credit — enough for well over 1,000 domains at no cost. A run also stops automatically once it reaches your run's maximum charge (Apify's pay-per-result cost cap), so you always know the ceiling before you start.

Input

All fields are optional — running the actor with an empty input ({}) analyzes a small default list of well-known public sites so you can see real output immediately. See the Input tab for the full configuration schema.

Field	Type	Default	Description
domains	array of strings	["wordpress.org", "nextjs.org", "allbirds.com", "shopify.com", "github.com"]	Domains or full URLs to analyze (max 1,000 per run). A bare domain is fetched over HTTPS. Duplicates are ignored.

Example input:

{
  "domains": ["stripe.com", "shopify.com", "wordpress.org"]
}

Output

You can download the dataset in various formats such as JSON, HTML, CSV, or Excel. One item is produced per domain that could be fetched, with the same keys every time. These are real items from a live local run of this actor:

{
  "domain": "wordpress.org",
  "inputUrl": "wordpress.org",
  "finalUrl": "https://wordpress.org",
  "statusCode": 200,
  "technologies": [
    { "name": "MySQL", "categories": ["Databases"], "version": null, "confidence": 100 },
    { "name": "Nginx", "categories": ["Web servers", "Reverse proxies"], "version": null, "confidence": 100 },
    { "name": "PHP", "categories": ["Programming languages"], "version": null, "confidence": 100 },
    { "name": "WordPress", "categories": ["CMS", "Blogs"], "version": "7.2", "confidence": 100 },
    { "name": "WordPress Block Editor", "categories": ["Page builders"], "version": null, "confidence": 100 }
  ],
  "categoriesSummary": ["Blogs", "CMS", "Databases", "Page builders", "Programming languages", "Reverse proxies", "Web servers"],
  "title": "Blog Tool, Publishing Platform, and CMS – WordPress.org",
  "metaDescription": "The open source publishing platform of choice for millions of websites worldwide.",
  "socialLinks": [
    "https://www.x.com/WordPress",
    "https://www.facebook.com/WordPress/",
    "https://www.linkedin.com/company/wordpress"
  ],
  "fetchedAt": "2026-09-17T15:23:36+00:00"
}

{
  "domain": "nextjs.org",
  "inputUrl": "nextjs.org",
  "finalUrl": "https://nextjs.org",
  "statusCode": 200,
  "technologies": [
    { "name": "Next.js", "categories": ["JavaScript frameworks", "Web frameworks"], "version": null, "confidence": 100 },
    { "name": "React", "categories": ["JavaScript frameworks"], "version": null, "confidence": 100 },
    { "name": "Node.js", "categories": ["Programming languages"], "version": null, "confidence": 100 },
    { "name": "Vercel", "categories": ["PaaS"], "version": null, "confidence": 100 }
  ],
  "categoriesSummary": ["JavaScript frameworks", "PaaS", "Programming languages", "Web frameworks"],
  "title": "Next.js by Vercel - The React Framework",
  "metaDescription": "Next.js by Vercel is the full-stack React framework for the web.",
  "socialLinks": ["https://github.com/vercel/next.js", "https://x.com/nextjs"],
  "fetchedAt": "2026-09-17T15:18:50+00:00"
}

Tips / limiting cost

• Keep domains focused on the sites you actually need — you're charged per domain analyzed, so trimming the list directly controls run cost.
• A domain behind heavy JavaScript-only rendering may show fewer detected technologies than a browser-based tool would, since this actor never launches a browser (see Limits below).

FAQ, disclaimers, and support

How does detection work? Every domain gets a single HTTP GET (redirects followed, 20-second timeout). The actor matches the response's headers, cookies, raw HTML, <script src> attributes and <meta> tags against a technology fingerprint database, the same approach used by well-known technology-detection tools. No browser is launched.

Why is version often null? Only a subset of fingerprints define a version-extraction pattern (e.g. from a generator meta tag or a version string in a header). When a technology is detected but no version pattern matched, version is null rather than a guess.

Does this scrape personal data? No. The actor only reads what a server already serves publicly to any visitor's browser (headers, cookies, HTML) and only extracts technology signals, page metadata, and public social profile links — never email addresses or any other personal data.

Why did some domains not appear in my results? A domain that could not be reached (DNS failure, timeout, connection refused, TLS error, or a non-HTML/non-text response) is logged and skipped — it is never charged and never becomes a dataset row. Check the run log for the exact reason.

Legal & compliance note

Our actors are ethical and do not extract any private user data, such as email addresses, gender, or location. They only extract what the target site already serves publicly to any visitor. You should be aware that results could still contain personal data (e.g. a name in an author byline). Personal data is protected by the GDPR in the European Union and by other regulations around the world. You should not scrape personal data unless you have a legitimate reason to do so. If you're unsure whether your reason is legitimate, consult your lawyers.

This actor detects technologies using a fingerprint database vendored from the open-source wappalyzergo project (MIT license), matched with the regex library (Apache-2.0 license). It does not scrape wappalyzer.com, builtwith.com, or any other technology-detection website. See THIRD_PARTY_NOTICES.md in this actor's source for the full license text and attribution.

Limits & notes

• Only public, internet-routable HTTP(S) targets on their default port (80/443) are fetched. Domains that resolve to a private, loopback, link-local, or otherwise internal address (including cloud metadata endpoints) are rejected and skipped, never charged.
• Up to 1,000 domains per run; redirects are followed up to 5 hops (each re-validated the same way), and each response body is capped at 2 MB for detection.
• One plain HTTP GET per domain — no browser, no JavaScript execution. A small number of technologies that can only be detected from an executed JS global or a rendered DOM state are not detected by this actor.
• Sites that block or challenge automated HTTP clients (e.g. a bot-protection wall) may return a non-representative response; the actor reports whatever status code and body it actually received rather than guessing.
• Concurrency is fixed at 10 simultaneous requests with a 20-second timeout per domain, to stay a respectful, low-impact client of every site it visits.
• Domain safety checks (public IP only, allowed scheme/port) are performed by resolving DNS at request time, immediately before connecting. A narrow DNS-rebinding race is not fully closed: a hostname could in principle resolve to a public IP at the moment of validation and to a different, private IP a moment later at actual connect time. Pinning the validated IP into the connection would close this but adds meaningful complexity; given how narrow and timing-dependent this window is, it is a known, accepted limitation rather than something this actor fully prevents.

Support

Found a bug or have a feature request? Use the Issues tab on this actor's page. For programmatic access, see the API tab for ready-made code snippets in your language of choice.