How to Tell If a Website Uses Shopify

TL;DR: Start with an extension, then inspect the evidence behind its result. Shopify asset URLs, globals, cart responses and domain records can support attribution, but an extension and source search may count the same clue twice. Generic app scripts and familiar page design do not establish Shopify. Keep conflicting cases in a manual review queue.

Start with the evidence behind the label

A platform label is useful when qualifying Shopify leads, but a mistaken label can lead to the wrong service pitch. Record what the page actually exposes and when you checked it.

Use Store Inspector, BuiltWith or Wappalyzer for a first pass. A detector's positive result is a starting point. A negative result can mean no supported visible signature on the inspected page, rather than no Shopify backend.

The following methods are proposed checks, not a calibrated accuracy or timing benchmark. Their availability varies by storefront architecture and region.

A dated example: Gymshark source has assets without theme globals

On October 10, 2026, we fetched the raw public HTML of Gymshark's homepage and one product page. Both returned HTTP 200. Exact static substring checks found:

One homepage match was https://cdn.shopify.com/s/files/1/0098/8822/files/gymshark_social_banner_1200x1200.jpg?v=1549554764. The product HTML included a Shopify CDN image URL for the displayed tank.

The counts are substring occurrences, including repeated URLs in the HTML. They are not distinct assets, loaded requests or independent platform checks. We did not execute browser globals or access /cart.js in this experiment. Missing static globals therefore say nothing about what a browser might create later.

For separate attribution, Shopify's Gymshark case study documents its move to Shopify Plus; Algolia's customer account describes a headless storefront built on Shopify. These are publisher accounts of that implementation, not a fresh merchant-admin inspection.

The observed lesson is specific: requiring Shopify.theme or Shopify.shop in raw HTML would have rejected both pages despite their asset evidence and published platform history. CDN URLs alone can be retained or reused after a migration, so the same result on an unknown domain would still need corroboration. This two-page example does not establish detector precision or recall across storefronts.

Method 1: Inspect an extension's evidence

Run the detector on the homepage and an actual linked product page. Record the page URL, date, tool and result. If it exposes a signature or asset URL, inspect that clue directly.

Checking /cdn/shop/ in source after an extension matched that same asset verifies the extension's observation; it does not add a second independent source. Browser permissions, page loading and the extension's supported patterns can affect the result. Leave missing or conflicting details unresolved.

Method 2: Search source and loaded assets

Open page source and search for:

• cdn.shopify.com or Shopify-linked CDN hosts
• /cdn/shop/ asset URLs
• Shopify.shop or Shopify.theme assignments
• A merchant-specific myshopify.com reference

Read the surrounding code. A live image URL, a script setting a merchant domain and a paragraph discussing Shopify have different evidential value. A historical copied snippet can remain after a platform change.

If the raw HTML is sparse, inspect loaded resources using the browser's Network panel. Chrome's Network documentation explains how to preserve and inspect requests. Record the request and page context; loading a Shopify-hosted image supports use of that asset, rather than proving the current checkout backend.

Headless front ends and asset proxies may hide expected theme signatures. Absence from one page or one loading state is not a platform exclusion rule.

Method 3: Check real routes

Follow a product link that the storefront actually exposes. /products/all asks for a product with the handle all; it is not a universal product catalog endpoint. A 404 there does not argue against Shopify.

/cart and /collections/all can supply context on a conventional storefront, but other platforms can use the same routes and headless Shopify can use different ones. Record the response rather than judging the URL shape or cart design alone.

Method 4: Inspect a read-only cart response where available

Shopify's Ajax Cart API documents a read-only GET /{locale}/cart.js response for a theme-based online store. Use the storefront's locale-aware path when available. Relevant response fields include currency, item_count, items and total_price.

A matching live response is more useful than a generic cart URL. Confirm the response format, domain and page context, then compare it with a distinct clue such as merchant-linked platform/domain evidence. Other systems can imitate response fields, so do not treat a shape match as universal proof.

A blocked or missing endpoint is inconclusive for a headless or customized storefront. Do not add products, enter customer details or advance checkout just to obtain a platform label. Public, read-only checks should be enough for a research queue; ask the merchant when the business decision requires confirmation.

Method 5: Compare third-party lookup records

BuiltWith and Wappalyzer can help discover domains and show broader infrastructure. Record the date of the lookup and any stated last-observed date.

Two lookup tools may use the same public signatures. Their agreement does not establish independent ground truth, and historical classifications can outlive a migration. Compare important records with current page evidence and keep the historical lookup separate in your log.

Method 6: Treat app footprints as supplementary

An app vendor name can suggest what to investigate, but it may serve several ecommerce platforms. For example, Klaviyo publishes a WooCommerce integration, so a generic Klaviyo script cannot establish Shopify.

A vendor request with explicit Shopify integration context may strengthen the hypothesis. Record that context rather than awarding platform confidence for every review, lifecycle or subscription script. App hits can also arise from stale code or broad parser patterns. See app detection and its limits.

Method 7: Check domain records

Shopify's current manual domain guidance specifies shops.myshopify.com for a conventional www CNAME. A merchant-linked CNAME can provide evidence from a different layer than a page asset.

For a domain you are permitted to inspect, a read-only command is:

dig CNAME www.example.com +short

Use the actual host, not a guessed www variant. The documented target is useful when present, but custom headless hosting, proxies, apex-record flattening or a different primary domain can produce other results. A DNS record also may survive a migration; compare it with the live storefront.

Handle conflicting clues without a point score

The earlier checks overlap. Counting an extension, a source asset and a network request for that asset as three votes would overstate the evidence. We do not have a retained labeled validation panel that justifies numerical weights or a probability cutoff.

Use evidence states instead:

These are operational rules, not validated probability bands. “Supported” still does not prove Shopify Plus, a full app inventory or a commercial need.

Hypothetical example A: extension and source agree

An extension identifies Shopify and source contains /cdn/shop/. Record the asset behind both observations as one underlying clue. Seek a separate live platform response or merchant/domain attribution before moving the account out of the hypothesis queue.

Hypothetical example B: custom storefront with partial clues

A page has Shopify CDN images but no theme globals. Inspect live response/domain evidence and reliable platform accounts. The Gymshark observation shows why missing globals alone cannot settle this case, but it does not establish the architecture of another merchant.

Hypothetical example C: lookup record conflicts with the page

A historical lookup says Shopify while current checks expose no expected clues. Keep the case unresolved. Neither stale detection nor frontend invisibility is proved until you obtain additional evidence; do not label it migrated merely because a signature is absent.

Keep a useful evidence log

For each account, save:

• Inspected URL, final host, locale and observation date
• Detector name and result
• Exact source/request clue and its context
• Read-only response or DNS result, including failures
• Publisher or merchant attribution with its date
• Which observations share the same underlying asset
• Evidence state, conflicts and next verification step

This lets another researcher inspect the reasoning without repeating every check. Once attribution is supported, move to theme research, pixel research or lead qualification according to the task.

FAQ

Can a Shopify backend be difficult to detect?

Yes. A headless front end, account-only behavior or proxy can obscure conventional theme clues. Use a bounded set of public checks, then retain uncertainty or obtain merchant confirmation.

Is an app footprint decisive?

A generic multiplatform vendor hit is supplementary. Inspect Shopify-specific context and corroborate the platform separately.

How many clues are enough?

There is no validated count in this guide. Evaluate specificity, freshness and independence; several copies of one image URL remain one kind of evidence.

Is public inspection always permitted?

The workflow describes public, read-only observations. It does not determine permission for every tool, access method or jurisdiction. Check applicable site/tool terms and the rules for your intended use.