Shopify Theme Detector: How to Find Out Which Theme a Store Uses

A Shopify theme detector answers a small but useful question: which theme is this store actually running. If you build stores, sell apps, or prospect ecommerce businesses, the theme is a quick read on how a store was put together, how custom the build is, and sometimes how much budget went into it. The good news is that Shopify stores announce their theme in the page they serve to every visitor, so you can often find out by hand in under a minute, and a detector just does that reading faster.

This guide covers both. First the manual signals a Shopify theme detector reads, so you understand what is real and what is guesswork. Then the tools that read those signals for you. Then the honest part: what the theme tells you, what it does not, and why for prospecting the missing apps usually matter more than the theme name.

The signals a Shopify theme detector actually reads#

Every detector, manual or automated, is reading public output the store already serves. Nothing here involves logging in or touching anything private. These are the real tells, in roughly the order of how reliable they are.

The Shopify.theme object#

This is the single most direct giveaway. Open any product or collection page on a Shopify store, view the page source (Ctrl+U, or Cmd+Option+U on a Mac), and search (Ctrl+F) for Shopify.theme. On most stores you will find an inline JavaScript object that looks something like this:

Shopify.theme = {"name":"Dawn","id":123456789,"theme_store_id":887,"role":"main"}

That name field is the theme. The id is the store’s internal theme id, and theme_store_id is present when the theme came from the Shopify Theme Store. If a store is running Dawn, Debut, Impulse, Prestige or any other named theme, this is where it shows up. It is the field most Shopify theme detector tools read first, because it is both common and explicit.

Asset URLs on cdn.shopify.com#

Shopify serves theme assets from cdn.shopify.com. In the page source, search for cdn.shopify.com and look at the asset paths. Theme stylesheets and scripts are served from a path that includes the theme’s files, and the asset URLs frequently carry the theme name or its asset filenames. Even when the Shopify.theme object is missing, the asset paths often still reveal the theme, and the presence of cdn.shopify.com itself confirms the store is on Shopify at all.

The schema_name in theme settings#

Themes ship with a settings_schema.json that defines their settings, and the first entry usually carries a theme_name or schema_name value. Some of this surfaces in the rendered page or in the theme’s published asset files. Searching the source for schema_name can confirm or refine what the Shopify.theme object told you, and it is a useful cross-check when a store has renamed the theme in its admin but left the schema untouched.

Telltale class names and section markup#

Shopify themes structure their markup in recognizable ways. Sections carry ids and data attributes, and many themes use distinctive class-name prefixes. You do not need to memorize these, but if the explicit signals are stripped, the shape of the markup, the section naming, the way the cart drawer is built, can still point an experienced eye at a specific theme or theme family. This is the least precise signal and the one a good detector treats as corroboration, not proof.

Tools that read the signals for you#

If you would rather not read source by hand on every store, several tools do it automatically. They are reading the same public signals described above, just faster and across more stores.

• General technology detectors like Wappalyzer and WhatRuns identify that a site is on Shopify and often surface the theme alongside the rest of the stack. They run as browser extensions, so you click once on the store and read the panel.
• Dedicated Shopify theme detector tools focus specifically on the theme question and tend to parse the Shopify.theme object and asset paths directly, sometimes adding the app stack a store runs.
• A broader stack checker reads the theme as one signal among many, alongside the apps, pixels and analytics a store runs, which is closer to what you need if you are qualifying the store rather than just admiring the theme.

For a side-by-side of the general detectors and where each fits, the comparison of BuiltWith and Wappalyzer alternatives covers the free tiers and the paid lines honestly. And if you want the manual reading for any CMS, not just Shopify, the guide on how to detect the CMS a website uses walks through the same view-source approach across platforms.

Reading the result on a real store#

It helps to see how these signals stack up on an actual store, in the order you would read them. Open a Shopify storefront and view the source. Your first move is Ctrl+F for Shopify.theme. If the object is there, you have the theme name and id immediately, and most of the time the job is done in that one step. If it is not there, you do not panic, you move down the list.

Your second move is cdn.shopify.com. Finding it confirms Shopify even when the theme object was stripped, and the asset filenames often still carry the theme’s fingerprint. Your third move is schema_name, which corroborates the name and catches the case where a store renamed the theme in its admin but left the settings schema alone. Only if all three come up empty do you fall back to reading the section markup and class names, which is the soft signal and the one most likely to be a theme family rather than an exact name.

The discipline here is to stop at the first solid answer and treat the later signals as backup, not to chain guesses. A clean Shopify.theme read does not need corroboration; a missing one is where the lower-confidence signals earn their place.

Custom themes versus marketplace themes#

