An app audit that starts from the Apps page in Shopify admin answers the wrong question. That page tells you what is installed. Shoppers never meet an installed app; they meet the scripts, styles and markup it leaves in the storefront. Audit those, and the app list becomes a cross-reference rather than the source of truth.

In short

  • 17 checks in four passes: inventory, placement, overlap, and confirmation before removal.
  • The public storefront HTML answers most of the inventory and placement questions on its own.
  • Overlap and orphaned code need the public evidence and the admin side by side.
  • Presence of a script is evidence of load, never proof of performance or revenue impact.

Why the installed-app list is the wrong start

Three groups of apps make the admin list unreliable as an audit input. Back-office apps that never touch the storefront inflate the count without costing a shopper anything. Apps that were uninstalled but wrote code directly into the theme keep costing shoppers while no longer appearing in the list at all. And apps built with theme app extensions can be installed, enabled in one template, and inert everywhere else.

The storefront is the only place where all three collapse into the same measurable thing: requests the browser has to make and code it has to parse. So the audit starts there, then reaches for the admin to explain what it found.

How to use this checklist

The four passes build on each other. Inventory first, because you cannot judge placement or overlap for scripts you have not listed. Confirmation last, because that is where an audit turns into changes on a live store, and it deserves its own discipline.

Public response

Visible in the storefront’s public HTML, headers, robots.txt or sitemap.

Browser needed

Needs a real browser session, device conditions, or field data.

Admin or theme access

Needs Shopify admin, theme code, or a vendor account to confirm.

Public evidence here means the initial HTML document of a storefront page, exactly as a crawler or first-time visitor receives it. That includes every <script> element, its attributes, the hostnames it references, inline code and JSON blocks, and markup left by app blocks and embeds. It excludes anything a script goes on to load after it runs, which is why a tag manager needs a browser to audit properly.

Inventory what actually loads

  1. Check 1: Split the script inventory three ways

    Public response

    Count external script files, inline executable blocks, and data blocks such as application/json or application/ld+json. Do it for the homepage, one collection and one product page. The three numbers point at different owners: external files at vendors, inline code at the theme and app embeds, data blocks at whatever is serializing product or configuration state into the page.

  2. Check 2: List every distinct third-party host

    Public response

    Group external scripts by hostname and separate the store’s own domain and Shopify’s CDN from everything else. Every remaining host is a vendor, a connection setup, and a dependency on someone else’s uptime. The list is usually shorter than the app count and more honest.

  3. Check 3: Match hosts and markers against known vendor signatures

    Public response

    Many apps are recognizable from a hostname, a global variable, or a distinctive class name. Record the vendor and the category it serves: reviews, email and SMS, chat, analytics, upsell, search. Treat every match as inferred. A signature proves code from that vendor is present, not that an app is installed, licensed or in use.

  4. Check 4: Note app proxy paths and theme app-block markers

    Public response

    References to /apps/ paths indicate an app proxy serving content through the store’s domain. Markup such as shopify-app-block or data-app-id attributes indicates theme app extensions rendering into sections. Both are useful because they tie storefront output to an app rather than to hand-written theme code.

  5. Check 5: Read the inline configuration blobs

    Public response

    Inline blocks often carry an app’s settings, a shop identifier, or a full product payload. They tell you which apps are configured to do something on this page and which are merely present. Large inline JSON is also the usual reason an HTML document balloons past a megabyte.

App Audit produces the first four checks for any public storefront URL, with hosts, reference counts and sanitized source paths shown next to each finding.

Run App Audit

Judge placement, not just presence

