This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/shopify-inventory-management-audit. The canonical URL points back there.
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 headline median is 3.9% of a catalogue. It is also close to useless on its own, because it blends two different populations: the nineteen stores under 300 products sit at a median of 0.5%, and the nine stores with 300 or more sit at 11.8%. Size is the thing that separates them.
- A sold-out product does not go quiet. We followed one through: HTTP 200, "Sold out" on it, and its URL still in the store's own sitemap, still being handed to search engines. One product, on one store — but nothing about it required the merchant to do anything.
- You can get your own number in one paste, from a browser, with nothing installed and nothing written to your store. The same data is public on every Shopify storefront, including yours — which is the other half of this article.
What this article is not. It does not cover stock levels, reorder points or multi-location inventory. Everything below comes from outside the store, where quantities are invisible. The one thing you can measure from out there is which products a shopper cannot buy — and, because it is public on every store, how your share compares to other people's.
Get your number first
This uses the public products endpoint — the same one your storefront's own theme calls, and the same one anyone can open in a browser. It only reads. There is no line in it that writes, and it needs no app, no login and no permissions. If you would rather not paste code you cannot read, the fetch call below is the same URL you can open in a browser tab yourself — the script just does it for every page and counts.
Open your own storefront in a browser, open the developer console (⌥⌘J on a Mac, Ctrl+Shift+J on Windows), and paste:
const gone = []; let total = 0;
for (let page = 1; ; page++) {
const r = await (await fetch(`/products.json?limit=250&page=${page}`)).json();
if (!r.products.length) break;
total += r.products.length;
for (const p of r.products)
if (p.variants.length && p.variants.every(v => v.available === false)) gone.push(p.handle);
await new Promise(done => setTimeout(done, 300)); // be polite to the store
}
console.log(`${gone.length} of ${total} published products are fully unavailable — ${(100 * gone.length / total).toFixed(1)}%`);
console.table(gone.map(h => ({ product: h, url: `/products/${h}` })));
It prints a line like 47 of 412 published products are fully unavailable — 11.4%, then a sortable table of exactly which ones, each with its /products/<handle> path so you can open them straight from the console — because the count on its own is not a task and the list is. A few hundred products takes a couple of seconds.
One detail if you write your own version: stop paging on an empty page, never on "fewer than I asked for". That endpoint can return a short page and still have more behind it. Our first attempt got it wrong and read one 3,100-product store as 238 products — a 13x undercount with no error and no warning. Every figure in this article comes from the corrected version.
If nothing happens when you paste, your browser may be asking you to type allow pasting first — do that and paste again. If it prints 0 of 0, the storefront is password-protected or the catalogue is not published, and there is nothing to read from outside. If it throws, you are almost certainly not on the storefront domain: this has to run on the shop's own site, not in the admin.
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. That is what the number counts.
Now the part that decides whether that number means anything.
Does this sample look like you?
Before the benchmark, the thing that decides whether you can use it: the median catalogue in our 28 stores is 120 products. That is small. It matters, because catalogue size turns out to separate these stores more cleanly than anything else we measured.
| Group | Stores | Median share sold out and published |
|---|---|---|
| Catalogues under 300 products | 19 | 0.5% |
| Catalogues of 300 products or more | 9 | 11.8% |
| All 28 | 28 | 3.9% |
So the 3.9% everyone would quote is a blend, and if you have a real catalogue, the number to compare yourself against is closer to 11.8% than to 3.9%.
Three things you should know before borrowing that 11.8%. Three of the nine large catalogues are at exactly zero, so it is a tendency, not a rule. At the small end the percentage is mostly noise — three of the stores reading above 15% have catalogues of 12, 33 and 47 products, where two sold-out items is 16.7% and means nothing; below a few hundred products, count the products, not the percentage. And the nine "large" stores actually run from 594 to over 5,000 products, because our sample has a hole in it: there is no store between 253 and 594 products. If your catalogue is in the low hundreds, you are sitting in that hole, and the truthful answer is that we did not measure anyone like you.
So is your number bad?
Here is where our 28 stores actually sit, and what we would do at each level. The bands are drawn from that distribution, not from a standard — there isn't one.
| Your number | Where that sits in our sample | What we would do |
|---|---|---|
| 0% | Twelve of the 28, and most of them are small | Nothing. Come back after your next season. |
| Under about 2% | The low end of the sixteen stores that have any at all | Open the list, confirm they are deliberate — seasonal, pre-order, back-in-stock capture — and stop. |
| Roughly 5–15% | Where most of our larger catalogues live; the 300+ group's median is 11.8% | Worth an hour. For each one: is it coming back, and is anything still sending traffic to it? |
| Over 20% | We have no store here. Ours jump from 19.1% straight to 98.8% | Look for a cause, not a list. A supplier feed that stopped, a discontinued line nobody unpublished, or a whole region reading as unavailable. |
The last row is reasoning, not measurement — we have nothing between 19.1% and 98.8%, so if that is you, we can tell you what to look for but not what is normal.
What each option actually costs
There is no single right answer. Four ways to handle a product on that list:
| 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 |
The second one is where the money is, and it is the one no inventory tool helps with: the fact lives in the catalogue and the spend lives somewhere else entirely.
If you are not buying traffic, that whole option is empty and the question changes shape: what is left is merchandising, not spend. The thing that matters then is whether shoppers meet sold-out products before they meet buyable ones — and that is fixed at collection level, not product level. Automated collection conditions can drop a product out of a collection when it goes unavailable, and Search & Discovery's sort order can push out-of-stock items to the back of every collection. Neither touches the product's URL, so the page stays for anyone who arrives with intent and stops filling your merchandising.
And not all of the number 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. The count is a starting point, not a to-do list.
Why you can measure this at all — and so can everyone else
Your published catalogue, and which of it is currently buyable, is readable by anyone with a browser. Not through a leak — it is how Shopify storefronts are built, and it is the same endpoint the paste above uses. That cuts both ways: it is why you can measure your own store in one line without installing anything, and it is why anyone else can measure it too, competitors included.
It is also why a sold-out product is not quietly parked. We took the first fully-unavailable product from one store in the sample and followed it through: the page returned HTTP 200, rendered with Sold out on it, and its URL was listed in the store's product sitemap — the file the store submits to search engines. That is one product on one store, not a survey — but nothing about it required the merchant to do anything, and for a product coming back next month it is the behaviour you would want. 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.
A page nobody can buy from still costs whatever you are spending to send people to it. We did not measure that cost on any of these stores, so treat that sentence as the argument it is rather than a finding.
The raw counts, for anyone checking our arithmetic
| 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. These are pooled totals across all 28 stores and one store dominates them — drop it and the pooled figure falls from 23.9% to 8.3%. Per store is the only way to read this; the tables above are the ones to use.
available: false means Shopify will not sell that variant right now. That is narrower than it sounds, and it makes every number here a floor: a store running "continue selling when out of stock" keeps available: true on inventory it does not have, and those products are not in our count.
The one store at 98.8% — 4,942 of the first 5,000 products we could read — deserves stating properly. It hit our 5,000-product reading ceiling, so its real catalogue is larger and we do not know by how much. And storefront availability is answered for the market you read from, so a catalogue can read differently from another country; we read from one location and did not repeat it from a second. We did not go back and re-read it from a second location, so we cannot tell you which it is: a store that has genuinely stopped selling and a store that reads as unavailable from where we happened to be look identical from outside. What we can say is the shape — 24,846 of its 24,904 variants (99.8%) came back unavailable, with only 29 products in a mixed state.
We left it in the sample on purpose: our exclusion rules run on catalogue size, set before reading anything, and dropping a store because its result was extreme would be choosing the answer. But it is why we never quote a pooled figure — this one store supplies 4,942 of the 6,942 fully-unavailable products above, 71% of the total.
What the endpoint will not tell you
It only returns products published to the online store, so anything unpublished is invisible to it. It gives you availability, not quantities.
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, with a median catalogue of 120 products. Treat every figure as descriptive of these 28 stores, and read the size split above before borrowing any of them.
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. The size split uses 300 published products as the cut. That is a round number, not a discovered one, and the finding does not rest on it: at every threshold we tried between 100 and 1,000 products the larger group's median is the higher of the two, and from 300 upward it sits at 11.8%.
Limits, in one place. We cannot tell a deliberate seasonal page from a forgotten one, and that difference matters more than the count does. Our figures are a floor, for the continue-selling reason above. Four catalogues are counted only to 5,000 products. We did not look at any of these stores' advertising, traffic or revenue, so nothing here prices the problem. And we have one reading per store on one day, so we cannot tell you whether these levels are stable 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.
FAQ
How do I see all out of stock products in Shopify?
Two different questions, and they have different answers. To find and fix them in your own store, the admin's product list has filters. To get a share of your catalogue — a single number you can compare against other stores, or read for a store you have no admin access to at all — use the public endpoint and the paste above. This article is about the second one, because the first one already has an answer and nobody publishes the comparison.
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".
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.
Published 25 August 2026, revised 26 August 2026, 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. Every figure here was collected from the outside, on 25 August 2026, using only endpoints any shopper's browser can reach — no admin access, no store's data pulled through our app, nothing authenticated.
Originally published at https://arvio.a.xyz/blog/shopify-inventory-management-audit. More Shopify bulk-editing writeups are on the Arvio blog.
Top comments (0)