Website Tech Stack & Contact Scraper

Analyse any list of websites in bulk. For each one: what it's built on, what tools it runs, and the business contact details it publishes.

What you get

Field	Example
platform	shopify · wordpress · wix · webflow · squarespace · woocommerce · magento · bigcommerce · drupal · ghost · framer …
isEcommerce	true
frameworks	["nextjs","react"]
analytics	["google-analytics","meta-pixel","hotjar"]
marketing	["klaviyo","intercom"]
payments	["stripe","shoppay"]
hasAnalytics, hasLiveChat, isHttps
primaryEmail, emails	bulkorders@allbirds.com
socialLinks	{instagram: …, facebook: …, linkedin: …}
title, description, ogTitle, ogImage, siteName, language
server, poweredBy, generator, finalUrl

Detection is structural, not keyword matching

A platform is only reported when a structural marker is present, a CDN host, an asset path, a generated class, a JS global. Matching the bare product name flagged stripe.com as WooCommerce during testing, purely because their integration docs mention it. That class of false positive is what makes tech-stack data useless for outreach, so it's designed out.

Filters that build lists

{
  "websites": ["shop-a.com", "shop-b.com"],
  "platformFilter": ["wordpress"],
  "withoutAnalyticsOnly": true
}

• platformFilter: everyone on WordPress, or everyone on Shopify
• ecommerceOnly: only real storefronts
• withEmailOnly: drop sites with no published contact
• withoutAnalyticsOnly: sites running no analytics tag at all: a strong signal of an unmaintained site, and a ready-made pitch list

Filtered-out sites are not charged.

Pairs with the Local Business Scraper

Run Local Business Scraper to get businesses in a city, feed the domains in here, and you have a qualified list, who's on which platform, who's running no analytics, who to contact.

Who this is for

• Agencies: find every WordPress site in your market, or every store with no analytics
• SaaS sales: territory lists segmented by the tools prospects already run
• Competitive research: what your competitors' stack looks like
• E-commerce, which platform and payment providers a market uses

Privacy, role addresses only

This Actor collects only generic business mailboxes the company publishes on its own site: info@, sales@, support@, careers@ and similar. Person-shaped addresses are discarded. During testing it picked up jane.diaz@stripe.com from Stripe's own API documentation, exactly the personal data this Actor must not collect, and that filter exists because of it.

It also does no email pattern guessing. Inventing firstname.lastname@company.com is how spam lists get built, and this Actor will not do it. Only the domain's own pages are fetched, no third-party data brokers.

Pricing

Pay per result. One row = one website. Sites that fail to load come back as error rows and are not charged, and neither is anything your filters removed.

A BuiltWith alternative for the part most people need

Commercial tech-lookup services price their cheapest tier around what a whole prospecting month costs. If what you need is "which platform is this site on, is it ecommerce, and who do I email", that is what this does, per site, with no seat licence and no minimum.

Website technology detection here means the served HTML is read for structural tells: CDN hostnames, generated asset paths, framework globals and the <meta name="generator"> tag.

Platforms and CMS detected: Shopify, WooCommerce, Magento, BigCommerce, PrestaShop, Wix, Squarespace, Webflow, WordPress, Drupal, Joomla, Ghost, HubSpot CMS, Framer, Carrd.

Alongside the platform you get analytics and marketing tags, payment providers, frameworks, social profiles, contact emails, the server header, HTTPS status and whether the site is ecommerce.

What it does not do. It does not track a technology's history over time, and it does not report install counts across the web. Those are the things the paid services build their index for, and no single-site fetch can produce them.

Notes

• includeContactPage follows the site's own contact/about link for details missing from the home page. It costs one extra request per site; turn it off to halve the run time.
• Detection reads the served HTML. Content rendered entirely client-side after load can be missed on heavily JS-driven sites.
• Set a max charge per run in the run options for a hard spend ceiling. The Actor honors it and stops cleanly.