Audit my store

Checks you can run on a Shopify store — including one somebody else built.

Every check names a failure, gives you the steps to run it yourself, and says where it is blind. They are meant to be used on other people's work.

This page is built to Verify it yourself

I didn't write this to publish it. I wrote it because I shipped a store once that passed everything I checked, and broke two weeks later on something I hadn't thought to check — and I realised "I'll remember" is not a process.

So it went on paper. The things a build has to clear before it goes out. It has been in use for years, it predates this website by a long way, and until now it has been an internal document — the thing I run against my own work, not the thing I show clients.

It's published now for a straightforward reason: you have no way to tell a good Shopify build from a bad one by looking at it. Nobody does — that's the actual problem with this market, not that developers are dishonest. So rather than tell you I'm careful, here is the thing I'm careful with. Run it against me. Run it against whoever else you're talking to.

The checks

You can evaluate a Shopify developer's work without being able to read code. Open the store on your phone and run it through PageSpeed Insights; open the theme customizer and try to change a heading; ask what the performance budget is and whether the answer is a number. A developer who runs checks can tell you what they are; a developer who doesn't will tell you they're thorough. These are the checks I run before anything of mine ships — written here as things you can run on anyone, including me, and including whoever built the store you have now.

Run these now

Nothing but your phone and a free tool. No admin login, no developer, no permission from anyone.

A performance target that holds as content grows

Whether the store is fast on the pages that carry real content, measured in numbers rather than impressions.

What it catches

A store benchmarked on launch day, on a homepage with four products and no apps, tells you nothing. Performance failures arrive with the catalogue: the collection page with 200 products, the product page with a review widget and a size chart and an upsell block. If nobody set a budget, there is nothing holding the line — and every added feature spends from an account no one is tracking. The cost is not abstract. It is the conversion rate six months from now, and nobody will attribute it to the build.

How to check it yourself
  1. Open PageSpeed Insights and run three pages, not one — your homepage, your busiest collection page, and a product page with its reviews and upsells live. They fail differently, and the collection page usually fails worst.
  2. Read the mobile number first. Desktop flatters everything.
  3. If the report shows field data from real visitors, trust it over the lab score — that is what your customers actually got, over the last 28 days.
  4. Write down three numbers per page. Largest Contentful Paint — under 2.5s; how long until the main thing appears. Interaction to Next Paint — under 200ms; how long until a tap does something. Cumulative Layout Shift — under 0.1; whether the page moves under your thumb while it loads.
  5. Then ask one question: what is the performance budget for this store, and what happens when a new app breaks it? An answer that is a number is a build with a budget. An answer that is a reassurance is not.

Measured against Core Web Vitals thresholds

What it misses

A score is one page on one run. It cannot separate what the developer built from what apps did afterwards — a fast theme with four heavy apps reads as a slow store, and the theme may not be at fault. It also says nothing about perceived speed, which is what the visitor experiences, and nothing about whether a number that is fine today survives the next campaign.

WCAG 2.1 AA, verified — not intended

Whether accessibility is a measured state or a stated value.

What it catches

Accessibility described as a value rather than a state. “We follow best practices” is not a conformance claim, and the difference is legally and practically real — a store that cannot be used with a keyboard excludes people who would have bought.

How to check it yourself
  1. Run the store through WAVE or Lighthouse's accessibility audit.
  2. Then do the part tools cannot: put the mouse away and tab through a product page to the cart. If you cannot reach the add-to-cart button, or cannot see which element is focused, that is a failure you found in ninety seconds.
  3. Check colour contrast on your own phone, in daylight.

Measured against WCAG 2.1 AA

What it misses

Automated tools catch roughly a third of WCAG failures. They cannot tell you whether alt text is accurate, whether the reading order makes sense, or whether a screen-reader user can complete a checkout. A store can pass every automated check and still be unusable with assistive technology.

Documentation your team can actually use

Whether the handover is a document or a phone number.

What it catches

The handover that is a zip file and a phone number. Six months on, the person who built it has moved on and nobody knows why the collection template has a conditional in it.

How to check it yourself
  1. Ask for the handover document before you sign, not after.
  2. Read the first page: does it explain how to do the three things you will actually need — add a section, change a setting, deploy a change?
  3. Documentation written for the next developer is a different document from documentation written for you, and you need both. A README that only lists build commands is for them, not you.
What it misses

Whether the documentation is accurate. Nobody re-reads their own handover doc after the third revision to the theme, and drift is invisible until you follow a step that no longer works.

A QA phase with a checklist, not a click-around

Whether testing is a defined stage or an afternoon.

What it catches

Undefined QA means the bugs get found by customers. The pattern is consistent: desktop Chrome works, and the failures live where nobody looked — Safari on an older iPhone, the form with a validation error, the collection page at 200 products.

