How to Tell What Ecommerce Platform a Site is Using

There are a dozen articles on this topic and most of them say “use BuiltWith.” BuiltWith is fine, and it is also wrong often enough that it is worth knowing how to check yourself — particularly now that headless storefronts hide the commerce platform behind a frontend framework that tells you nothing.

We do this regularly, usually to work out what a prospective client is actually running before a first call. Here is the order we go in, from most reliable to least.

Start with the asset URLs

This is the single highest-signal check, and it takes about ten seconds. Open the page, view source, and look at where images, CSS and JavaScript are being loaded from. Platforms serve their assets from their own CDNs, and those hostnames are distinctive:

A site with 138 references to cdn11.bigcommerce.com is a BigCommerce store. This is not a guess, and it does not require a tool.

The reason this beats most other methods is that asset hosting is awkward to disguise. A store can change its theme, strip identifying classes and remove the platform’s own scripts, but it is still loading product images from somewhere.

Check the platform’s own endpoints

Every platform exposes URLs that only that platform has. Append these to the domain and see what comes back:

• Shopify — /cart.js returns a JSON cart object. /products.json frequently returns the whole catalog. Both are Shopify-specific and both are open on most stores.
• BigCommerce — /api/storefront/cart returns JSON for a Stencil storefront.
• WooCommerce — /wp-json/wc/store/products on stores with the Store API enabled, and /wp-json/ alone confirms WordPress underneath.
• Magento — /rest/V1/directory/currency responds on a default configuration.

A JSON response where you expected a 404 is close to conclusive.

Read the class names

Platforms impose naming conventions on their themes, and most stores never strip them:

• Shopify — shopify-section- prefixes on section wrappers, and a Shopify global object in the console carrying Shopify.shop and Shopify.theme.
• WooCommerce — woocommerce, woocommerce-page and wc- prefixes on the body and product elements, plus a WordPress generator meta tag.
• Magento — data-mage-init attributes and Magento_ module names in the RequireJS configuration.
• BigCommerce — Stencil themes are less rigidly conventional, which is why the CDN check matters more here.

Then check the headers

Response headers are quick to read and occasionally decisive. Shopify sets x-shopid and x-shopify-stage. Salesforce Commerce Cloud and several others identify themselves in server or x-powered-by. WordPress hosts often expose x-pingback.

Headers are easy for a CDN to strip, so their absence proves nothing — but their presence is reliable.

Where all of this breaks: headless

Everything above assumes the storefront is rendered by the commerce platform. Increasingly it isn’t, and this is the part most articles on this topic have not caught up with.

A headless build puts a framework — usually Next.js — between the shopper and the commerce backend. The storefront is served from Vercel, Netlify or Cloudflare. The HTML is React output with hashed class names. There are no platform class conventions, no platform CDN for the page assets, and no platform endpoints on the storefront domain.

BuiltWith will confidently tell you the site runs Next.js and React. That is true and almost useless: it tells you how the frontend was built, not what is processing the orders.

To find the commerce layer on a headless storefront:

Watch the network tab during a cart action. The storefront has to talk to the backend eventually. Add something to the cart with devtools open and look at the XHR and fetch requests. A GraphQL call to *.myshopify.com is Shopify. A call to *.mybigcommerce.com is BigCommerce. Commercetools, Saleor and the rest each have recognizable API hostnames.

Check where checkout goes. Many headless builds keep the platform’s hosted checkout, so the moment you proceed to pay, the domain changes and tells you everything.

Look at the product image URLs anyway. Headless storefronts very often still serve product media from the platform’s CDN, because migrating catalog imagery is work nobody volunteers for. cdn.shopify.com images on a Next.js site is a Shopify backend.

Check /robots.txt and the sitemap. These are often still generated by, or point back to, the commerce platform.

Tools, and where they mislead

Wappalyzer and BuiltWith are worth running — they are fast and right most of the time on conventional builds. Their failure mode is specific and predictable: they report the frontend framework on headless sites, and they report stale results on sites that recently replatformed, because both rely partly on historical data.

Treat them as a first opinion. If the answer matters — you are scoping a migration, or sizing up a competitor — confirm it with the asset URLs and the network tab.

What this actually tells you

Knowing the platform tells you less than people expect. It tells you roughly what the constraints are and roughly what a build cost. It does not tell you whether the store is well built, which is a separate question and usually the one that matters.

We check platforms as a starting point for a more useful conversation: what the store is running, what it is running into, and whether the platform is genuinely the limitation or just the thing available to blame. If you are weighing that up for your own store, tell us what you’re running into.