How to use Shopify app detector | Checkout Club¹⁰¹

The pass

Paste the store URL. Open Shopify app detector and do it in this order.

Paste the store, preferably a product URL if the homepage hides the widgets you care about.
Read the names and open the App Store links. Note which jobs sit beside the buy button: reviews, a subscription, an upsell.
Separate theme sections from apps. A cart drawer can be either. The theme finder is the other half of that question.
Decide which jobs you want on your own page. Each storefront app is another script. The detector is not a speed test, but the list is the input to one.

The mistake that wastes the pass

Installing the competitor’s whole list. You copied their scripts and none of their offer.

How you know it worked

You can open the App Store listing for each name that matters, and you can say which ones render next to the buy button. A list you cannot open is not finished.

Match each storefront name to the theme editor

Open the published theme in Shopify admin, Online Store, Themes, Customize. Choose the product template for ceramic pour-over. Walk the section list and mark every app block. Then open app embeds for that theme and mark every embed that is enabled. Put those marks next to the detector names. A name that appears in the detector and nowhere in this theme needs an explanation: another template, a script in theme code, or a result captured on a different theme than the one you opened.

A name that appears in the editor and not on the detector deserves a logged-out reload of the product URL. Some blocks render only when they have data. An empty widget may leave a small script or none. Write what you observe. Do not force the two lists to match by installing something. The point of the session is a map, and unmapped names are allowed until you understand them.

While you are on the form, restate its job so app work does not swallow it. Title, price, variant picker, buy buttons. For this product the price to recognize is 54. If an app block repeats the price or adds a second buy button, note the app name as the source of the duplicate. The fix, later, is to disable that piece or reconfigure it, not to restyle both until they match by accident.

Work template by template if you must, but finish the product template before you touch the blog. Most accidental scripts that hurt a shop show up beside the form, in a sticky bar, or as a popup embed. Homepage apps can wait until the product URL is mapped. Write the theme name on the map so Thursday publish does not inherit Monday comments aimed at a different copy.

Write keep, pause, or remove on each row

Give every mapped storefront app one of three words. Keep means it stays enabled on the published theme because the job is real and owned. Pause means you disable the embed or the block on the theme you are testing, without uninstalling, so you can see the page without it. Remove means you will uninstall after the pause proved the page still meets its promises, or after the owner agreed the job is dead. Three words stop the vague status "review later" from becoming permanent.

Add the job in the same row, in buyer language, plus the owner. No owner means pause is the strongest word you should use until someone claims it. Add the theme name. Add whether you saw an App Store link. Leave billing blank if you did not look at billing. An empty billing cell is more honest than a guess copied from a listing.

Do not pause ten apps in one edit. Pause one, reload the product URL logged out, and write what disappeared. Then decide. A pile of simultaneous pauses makes a broken form impossible to attribute. The form should remain after each pause. If the form disappears, that app was involved in purchase, and the word becomes keep until you have a replacement you have tested.

For ceramic pour-over, typical pause candidates are duplicate badges, a second review widget, a popup that covers the picker, and a holiday bar whose date has passed. Typical keep candidates are the one widget that explains a variant the photos do not explain, if you truly use it. Typical remove candidates are apps with no visible job after the pause. Your shop will differ. The method is the part worth repeating.

Disable one embed and reload the product page

Pick the first pause row. In the theme editor, disable that embed or hide that app block on the product template only, if the app allows a local hide. Save. Open the product URL in a browser where you are not tucked into an editor preview if you can. Hard refresh. Look at the form first, then the place the widget used to occupy, then the rest of the template. Write one sentence: what left, and whether anything you needed left with it.

If nothing visible left and the detector still reports the app, an embed may remain on the theme, or the script loads from a section you did not edit. Go back to the embed list. The goal is not to fight the tool. The goal is a storefront that matches the decision. When the app should be paused, buyers should stop receiving that behavior. When you rerun the storefront check later, the name leaving the list is a useful confirmation, not the only one. Your eyes on the URL matter more.

If the layout breaks, re-enable the embed before you do anything else. Breakage means you found a dependency. Change the row from pause to keep, and write the dependency in plain language: "collection grid uses this app" or "form is this app." Dependencies are good news. They stop an uninstall. They also stop you from blaming the theme for a layout the app owns.

Repeat for the next row on a different day if the first change was emotionally loud. You do not need to finish the whole list in one sitting. A finished single row is a cleaner shop than a half-finished pile. Publish only if the edit was on the theme buyers use and you meant to change what they see. Sandbox pauses stay on the sandbox.

Hand the map to whoever owns the theme

Send the map, the theme name, and the product URL. Say which rows are already paused and which are proposals. Proposals are not permission. The theme owner enables or disables embeds. An app owner may be a different person from the theme owner. Name both when you know them. A freelancer who "does the site" still should not uninstall a billing-bearing app because a map said remove, unless the contract includes that.

Include the acceptance line: on the published theme, the product URL shows the keep widgets, hides the pause widgets, and still presents title, price, variant picker, and buy buttons. Ask them to reply with exceptions rather than with a new stack. If they want to add an app, they start a new row with a job, they do not fold it into this cleanup.

Give them the rerun path /app-detector/ and the theme path /theme-detector/ so they can refresh names after a publish. Tell them a refresh does not replace the map. It checks whether the public load still agrees with the keep rows. Admin-only apps will still be absent. That absence is correct. They should not reinstall storefront scripts to "complete" the detector.

If the map is for a client, attach exclusions: this is not a security review, not a billing audit, and not a speed engagement. You looked at storefront load and theme placement. You can sell those other engagements separately, with the right access. Mixing them into one vague cleanup produces claims you cannot support.

How you know the storefront agrees with the note

The storefront agrees when a logged-out visit to ceramic pour-over matches the keep and pause decisions. Widgets you kept are visible in the placement you wrote. Widgets you paused are gone from that URL. The price still reads 54 if that is the live price. Variants still change. The buy button still works through to cart. You check cart once. You do not need a full purchase to see that the button started the path, but if your process allows a test order, a test order is the stricter check.

The note agrees when a second person can disable the same embed without asking you which theme you meant. If they cannot, add the admin nickname and a screenshot of the embed toggle. Agreement is operational. A beautiful table that points at the wrong theme is a failure even if every app name is spelled correctly.

Rerun the storefront detector after the changes have had a chance to appear on the public URL. Expect the paused app to drop off if it truly stopped loading. If it remains, you missed an embed, a block, or a hardcoded script. Find it before you uninstall anything else. If a kept app drops off, you disabled too much. Restore it. The rerun is a mirror. It is not a grade, and it does not produce a performance delta.

Stop when the map, the editor, and the logged-out URL tell the same story. Archive the map with the date and the theme name. The next campaign that wants a new popup must add a row rather than paste a script into a theme file where this map will never see it. If someone later pastes a script anyway, the next detector run is how you catch the surprise. That is a good use of a repeat check.