How to check it yourself
  1. Ask to see the QA checklist. Not whether one exists — ask to see it.
  2. A real one is specific and boring: named devices, named browsers, named paths. If what comes back is a paragraph about attention to detail, there is no checklist.
  3. Check whether it is run before launch or after the client complains, and who signs it off.
What it misses

A checklist can be thorough and still be run carelessly. It is evidence of a process, not proof it was followed — which is why the checks that follow are things you verify on the store itself rather than on the document.

A defined first month after handover

Whether the riskiest thirty days are scoped or improvised.

What it catches

The gap between launch and steady state is where projects go wrong, and it is almost never scoped. Launch reveals things: a bug in a browser nobody tested, a question about the admin, an app conflict that only appears with real traffic. If nobody agreed who handles that, it gets handled by whoever you call — and whether that is free is discovered at the worst moment.

How to check it yourself
  1. Ask what happens in the thirty days after launch, and get the answer in writing before you sign.
  2. Three specifics: what is covered, what is not, and what a bug costs if it turns out to be yours rather than theirs.
  3. A defined period with a stated boundary is worth more than an open-ended promise of goodwill.
What it misses

It says nothing about what happens in month four. A defined first month is a floor under the riskiest period, not a support contract — and if you need one of those, that is a separate conversation.

A store you can change in six months without me

Whether the exit exists, whether or not you use it.

What it catches

The build that is excellent and captive. Custom work that only its author can maintain is a business risk wearing a quality badge, and it is the failure that takes longest to surface — you do not discover it until you need someone else.

How to check it yourself
  1. Ask a direct question: if I hired a different developer tomorrow, what would they need, and how long before they could ship a change?
  2. Then check the answer is true — is the code in a repository you own? Are the deployment credentials yours? Is the theme in version control, or is it edits made live in the admin?
  3. You are checking whether the exit exists, not whether you will use it.
What it misses

It cannot measure how hard the code is to pick up, only whether the artefacts exist. A repository you own can still contain a theme nobody wants to inherit.

Checkout, end to end

Whether the checkout completes, not merely renders.

What it catches

The gap between a checkout that renders and a checkout that completes. Discount codes, shipping calculation, address validation, payment, the confirmation email, the order arriving where it should.

How to check it yourself
  1. Buy something. Actually buy it — put a real product in the cart, apply a discount code, use a real address, complete the payment, and check the confirmation email arrives.
  2. Do it again on your phone, and once more with the back button halfway through. Broken back-navigation on a cart is one of the most common untested paths.
  3. If the store has multiple shipping zones or payment methods, test more than one.
What it misses

One purchase on one path. It cannot tell you what happens at volume, or on a payment method you did not test, or when an app that touches the cart updates next month.

This check needs a live store — this page cannot demonstrate it.

The conversion paths, walked

Whether the paths that carry money were walked or assumed.

What it catches

The failure with the most direct line to revenue, and the one most often misdiagnosed. Every path that carries money — search to product, collection to cart, cart to checkout, the mobile menu, the size guide that opens over the buy button — walked deliberately rather than assumed. A break here reads in analytics as a drop-off, which gets blamed on traffic quality for months.

How to check it yourself
  1. Walk the three paths a customer actually takes, on your phone, as though you had never seen the store.
  2. Search for a product using the word a customer would use, not the one in your catalogue. If it returns nothing, that is revenue.
  3. Add to cart from a collection page rather than a product page. Then hit back.
  4. Open your analytics, find the step with the biggest drop, and walk that one slowly. What you find is usually mechanical, not persuasive.
What it misses

It finds broken paths, not unpersuasive ones. A checkout that works perfectly and asks for an account before it asks for an email is not broken — it is just costing you money, and this check will not flag it.

This check needs a live store — this page cannot demonstrate it.

The browsers your customers actually use

Whether the tested browsers match the ones in your analytics.

What it catches

The gap between the browsers a developer uses and the ones in your analytics. Older Safari versions, in-app browsers inside Instagram and TikTok, and whatever the long tail of your audience turns out to be. A shopper arriving from a paid social post is often in a browser nobody tested — on the traffic you paid the most for.

How to check it yourself
  1. Open your analytics and find the browser and device breakdown. Take the top five, and anything above 2%.
  2. Then check the store on the ones you do not personally use — and specifically, open the store from a link inside Instagram rather than in Safari, because that is a different browser with different rules.
  3. Ask the developer for their tested list and compare the two.
What it misses

Analytics only show the customers who stayed. A browser where the store is broken shows almost no traffic — which reads as “not worth testing” and is the opposite of the truth.

Needs your Shopify admin

Which you already have, if it is your store. Nothing here needs a developer — only a login.

