How to Find Out What E-commerce Platform a Website Uses

Whether you are sizing up a competitor's store, qualifying a sales prospect, or planning a migration, one of the first useful facts about any online shop is the platform it runs on. E-commerce platforms leave clear fingerprints — in asset domains, URL paths, headers, cookies and the checkout flow — so identifying one is usually a matter of knowing where to look. This guide covers the major platforms and their tells, plus how to read the trickier cases like headless and enterprise commerce.

For the general approach behind all platform detection, see how to find out what a website is built with; here we focus on commerce.

Why identify the e-commerce platform?

The platform shapes almost everything about a store. Merchants benchmark competitors and decide whether to switch. App, theme and agency businesses qualify whether a store is a fit for their product or services — a Shopify app maker only cares about Shopify stores, for instance. Sales teams build targeted prospect lists by platform. And anyone planning a migration needs to know the starting point to estimate the work. Because the platform is the foundation of the store, naming it correctly is the highest-leverage single fact you can establish — almost every other decision, from which apps are available to how much a redesign costs, follows from it.

The major platforms and their tells

Most stores run on one of a dozen platforms, and each has a recognisable signature:

Platform	Primary tells
Shopify	cdn.shopify.com / /cdn/shop/ assets, window.Shopify, x-shopify-stage header
WooCommerce	/wp-content/plugins/woocommerce/, woocommerce body class, WordPress tells
Magento / Adobe Commerce	/static/version… paths, Mage/Magento objects, mage-cache cookies
BigCommerce	cdn11.bigcommerce.com assets, BigCommerce markers in source
Salesforce Commerce Cloud	demandware.static / *.dwstatic domains, dwac/dwsid cookies
Wix Stores	static.wixstatic.com plus Wix Stores widgets
Squarespace Commerce	static1.squarespace.com plus commerce markup
PrestaShop	/modules/, prestashop JavaScript object, generator tag
OpenCart	index.php?route= URL patterns, OpenCart markers
Ecwid	app.ecwid.com scripts embedded in another site

A single matching asset domain or path from this table usually names the platform with confidence. For the two most common — Shopify and WooCommerce — it is worth knowing the deeper details, which is why each has its own guide: how to tell if a website is built with Shopify and how to tell if a website is built with WordPress (WooCommerce runs on WordPress).

Read the headers and cookies

The response headers and cookies confirm what the assets suggest. Open the Network tab, reload, and click the document request. Platform-specific headers (x-shopify-stage for Shopify) and cookies (mage-cache-storage for Magento, dwsid for Salesforce Commerce Cloud, WordPress and WooCommerce session cookies for WooCommerce) come from the server and cannot be styled away by a theme, which makes them more trustworthy than markup alone.

Use the checkout as a tiebreaker

Storefronts get heavily customised; checkouts rarely do. The checkout is usually the most platform-specific, least-themed part of a store, and sometimes runs on a platform-owned domain. When a homepage has been styled beyond recognition, adding an item to the cart and beginning checkout (no purchase required) often exposes the platform immediately. This is the single most useful move for stubborn, design-led stores.

Headless and enterprise commerce

Two cases need a lighter touch. Headless commerce decouples the storefront from the commerce engine: the front end renders through a framework like Next.js while the cart, catalogue and checkout run on a platform such as Shopify, BigCommerce or commercetools behind the scenes. The storefront tells disappear, but the commerce API calls in the Network tab and the checkout still reveal the engine. Enterprise platforms like Salesforce Commerce Cloud and Adobe Commerce power large retailers and are identifiable from their static-asset domains and cookies, even when wrapped in a sophisticated custom front end. The practical lesson is the same in both cases: when the storefront goes quiet, let the cart, the checkout and the API traffic do the talking, because the commerce engine has to reveal itself somewhere to actually take an order.

What the platform tells you

