August 25, 2026

How much of your Shopify catalogue is unbuyable right now

Key takeaways

We read the public product catalogue of 28 live Shopify storefronts on 25 August 2026 — 29,009 products, 132,681 variants — and counted the products where every variant is unavailable and the product is still published.
The median store carries 3.9% of its catalogue that way. Nine of the 28 carry more than 10%. Twelve carry none at all.
One store carries 4,942 of the first 5,000 products we could read. That single store is why we lead with the median: pool everything together and the number is 23.9%, which describes nobody.
A sold-out product is still a live page. We picked one at random and checked: HTTP 200, "Sold out" on the page, and its URL still sitting in the store's own product sitemap, still being handed to search engines.
You can check your own store in about a minute with one URL and no app installed. The recipe is below, along with the pagination trap that made us understate one catalogue by 13x before we caught it.

Published 25 August 2026 by Adot Technologies Inc, the team behind Arvio. Everything here comes from reading public storefront endpoints on 25 August 2026 with no admin access and no app installed on any of these stores. Sample, exclusion rules and limits in the method section.

The quick version

Open https://yourstore.com/products.json?limit=250 in a browser. That is your published catalogue as anyone can read it.
Every variant carries an available flag. A product where all of them are false is a page a shopper can reach, read, and not buy from.
Count those, then decide whether that number is the one you expected.

What we counted

For each store we fetched the public products endpoint, paged through the whole catalogue, and classified every product:

Class	Definition	Products	Share
Fully unavailable	every variant `available: false`	6,942	23.9%
Partly unavailable	some variants `available: false`	1,449	5.0%
Any unavailability	either of the above	8,391	28.9%

At variant level, 37,547 of 132,681 variants (28.3%) were unavailable.

Those are pooled totals across all 28 stores, which is the wrong way to read them.

Why the average describes nobody

One store in the sample hit our reading limit of 5,000 products, and of those, 4,942 — 98.8% — are entirely out of stock and still published. That one store moves the pooled figure by itself. We are not naming it, or any of the others.

Per store, the distribution looks like this:

	Share of catalogue fully unavailable
Lowest quartile	0.0%
Median	3.9%
Upper quartile	11.8%
Maximum	98.8%

12 of 28 stores have no fully-unavailable published products at all.
16 of 28 have at least one.
9 of 28 are above 10%.
Drop the 98.8% store and the pooled figure falls from 23.9% to 8.3%.

If you take one number from this article, take 3.9%, and take it as "the middle store", not "the typical store". With 28 stores there is no typical.

What "unavailable" does and does not mean

available: false on a variant means Shopify will not sell it right now. That is narrower than it sounds.

It is a floor, not a total. A store that turns on "continue selling when out of stock" keeps available: true on inventory it does not have. Those products are not in our count. Every number here understates the real amount of unbuyable stock.

Not all of it is a mistake. A seasonal line that comes back every October, a pre-order page, a product with an email-me-when-it-returns capture: those are deliberate, and a sold-out page that collects demand is doing a job. What we counted is a number, not a pile of mistakes. Most merchants have simply never had it in front of them.

And you will not see it from the admin. The product list shows inventory product by product as you scroll. Nothing in that view adds it up.

A sold-out product is still a live page

We took the first fully-unavailable product from one store in the sample and followed it through:

The product page returned HTTP 200.
The page rendered, with Sold out on it.
Its URL was listed in the store's product sitemap — the file the store submits to search engines.

None of that is a bug. It is the default, and for a product coming back next month it is the right default. It does mean the page keeps everything a live product page has: it is crawlable, it is in the sitemap, it can rank, and it will take a click from any link that still points at it.

That is the reason to know your own number. A page nobody can buy from still costs whatever you are spending to send people to it.

Check your own catalogue in about a minute

The endpoint is public and read-only. Nothing here writes to your store.

One page: https://yourstore.com/products.json?limit=250

Whole catalogue, counted:

