Shopify theme detector

What Shopify theme detector means for a Shopify store

You get the theme name and whether it is on the Theme Store or custom. What that includes, and what it leaves out.

Key takeaways

  • Read the checks, not only the headline.
  • Confirm anything you might change in the admin, the ad account, or both.
  • If the result cannot see cost, sessions, or repeat rate, it cannot answer those questions.

What you actually get

Shopify theme finder names the theme a public store is running, including a theme the merchant renamed in the editor, and says whether it comes from the Theme Store or is custom.

The name tells you which product form, which cart, and which section library you are looking at. Dawn and the other free Online Store 2.0 themes are still the base of a large share of stores. “Custom” in a sales call is often a renamed copy of one of those.

Online Store 2.0 themes build the product page from sections. A Dawn result means those sections exist and can be reordered. It does not tell you the order the merchant chose, and it does not tell you the page speed.

What it leaves out

The finder names the public theme. It does not open theme files in the admin, and it cannot tell you how heavily the sections were edited.

The steps for a single pass are in how to run Shopify theme finder.

What a Shopify theme detector names

A Shopify theme detector reads the published storefront and names the theme that shop is serving. The name still resolves when someone renamed the theme inside the theme library. Merchants rename copies all the time: a live Dawn might sit in admin as Brand main, Homepage refresh, or Q4 layout. The library label is for your team. The public name is the theme the assets belong to. If the storefront is a copy of Dawn, the result can still say Dawn even though the row in admin says something else. That is the fact you put next to a pitch that calls the theme custom.

Next to the name, the result says Theme Store or custom. Theme Store means the published theme matches a theme distributed through the Shopify Theme Store, including the free Online Store 2.0 themes many shops start on. Custom means the public theme does not match one of those known Theme Store themes. The split is about origin, not about taste. A careful studio build can be custom. A file someone pasted together can be custom. Neither label grades the photography, the offer, or the product page.

The check stops at that public identity. It does not open theme files. It does not walk section settings and announce that a hero, a gallery, or a description was heavily edited. It does not diff your product template against a fresh install of the same theme. If you need edit depth, a person still opens the theme editor and looks. Sometimes they open the code editor too. Treat any sentence that sounds like an edit-depth report as outside this result.

It is not a speed test. A shop on Dawn can feel slow. A shop on a custom theme can feel quick. Load time depends on images, fonts, apps, and how a specific template is built. You measure that with a performance check on a defined page. Keep that measurement away from the theme name so nobody praises or blames a theme for seconds that were never recorded. Run the name check from /theme-detector/ on the domain you mean, yours or one you are comparing.

  • Public theme name, including a renamed copy in the theme library
  • Theme Store versus custom, as an origin label
  • No opening of theme files and no edit-depth verdict
  • No speed score and no ranking of design quality
  • A separate pass at /app-detector/ when you need storefront apps

Dawn, free Online Store 2.0 themes, and the custom claim

Dawn and the other free Online Store 2.0 themes are common because they are a supported place to start. They ship with sections, a product template, and a product form that already holds the purchase path. Plenty of shops you respect are on one of those themes with their own colors, type, photography, and apps. The storefront can look considered without the theme being a from-scratch build. When you are the merchant, that is often the outcome you want: a theme you can hire for, document, and edit without inventing a private system.

In a sales call, custom is often a renamed Dawn. The person on the call may have spent real hours in the editor. They may have art-directed the homepage. They are still describing editor effort, not a different theme. Editor effort stays inside the theme you already publish. A different theme replaces the section library, the templates, and the app embeds tied to the theme you are leaving. Those are different bills, different risks, and different handoffs. The public name is how you tell them apart before you sign anything.

If the detector says Dawn, or another named Theme Store theme, you stop treating the shop as a black box. You can brief someone who already knows that theme. You can open a fresh copy of the same theme in a development store and compare the product template by clicking, not by guessing. You are orienting. You are not awarding a score, and you are not claiming the live shop is unmodified. Sections may have been added. Colors may have been changed. The name does not measure that work. It only tells you which library the work sits in.

If the detector says custom, you do not pretend a public Dawn manual matches the shop line for line. You also do not panic. Custom means you will confirm the section list in the editor of that theme, you will ask who can edit it, and you will budget time to click templates rather than to read Theme Store docs. A custom label is a planning fact. It becomes expensive only when a proposal assumes Theme Store sections that this build does not have.

Sections on an Online Store 2.0 product template