Naming the platform lets you infer a great deal: the likely budget and scale (Ecwid or a basic Shopify plan at one end, Salesforce Commerce Cloud at the other), the flexibility and customisation model, the app and integration ecosystem available to the store, and the migration effort if a move is on the table. For prospecting and partnerships, the platform is often the single best qualifier — which is why technology-based lead lists are built around exactly this signal (see how to find websites using a specific technology).

Reading the store's wider stack

The platform is the foundation, but a store's competitiveness lives in the tools layered on top — and those are detectable too. Payment providers announce themselves through their scripts: js.stripe.com for Stripe, PayPal's SDK domain, and the Apple Pay or Shop Pay buttons that hint at the checkout setup. Reviews and social proof apps (Judge.me, Yotpo, Trustpilot) inject star widgets from their own domains. Analytics and tag management are nearly universal — Google Tag Manager, Google Analytics, the Meta pixel and TikTok pixel all load from recognisable domains and reveal how a store measures and markets itself. Email and marketing automation (Klaviyo is especially common in commerce) leaves embedded scripts too. Reading these alongside the platform paints a picture of how a store actually operates: how it takes payment, builds trust, and acquires customers.

Estimating the store's scale and plan

You can often infer roughly how large a store is from its stack. An Ecwid widget embedded in a small business site, or a basic Shopify theme with few apps, suggests a modest operation. A Shopify Plus store (with checkout.liquid customisations or Plus-only apps), an Adobe Commerce install, or Salesforce Commerce Cloud points to a mid-market or enterprise retailer with a real budget. The density of the app stack is itself a signal: a store running a dozen well-integrated apps for reviews, upsells, subscriptions and loyalty is investing seriously in conversion, whereas a bare storefront is either very new or very lean. None of this is exact, but for prospecting and competitive sizing it is a fast, useful estimate.

Common mistakes when identifying a platform

A few errors trip people up. Mistaking an embedded widget for the platform is the classic one — a content site can embed an Ecwid or a single Shopify "buy button" without being a Shopify store. Reading a payment or analytics script as the platform: Stripe and Google Tag Manager appear on stores across every platform, so they identify tools, not the engine. And stopping at the homepage: a design-led store can hide its platform on the front page but reveal it instantly at the cart. When two signals seem to disagree, trust the source of the store's own core assets and the checkout over any third-party script bolted on top.

What a migration between platforms involves

Because so many stores eventually outgrow or switch platforms, detection often precedes a migration decision — and the source platform shapes the work. Moving from one hosted platform to another (say, BigCommerce to Shopify) is mostly a data export-and-import plus a theme rebuild. Moving off WooCommerce means untangling a WordPress install and its plugins, which can be more involved than it first appears. Moving to or from an enterprise platform like Adobe Commerce or Salesforce Commerce Cloud is a serious project in its own right. Whatever the direction, three things always need care: migrating the product catalogue and customer data intact, preserving URLs with redirects so hard-won search rankings survive, and recreating the checkout and payment configuration. Knowing the starting platform is precisely what lets you estimate any of this with confidence rather than discovering the scope halfway through.

How accurate is e-commerce detection?

For standard stores, platform detection is highly reliable — the asset domains, paths, headers and cookies triangulate quickly, and the checkout resolves the stubborn cases. Accuracy drops for fully headless builds (where you must read API traffic rather than storefront markup) and for bespoke in-house platforms that match no public signature. The reliable rule holds: corroborate the asset domain with a header or the checkout before you commit to an answer.

The fast, reliable workflow

1. Search the source for platform asset domains and paths (cdn.shopify.com, /wp-content/plugins/woocommerce/, /static/version).
2. Read the headers and cookies for platform-specific entries.
3. Begin checkout (without buying) to reveal the platform on customised stores.
4. Watch the Network tab for commerce API calls on headless builds.
5. Cross-check two signals before concluding.

Go deeper

• The full method: how to find out what a website is built with.
• The two big platforms in depth: Shopify and WordPress/WooCommerce.
• Turn it into prospecting: how to find websites using a specific technology.

Want the platform, apps and full stack in one pass? Analyse any store with StackOptic — free, no sign-up.