Shopify Conversion Audit With Claude Code

What Shopify decides for you

A Shopify conversion audit is not a generic one with the word Shopify added. The platform owns several of the things you would otherwise audit, and knowing which is the difference between useful findings and a list of changes you cannot make.

Shopify owns checkout on every plan below Shopify Plus. It owns the URL structure. It owns the cart endpoints. Apps inject front-end code you did not write and frequently cannot see in your theme. And the theme you are auditing may carry demo content and behaviours from a vendor who never saw your catalogue.

So the audit runs in a different order from a generic one: measurement first, because apps break it; then the parts you control; then a clear statement of what is platform behaviour rather than a defect.

The platform-agnostic version is the conversion audit workflow, and how to build a website with Claude Code covers the decisions that make a store auditable in the first place.

Start with the events, because apps duplicate them

On Shopify this is not a formality. Shopify fires its own analytics. Apps commonly add their own purchase and add_to_cart events. A theme may fire a third from a custom pixel. Nothing warns you.

The symptom is a conversion rate that is exactly half, or exactly double, what it should be — uniformly, so nothing looks anomalous.

List every source of analytics events on this store: Shopify's own,
theme code, custom pixels, and each installed app. For the purchase
and add-to-cart events specifically, identify every place they can
fire.

Then complete one real transaction and report how many times each
event actually fired. Report the observed count, not the intended
one.

Until that number is one, everything downstream is measuring something other than what you think.

The product page

The highest-value page and the one most often audited last. What matters, roughly in order:

• Is the price visible without scrolling on a 375px viewport? Measure it rather than assuming — themes that look fine on a desktop preview routinely push the buy button below the fold on a phone.
• Does the button say what happens? "Add to cart" is honest. A button that adds to cart while saying "Buy now" is not.
• Are variants selectable without ambiguity, and does the price update when they change?
• Is the first image the one that explains the product, rather than the one that happened to upload first?
• Are delivery and refund terms reachable before purchase, not only from the footer? For a digital product this matters more, not less: there is nothing to return, and saying so plainly beforehand prevents the dispute.
• Does the page load its own images at the size it displays them? Shopify's image CDN will serve any size you ask for, including one four times too large.

The cart

Cart problems are usually structural rather than aesthetic:

• Can quantity be changed, and does the total update without a full reload?
• Is there a route back to the catalogue that is not the browser's back button?
• Do discount codes fail with a message that says why?
• Are shipping costs knowable before checkout, or is the first mention on the payment step?

The last one causes more abandonment than any button colour ever has, and on a digital product the fix is a sentence rather than a redesign: say there is no shipping.

Checkout, and what you cannot change

Below Plus, checkout is Shopify's. You can change the branding, the language and which fields are required; you cannot change the flow.

That makes the honest audit finding usually one of these:

• A required field that need not be required. Address collection on a digital-only order is the common one, and it is a setting.
• A payment method visitors expect and cannot find.
• An app inserting itself into the flow with an upsell or a survey.

Anything else about checkout structure belongs in the report as platform behaviour, explicitly labelled, so nobody spends a sprint trying to change it.

Mobile, on a real device

Emulation misses three things that matter commercially: the actual tap target size under a thumb, the keyboard covering the field being typed into, and the real network. Complete a purchase on a phone, on cellular, before writing the mobile section of any report.

Then check the boring measurable things: no horizontal scrolling at 320px, every tap target at least 24 × 24 CSS pixels, and no control that depends on hover.

Trust and the pages nobody reads until they matter

Refund, privacy, terms, contact. Nobody reads them, and their absence is felt anyway. Check they exist, are reachable, say something specific, and do not contradict the product page — stale merchandising copy claiming something the store no longer does is a credibility problem that compounds quietly.

Reading the theme rather than the page

Several conversion problems are visible in the theme source and invisible in the rendered page until conditions align:

• loading="lazy" on the first image in a product loop, which delays the largest paint on every collection page
• image_url without a width, serving the original at whatever size it was uploaded
• A section that renders a fallback only when a field is empty — so it looks correct on every product that has the field, and wrong on the one that does not
• Settings referenced in a template but absent from the section schema, which Shopify silently discards

The Shopify build guide covers the theme workflow these come out of, and the Admin API guide covers scripting the checks so they run on every push rather than when someone remembers.

After the order

For a digital product the post-purchase step is the product. If the download does not arrive, everything upstream was wasted.

The awkward part: a third-party delivery app stores its files privately, and the Admin API generally cannot see whether a file is attached. A product can be active, priced, published and completely undeliverable, and every API-based check will call it healthy. The only proof is a real paid order that gets fulfilled — so place one, and treat any check that claims otherwise as unproven.