How to Tell if a Website Is Built with Magento (Adobe Commerce)

To tell if a website is built with Magento — now sold by Adobe as Adobe Commerce — look first at its asset paths: static theme files served from /static/version<number>/ and product images from /media/ are standard to every Magento storefront, and you will see them in View Source and the DevTools Network tab. Confirm with the server side — run curl -I and watch for an X-Magento-* or Mage-Cache-* header, plus cookies like mage-cache-storage and form_key — and with the JavaScript, where Magento uses RequireJS with Magento_* module names and a mage/ namespace. This guide covers every signal, the recognisable checkout URLs, and what finding Magento tells you about a store.

It pairs with how to find out what ecommerce platform a website uses and the broader how to find out what technology a website uses, since Magento is one of the major commerce platforms you will encounter.

What Magento (Adobe Commerce) is, briefly

Magento is a powerful, open-source ecommerce platform written in PHP. It comes in two editions that share the same core: Magento Open Source, the free community edition, and Adobe Commerce (formerly Magento Commerce), the paid enterprise edition Adobe sells after acquiring Magento in 2018. It is known for being flexible and feature-rich but heavy — a self-hosted platform that powers large, complex catalogues and is typically run by mid-market and enterprise merchants with development resources behind them, rather than the hands-off, hosted-SaaS model of a platform like Shopify.

For detection, the important consequence is that Magento has a very distinctive architecture: the way it deploys and versions assets, the headers and cookies it sets, and its RequireJS-based front end are consistent across stores. Because Open Source and Adobe Commerce share that core, the fingerprints identify the Magento platform; telling the two editions apart from the outside is harder and usually inferred from scale and enterprise features rather than a single signal.

Signal 1: the /static/version and /media/ asset paths

The most consistent Magento fingerprint is its asset paths. Magento serves deployed theme files — CSS, JavaScript, images — from a /static/ directory, and crucially it versions that path with a /version<number>/ segment so it can cache aggressively and bust the cache on each deployment. So in the Network tab you will see requests to URLs like:

/static/version1700000000/frontend/Vendor/theme/en_US/css/styles.css

Separately, catalogue and user-uploaded content — principally product images — is served from a /media/ directory, with paths like /media/catalog/product/.... Both /static/version*/ and /media/catalog/ are baked into how Magento delivers a storefront, so seeing assets load from them is a strong, reliable platform signal. Open View Source (Ctrl/Cmd + U) and the Network tab and look for these two paths; together they are a powerful tell.

Signal 2: response headers and cookies

Magento often gives itself away from the server side. Run curl -I https://example.com (or read the Response Headers in the Network tab) and watch for Magento-specific headers: an X-Magento-* header — for instance related to Varnish cache tags — and a Mage-Cache-* header from Magento's full-page cache. Many Magento stores sit behind Varnish for full-page caching, so you may also see Varnish's Via and X-Cache headers in front of the application.

On the client side, Magento sets recognisable cookies. Look in DevTools (Application → Cookies) for mage-cache-storage, mage-cache-sessid and a form_key (used as a CSRF token on forms), among others. These cookies are characteristic of Magento and corroborate the platform alongside the asset paths. For more on reading the server side, see how to read a website's HTTP response headers.

Signal 3: RequireJS, Magento_* modules and the mage/ namespace

Magento's front end has a distinctive JavaScript fingerprint. It uses RequireJS to load modules, and the module names follow Magento's conventions: you will see Magento_* module references — Magento_Theme, Magento_Checkout, Magento_Customer, Magento_Catalog — and a mage/ namespace for the platform's own utilities, such as mage/cookies, mage/translate and mage/url. Searching the page source for Magento_ or mage/ quickly surfaces these. You will also often find a requirejs-config.js and inline require([...]) calls wiring up the page. This RequireJS-plus-Magento_/mage/ pattern is specific to the platform and is a clean front-end signal that complements the asset and header tells.

Signal 4: checkout and account URL patterns

Magento's URL structure is recognisable and corroborates the platform. The cart and checkout live at predictable paths — /checkout/cart/ for the cart and /checkout/onepage/ (or simply /checkout/) for the checkout — and customer pages sit under /customer/account/ (with /customer/account/login/ for sign-in). Catalogue pages frequently use .html suffixes on category and product URLs in default configurations. Navigating to the cart or hovering the account link and reading the destination URL is a quick corroborating check: these patterns are Magento defaults and line up with the asset, header and JavaScript signals to confirm the platform.

The signal table

Signal	Where to find it	What it means
/static/version<number>/... assets	Network tab, View Source	Magento versioned static deploy — strong
/media/catalog/product/... images	Network tab, View Source	Magento media directory — strong
X-Magento-* / Mage-Cache-* headers	curl -I, Network tab	Magento / full-page cache — strong server signal
mage-cache-storage, form_key cookies	DevTools → Application → Cookies	Characteristic Magento cookies
Magento_* RequireJS modules, mage/ namespace	View Source / JS	Magento front-end framework — distinctive
/checkout/cart/, /customer/account/ URLs	Address bar / links	Magento default URL patterns

A single matching signal is suggestive; two or more together confirm Magento with confidence.

Method 1: View Source and the Network tab