Structure that survives the next change

Whether the theme can absorb a new section without a developer rewriting a template.

What it catches

The store looks finished and behaves fine — until the first real change. A seasonal landing page, a new product range, a campaign block. If the theme was built as a set of one-off templates rather than reusable sections, every one of those becomes a quote. You'll notice six to nine months after launch, as a rebuild estimate for something that should have taken an afternoon.

How to check it yourself
  1. In Shopify admin, go to Online Store → Themes → Customize.
  2. Pick any page other than the homepage and try Add section. Count what you are offered — two or three, with the rest of the layout fixed, means the page is hardcoded rather than composed.
  3. Try to drag a section above another. If sections cannot reorder, they are not sections.
  4. Look at the section names. home-hero, about-intro — names that bind a block to one page tell you it was built once, for that page.

Measured against Shopify theme architecture — sections and blocks

What it misses

Nothing about whether the structure is right for your business — a theme can be perfectly composable and organised around sections nobody needs. It also cannot see the Liquid underneath. It is a floor, not a verdict.

A merchant who can edit without calling anyone

Whether the person who owns the store can change its content without a developer.

What it catches

Every piece of copy hardcoded into a template is a future invoice. You want to change a heading; the heading lives in Liquid; now it is a job. Multiply by the number of small changes a live store actually needs and you have a maintenance contract nobody agreed to.

How to check it yourself
  1. In Customize, click into a section and open its settings.
  2. Take the three things most likely to change in the next six months — a headline, a promotional message, a button's destination — and change each one from the settings panel. Anything that requires touching code is hardcoded.
  3. Check images the same way. A background image that cannot be swapped from settings will be swapped by a developer, every time.
  4. Then check the opposite failure: are there forty settings on one section? A panel nobody can navigate is as unusable as no panel.
What it misses

Whether you will actually edit it; plenty of well-built stores are never touched by their owners. And it cannot judge whether the settings are labelled in language you understand — a field called section_cta_alt_url is technically editable and practically not.

Every app's cost, decided deliberately

Whether anyone costed the apps before installing them.

What it catches

The store that accumulated eleven apps, each individually defensible, that together add four seconds. Apps are the most common way a fast build becomes a slow store, and the decision to add one is almost never costed.

How to check it yourself
  1. List the apps on the store. For each, ask two questions: what does it do that the theme could not, and what does it cost in load time?
  2. Verify rather than assume — run PageSpeed on a page where the app is active and one where it is not.
  3. If nobody can tell you what an app is for, that is your answer.
  4. Ask the developer what happens when you want to add a fourteenth.
What it misses

It cannot tell you whether the app is worth its cost — a review widget that slows the page by 300ms and lifts conversion by 2% is a good trade, and this check does not do that arithmetic. It only tells you whether anyone did it.

Needs someone who reads theme code

The honest one. This is the check you cannot run alone, and it says so rather than pretending otherwise.

Rendering that doesn't make the shopper wait

Whether Liquid, scripts and third-party code delay the content the shopper actually came for.

What it catches

The page waiting on work the shopper does not need yet, and the shopper waiting with it. It happens on both sides of the request. On the server, Liquid runs before the page reaches the browser — so a section doing expensive work the visitor may never scroll to still delays everything above it, and that is the part most specific to Shopify. In the browser, blocking scripts, app embeds and third-party tags delay the first thing the shopper sees, which is usually the product. A store can be well built everywhere else on this list and still lose the visitor in the first two seconds.

How to check it yourself
  1. The server half you mostly cannot run yourself, and I would rather say so than pretend. Look for the symptom: a store that scores acceptably in PageSpeed and still feels slow in your hand, particularly on the first load of a collection page.
  2. The browser half you can. Open the store in Chrome, press F12, and reload with the Network tab open. Anything loading before the product image that is not your theme is a candidate — app embeds, chat widgets, review scripts, tag managers.
  3. In the same panel, look at what blocks rendering: scripts in the document head with no defer or async are the page waiting on code before it draws anything.
  4. Then ask the developer directly — what runs before the shopper sees the product, and what did you move? An answer that names a specific section or script is a real answer. An answer about best practices is not.
What it misses

The browser half you can see; the server half you cannot. Confirming what Liquid does before the page is sent means reading the theme's code, and that needs someone who can — a real limit on this list, not a modest one. A symptom is also not a confirmation: a good server response time means the evidence is absent, not that the problem is.

This check needs a live store — this page cannot demonstrate it.

What isn't here

Two things are missing from the list above, deliberately.

The thresholds. The list says "a performance target"; it doesn't say what mine is. The numbers I hold builds to are the part I've spent years calibrating, and they're the part that's genuinely mine.

Some of the techniques. How I fix what the checks find — particularly on Liquid and theme architecture — isn't published either.