# Pages through the public catalogue and counts fully-unavailable products.
store="yourstore.com"; page=1; total=0; soldout=0
while :; do
  body=$(curl -s "https://$store/products.json?limit=250&page=$page")
  n=$(echo "$body" | python3 -c "import sys,json;print(len(json.load(sys.stdin)['products']))")
  [ "$n" -eq 0 ] && break
  total=$((total+n))
  soldout=$((soldout+$(echo "$body" | python3 -c "
import sys,json
ps=json.load(sys.stdin)['products']
print(sum(1 for p in ps if p['variants'] and all(v.get('available') is False for v in p['variants'])))")))
  page=$((page+1))
done
echo "$soldout of $total products fully unavailable"

The trap we fell into. Our first run of this stopped paging when a page returned fewer than 250 products, which is the obvious way to detect the last page. It is wrong. That endpoint can return a short page and still have more pages behind it — one store reported 238 products to our first version and 3,100 once we fixed it to stop only on an empty page. A 13x undercount, with no error and no warning. If you write your own version of this, stop on zero, never on "fewer than I asked for".

What the endpoint will not tell you. It only returns products published to the online store, so anything unpublished is invisible to it. That is the right answer to "what can a shopper see" and the wrong one for a full inventory report. It gives you availability, not quantities. And it respects the market you are reading from, so a catalogue can read differently from another country.

Variants per product

Across the 28 stores, the median catalogue runs 1.81 variants per product, and 23 of the 28 are above 1. The range is wide: 1.00 at the low end, 39.70 at the high end.

We had measured 1.76 on our own test store before this survey, by counting the rows in its price grid. Two independent samples landing at 1.76 and 1.81 is about as much agreement as small samples ever give you. So: whatever number you have in mind for a catalogue job, the number of things to touch is roughly 1.8x larger. For one store in this sample it was nearly 40x.

What to do with the number once you have it

There is no single right answer, and which one is yours depends on things this measurement cannot see. Four options, with what each costs:

Option	What it does	What it costs
Leave it up	Keeps the URL, the rankings, the reviews and the back-in-stock capture	Every click you are still paying for lands on something unbuyable
Leave it up, but stop paying to reach it	Keeps the page's earned traffic, cuts the bought traffic	Requires knowing which campaigns and flows still point at it, which no inventory report tells you
Unpublish	Removes it from the storefront	The URL stops resolving; anything linking to it, including search results and old emails, now goes nowhere
Keep selling it anyway	Continue-selling on backorder	Only honest if the delivery promise on the page changes too

Most stores need the second one, and it is the one no inventory tool helps with: the fact lives in the catalogue and the spend lives somewhere else entirely. That gap is why we counted this at all.

Method

Sample. 28 live Shopify storefronts, read on 25 August 2026. The frame is a convenience sample: storefront domains from stores that have installed our app at some point. It is not random and it is not representative of Shopify as a whole; it skews small and young. Treat every figure as descriptive of these 28 stores.

Collection. One read-only pass per store against public endpoints (/products.json, /robots.txt, /sitemap.xml, and one product page), one request per second, with a self-identifying user agent. No admin access, no app installed, no authenticated session, nothing written anywhere.

Exclusion rules. We excluded, before looking at any result: stores whose storefront did not serve a public catalogue (password-protected, closed, or unpaid), stores whose products endpoint did not return valid JSON, and any store with fewer than 10 published products. A store with 3 products produces percentages that swamp the distribution.

Truncation. We paged to a ceiling of 5,000 products per store. Four stores hit that ceiling, so their catalogues are counted only to 5,000, including the 98.8% store. Their true totals are larger and unknown to us.

Definitions. "Fully unavailable" means every variant of a product carries available: false. "Published" means the product is returned by the public storefront endpoint at all. Variant counts are as reported by that endpoint.

What we could not verify

Intent. We cannot tell a deliberate seasonal page from a forgotten one. Nothing in the public data distinguishes them, and the difference matters more than the count does.
Real stock levels. The endpoint gives availability, not quantities, and continue-selling stores report available: true on stock they do not hold. Our figures are a floor.
The four truncated catalogues. Counted to 5,000 products each; the remainder is unmeasured.
Anything about money. We did not look at any of these stores' advertising, traffic or revenue, and we are not claiming a cost for any of this. The link between an unbuyable page and wasted spend is an argument, not a measurement, and we have labelled it as one throughout.
Whether any of this generalises. 28 stores from a biased frame. It is a real measurement of a small, odd sample, which is different from a benchmark, and we would rather publish it with that attached than round it into one.

What we still don't know

How fast the number moves. We have one reading per store on one day, so we cannot tell you whether the median store's 3.9% is a stable background level or the tail of a stockout that started last week. That takes the same measurement repeated weekly, which we intend to do and have not done yet. Until then, treat this as one frame of a film.

FAQ

How do I see all out of stock products in Shopify?

In the admin, filter the product list by availability. From outside the admin, including for a store you do not own, every store's published catalogue is readable at /products.json, and each variant carries an available flag. The script above counts them.

Do sold out products hurt my store?

Not by existing. The cost shows up when you are still paying to send people to a page that cannot take an order, or when a large share of what a shopper sees in a collection is unbuyable. That is why the useful thing is the share of your catalogue, not the count.

Should I delete or unpublish out of stock products?

Neither, if it is coming back. Unpublishing removes the URL, which throws away whatever ranking and links the page had earned. Deleting is worse and is not reversible. The reason to unpublish is that the product is genuinely gone for good.

How do I hide sold out products on Shopify?

At collection level rather than product level: automated collection conditions and the sort order in Search & Discovery both change what a shopper meets first without touching the product's URL. That keeps the page for anyone who arrives with intent, and stops it filling your merchandising.

What does `available: false` mean in the Shopify products endpoint?

That Shopify will not sell that variant at this moment. A store using continue-selling on backorder reports available: true even with no stock, so the flag reads as "buyable", not "in stock".

How many variants does a typical Shopify product have?

In our 28-store sample, the median catalogue ran 1.81 variants per product, with a range from 1.00 to 39.70. Our own test store ran 1.76. For planning any catalogue-wide job, assume the work is roughly 1.8x your product count, and check your own ratio before committing to a number.

Is my Shopify catalogue public?

Yes. That endpoint is open on every Shopify storefront, so your published catalogue and its availability are readable by anyone, competitors included. Nothing in this article uses anything a shopper could not see.

Why does my product count differ from my sitemap?

Product sitemap files cap at 1,000 URLs and then continue in a second file, and the first file also carries the home page URL, so a 1:1 comparison against a catalogue count is off by one before you start. In our sample every non-truncated store matched its sitemap to within one URL.

Related: How to change prices in bulk in Shopify — where the 1.76 variants-per-product figure came from, timed in a live admin.

Related: What a Shopify virtual assistant does — the same catalogue arithmetic, priced against what page one of that search charges per hour.

Written by Adot Technologies Inc, the team behind Arvio: AI Store Operator — ask what changed across your catalogue, review every edit before it goes live, and undo anything.