Start with the source and the Network tab together. Open the homepage, press Ctrl/Cmd + U, and search for /static/version, /media/, Magento_ and mage/. Then open DevTools (F12), go to the Network tab and reload to watch the /static/version*/ and /media/catalog/ requests fire. This combination is the fastest reliable read: the asset paths are intrinsic to how Magento serves a storefront, and the Magento_/mage/ references confirm the front end. Because these markers are in the server-rendered HTML and the actual asset requests, they are hard to miss and hard to fake while genuinely running the platform.

Method 2: curl -I for headers and cookies

From a terminal, curl -I https://example.com prints the response headers, where you may catch an X-Magento-* or Mage-Cache-* header and the Varnish caching headers that often sit in front of a Magento store. To inspect cookies, load the site in the browser and open DevTools → Application → Cookies, looking for mage-cache-storage, mage-cache-sessid and form_key. The header-and-cookie method is valuable because it reads the server side, which complements the front-end signals and is useful for scripting checks across many URLs. It cross-references neatly with hosting detection — see how to find out where a website is hosted for what the headers and IP reveal about the deployment.

Method 3: Wappalyzer and BuiltWith

For a one-click read, the Wappalyzer browser extension and BuiltWith both recognise Magento and Adobe Commerce and list the platform alongside the hosting, CDN and any payment or analytics tools. They are convenient for a quick confirmation and for capturing the whole stack at once. As with any tool, treat their output as a strong starting point and verify the important calls against the raw signals — the /static/version*/ and /media/ paths, the Magento headers and cookies, and the Magento_/mage/ references are the ground truth, and a quick View Source plus curl -I confirms what an extension reports.

A worked example

Say you are sizing up a competitor's online store. You open the Network tab and reload, and immediately see CSS and JS loading from /static/version1699999999/frontend/... and product images from /media/catalog/product/... — the two classic Magento asset paths. You search the source and find Magento_Checkout and Magento_Customer RequireJS modules plus a mage/cookies reference. Running curl -sI returns an X-Magento-Cache-Debug header and Varnish X-Cache headers in front. You check cookies and spot mage-cache-storage and a form_key. Finally, you hover the cart link and it points to /checkout/cart/. Every signal lines up: this is a Magento (Adobe Commerce) store, fronted by Varnish full-page caching. In a couple of minutes you have not just the platform but a read on its caching architecture and enterprise scale.

Distinguishing Magento from other ecommerce platforms

It is worth knowing how Magento differs from the other major platforms so you do not misattribute. Shopify is a hosted SaaS platform with its own tells — cdn.shopify.com assets, a Shopify.theme object and /cdn/shop/ paths — and no /static/version*/ or Magento_ modules; see how to tell if a website is built with Shopify. WooCommerce is WordPress-based, with /wp-content/plugins/woocommerce/ assets and woocommerce-* body classes rather than Magento's structure; see how to tell if a website is built with WooCommerce. BigCommerce and other hosted platforms each have their own CDN domains and markers. So the /static/version*/ and /media/catalog/ paths plus the Magento_/mage/ references are what specifically point to Magento rather than a different platform. The broad approach to telling them apart is covered in how to find out what ecommerce platform a website uses.

The Open Source versus Adobe Commerce question is harder from the outside, because the two editions share the same fingerprints. You generally infer the enterprise edition from scale and features — large catalogues, advanced merchandising, B2B functionality, sophisticated promotions, and the kind of infrastructure (multiple Varnish nodes, a heavy caching layer) that signals a serious operation — rather than reading a single definitive marker. Be honest about that limit: the signals confirm Magento confidently, while the edition is an educated inference.

Why the platform matters

Knowing a store runs Magento tells you a lot. Magento (Adobe Commerce) is an enterprise-grade platform, so its presence signals a larger, more complex and usually higher-budget store than a typical hosted-SaaS shop — bigger catalogues, more customisation and a development team behind it. For agencies and developers, that identifies Magento-specific build, maintenance and integration opportunities, since Magento stores need ongoing technical work. For competitive research, it reveals a rival's commerce architecture and scale. And for sales qualification, it tells you a prospect has invested in serious commerce infrastructure and likely has the budget and needs that go with it. The platform is one of the most informative single facts about how a major online store is built.

How reliable is Magento detection?

Very reliable. The /static/version*/ and /media/catalog/ asset paths, the Magento_/mage/ JavaScript references, and the Magento headers and cookies are intrinsic to how the platform serves a storefront, so they are present on the large majority of Magento stores and are not used by unrelated tools. The main nuances are the edition question (Open Source versus Adobe Commerce, which the signals do not definitively separate) and heavy customisation or a CDN sitting in front, which can rename or mask some asset paths — though the cookies, headers and RequireJS modules usually still give the platform away. Combine the asset paths, the server signals and the front-end modules, and you can state "this is Magento" with genuine confidence.

The workflow

1. Open the Network tab and watch for /static/version<number>/ and /media/catalog/ asset requests.
2. View Source and search for Magento_ modules and the mage/ namespace.
3. Run curl -I for X-Magento-* / Mage-Cache-* headers, and check cookies for mage-cache-storage and form_key.
4. Read the checkout/account URLs (/checkout/cart/, /customer/account/) to corroborate.
5. Combine the signals — asset paths plus headers plus Magento_ modules means Magento.

Go deeper

• The platform question in general: how to find out what ecommerce platform a website uses.
• A hosted-SaaS contrast: how to tell if a website is built with Shopify.
• The WordPress-based alternative: how to tell if a website is built with WooCommerce.
• The server side: how to read a website's HTTP response headers.

Want the ecommerce platform, hosting and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.