How I Would Audit 20 Shopify Product Pages: UX Mistakes That Could Cost Sales
Disclosure, and a change of title: I set out to write "I Audited 20 Shopify Product Pages". I did not finish that audit, so I am not going to claim it. When I tried to collect a set of live product pages, most of the storefronts I tried answered automated requests with rate-limit responses (HTTP 429). I chose not to work around that. I also had no way to run mobile device checks, screen-reader passes or real-user performance tests on 20 stores, and I have no analytics from any store to draw on. So this article reports no findings from 20 stores, no counts and no revenue effects. What it does offer is the method I would use: what to inspect on each page, what a fix usually looks like, and how to check that the fix helped.
Disclosure, and a change of title: I set out to write "I Audited 20 Shopify Product Pages". I did not finish that audit, so I am not going to claim it. When I tried to collect a set of live product pages, most of the storefronts I tried answered automated requests with rate-limit responses (HTTP 429). I chose not to work around that. I also had no way to run mobile device checks, screen-reader passes or real-user performance tests on 20 stores, and I have no analytics from any store to draw on. So this article reports no findings from 20 stores, no counts and no revenue effects. What it does offer is the method I would use: what to inspect on each page, what a fix usually looks like, and how to check that the fix helped.
That makes this a different article from my broader post on 12 Shopify design mistakes. That one walks the whole store. This one stays on a single template, the product page, and treats it as something you inspect against evidence.
How I would scope the audit
Twenty pages is enough to see patterns, but only if they are chosen on purpose. I would take pages from one store (best sellers, a long-tail product, a product with many variants, a product that is often out of stock) or, for a market study, from public stores with a spread of categories. For each page I would write down the URL, the date, the device and browser, and whether I observed the issue directly or am inferring it.
That last distinction matters most. A claim like "the size chart is hidden behind a tab" is something you can see. A claim like "this is costing sales" needs analytics, session recordings or an experiment, and a page inspection alone cannot supply it. I would keep three columns in the working sheet: observed, inferred and measured, and keep the headline findings to the first and third.
| Evidence type | Example | What I can say |
|---|---|---|
| Observed | Delivery cost is only shown at checkout | This page does not show it |
| Inferred | That may make shoppers hesitate | A hypothesis to test |
| Measured | Cart starts changed after the fix | Only with data and a fair comparison |
Below are the nine areas I would check on every page. For each, I note the friction, a concrete improvement and how I would validate it.
1. Unclear product value and purchase information
The friction: a shopper lands on a page and cannot quickly tell what the product is, what it costs in total, or what they get in the box. Vague titles, a price with no context (per unit, per month, before tax) and descriptions that open with brand storytelling all push the answer further down.
The improvement: put a plain product name, the price, a one-line description of what it is for and the main purchase condition (size, subscription, shipping region) near the top. Move the brand story lower.
How I would validate it: a five-second test with a handful of people who have not seen the store: ask what it is, who it is for and what it costs. If answers differ from what you intended, the page is unclear. This is qualitative, so I would treat it as a diagnostic, not a result.
2. Photography that does not answer questions
The friction: every image is a styled hero shot on a clean background. There is no scale reference, no close-up of material or stitching, no image of the back or the inside, and no image showing the product in use. Shoppers cannot touch the product, so images carry that job.
The improvement: plan the gallery around the questions people ask: how big is it, what is it made of, how does it open or fit. Add at least one scale shot, one detail shot and one in-use shot, and write alt text that describes what each image shows. If the product comes in several colours, make sure the gallery changes with the selected variant.
How I would validate it: read the support inbox and pre-sale questions for repeated queries that a photo could answer. After changing the gallery, watch whether those questions drop. That is a support signal, not a conversion claim.
3. Variants and unavailable combinations
The friction: colour and size selectors that look similar in every state, no clear sign of which option is selected, and unavailable combinations that only reveal themselves when the button changes to "Sold out" or when nothing happens at all. A shopper who picks the wrong pair has to guess how to recover.
The improvement: show the selected value in text next to the label, mark unavailable options visibly and with text (not colour alone), and say what to do next, for example offering a back-in-stock notification for that exact combination. For themes that need changes here, this is a template-level job, the sort of thing covered by Shopify theme customization.
How I would validate it: on each page, try every combination with the keyboard and with a phone in portrait. Record which states are confusing. Then recheck after the change; no analytics needed to confirm the states now behave.
4. Hidden delivery costs, timelines and returns
The friction: shipping cost, delivery window and the returns policy sit on separate policy pages or appear only at checkout. Shoppers who care about those answers either leave to look or add to cart and hope.
The improvement: a short block near the buy button that states the delivery estimate for the shopper's region, the shipping cost or threshold, and the returns window in one or two lines, linking to the full policy. Only state what the store actually does, and keep it in sync with the policy page.
How I would validate it: compare what the product page says to what checkout and the policy page say. Any mismatch is a finding by itself, since it affects trust. If analytics exist, I would look at cart-to-checkout drop-off before and after, with the caveat that other changes during the same period can also move it.
5. Weak specifications and sizing guidance
The friction: specifications are a paragraph of marketing copy, dimensions are missing, and the size chart is an image that cannot be read on a small screen. Returns for the wrong size are a cost to the store and the shopper alike.
The improvement: use a short list or table for dimensions, materials, weight and care, using units the audience expects (and both when serving more than one market). Make sizing guidance real text with a note on how to measure, placed next to the size selector, not on a separate page.
How I would validate it: ask someone to complete a fit task using only the page, for example "which size would you order for a 40 cm laptop?". Where they cannot answer, the specification has a gap. For stores with return reasons recorded, I would also review whether "wrong size" returns change over time.
6. Review context and misleading trust cues
The friction: a star average with no count, reviews that cannot be filtered by variant or by recency, badges such as "bestseller" or "as seen in" with nothing behind them, and review widgets that load late and shift the layout.
The improvement: show the number of reviews next to the rating, let shoppers read the lower ratings, and surface the details that help a decision (size bought, use case). Only show trust claims you can substantiate. The US Federal Trade Commission has a rule on consumer reviews and testimonials (16 CFR Part 465), and Google's guidance on review snippet markup says marked-up reviews must be visible on the page and must not be fabricated or undisclosed incentivised ones. If you add structured data, follow Google's product structured data documentation and mark up only what is on the page. I am not a lawyer; check what applies to your business.
How I would validate it: read the lowest-rated reviews as a shopper would, and check whether the displayed average and count match the widget's own data. Then check the page for layout shift when the reviews load.
7. Mobile purchase controls, overlays and sticky bars
The friction: on a phone, the add-to-cart button sits far below long text, a newsletter or discount overlay appears before the shopper has seen the product, and a sticky bar covers the footer or hides whatever has keyboard focus. Small tap targets make selecting a size or quantity error-prone.
The improvement: keep the primary purchase controls reachable without long scrolling, delay or remove entry overlays on product pages, and make sure any sticky bar leaves focused elements visible. WCAG 2.2 asks that a focused component is not entirely hidden by author-created content (Success Criterion 2.4.11, level AA) and that pointer targets are at least 24 by 24 CSS pixels unless an exception applies (2.5.8, level AA). Good hierarchy on small screens is the kind of problem a Shopify UI/UX design review is meant to catch.
How I would validate it: test on at least one real iPhone and one real Android phone, in portrait, with the keyboard open and closed. Tab through the page with an external keyboard and note any focus that disappears behind the bar. I could not do this for 20 stores, which is one more reason I am not reporting an audit.
8. Accessibility and error recovery
The friction: form controls without labels, quantity fields that accept nonsense, error messages that only change a border colour, and an "Add to cart" button that gives no feedback. A shopper using a screen reader or just a bad connection cannot tell whether the action worked.
The improvement: every control gets a programmatic label, errors are written in text and tied to the field, and adding to cart is confirmed in a way that is announced as well as seen. WCAG's Error Identification criterion (3.3.1) asks that automatically detected input errors are identified and described in text.
How I would validate it: run an automated checker to catch the obvious cases, then walk the purchase path with a keyboard and a screen reader. Automated tools find only part of the problems, so I would not claim a page "passes" on a scan alone.
9. Performance and widget overload
The friction: several apps each add a script and a block: reviews, upsells, size guides, popups, loyalty, chat. The main product image then competes with them for bandwidth, and widgets that inject late push the page around.
The improvement: list every script on the page, keep the ones that earn their place and remove or defer the rest. Shopify's theme performance best practices recommend auditing third-party scripts, avoiding lazy-loading the largest above-the-fold image, and reserving space for injected content to prevent layout shift. Google's Core Web Vitals guidance describes a good experience as Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, assessed at the 75th percentile of real page loads. For diagnosing a slow main image, see how to optimise LCP. Work like this usually sits with Shopify performance and SEO optimization.
How I would validate it: lab tools are useful for finding causes, but the thresholds above are about real-user data, so I would check field data where the store has enough traffic, and use lab runs only to compare before and after. A lab score on its own is not proof of what shoppers experienced.
A prioritized checklist
If I had one afternoon per product page, this is the order I would work in. It ranks by how much a problem can block a purchase or break trust, not by how often I have seen it, because I have no occurrence counts to offer.
- Can the shopper buy? Variants work in every combination, unavailable states are explained, and add to cart gives clear feedback.
- Is the offer complete? Price, delivery estimate and returns terms are visible near the button and match the policy and checkout.
- Do keyboard and phone users get through? Sticky bars and overlays do not hide focus or content, and targets are large enough.
- Are the product facts usable? Specifications and sizing are text, not images, and answer the questions in your support inbox.
- Can the trust cues be defended? Review counts, badges and any structured data reflect real, visible content.
- Do the images answer questions? Scale, detail and in-use shots exist, with accurate alt text.
- Is the page light enough? Every app script justified, the main image prioritised and layout shift controlled.
Log each finding with its evidence type from the table above. Fix the first three before polishing anything else.
Where I would be careful
Three limits apply to everything here. Page inspection finds friction; it does not prove lost sales. Findings on one theme and catalogue do not transfer automatically to another. And a fix can introduce a new problem, so each change should be checked on its own, ideally one at a time, so you know which change did what. A sensible way to confirm impact is a controlled test or a before-and-after comparison that accounts for seasonality, and the planning for that belongs with Shopify CRO work.
Want this done on your store?
If you would like a product-page review run this way, with each finding labelled as observed, inferred or measured and a short, ranked list of fixes, you can get in touch and tell me which products and devices matter most to your shoppers.