Online Store 2.0 themes are assembled from sections. A section is a region on a template: media, the product form, a materials story, recommendations, or a block an app supplied. In the theme editor you add a section, reorder it, hide it, or change its settings. Most layout requests from a merchant are section requests. Move the description under the gallery. Add a shipping note. Turn off a promotional bar on this template only. None of those requests require a new theme, and none of them are answered by the theme name alone.

The product template is the template Shopify uses for a product URL, unless that product is assigned a different template. The control is the template dropdown at the top of the theme editor. The path is Shopify admin, then Online Store, then Themes, then Customize, then the product template dropdown. The detector does not click that dropdown. It tells you which theme owns the editor you are about to open. You still have to choose the template that the product actually uses.

Say an aluminium phone stand is assigned to a template called stand, while the rest of the catalog uses the default product template. The public theme name covers both templates. The assignment lives on the product. If a brief says edit the product page and nobody writes down the template name, the work lands on the default template and the stand URL never changes. Write the theme name and the template name as two fields. They answer different questions.

On a Theme Store theme, the section library starts as the one the theme author shipped, plus sections you or an app added later. On a custom theme, the library is whatever that build includes. You confirm either way by opening the editor and reading the section list on the template you care about. The detector will not list those sections. Adding that list yourself is the first useful note after the name comes back. A homepage full of sections does not tell you the product template is equally flexible. Check the template you sell on.

What the product form is responsible for

The product form holds the title, the price, the variant picker, and the buy buttons. On a stand listed at $29, that form is where the price appears, where a finish or color is chosen, and where the buyer adds the stand to the cart. Everything else on the product template can support that decision. The form is the decision. When you talk about the theme, keep those four jobs attached to the form so later edits do not scatter them into apps, custom liquid, and floating buttons that nobody can find on a phone.

Sections and apps may sit above the form, beside the media, or below the description. That placement is layout. It is not the form. If an app replaces the product form, you are no longer looking at the theme form, and you will only see that by selecting the block in the editor. The theme name will not announce the replacement. Click the form on the product template and read the block type before you ask anyone to restyle the price or the variant picker.

Leave the form intact when the job is explanation. A materials paragraph, a desk-scene photo, a size sketch, and a delivery note can be sections around the form. Title, price, variants, and purchase stay in one place. Splitting those four across apps makes the page harder to reason about, and it makes a later theme switch riskier, because each replacement has to be reattached on the new theme. Variant structure is merchandising. If the stand comes in two finishes, those are variants on the product. The theme only decides how the picker looks.

The detector does not tell you whether the picker is buttons or a dropdown, whether the price shows a compare-at amount, or whether a subscription app has wrapped the buy button. Those are editor facts. Open the product template, select the form, and write one line: theme form, or replaced by a named app. That single line prevents a redesign from styling a block the shop no longer uses.

App embeds live on the theme you publish

App embeds are stored per theme. You can enable an embed on the theme you are publishing and still find it off on a duplicate you made for a trial layout. Buyers only experience the theme that is published, or the preview you deliberately share. A preview that looks strangely empty may be a theme copy with embeds disabled, not a cleaner design. Before you judge the layout, check embeds on that exact theme. The public theme name tells you which published theme buyers hit. It does not list the embeds.

Use the theme result beside a storefront app result, not instead of it. The Shopify app detector at /app-detector/ is the pass that names apps loading on the storefront. The theme detector will not do that job, and the app detector will not tell you whether the theme is Dawn or custom. Keeping the two notes in separate fields stops a theme project from turning into an app-install project halfway through.

When you duplicate a theme, assume embeds need a look. When you publish a different theme, assume you must re-enable the embeds you still want, on the theme you are about to publish. An app can be installed on the shop and still be absent from the live theme. Installed and embedded are different states. The theme name is how you label which embed checklist is the live one.

You leave this check with a theme name, a Theme Store or custom label, and a reason to open one theme editor. You do not leave with a file review, a percentage of sections changed, or a load-time number. Write the name down before you open Customize, so the editor session starts from a fact instead of from the nickname in the theme library.

Shopify questions

Does Shopify theme finder need access to the Shopify admin?

No. Public tools read a URL anyone can open. Calculators use the numbers you type and do not connect to the store.

Can the result be wrong?

Yes. A public tool can read the wrong URL, miss an app that never loads, or match the wrong brand. A calculator repeats a cost you left out. The result is only as good as that input.