Why tell you what I'm keeping back? Because a standard that claims to be complete is making a claim you can't verify , and this whole page is an argument against those. The checks are the framework, and the framework is what lets you evaluate anyone. The thresholds only matter once you've hired someone, and by then you can ask.

The two I can't show you here

A developer's marketing site can demonstrate some of a store standard and not all of it. Two of these checks require a live Shopify store with real orders moving through it, and this page is not one — it's a static site, so there's no checkout to test and no Liquid to profile. Here's exactly what that means, and where those two get demonstrated instead.

Checkout, end to end

There's no checkout on this site. Nothing to test, and no honest way to simulate one: a demo store with no traffic, no app stack, no inventory and no six months of someone else's edits is not a store under load. It would look like proof and be a showroom.

Rendering that doesn't make the shopper wait

Liquid is Shopify's templating language. This site doesn't run on Shopify, so there's no Liquid here to block anything. The check is real and it's meaningless on this surface.

Where they do get demonstrated: on client stores, as permissions come through — see below. Until then the honest version of my claim is narrower than it could be: this site meets all of them but those two, measurably and publicly, and I'm telling you which two it doesn't rather than letting "built to the standard" quietly imply the lot.

This page, measured

Largest Contentful Paint
1.95 s
Interaction to Next Paint
0.09 s
Cumulative Layout Shift
0
Lighthouse performance
98 / 100
WCAG 2.1 AA
1 automated failure

Measured on this page, 2026-09-12, with Lighthouse 13.4.1 (median of 3 runs, by LCP). Re-measured on every deploy. The accessibility row is label-content-name-mismatch.

Where these come from. Measured on this page, on the date shown, with the instruments named in the performance and accessibility checks — the same ones you'd use. Not a screenshot: the numbers are read at build time, and if they get worse, they get worse here.

What a failure looks like. If this page stops meeting the thresholds, this section shows it. There is no version of this page where the numbers are hidden because they went the wrong way — that's the whole point of putting them on the surface that makes the claim. A published standard whose author's own site quietly fails it is a self-refuting artifact, and the failure would be visible to you before it was visible to me.

Run it on me

Everything above is written to be run, and most of it doesn't need me. The instruments are free and public:

  • PageSpeed Insights — the performance target, and what the apps cost
  • WAVE — accessibility, the automated third of it
  • Lighthouse — performance and accessibility, in your browser
  • Your own phone — checkout, the conversion paths, and the browsers your customers actually use. For those it's the only instrument that matters
  • Shopify admin — the theme's structure, whether you can edit it, and the app audit, on any store you have access to

Point them at this page. Point them at whoever else you're talking to. If this site fails a check, that's a fact about me you found without asking my permission — which is the arrangement I'd want if I were the one hiring.

The part that's still coming

Two checks need a live store, and the honest place to demonstrate them is on stores I've built for other people. That requires their permission, in writing, and I'm asking for it properly rather than assuming — which is slower than it sounds.

As those land, they appear in the record — scored against the same checks, before and after. Some will be anonymous, because the client permits the work but not the name, and that's their call rather than mine.

What I'm not going to do is fill the gap with a demo store. A store with no traffic, no apps and no history would pass every check and prove nothing, and building one to look like evidence is the kind of thing this page exists to help you catch.

Questions about the list

Why these checks and not others?

Because these are the ones that have cost me or a client something. The list grew by failure, not by design — each one is on there because something went wrong once and I didn't want it to go wrong twice. It isn't exhaustive and I'd be suspicious of anyone who said theirs was. If you're evaluating a developer and they have a different list with reasons behind them, that's a good sign, not a contradiction.

What happens if one of my builds fails a check?

It doesn't ship. That's what having a threshold is for — the point of writing the number down is that it decides rather than advises. If a check fails and the fix is out of scope, the client hears that before launch, not after.

Can I use this to evaluate my current developer?

Yes, and that's the main reason it's published. Nothing on this list requires you to be talking to me. If you run it and everything passes, you have a good developer and now you know why — which is worth more than a second opinion.

Isn't publishing this just marketing?

It's on a website that sells development work, so partly, obviously. The test is whether it's useful when you don't hire me — and the checks above are runnable on any store by anyone, which is either true or it isn't. You'll know within ten minutes.

Do I need to be technical to run these?

For most of them, no. Three need access to Shopify admin, which you have if it's your store — structure, editability, and the app audit. Only render-blocking Liquid genuinely needs someone who can read a theme, and it says so rather than pretending otherwise. Everything else runs on a free tool or your own phone.

What if my developer refuses to answer these?

That's an answer. A developer who runs these checks finds the questions easy — they're describing work they already did. Defensiveness here usually means the check wasn't run, and it's better to find that out now.