Two stores with the same twelve scripts can have very different storefronts depending on where and how those scripts load. Presence is a count. Placement is the cost.

  1. Check 6: Global versus template-scoped loading

    Public response

    Compare the script list across the homepage, a collection and a product page. A reviews widget on every page including the blog, or a size-guide script loading on the homepage, is usually the result of an embed placed in theme.liquid when a section-level block would do. Changing it needs the theme editor; seeing it does not.

  2. Check 7: Blocking versus deferred

    Public response

    Read the attributes. A script without async, defer or type="module" in the <head> holds up rendering until it arrives and runs. Shopify’s own guidance on third-party scripts makes the same point: audit what loads, remove what is unused, and defer what remains.

  3. Check 8: The same library loaded more than once

    Public response

    Two copies of a slider library, two versions of a polyfill bundle, or two vendors each shipping their own copy of the same framework. Look for repeated filenames and near-identical URLs with different version numbers. This is the cheapest thing on the list to fix and the easiest to miss.

  4. Check 9: Tag managers as containers for more tags

    Browser needed

    A single tag manager script in the HTML can inject a dozen more at runtime. The HTML shows the container; only a browser session shows what the container loads. Export the container configuration and audit it as its own list, with its own owner.

Find overlap and orphaned code

  1. Check 10: Two vendors doing the same job

    Public response

    Group the recognized vendors by category. Two review platforms, two chat widgets, two email capture tools, or two analytics suites on the same page nearly always means a switch that was never finished. Public evidence can show the overlap; the admin and the invoices show which one is still paid for.

  2. Check 11: Scripts for apps that are no longer installed

    Admin or theme access

    Take the vendor list from the storefront and check each against the Apps page. Anything loading in the storefront with no matching installed app is a candidate for leftover code, most often from an app that edited theme files directly rather than using a theme app extension.

  3. Check 12: Theme snippets and assets that reference uninstalled apps

    Admin or theme access

    Search the theme code for the vendor names you found and for the ones you expected but did not find. Look in layout/theme.liquid, snippets/ and assets/, and at {% render %} and {% include %} tags pointing at files nobody recognizes. Read the leftover code guide before removing any of it.

  4. Check 13: App embeds enabled but not used

    Admin or theme access

    In the theme editor, list every app embed and whether it is switched on. Compare that against the apps the team actively uses. An enabled embed loads on every page whether or not anyone configured it to do anything.

Confirm before you remove anything

Everything above produces candidates. None of it produces permission. These four checks are what turn a candidate into a safe change.

  1. Check 14: Who owns the vendor relationship

    Admin or theme access

    Before touching a script, find the person who pays for the vendor and the person who reads its reports. A tag that looks orphaned to engineering is sometimes the only thing feeding a marketing dashboard.

  2. Check 15: What breaks when the script is gone

    Browser needed

    Duplicate the live theme, remove the code in the copy, and walk the storefront in a browser: product page, add to cart, cart drawer, checkout entry, account pages. Watch the console. Some leftover code is genuinely dead; some is silently holding up a feature no one remembers wiring.

  3. Check 16: Tracking and consent implications

    Admin or theme access

    Removing or adding analytics, advertising or session-recording scripts changes what data is collected and under which consent. Check the privacy policy and the consent tool configuration match what will actually load after the change.

  4. Check 17: A rollback measured in minutes

    Admin or theme access

    Keep the pre-change theme copy unpublished and untouched until the change has survived a normal week of traffic. Publishing the backup should be the whole rollback plan, and it should take less time than writing a support ticket.

A useful rule

Remove one thing at a time, on a duplicated theme, with a baseline captured first. An audit that removes eight scripts in one publish has no way to tell which removal helped and which one broke the size chart.

What App Audit covers

App Audit reads the bounded initial HTML of a public storefront page and reports the inventory side of this checklist: the script split, distinct third-party hosts, recognizable vendor signatures with their categories, app proxy paths and theme app-block markers, and any category where more than one recognized vendor appears. Each finding shows the evidence it came from.

It does not execute JavaScript, follow what a tag manager loads, see the Apps page, read theme files, or measure performance or revenue impact. It is explicit that recognized vendors are inferred from public evidence and that the result is not an installed-app inventory. The rule set is versioned, so an App Audit from last month still means what it meant when it ran.