Shopify Product Page Optimization: The 95% You Never Scroll To
Key takeaways
- Across 23 real Shopify storefronts (14,479 product pages), 8,751 pages tripped at least one of three very low bars: description under 200 characters, fewer than two images, or no product type set.
- 8,337 of those 8,751 — 95.3% — sit on page 3 or deeper of the store's own collection. Per-store median: 87.6% (22 stores).
- The cause is catalogue volume, not page depth. In stores with 20+ collection pages, page 1 holds a median of 1.1% of the catalogue. We tested "deep pages are worse" store by store and our own data killed it.
- So "optimizing your product pages" is, in practice, an argument about coverage: what share of the catalogue gets looked at, and how often.
Coverage is the whole argument
Arvio reads your live catalogue every night, ranks what is costing you the most, and drafts the actual edit for each product. Nothing is written until you approve it.
The 30-second version: run the same three checks on your own store
This is read-only. No login, no app install, nothing written anywhere. Save it as audit_catalog.py:
#!/usr/bin/env python3
import json, re, sys, urllib.request
shop = sys.argv[1].rstrip("/") # https://yourstore.com
handle = sys.argv[2] if len(sys.argv) > 2 else "all" # collection handle
per_page = int(sys.argv[3]) if len(sys.argv) > 3 else 24 # products per page on YOUR collection page
def text(html): return re.sub(r"<[^>]+>", " ", html or "").strip()
products, page = [], 1
while page <= 20: # 20 x 250 = 5,000 products
url = f"{shop}/collections/{handle}/products.json?limit=250&page={page}"
req = urllib.request.Request(url, headers={"User-Agent": "catalog-audit"})
batch = json.load(urllib.request.urlopen(req)).get("products", [])
if not batch: break
products += batch; page += 1
bad = []
for i, p in enumerate(products):
flags = []
if len(text(p.get("body_html"))) < 200: flags.append("thin_desc")
if len(p.get("images") or []) < 2: flags.append("<2_images")
if not (p.get("product_type") or "").strip(): flags.append("no_type")
if flags: bad.append((i // per_page + 1, p["handle"], ",".join(flags)))
deep = [b for b in bad if b[0] >= 3]
n = max(len(products), 1)
print(f"products {len(products)} ({-(-len(products)//per_page)} pages at {per_page}/page)")
print(f"tripped >=1 check {len(bad)} ({100*len(bad)/n:.1f}%)")
print(f"...of those, page 3+ {len(deep)} ({100*len(deep)/max(len(bad),1):.1f}% of your problem pages)")
for pg, h, f in bad[:10]: print(f" page {pg:>3} {h[:44]:<44} {f}")
Run it:
python3 audit_catalog.py https://yourstore.com all 24
Two things to get right before you trust the page numbers:
- The third argument is your real products-per-page count, not a guess. Open page 1 of that collection in a browser and count the product cards. Across our sample this ranged from 12 to 37 per page — that one number moves every "which page is this on" answer, which is why we read it out of each store's own collection HTML instead of assuming a default.
- The script stops at 5,000 products. Our audit stopped at 2,000 per store, which matters below.
It prints three lines and the first ten offenders:
products <n> (<n> pages at <n>/page)
tripped >=1 check <n> (<n>% )
...of those, page 3+ <n> (<n>% of your problem pages)
The rest of this post is what those three lines looked like across 23 stores that are not ours, and what we got wrong on the way.
What we measured, and what we could not
Sample. 60 Shopify storefronts. The list of 60 was drawn on 2026-08-26; every catalogue in this study was re-read fresh on 2026-09-10, the day it was analysed. All data comes from each store's public /products.json and its collection page HTML. None of these are our own stores or our customers' stores, and we have no relationship with any of them — which also means we could not verify anything that isn't publicly readable.
Exclusion rule. A store only enters the analysis if its largest collection runs to at least 3 pages — otherwise there is no "page 3 or deeper" bucket and the store cannot answer the question. That dropped 37 of 60: 31 too shallow, 3 with an empty collection, 2 that errored, 1 where the per-page count could not be read. 23 storefronts, 14,479 products remained. The per-store figures below are computed over 22 of those 23: one store is absent from the paired computation and we could not reconstruct which, so we report the smaller number rather than rounding it up.
The three checks, each deliberately set at a floor rather than at "good":
| Check | Threshold | Why this bar |
|---|---|---|
| Thin description | plain-text body under 200 characters | Roughly two sentences. Below this there is nothing on the page to read |
| Too few images | fewer than 2 | One image means no second angle, no scale shot, no detail |
| No product type | field empty | It's the field your collections, filters, and product feeds hang off |
A page counts as a problem page if it trips any one of the three.
Position. Rank is the product's position in the store's own collection order — the order a shopper pages through — and "which page" uses the real per-page count from that store's collection HTML.
Truncation. Four stores were cut off at 2,000 products. The part that got cut is the deep end, so those four contribute all of their page-1 products and only some of their deep ones. 95.3% is therefore a lower bound, not a point estimate.
Not measured: image alt text and the SEO title tag. /products.json does not expose either field, so we have no data on them and this post makes no claim about them in either direction.
Conflict of interest. We make a Shopify agent. The finding below is the argument for a category of tool we happen to sell, The numbers here are ours; what you can reproduce is the method — the script above runs the same three checks on any stores you pick.
8,337 of 8,751 problem pages sit past page 3
| Count | Share | |
|---|---|---|
| Product pages analysed | 14,479 | — |
| Tripped at least one check | 8,751 | 60.4% of all pages |
| ...of those, on page 3 or deeper | 8,337 | 95.3% of problem pages |
| Per-store median (22 stores) | — | 87.6% |
Two readings of that 60.4% are both true and worth separating. One: three out of five product pages in this sample fail a bar that is genuinely low. Two: these are floors, not standards — a page with a 210-character description and two images passes every check here and can still be a bad page. We chose bars we could measure identically across 23 strangers' stores, which is the same reason they are blunt.
The mechanism is catalogue volume, not page depth
Here is the article we expected to write: products get worse the deeper they sit, because merchants set up the first page carefully and lose steam. It is intuitive, and the aggregate numbers appeared to support it.
Then we compared each store against itself — its own page 1 versus its own page 3+ — and the effect vanished:
| Check | Deep worse | Deep better | Tied | Median difference |
|---|---|---|---|---|
| Empty description | 6 stores | 1 | 15 | +0.0pp |
| Thin description | 10 | 8 | 4 | +0.0pp |
| No product type | 7 | 6 | 9 | +0.0pp |
| Fewer than 2 images | 11 | 4 | 7 | +0.07pp |
Empty description is the zero-character subset of thin description, reported on its own line because it is the case with nothing on the page at all — the three checks are still three.
Ten stores worse, eight better, four tied is not a pattern. Deep pages in these catalogues are not systematically worse than the shallow pages in the same store.
The 95.3% is arithmetic. In the stores with 20 or more collection pages, page 1 is a rounding error:
| Catalogue size | Products/page | Pages | Page 1 as share of catalogue |
|---|---|---|---|
| 2,000 * | 12 | 167 | 0.6% |
| 1,508 | 12 | 126 | 0.8% |
| 2,000 * | 20 | 100 | 1.0% |
| 1,576 | 16 | 99 | 1.0% |
| 2,000 * | 24 | 84 | 1.2% |
| 2,000 * | 37 | 55 | 1.9% |
| 601 | 25 | 25 | 4.2% |
| 395 | 17 | 24 | 4.3% |
* = truncated at 2,000; the true catalogue is larger and the true page-1 share is smaller still. Median across these eight: 1.1%.
Your catalogue is roughly uniformly mediocre. It just happens that around 99% of it sits past page 1, where nobody scrolls — including you. That 99% is a share of all pages; the 95.3% above is a share of the problem pages. Two different counts.
That reframes the job. The question stops being how do I optimize a product page (you already know: write the description, add the second image, set the type) and becomes what walks all 1,576 of them.
Method 1: the Shopify admin, one product at a time
This is the version that cannot be wrong about the page, because you are looking at the actual page while you write. For a store in the shallow half of our sample — one or two collection pages — this is not just adequate, it's the correct answer, and you should close this post and go do it.
It stops for a reason that has nothing to do with quality. At 99 pages, "I'll do a few every evening" is a plan with an end date measured in seasons, and the pages you edited in week one are not the pages your catalogue looked like by week nine.
Method 2: CSV export and re-import
Export, edit in a spreadsheet, re-import. This is the right shape when you already know the value you want in a column — a supplier's product types, a batch of vendor names, tags you can derive from the handle.
It is the wrong shape for descriptions, because the spreadsheet doesn't know anything about the product. You still have to write every one of those descriptions yourself, and a spreadsheet full of near-identical descriptions is worse than a thin one.
One thing to verify before you trust a round trip: export a collection, change exactly one product, re-import, and diff the result against what you exported. You want to see for yourself which columns a re-import writes and which it leaves alone, on your store, before you do it to 1,500 products.
Method 3: something that covers the whole catalogue, nightly
If the problem is coverage, the tool has to visit every product — including the ones you have never opened.
That is the shape Arvio takes. It's an AI store agent: it scans your store daily, ranks the gaps by what it estimates each one is costing you — a ranking that runs on your own store's data, which a public-catalogue study like this one cannot see — and then writes the actual edits against your live catalogue — the description, the missing product type — and holds each one for your approval. Nothing changes until you approve it, and every edit can be undone. It reads across Shopify plus connected tools like Klaviyo and Google Ads, so the ranking isn't blind to what's happening outside the product page.
A list is not a fix: an audit tool that hands you a list of problem pages has not written a single description. The list was never the hard part — you could have generated it in this post's first section, in 30 seconds, for nothing.
Arvio also isn't a bulk editor with AI bolted on. Bulk editing is one of the things it can do once it knows what's wrong; it is not the reason it exists.
Across the 23 stores we read, 95.3% of the problem pages sat past page 3, at a per-store median of 87.6%. Your own split will be its own number. The point of a nightly pass is that the far end of the catalogue gets the same attention as the first screen, without you having to remember it exists.
Five ways this goes wrong
- Optimizing what you can see. Page 1 is a median 1.1% of a deep catalogue. A page-1 sweep is a real improvement to 1.1% of your product pages.
- Fixing by template. Hundreds of pages carrying the same rewritten paragraph with the product name swapped in clears our thin-description check and helps nobody. The check is a floor; passing it is not the goal.
- Counting edits instead of coverage. "1,200 products updated this month" doesn't say whether the same 1,200 got updated four times. Measure the share of the catalogue that was looked at, and when it was last looked at.
- Auditing again instead of fixing. A second audit produces a second list. The gap between "we know" and "it's written" is the entire job.
- Trusting a spot check. Our own aggregate buckets pointed confidently at a depth effect that does not exist — 80% of the deep-page sample came from six large stores, so we were reading store mix and calling it depth. Compare a store against itself before you believe a pattern.
When a nightly agent is the wrong tool for you
- Your catalogue is small. 31 of the 60 storefronts we sampled didn't have three collection pages. If that's you, an afternoon in the admin beats any tool, and you'll write better copy than any of them.
- Every word needs legal or clinical review. If each change has to be signed off by a human specialist, an approval queue that fills up nightly is a new bottleneck, not a saved afternoon.
- You already know the exact values you want. Bulk price changes, a tag migration, a vendor rename — that's a spreadsheet operation. Use a bulk editor; it's the right tool and it's cheaper.
FAQ
What counts as an optimized Shopify product page?
There's no single definition, so for this study we used three floors we could check identically across 23 strangers' stores: a description over 200 plain-text characters, at least two images, and a product type set. 60.4% of the 14,479 pages we looked at failed at least one. Clearing all three doesn't make a page good; failing one means something is definitely missing.
How many images should a Shopify product have?
We only tested the floor of two, and we did not measure what number performs best — that would need conversion data we don't have for other people's stores. What the data shows is how common the floor failure is, not the optimum.
How long should a Shopify product description be?
We used 200 characters as the line between "thin" and "has something on it," which is roughly two sentences. Treat it as a smoke alarm, not a target. We did not test description length against any outcome.
Does the product type field actually matter?
We measured whether it's filled, and nothing else. It's the field collections, filters, and product feeds are built on, so an empty one has downstream effects inside your own store — but we have no data here on what it does to traffic.
Are older or deeper products worse than the ones on page 1?
We tested exactly this, store by store, and found no systematic difference: across 22 stores the median gap between page 1 and page 3+ was 0.0pp on three of the four rows above, and the direction disagreed store to store. The reason most problem pages are deep is that most pages are deep.
Will fixing these pages improve my search rankings?
We can't tell you that, and anyone who does from a catalogue audit is guessing. This study measured the state of 14,479 product pages and where they sit. It measured no outcome — no rankings, no traffic, no revenue.
Can I run this on a competitor's store?
Yes. /products.json is a public read-only endpoint — that's how we read 60 storefronts without an account on any of them. Be considerate about request volume, and note that the two fields people most want to compare, alt text and the SEO title tag, aren't in it.
How long does it take to fix a catalogue at this scale by hand?
We didn't measure a per-page time, so any number here would be invented. The ratio is the more useful figure: at a median 1.1% of the catalogue on page 1, a manual pass over the products you actually look at leaves roughly 99 out of 100 untouched.
Arvio: AI Store Operator — install it on the Shopify App Store. It visits every product in the catalogue rather than the ones on page 1, and drafts the missing description or product type for each one for you to approve. From $9.90/mo, with a 5-day free trial.
Sample of 60 public Shopify storefronts drawn 2026-08-26; every catalogue re-read fresh, analysed and published 2026-09-10. Sample, exclusion rules, thresholds and truncation are described in full in "What we measured, and what we could not" above. Last updated: 2026-09-10.