Website Technology Detector - CMS, Analytics and Chat

Scan public homepages in bulk and return recognized website technologies with the matching evidence. Useful for agencies filtering prospect lists by CMS, analytics, marketing or chat tools.

This first release supports 24 technologies. Detection means an indicator appeared in the returned HTML or headers, not that a tool executes or has an active subscription.

How to use

1. Enter website domains or URLs in Websites or domains.
2. Set the maximum websites and concurrency.
3. Run, then filter technologyNames or export the CSV.
4. Read scanStatus and the run summary before treating missing detections as unknown.

{"websites": ["https://wordpress.org/", "https://nextjs.org/"], "maxWebsites": 10, "concurrency": 2}

Input paths, fragments and query strings are removed: this scans homepages only. The same domain and its www equivalent are processed once. Distinct subdomains are separate websites. CSV-file ingestion is not included in this release.

Supported technologies

Category	Technologies
CMS	WordPress, Drupal, Ghost, Joomla
Website builder	Wix, Squarespace, Webflow
E-commerce	Shopify, WooCommerce
Analytics	Google Analytics, Hotjar, Microsoft Clarity, Plausible
Tagging	Google tag, Google Tag Manager
Advertising	Meta Pixel
Chat / support	Intercom, Crisp, Tawk.to, Zendesk
Marketing	HubSpot
Framework	Next.js, Nuxt
CDN / reverse proxy	Cloudflare

Each technology has one or more deliberately narrow signatures. The catalog is not an exhaustive replacement for a comprehensive technology database. Generator metadata, selected same-site assets, script sources, two inline configuration patterns, and the Cloudflare server header are inspected. Plain article text and regular hyperlinks are not scanned for brand names. Versions are returned only from recognized generator metadata. Cloudflare evidence identifies a proxy/CDN signal, not the origin hosting provider. Google tag is kept separate from Analytics because Google Ads can also use gtag.js.

Output

One row per unique input domain, including diagnostic rows for failed sites.

Field	Meaning
website, domain	Normalized requested homepage and domain
finalUrl, httpStatus	Final homepage URL (without query) and HTTP status, when available
scanStatus	detected, no_signals, or failed
technologyNames, technologyCount	Flat names and count, convenient for spreadsheets
technologies	Name, category, optional version and evidence objects (type, marker)
error	Sanitized failure code; null for a readable site
rulesetVersion, scanMode	Fingerprint version and static_homepage mode
scrapedAt	UTC timestamp
billingEvent	Custom event name when enabled, otherwise null

SUMMARY records processed, detected, unknown and failed websites, duplicates, omitted websites and the stopping reason. If all processed sites fail, the run fails after saving its diagnostics. A readable page with no recognized signals is a valid result. Mixed runs keep successful results and expose failures in their rows and summary.

Limits and recovery

• No browser, login, JavaScript execution or remote script downloads. Dynamically injected tags, consent-dependent scripts, self-hosted variants and custom themes can be missed. A matching indicator can also be present in unused template code.
• One robots.txt request and one homepage request per site, plus at most five redirects for each. Redirects to other domains are reported instead of followed.
• robots.txt is respected. Unavailable or restrictive rules stop the scan; crawl delays above ten seconds are reported as unsupported. Bodies are bounded to 512 KB for robots and 2 MB for HTML; oversized responses are reported.
• DNS destinations are checked at connection time. Only public HTTP(S) destinations on standard ports are accepted. No cookies or raw page bodies are stored in the results.
• Input is fingerprinted before output starts. Existing dataset rows are reused on a restart, including rows written before a summary update. Concurrent runs must use separate default storage. A crash between charging and durable output cannot provide an exactly-once billing guarantee.

Pricing

Pay per event: $3 per 1,000 readable websites, plus $0.005 per run start at the default 256 MB memory. Apify charges one start unit per GB of allocated memory, with a minimum of one unit. A readable website is charged once even when no supported technology is found. Failed-site diagnostic rows have no website-scan charge. A run-start charge can still apply when every site fails. Check the Pricing tab for the current rate.

The website-scanned event applies to detected and no_signals results. Automatic dataset-item charging is disabled. Set a maximum cost per run to limit charges; the Actor stops writing paid results when the event budget is exhausted. An already-started batch of at most concurrency websites may finish scanning.

Development

python -m pip install -r requirements.txt
python -m unittest discover -s test -v
python scripts/smoke.py

The smoke script makes six initial public requests across three sites; redirects can add requests. It writes a local validation report. CI runs it in a separate job so that live access problems can be distinguished from deterministic test failures.

Signature references:

• Google tag setup
• Google Tag Manager installation
• Cloudflare HTTP headers

Use public website data responsibly and respect applicable site rules. Related LeadProof tools: Website Email Finder, Google Maps Scraper, and LeadProof.