One of the most useful things the theme signal tells you is roughly how custom a store’s build is, and that distinction matters more than the exact theme name for most prospecting.

A store running an unmodified Theme Store theme like Dawn is, in build terms, close to default. That is not a criticism, plenty of strong stores run popular themes, but it tells you the store probably did not invest heavily in bespoke front-end work. The theme_store_id being present is a hint that the theme came from the marketplace.

A store running a theme with a name you do not recognize, or with the theme_store_id absent, may be on a custom or heavily forked theme. That usually signals more investment, an agency build, or a developer in the picture. The detector cannot measure how much was changed, but the presence or absence of a marketplace id is a reasonable proxy for “off the shelf” versus “built for them”.

Either way, treat the result as a starting point. A store can take a marketplace theme and customize it extensively, in which case the detected name understates the work. The theme name is the floor of the build, not a measurement of it.

What theme info does not tell you#

A Shopify theme detector is precise about one thing and silent about a lot of others. Being honest about the gaps keeps you from over-reading a result.

• It does not tell you how much the theme was customized. A detected Dawn could be near-default or rebuilt past recognition.
• It does not tell you the apps a store runs. Reviews, email capture, upsells, subscriptions and loyalty are all separate signals, and they are often where the real story is.
• It does not tell you the store’s revenue or traffic. The theme is a build signal, not a performance one.
• It does not always work. A headless Shopify store renders a separate frontend and may never expose the standard Shopify.theme variables, and a store can strip the signals deliberately. A blank result means “not detected”, not “no theme”.

That last point is the one to hold onto. Any detector worth using is clear when it cannot see the answer, rather than guessing a theme to look confident.

Reading the app stack alongside the theme#

The theme is the design layer, but a Shopify store’s behavior comes from its apps, and those leave signals in the same page source. While you are already reading the source, it is worth a second pass for the app stack, because for prospecting the apps are usually the more interesting half.

Apps inject their own scripts and stylesheets, and many serve assets from recognizable domains or load distinctively named files. A reviews app, an email capture popup, an upsell widget, a subscription tool, a loyalty program, each tends to add a script tag you can spot. You do not need to identify every app by name. What you are reading for is presence and absence: does this store have email capture at all, does it have any reviews app, is there a cart-upsell script. The specific vendor matters less than whether the function exists.

This is also where cookie names help. In developer tools, the Application or Storage tab lists the cookies set on page load, and many ecommerce tools set distinctively named cookies the moment you land. Pairing the script scan with the cookie list gives you a fuller picture of the store’s functional stack than the theme alone ever could.

The reason this matters is timing. Reading the theme and the apps in one sitting, off the same page source, means you finish with both halves of the story: how the store was built, and what it is and is not doing. That is the read that actually drives a decision about whether the store is worth your time.

From theme to the broader stack: the gap is the signal#

Knowing the theme is satisfying, but if you do this for prospecting, the theme is rarely the pitch. The pitch is usually in what the store is missing. A Shopify store is a tidy example, because the gaps map directly to services and apps.

• A store with no email marketing platform detected is leaving the highest-margin channel in ecommerce on the table. That is a flows-and-retention conversation with the problem already visible.
• A store with no reviews app is missing social proof on its product pages, which is a conversion pitch.
• A store running ads with no Meta pixel or conversion tracking is spending money it cannot measure, which is a paid-media pitch that proves itself.
• A store with no upsell or post-purchase app is leaving average order value unimproved, which is a concrete, testable improvement.

The theme qualifies how the store was built; the gaps tell you what to say. That is the difference between knowing which Shopify theme a store uses and knowing why it matters for your next outreach. Reading the full stack, theme plus apps plus the absences, is exactly the lens Website Technology Checker is built around. It reads the same public signals any detector does, then leads with the gaps and scores them for how clearly they signal an opportunity.

If your outreach runs where ecommerce owners already pay attention, a tool like Inflowave handles the Instagram side of that follow-up once a gap check flags a store worth contacting. And when you want to find the stores in the first place rather than check them one at a time, a lead scraper pairs naturally with a stack-and-gaps read.

A fast routine#

For a single store, you do not need any tool at all. Open the page source, search for Shopify.theme, and read the name field. Cross-check the asset paths on cdn.shopify.com if you want to confirm. Note whether theme_store_id is present, which tells you marketplace versus custom. That is the theme settled in under a minute.

For many stores at once, the manual route does not scale, and you lean on a detector. Pick one that reads more than the theme, because the theme alone is half the story. The full value is reading the build to understand the store and reading the gaps to know what to offer. If you want the gap-first piece of that the moment it ships, the waitlist is the place to start, free at launch.