Get a free instant audit of your site, real findings in 15 seconds. Try it →
Industries Healthcare Industrial B2B Consumer Property & Development Professional & Trade Services Retail & Hardware Automotive (4x4) Fashion & Beauty Instant Audit Services Work Platform Why 121 Pricing Free Audit Founder Call Resources News About 1300 121 979 Book a Discovery
Book a Discovery
📞 1300 121 979 Book a Discovery
← News Tech · Internal Tools · June 2026

Why we built our own platform detector Cloudflare Worker.

By Adam Ducquet · 15 June 2026 · 3 min read

When Adam asked "what % of recent revenue comes from clients on Shopify or WooCommerce?", we needed to verify the answer empirically. We built a Cloudflare Worker that detects ecom platform from the live website, ran it against all our client URLs, and reconciled against the Xero invoice ledger. Why we built it ourselves instead of using BuiltWith / Wappalyzer.

AD
Adam Ducquet
Managing Director - Head of Strategy · 121 Group · Senior strategist

The brief

For each of our the client URLs, detect what ecommerce platform (Shopify, WooCommerce, BigCommerce, Magento) and what CMS (WordPress, WordPress, Webflow, Wix, Squarespace, Cloudflare Pages, Next.js, Joomla, HubSpot CMS, Wagtail, Hugo, Jekyll, Gatsby) the live site is running. Cross-reference with Xero invoice data per client to compute trailing-3mo and trailing-12mo revenue per detected platform.

Why not BuiltWith or Wappalyzer

Three reasons:

  1. BuiltWith API pricing. BuiltWith is excellent for high-frequency lookups against a large URL set, but the pricing didn't justify a one-off internal audit.
  2. Network egress matters. some Australian sites rate-limit repeated automated checks from a single network. A Cloudflare Worker fetches from CF edge with different DNS resolution, bypassing the local network issue.
  3. Custom signature patterns. We needed to detect WordPress (which surfaced as 22% of revenue, an unexpected discovery), Cloudflare Pages (Marrambi pattern), Wagtail, and other less-common platforms. Custom regex patterns in our own worker were faster than tuning a third-party API to detect them.

What the worker does

The worker is ~200 lines of JavaScript on a private Cloudflare Worker endpoint:

  • Accepts POST {urls: [.]}
  • Fetches each URL with browser-like UA + Accept headers
  • Runs regex pattern matching against the response body for known platform signatures
  • Returns {results: [{url, status, platform, signals, error}]}

Signature patterns cover Shopify, WooCommerce, Magento, BigCommerce, WordPress, Webflow, Squarespace, Wix, WordPress (non-Woo), Cloudflare Pages, Joomla, HubSpot CMS, Wagtail, Hugo, Jekyll, Gatsby, Next.js. Detection signals include CDN URLs (cdn.shopify.com), generator meta tags, plugin path patterns (/wp-content/plugins/woocommerce), framework-specific JS bundles.

What the data showed

  • WordPress: a meaningful share of revenue (unexpected, one healthcare portfolio dominates this number)
  • WooCommerce: 16.3%
  • WordPress (non-Woo): 14.1% (our WA-based clients)
  • Shopify: 9.1%
  • Webflow: 1.7% (a couple of brands)
  • Mix of Cloudflare Pages, Wix, Squarespace, Next.js custom, others: ~36% combined

Total Shopify + WooCommerce: 25.4% of trailing-12mo services revenue. The empirical answer to Adam's question. The website now reflects the answer.

For other agencies wanting to do this

The CF Worker pattern is reproducible. Three operational requirements:

  1. A list of client URLs (we maintain ours in a curated JSON, updated when new clients sign)
  2. A Cloudflare Workers account (free tier suffices for ~100K requests/month)
  3. Xero / accounting-system data export with per-client revenue (we use our standard 24-month invoice export)

Read more:

↑ Back to top

Want similar custom-tooling work for your operations?

Book a Discovery
Adam Ducquet
Adam Ducquet
Founder and Managing Director, 121 Group. Twenty years building measurable growth programmes for Australian brands, and the senior strategist on every account.
About Adam · LinkedIn · Published 15/06/2026