Most Shopify audit checklists are long because length looks thorough. In practice a store owner needs a shorter thing: the checks that change a decision, the evidence behind each one, and a clear label on which checks a public scan can answer and which need someone with admin access. That is what this list is.

In short

  • 25 checks, grouped by the question they answer rather than by discipline.
  • Every check is tagged: public response, browser needed, or admin access needed.
  • Nineteen of the 25 can be answered from public evidence anyone can fetch. Six need a browser session or admin access.
  • A public scan is a starting point for a technical conversation, not a verdict on revenue.

How to use this checklist

Work through the sections in order. The first two cover whether the store can be reached and understood at all; problems there make everything after them less relevant. The third and fourth cover weight and structure, which is where most stores that “feel slow” actually have their issue. The last section is the honest list of things no public scanner can see.

Each check carries an evidence tag. The tag matters more than the check, because it tells you who can answer it and how much you should trust the answer.

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.

A note on what public evidence means here: the response any visitor or crawler receives when requesting the storefront. That covers the HTML document, its headers, the redirect chain, /robots.txt and /sitemap.xml. It does not cover JavaScript execution, the rendered page, the Shopify admin, the theme editor, or anything behind a login.

Can search engines and shoppers reach the store?

These checks are binary and cheap. When one fails, it is usually the most important finding in the whole audit, because it affects every page at once.

  1. Check 1: HTTPS is enforced and the primary domain wins

    Public response

    Request the http:// version, the apex domain, and the www variant. Each should reach the same primary URL in one hop with a permanent redirect. Two or three hops is common after a domain change and costs every first visit a round trip. Shopify handles the redirect when the primary domain is set correctly; a proxy or DNS-level redirect in front of it is where chains appear.

  2. Check 2: The homepage returns 200 without a detour

    Public response

    A homepage that answers 301 to itself with a query string, or 302 to a locale path, or 200 with a maintenance template, looks fine in a browser and wrong to a crawler. Record the final status, the final URL, and every hop in between.

  3. Check 3: robots.txt exists and blocks only what it should

    Public response

    Shopify generates a sensible default that keeps crawlers out of cart, checkout, search and account paths. The file can be customized through the robots.txt.liquid template, which is also how well-intentioned edits end up blocking collections or product images. Read the live file, not the theme file, and check every Disallow against a path you actually want indexed.

  4. Check 4: sitemap.xml resolves and its child sitemaps are live

    Public response

    Shopify serves an index at /sitemap.xml that points to product, collection, page and blog sitemaps. Confirm the index returns XML, that each child URL returns 200, and that the domain inside the sitemap matches the primary domain. A sitemap still pointing at the myshopify.com hostname after a domain change is a real and common finding.

  5. Check 5: Key templates are not accidentally noindex

    Public response

    Look for a robots meta tag or an X-Robots-Tag header on the homepage, one collection, one product and one page. A noindex left over from a theme preview, a password period, or a staging copy is the single most expensive thing a public scan can catch.

  6. Check 6: Time to first byte, recorded as a trend rather than a verdict

    Public response

    One measurement from one location is a data point, not a diagnosis. Note the value, note where it was measured from, and compare it to the same measurement next week. A sudden change is informative; an absolute number without context is not.

Does each page say what it is?

Shopify themes generate most of these tags automatically, which is exactly why they go unchecked. Themes get customized, apps inject their own tags, and the defaults quietly stop being true.

  1. Check 7: Title tag present, specific, and not truncated

    Public response

    The homepage title should name the store and what it sells, in that order or the reverse, in roughly sixty characters. A missing title, a title that is only the store name, or one that repeats the shop name twice because both the theme and an SEO app append it, are all worth a line in the report.

  2. Check 8: Meta description present and written for a human

    Public response

    Search engines rewrite descriptions freely, so this is less about ranking and more about not shipping an empty tag or a description copied from a product feed. Check the homepage and one template of each type.

  3. Check 9: Canonical tag present and pointing where you expect

    Public response

    Shopify products can be reached at /products/handle and at /collections/collection-handle/products/handle. Standard themes canonicalize the second form to the first. Confirm that still holds after theme edits, and confirm the homepage canonical is the primary domain, not a myshopify.com URL or a locale path you did not intend to be primary.

  4. Check 10: One H1 per template

    Public response

    Read the HTML, not the rendered page. Logos wrapped in an H1, section headings promoted to H1 by a page builder, and product pages with no H1 at all are common after a few rounds of theme customization.

  5. Check 11: Structured data on product pages validates

    Public response

    Most themes emit Product JSON-LD; review and SEO apps often add their own. Two competing Product blocks with different prices or availability is a real problem. Copy the product page HTML into a schema validator and read what it finds rather than assuming the theme handled it.

  6. Check 12: hreflang is present and reciprocal if you sell across markets

    Public response

    If the store uses Shopify Markets with subfolders or country domains, each locale page should reference the others. Check one product page in two markets and confirm both list each other. Partial hreflang is a frequent leftover from a market that was switched off.

How much is the browser being asked to do?

This is where “the store feels slow” usually lives, and where the public HTML is more revealing than people expect. You cannot measure the shopper’s experience from a single document fetch, but you can count what that document asks the browser to load.

  1. Check 13: Size of the HTML document itself

    Public response

    A Shopify homepage is commonly a few hundred kilobytes of HTML. A document past a megabyte usually means inlined product data, embedded JSON for several apps, or a section repeated many times. Size alone is not a fault; it is a prompt to look at what fills it.

  2. Check 14: Script inventory: external, inline, and data blocks

    Public response

    Count the <script> elements and split them three ways: external files, inline executable code, and data blocks such as JSON. A store with 30 external scripts and 40 inline blocks has a different problem from one with five of each. Record the split, because the fix for each is different.

  3. Check 15: Distinct third-party hosts

    Public response

    List every hostname the HTML references for scripts. Each new host is a DNS lookup, a connection, and a vendor whose uptime is now part of yours. Six hosts is ordinary; twenty deserves a conversation about which vendors are still paying for themselves.

  4. Check 16: Recognizable vendors and category overlap

    Public response

    Match the hosts and inline markers against known app and vendor signatures. This is inference from public evidence, not an installed-app inventory, and the report should say so. What it does reliably surface is two review vendors, two chat widgets, or two analytics tags loading side by side.

  5. Check 17: Core Web Vitals from field data

    Browser needed

    Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift come from real browsers on real devices. Read them from Search Console’s Core Web Vitals report or the Chrome UX Report. A document fetch cannot compute them, and any tool that prints a vitals score from one server-side request is guessing.

Checks 14 through 16 are what App Audit reports for a public storefront: script split, distinct hosts, recognized vendors, and possible category overlap, each with the evidence shown.

Run App Audit

Is the storefront structurally sound?

  1. Check 18: Viewport meta tag present

    Public response

    Every current Shopify theme ships one. It disappears when a layout file is replaced wholesale or a landing-page builder takes over the <head>. Without it, mobile browsers render the desktop layout and scale it down.

  2. Check 19: Language declared on the html element

    Public response

    <html lang="en">, or the correct locale for each market. Screen readers and translation features depend on it, and a store selling in Spanish with lang="en" is a small, silent accessibility fault on every page.

  3. Check 20: Security headers are what you expect

    Public response

    Shopify sets a baseline on hosted storefronts and merchants control little of it directly. The useful question is whether anything changed after a CDN, proxy or headless layer was introduced: a missing Content Security Policy or Strict-Transport-Security header on a store that used to send one is a real finding.

  4. Check 21: Core templates return 200 and render the right thing

    Public response

    Fetch one collection, one product, one page, one blog post, the search page and a deliberately wrong URL. The first five should return 200 with the expected template; the last should return a real 404, not a 200 with “not found” text. This needs more than a homepage fetch, so do it by hand or with a crawler you trust.

What only admin access can confirm

Anyone who tells you a public scan covered these is overstating what it saw. They matter, and they need someone logged in.

  1. Check 22: Theme version, unpublished copies, and who edited what

    Admin or theme access

    How far behind the theme vendor’s current release is the live theme? How many unpublished copies exist, and is anyone sure which one is the backup? The theme library and its edit history are visible only in the admin.

  2. Check 23: App embeds switched on versus apps actually in use

    Admin or theme access

    The theme editor lists every app embed and whether it is enabled. Cross-check that list against the apps the team still uses. Public evidence can show an embed’s script loading; only the admin shows the toggle and the subscription behind it.

  3. Check 24: URL redirect table health

    Admin or theme access

    Shopify’s URL redirects only fire for paths that do not otherwise resolve, and the table accumulates entries for years. Export it, look for chains and loops, and confirm the redirects from the last migration still point at live pages.

  4. Check 25: Search Console coverage and the Shopify web performance report

    Admin or theme access

    Indexing status, crawl errors, and field vitals live in Search Console. Shopify’s own performance reporting lives in the admin. Both are first-party and both are more authoritative than any external tool for the questions they answer.

Turning findings into a decision

A list of 25 results is not a plan. Sort every finding into one of three piles before anyone opens the theme editor.

  • Blocks. A noindex on a live template, a sitemap on the wrong domain, a redirect loop, a robots rule that hides collections. Fix these first and fix them alone, so the effect is measurable.
  • Drag. Script count, host count, vendor overlap, oversized HTML, missing canonicals on secondary URLs. These cost a little on every page view and they compound. Schedule them as a batch with a baseline captured first.
  • Drift. A title that could be better, a description that reads like a feed, a header that is technically fine. Log them; do not let them crowd out the first two piles.

Before changing anything

Confirm which template the finding lives in, capture a baseline of the metric you expect to move, know who owns the code that will change, and have a rollback that takes minutes rather than a support ticket. Public evidence is grounds for investigation, not permission to edit a production theme.

What Store Check covers

Store Check is a bounded, read-only version of the public part of this checklist. It requests three things from a storefront: the homepage HTML, /robots.txt and /sitemap.xml. From those responses it reports on HTTPS, status and redirects, title, description, canonical, viewport, language, robots rules, sitemap availability, a Content Security Policy header, HTML size, script inventory, distinct hosts, recognized vendors, time to first byte at the moment of the scan, and whether the storefront presents as Shopify at all.

It does not execute JavaScript, crawl beyond those three requests, compute Core Web Vitals, or see anything in the admin. Every finding is labelled as observed, measured or inferred, ships with the evidence it came from, and is scored by a versioned engine so a report from last quarter still means what it meant then.