DEV Community: Arvio

What It Looks Like When the Fix Is Already Written

Arvio — Mon, 21 Sep 2026 06:09:50 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/arvio-writes-the-fix. The canonical URL points back there.

Key takeaways

Other tools tell you what's wrong. This one has already written the fix — you just approve it. This post is one recorded run on our own demo store, screen by screen, so you can see what that actually means before installing anything.
The product we asked about had a 62-character description: Solid acacia, finished by hand. Hand wash and dry immediately. What came back was a 364-character replacement, already drafted, sitting in an editable box.
Nothing was written until a button was pressed. The confirmation card says, in those words: Only this product will be updated — all others left untouched.
After it ran, the result card carried ✓ Description updated and the line This action can be undone. Let me know if you'd like to revert it. — we exercised the forward path only, so treat the undo as what the product offers, not as something this recording demonstrates.

The gap isn't knowing which products are thin. It's that fixing them is typing.

See it on your own catalogue

Arvio is an AI store operator: it reads your live catalogue, drafts the change, and shows it to you before anything is written.

See Arvio on the Shopify App Store →

Why a walkthrough instead of a feature list

Most descriptions of this kind of tool stop at the noun. "It rewrites product descriptions" is true of a great many things, including a text box and some patience. What it doesn't tell you is the part that decides whether you'd actually use it: what happens between asking and the change landing, and how much of that you control.

So this is a recording rather than a claim. One prompt, one product, on our own demo store. Everything quoted below is text that was on screen.

The instruction we typed was deliberately narrow:

Rewrite the product description for one product only: Acacia Round Tray. Leave every other product untouched.

What was there before

The product had a description. That's worth saying, because the interesting case isn't the empty field — it's the one that's technically filled and does no work:

Solid acacia, finished by hand. Hand wash and dry immediately.

Sixty-two characters. It's accurate. It tells a shopper the material and how to wash it, and nothing about why the thing is worth buying — what a description that does the work looks like is its own subject. Nothing in any admin flags this, because from the system's point of view the field is populated and the product is fine.

This is the category of problem that survives every audit you run. A checker asks "is the description empty?" and gets a no.

What came back: a draft, not a diagnosis

Here is the part that's difficult to convey without a picture. The response was not a report saying the description was thin, and not a suggestion that it be improved. It was the replacement text, already written, in a box you can edit:

The old line is struck through. Below it, under New Description (editable), sits the full replacement:

Crafted from solid acacia wood and finished by hand, this round tray brings warm, natural grain to any table. Its generous surface is perfect for serving drinks, breakfast in bed, or keeping everyday essentials tidy. Because every piece of acacia has its own unique grain, no two trays are exactly alike. To keep it looking its best, hand wash and dry immediately.

That's 364 characters of plain text against the original 62 — the lengths our catalogue diff recorded for the stored field before and after this run.

Two things about that box are worth more than the word count. It is editable — the draft is a starting point, not a verdict. And the button next to it had not been pressed. At this moment in the recording, nothing in the store had changed.

The confirmation card is the actual feature

What makes write access to your catalogue acceptable isn't the quality of the drafting. It's that you can see precisely what it is about to do, in narrow enough terms that you could refuse.

The card states its scope in a sentence:

Only this product will be updated — all others left untouched.

It names the product, Acacia Round Tray, shows the current description and the proposed one side by side, and labels itself (reversible). The button reads Confirm Update.

This is the inversion worth understanding. A tool that gives you a list of problems has moved the work to you and kept none of the risk. A tool that writes to your catalogue on its own has taken the work and handed you the risk. The card is the attempt at neither: the work is done, and the decision is still yours. We wrote up why that boundary is where it is, and where it comes from, in a separate post on why this is a fix and not a report.

Every product in the catalogue, same shape

One approval per change, and a diff you can read before you give it.

See Arvio on the Shopify App Store →

After the button: what it tells you it did

Pressing Confirm Update runs the change. That's what makes this two rounds rather than one: the first produced the plan and the draft, and nothing else; the second is the one that writes. The result card reports back:

Three things on that card matter.

It confirms the scope it promised. All other products left untouched. The claim made before the change is the claim repeated after it.

It shows the diff, not a success message. ✓ Description updated, then Old description struck through above New description in full. You can read what landed without opening another tab. There's a View in Shopify Admin → button for when you want to check the source of truth rather than take a card's word for it — which you should, and which is the whole reason that button exists.

It offers the way back. In those words:

This action can be undone. Let me know if you'd like to revert it.

Reversibility is what makes approving the first one bearable. If the cost of a bad rewrite is "fifteen minutes and some annoyance" rather than "find the original text, which you no longer have," then you'll actually try it on a real product instead of a test one.

What this run does not tell you

Everything above is a recording of our own product on our own store, so:

One product, one run. This is not a sample. It says nothing about consistency across a catalogue, or about what the second hundred rewrites look like.
We didn't measure whether the new copy sells better. No traffic, no conversion, no rankings. The 62-to-364 figure is a length, and length is not quality. A longer description that says nothing is worse than a short one that says something true.
It's our own demo store, stocked and described by us. Your catalogue is messier in ways ours isn't.
The recording is sped up. The interface printed 39s and 22s against the two rounds; we're repeating what it displayed, not offering it as an independently timed benchmark. Either way, don't read the clip's length as wall time, and don't read any of this as real-time.
Judgment is still yours. The tool can tell you a field is thin. It cannot tell you that the thin description was deliberate, that legal signed off on that exact wording, or that the product is being discontinued next week.

Where this is actually useful

The pitch is narrow.

It is useful when you have a catalogue where a meaningful number of products have descriptions like that 62-character one — present, accurate, doing no work — and the reason they're still that way is that fixing them is typing, not deciding. That's the specific bottleneck: not knowing which products are thin, but that the fix for each one is a small writing job, and there are as many of them as you have products.

And that's the question this post can't answer for you. We recorded one product. If you have four hundred, the honest read is that you'd be reading four hundred drafts and pressing the button four hundred times — approval is a real cost, and it scales with the catalogue exactly the way the typing did. What changes is the unit: reading something already written and deciding yes or no, rather than composing it from an empty box. Whether that trade is worth it at your catalogue size is a judgment we haven't measured and won't pretend to have.

It is not useful when you already know the exact values you want in a column. A tag migration or a vendor rename is a spreadsheet operation. It's also not useful if every word needs legal sign-off, because then the approval queue is the bottleneck and moving work into it doesn't help.

If you want the wider tour of what the thing does beyond this one interaction, we wrote that up here.

FAQ

Does it change anything before I approve it?
Not in this run. The confirmation card appeared with the draft in an editable box and nothing was written until Confirm Update was pressed. That is the design: the card names its scope — Only this product will be updated — all others left untouched. — before you decide.

Can I edit what it wrote instead of accepting it?
Yes. The box is labelled New Description (editable) and behaves like a text field. The draft is a starting point.

What if I approve something and regret it?
The result card says This action can be undone. Let me know if you'd like to revert it. We exercised the forward path in this recording and read the change back in the admin; we did not record a revert, so treat the undo as what the product offers rather than as something we demonstrated here.

How long did it take?
The interface displayed 39s and 22s against the two rounds. That's what it printed, not a number we timed ourselves. The clip is sped up for watching, so don't time it against the video, and don't read it as real-time — it's a job that runs, not a live edit.

Is this a bulk editor?
No, and the distinction is the point. A bulk editor applies values you already decided to many rows at once. Here the missing piece isn't applying a decision, it's making one per product: what should this description say. That's why every change comes with a diff and an approval rather than a row count.

Does it write the same way for every product?
We ran one product. We can't tell you how consistent it is across a catalogue, and anyone quoting you a consistency figure from a single run is guessing.

I have hundreds of products. Do I have to approve every single one?
In this recording, one change meant one approval. We haven't recorded what a few hundred look like, so we can't tell you there's a batch path or promise you there isn't — we'd rather say we don't know than guess on your behalf. Read the scale question as open, and size the trade yourself before you commit an afternoon to it.

Will better descriptions improve my traffic or sales?
We didn't measure that and this post doesn't claim it. What it establishes is the interaction shape: the change arrives written, scoped, and reversible.

Figures and quoted strings: one recorded run on our own demo store, 2026-09-21. Description lengths from the run's catalogue diff (62 → 364 characters stored). All on-screen text quoted verbatim from the recording. Last updated: 2026-09-21.

Arvio: AI Store Operator — install it on the Shopify App Store. It goes through every product in the catalogue, one approval at a time.

Originally published at https://arvio.a.xyz/blog/arvio-writes-the-fix. More Shopify bulk-editing writeups are on the Arvio blog.

Why We Ship the Fix Instead of the Report

Arvio — Mon, 21 Sep 2026 06:05:41 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/why-fix-not-report. The canonical URL points back there.

Key takeaways

Other tools tell you what's wrong. This one has already written the fix — you just approve it. This post is the reasoning behind that sentence, and the argument against the two more obvious designs.
A list of problems is not progress. A scan that returns a few hundred issues has converted one unknown into a few hundred small writing jobs and moved all of them to you. The finding was never the hard part.
Silent automation is worse, for a specific reason: it takes the work and hands you the risk. Catalogue copy is not a thing you want changed while you aren't looking.
The approval is where the design lives. The change arrives written and scoped — Only this product will be updated — all others left untouched. — and still doesn't run until you press a button.
What this post does not establish: this is an argument about design, not a measurement. We have no data showing this workflow produces better catalogues than an audit tool does.

Finding the problem was never the expensive part. Deciding and typing was.

See what "already written" looks like

Arvio is an AI store operator: it reads your live catalogue, drafts the change, and shows it to you before anything is written.

See Arvio on the Shopify App Store →

The report problem

Run any catalogue scan and you get a number. A few hundred products with thin descriptions. Some number with no product type — we ran exactly that count on a real catalogue. Some quantity of empty categories and absent SKUs.

That number feels like progress, and for about a day it is. You didn't know, and now you do. The trouble starts the moment you try to act on it, because the report has performed a conversion that nobody names out loud: it turned one vague worry into several hundred specific small jobs, and assigned every one of them to you.

And they are not jobs that a list helps with. If the finding is "this description is thin," the work isn't locating it — the report already did that. The work is deciding what the description should say instead, and typing it — once per product, all the way down the list. The report is complete and accurate and has not moved you a single product closer to done.

This is the part we'd expect to strand people, and it's not a failure of the tool: a scan that returns the same count next month is working exactly as designed, on a problem it was never able to touch. (We're reasoning about where the work lands, not reporting what anyone did — we have no data on how often these get re-run or abandoned.)

The asymmetry is the whole thing. Finding is cheap and automatable. Deciding and typing is expensive and wasn't automatable — until recently, which is what changed.

Why we didn't just automate it

The obvious response is to close the loop: if the tool can find the thin description and can also write a better one, let it write and be done. No list, no queue, no backlog of anything.

We didn't build that, and the reason isn't timidity about what the writing is worth.

It's that catalogue copy is customer-facing, permanent by default, and worth different amounts per product. A rewrite that's fine on a serving tray is a problem on the product where the wording was negotiated, or the one with a compliance constraint, or the one being discontinued next week. The tool cannot know any of that. It can see that a field is thin. It cannot see that the thin description was deliberate.

So full automation doesn't remove the risk. It relocates it — to a place where you find out about it later, from a customer, or not at all. The economics are bad in an asymmetric way: the upside of an unattended rewrite is a slightly better description, and the downside is wrong text live on your store for an unknown number of days. You would not take that trade on a product that matters, which means you would not enable it, which means the feature is useless precisely where the catalogue is valuable.

And there's a second cost that's easy to miss: a change you didn't see is a change you can't learn from. If the tool quietly rewrote every thin description you had, you have no idea whether it's any good at it. The approval isn't only a safety mechanism. It's the only moment where you find out what the thing actually does.

The third position

Between "here's a list, good luck" and "I changed it, hope that's fine" there's a position that only became available once drafting got cheap:

Do the work. Don't do the deciding.

Concretely, that means a change arrives in a particular shape. The draft is written — not suggested, not described, written, and sitting in an editable box. In the run we recorded, a product whose entire description read Solid acacia, finished by hand. Hand wash and dry immediately. came back with a replacement already drafted: "Crafted from solid acacia wood and finished by hand, this round tray brings warm, natural grain to any table…" — 62 characters of stored text replaced by 364, before anyone had agreed to anything. The scope is stated in narrow terms before you commit to it. In that run, the confirmation card says it in a sentence:

Only this product will be updated — all others left untouched.

Then nothing happens until you press the button. And afterwards, the result card carries the way back:

This action can be undone. Let me know if you'd like to revert it.

Take any one of those away and the thing stops working. If it isn't written, you're back to a list. If the scope isn't stated, you can't agree to it without checking the whole catalogue yourself. If you can't refuse it, your judgment is out of the loop precisely where the tool has none. And if you can't undo it, you won't press the button the first time.

If you want to see that sequence on screen rather than described, we published the whole run, screen by screen. The wider tour of what the thing does is over here.

One approval per change, and a diff you can read first

See Arvio on the Shopify App Store →

Three designs, side by side

	Audit / report	Silent automation	Written, then approved
Who finds the problem	The tool	The tool	The tool
Who writes the fix	You	The tool	The tool
Who decides it ships	You	Nobody	You
What you hold afterwards	A list of jobs	Changes you didn't individually read	A change you read and accepted
Cost of a bad call	—	Live wrong text, found later	Reject it, or undo it
What you learn about the tool	Nothing	Nothing	Whether it's any good

The last row is the one people don't anticipate. After ten approvals you have a real opinion about whether the drafting is worth having, because you read ten drafts. Neither of the other two columns gives you that at any point.

Where the boundary belongs

"Keep a human in the loop" is easy to say and usually means nothing, because it doesn't specify where. Put the human too early and you've built an audit: they do the work. Put them too late and the decision has already been made for them; a log they can read afterwards is a different thing from a choice they got to make.

The rule we landed on is about reversibility, and it's not specific to catalogues:

Automate up to the last irreversible step. Stop there, and make that step cheap to refuse.

Drafting is reversible — a draft you don't like costs nothing, you just don't press the button. Writing to a live storefront is not reversible in the same way; there is an interval where the wrong thing is public. So the boundary goes between them. Not because writes are scary, but because that's the first point where a mistake acquires a duration.

This also explains why the answer isn't "add a confidence threshold and auto-apply the easy ones." Confidence measures whether the model thinks the copy is good. It has no access to the thing that actually determines whether a change is safe — whether this product matters, and why it currently reads the way it does. Those aren't the same question, and only one of them is yours to answer.

What this argument doesn't prove

It's an argument, not a measurement. We have no comparative data showing this workflow produces better catalogues than an audit tool does.
Approval is a real cost. Per-change review does not scale to infinity, and if you have hundreds of thin descriptions you will be pressing a button a lot. We think it beats writing hundreds of descriptions. That's a judgment, not a finding.
Some jobs genuinely want the other designs. If you already know the exact values you want in a column — a tag migration, a vendor rename — that's a spreadsheet operation, and a report plus a batch update is the right shape for it. If a field is truly low-stakes and uniform, automate it and don't look.
We're describing two designs we didn't build, in their plainest form. Real audit tools and real automation products carry mitigations we haven't credited here — previews, dry runs, staged rollouts, per-field rules. The comparison is between the three shapes, not a claim about any particular product's worst case.
We're describing our own product's design, so read this as reasoning you can check against the recording, not as a neutral survey.

FAQ

Isn't this just an audit tool with extra steps?
The opposite, in the one place it matters. An audit ends by handing you the writing. This ends by handing you a decision, with the writing already done. Same finding, and everything expensive after the finding lands in a different place.

Why not let it run unattended on the obvious cases?
Because "obvious" is a property of the copy, and the risk is a property of the product. The tool can see that a description is thin. It can't see that the wording was negotiated, or that the item is being discontinued. Those don't correlate with how confident the model is.

What if I already know exactly what I want in every row?
Then you don't have this problem, and you shouldn't reach for this. Knowing the value already means the only work left is applying it, which a spreadsheet operation does perfectly well. What this is for is the other case: where the decision doesn't exist yet, and somebody has to work out what this particular description should say.

Doesn't approving every change defeat the point?
It would if approving were as expensive as writing. It isn't — reading something already written and deciding yes or no is a smaller job than composing it from nothing. That gap is where the saving lives, and it's real even though approval is not costless.

What if I trust it after a hundred changes?
That's the right instinct and you'd have earned it by reading a hundred drafts, which is exactly the thing the other two designs never let you do. We're not claiming the approval step should be permanent for everyone forever — only that it's where you start, and that removing it should be a decision you make with evidence rather than a default you never saw.

Do you have data showing this works better?
No. This post is a design argument. The measurable claims we do have are about the interaction — what appears on screen, in what order — and those are in the walkthrough.

On-screen strings quoted here are from one recorded run on our own demo store, 2026-09-21, reproduced with the full sequence in "What It Looks Like When the Fix Is Already Written". Last updated: 2026-09-21.

Arvio: AI Store Operator — install it on the Shopify App Store. It writes the change and waits for you.

Originally published at https://arvio.a.xyz/blog/why-fix-not-report. More Shopify bulk-editing writeups are on the Arvio blog.

Why ChatGPT Can't See Your Shopify Store — and Which Part Is Actually Missing

Arvio — Sat, 12 Sep 2026 18:58:23 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/chatgpt-cant-see-shopify-store. The canonical URL points back there.

Key takeaways

Start by asking an assistant three questions about your own store. The shape of the wrong answer tells you which check to run — and the four checks below only mean anything in order.
On our own demo store (fashionmore-3397.myshopify.com, read 2026-09-13), every page-level check passed: 4 of 4 product pages returned HTTP 200 with 322,364–371,301 bytes of HTML, and 4 of 4 carried a product node in their structured data.
Same store, same day: 8 of 67 products have a description under 120 characters, 19 have no product type, 9 have no tags — while 0 have an empty description body, 0 are missing a vendor, and 0 are missing a SKU. One page publishes a 52-character description; two publish an empty category rather than none at all, which is why nothing anywhere reports an error.
What this post does not establish: we measured what an assistant would have to read, not what any assistant did. Nothing here shows that filling these fields changes how you get described or recommended.
Across 42 other storefronts read 2026-08-31: vendor, price and stock status were present on 100% of 5,935 products and 31,767 variants, while 35.8% of variants had no SKU. What Shopify fills in is complete; what a person has to type is what's missing.

Your store probably isn't invisible. It has nothing to say.

The four checks are cheap. Filling the fields is what stalls

Arvio is an AI store operator: it reads your live catalogue, finds the products that have nothing in them, and writes the missing description for you to approve.

See Arvio on the Shopify App Store →

Start here: ask an assistant about your own store (two minutes, nothing to install)

Everything else in this post is a technical check. This one isn't, it's faster, and it's the only step that tells you which technical check is worth your afternoon.

Open a new chat with whichever assistant you care about and paste these three, one at a time, with your own domain in them:

1. What does yourstore.com sell? Be specific about the categories.
2. List five products from yourstore.com, with the price and whether each one is in stock.
3. I want <a thing you actually sell> for under <a price you actually charge>.
   Does yourstore.com have one? Link it.

Now read the shape of what comes back, not whether it's flattering:

What comes back	What that tells you	Go to
"I can't find that site" / "I'm unable to browse"	Nothing was read. Everything downstream is unanswerable until this changes	Step 1
A plausible description of your niche, but it can't name a single product	Something was read, and there was nothing specific in it	Step 3
Product names that are nearly right, or products you've never sold	It read something thin and filled the gap itself	Step 3, then 4
Right names, wrong prices, or things you discontinued	It read you fine. What it read is stale	Step 4
Right names, right details	This isn't a data problem, and this post won't help you	—

Before you believe the answer:

Run a control. In the same chat, ask the same three questions about a store you know is well stocked and well described — a competitor is ideal. If that one also comes back empty, you measured the assistant's browsing, not your catalogue. A blank answer has two completely different causes and they look identical.
One run is a smoke test, not a measurement. Answers move between assistants, between sessions, and depending on whether that chat can fetch pages at all. We are not reporting what any assistant said about our store, because we have no clean way to measure that; everything numbered in this post came from endpoints anyone can fetch.

First, the suspicion you can cross off: it probably isn't permission

When a store can't be described by ChatGPT, the first guess is usually that something is blocking the crawler. It is worth thirty seconds to rule out, because it is the one part of this you can settle by reading a single file.

An assistant that browses reads your storefront the way any other bot does: it requests the page, takes the HTML your server returns, and reads whatever structured data is sitting in it. It does not log in, and it does not see your admin. Whether it is allowed to make that request at all is decided by one file: yourstore.com/robots.txt.

So we read that file on all 42 storefronts in this post's sample, on 2026-09-13. All 42 responded. 41 of the 42 carry no AI-crawler rule at all — no GPTBot, no Google-Extended, no PerplexityBot, in either direction. The single store that names them allows all three. Not one of the 42 blocks any of them. Shopify does not ship a block by default, and almost nobody adds one.

Check your own if you like: open yourstore.com/robots.txt and search it for GPTBot. Finding nothing means nothing is being blocked. If you do want to change what that file says to AI crawlers, that is its own job and we wrote it up separately. The same goes for the newer machine-readable files stores publish for agents — we went and counted what is actually out there.

What none of this tells you is whether ChatGPT ever chose to fetch you, or what it did with the page once it had it. Permission is simply the cheapest thing to eliminate. Everything below assumes you were read, and asks a different question: what was there to read.

The order is the entire point

The checks themselves are not secret, and you have probably already met most of them. What gets left out is that three of the four are meaningless until the one above them passes, and that a failure at check 3 looks, from the outside, exactly like a failure at check 1 — both end with an assistant that can't tell a shopper anything about you.

#	Question	Where you look	Passing looks like
1	Does the page come back at all?	Your product URL in a private window	A real page, not a shell or a redirect
2	Is there a product node in the markup?	Any structured-data testing tool, fed the product URL	It finds one
3	Are the fields inside it filled?	The same readout — read the values, not the field names	`description` and `category` have something in them
4	Is what it says still true?	Three products the assistant named, against your admin	Price, stock and title match

Our own store is the argument for starting at the top rather than in the middle: it passes 1 and 2 on every page we checked, and it still has products with nothing to say.

Step 1 — Does the page come back at all?

We fetched four product pages from our demo store anonymously on 2026-09-13. All four returned HTTP 200, with 322,364 to 371,301 bytes of HTML each. There's a whole page there.

If your check fails here — a redirect loop, a password-protected storefront, a 404 on a handle you renamed — stop. Nothing below this line matters until the page responds.

Step 2 — Is there a product node in the markup? (and why a zero here might be your fault)

All four pages carried one. But three of the four published it as ProductGroup, and only one as Product — the difference being whether the item has variants.

That's worth knowing because it's the cheapest way to misdiagnose yourself. A tool or a search that only looks for Product reports nothing found on three of those four pages, and "nothing found" reads exactly like "this store has no structured data." It isn't. It's the wrong query.

So when step 2 returns a zero, run the same check against a store you're confident is set up properly. If that also returns zero, your check is wrong. (A tool that comes back with actual errors rather than with nothing at all is telling you about a different problem with a different fix.)

Step 3 — Are the fields inside it filled? (this is the check our own store failed)

Here's what those same four pages publish inside the product node:

Page	Structured-data `description`	`category`
Small charcuterie board	52 characters	`Serveware`
Handled cake stand	77 characters	`Serveware`
Round serving tray	362 characters	empty string
Woven bowls	784 characters	empty string

An empty string is not a missing field. Those two pages don't omit category — they publish it with nothing in it. A check that asks "is there a category?" gets a yes. This is the failure mode with no error message anywhere: the page is fine, the markup is there, the field is present, and the value is blank.

The blank is just your admin, passed through. The two pages with an empty category are the same two products that have no product type in the store's catalogue feed; the two with a value are ones that do. Four pages is not proof of how every theme builds that field, but it is the same two products, and it means the fix isn't a markup project — it's the product type field, on 19 products.

Four pages is a spot check. To widen it to the whole catalogue we read the store's own public catalogue endpoint — yourstore.com/products.json?limit=250, which any Shopify storefront that isn't password-protected serves without a login — and counted the fields product by product. That is the version of this check that scales past a handful of pages, and it runs on your store exactly as it ran on ours.

How to actually count it, without writing a line of code. Open that URL in a browser. What comes back is a single unbroken line of text — on our 67-product store, about 160,000 characters of it — and you are not meant to read it. You are meant to search it. Press Cmd-F (Ctrl-F on Windows) and your browser's find bar will report how many matches it found. That number is your count.

Search for exactly this	What it counts	Our store
`"product_type":""`	Products with no product type	19
`"tags":[]`	Products with no tags	9
`"body_html":""`	Products with a completely empty description	0
`"vendor":""`	Products with no vendor	0
`"sku":""` and `"sku":null`	Variants with no SKU — add the two	0

Those are the same five numbers as the table below, which is the whole point: the count in this post is one you can reproduce against your own catalogue in about a minute.

Three things to know before you trust it. If your browser shows a tidy collapsible tree rather than a wall of text, switch to its Raw Data view first — the searches above are literal, and a reformatted view inserts spaces where the file has none. limit=250 is a ceiling, so a catalogue larger than 250 products is only partly counted this way. And the one row you cannot get from a search is the first one in the table below: "description under 120 characters" needs something that can measure length, not merely find a blank.

All 67 products in that store, read the same day:

Check	Products failing	Products passing
Description under 120 plain-text characters	8	59
No product type set	19	48
No tags	9	58
Description completely empty	0	67
No vendor	0	67
No SKU on any variant	0	67

The bottom three rows are not a disclaimer, they're half the finding. Three of the six checks come back perfect. Nobody's store is uniformly empty, and if you go looking for "our data is a mess" you'll find yourself a contradiction and stop.

Step 4 — Is what it says still true?

Step 3's failure is silence. Step 4's failure is worse, because it produces confident answers.

In the 42 storefronts we read on 2026-08-31, 1,718 of 31,767 variants — 5.4% — were marked out of stock and still published in the public catalogue, across 34 of the 42 stores. Keeping a sold-out product listed is usually deliberate — a restock is coming, the page has history, returning customers search for it — so that is a count of a situation, not a count of mistakes. The stock flag itself was present on 100% of those variants, so nothing is hidden: an assistant that reads it can tell. An assistant that reads the title and the description and skips the flag will hand a shopper something you can't ship.

Concretely: take three products the assistant named at the top of this post and check them against your admin. Right price? Right stock? Is that seasonal bundle from last year still live? This is the branch where "AI can see my store" is true and still costing you.

Your evening, in order

If you do only what is on this list, you will have done the whole diagnosis. The times are what each step takes to run — not what it takes to fix whatever it turns up.

#	Do this	How long	What you end up knowing
1	Ask an assistant the three questions at the top of this post, with your own domain in them	2 min	Which row of that table you are in — and therefore which step below is the one that matters
2	Ask the same three about a competitor you know is well stocked, in the same chat	2 min	Whether an empty answer was about your store or about that assistant's browsing
3	Open one of your own product URLs in a private window	1 min	Whether there is a real page there at all. If there is not, stop — nothing below this counts
4	Open `yourstore.com/robots.txt` and search it for `GPTBot`	30 sec	Whether you are blocking anything. On the evidence above, you almost certainly are not
5	Feed that same product URL to a structured-data testing tool	3 min	Whether there is a product node. Accept `ProductGroup` as well as `Product` — most variant products publish the first one
6	In that same readout, read the values of `description` and `category`, not the field names	2 min	Whether your fields are filled or merely present
7	Open `yourstore.com/products.json?limit=250` and run the five searches from Step 3	2 min	Those same counts across your entire catalogue, instead of the one page you spot-checked
8	Take three products the assistant named back in step 1 and check price, stock and title against your admin	5 min	Whether what it read about you is still true

Under twenty minutes, and you come out the other side with a number — how many of your products have nothing in them — instead of a feeling. What to do about that number is the last section of this post.

What the same checks look like on other people's stores

We read the public catalogue of 42 storefronts drawn from a public list on 2026-08-31 — 5,935 products, 31,767 variants:

Field	Present	Missing
Vendor	5,935 / 5,935 — 100%	0
Price	31,767 / 31,767 — 100%	0
Stock status	31,767 / 31,767 — 100%	0
SKU	20,381 / 31,767 — 64.2%	11,386 — 35.8%

And per store, because a single average hides the shape:

Share of variants with a SKU	Stores
All of them	6
50–99%	19
1–49%	10
None at all	7

So "merchants leave their data empty" is not a true statement, and if that's the premise you're working from you'll spend a week sweeping fields that were never broken. The fields Shopify fills in for you are complete in every store we read. The fields a human has to type are missing at scale. Be careful how much weight you put on those three 100% rows: we never saw one of them fail, on any store, which means they may be describing how this endpoint serialises a product rather than how carefully anyone filled it in. The row that actually discriminates between stores is SKU. Price is there because you can't publish without it. Vendor is there because it's one box at the top of the form. SKU is missing on a third of variants because it's one box per variant, several hundred times, and nothing ever breaks when you skip it.

That's the same reason our own store has 19 products with no product type. It isn't a knowledge problem — the merchant knows what a product type is. The work is one small decision per product, several hundred times over in a catalogue of any size, and no part of the system ever complains.

What we measured, and what we could not

The single store. fashionmore-3397.myshopify.com is our own demo store, so treat it as one named case; it is not a sample of anything. All 67 products read from its public catalogue on 2026-09-13; structured data read on 4 of those 67 product pages, not all of them.

The 42 stores. Drawn from a public list: Shopify Community's Store Feedback board, where merchants post their own URL asking for a critique — 720 posts, 474 candidate domains, 230 still trading, from which 60 were drawn at random with a recorded seed — the other 244 had gone dark, so this frame is of survivors, and of merchants who post their store for critique, which skews new and small. We were only able to probe 43 of those 60, and all 43 had also published a machine-readable capability file, which makes them a tidier-than-average subset chosen by outcome rather than the random 60. So treat 35.8% as a floor, not an estimate, and not as a figure representative of Shopify at large. 42 of the 43 returned a readable catalogue; one failed to resolve.

Truncation. We read the first 250 products per store. 16 of the 42 hit that ceiling, so their deeper catalogue isn't in these totals, and we don't know which way that pushes the SKU number. Median catalogue as read: 140.5 products.

Not measured: image alt text. The catalogue endpoint doesn't expose that field at all, so we have no coverage figure for it in either direction — it's a blank, not a zero. Same for the SEO title tag. Both matter to an assistant reading your store; we just can't count them this way.

We sell an agent that fills these fields in. And you can't recheck the multi-store numbers: the frame file, the list of 60 and the 42 domains are not published, so treat every figure above that isn't about our own store as ours rather than as something you verified. What you can reproduce is the method on your own store — ask it the three questions, run the four checks in order.

So the diagnosis is cheap and the fix is a few hundred repetitions

That's the actual shape of this problem, and it's why the advice you've already read didn't help. Three ways through it:

In the admin, one product at a time. The right call when the answer is different for every product, which for descriptions it genuinely is. It's also the option whose cost is entirely your evenings — at 67 products it's an afternoon; at several hundred it's the thing you've been meaning to do since spring.

CSV export and re-import. Right when you already know the value you want in a column — supplier product types, a tag scheme you can derive from the handle, SKUs you can generate. Wrong for descriptions, because a spreadsheet doesn't know anything about the product, and several hundred near-identical descriptions clear every check in this post while helping nobody. Before you trust a round trip: export one collection, change exactly one product, re-import, and diff it against what you exported.

Something that goes through the whole catalogue for you. That's the shape Arvio takes. Arvio is an AI store operator. It scans your store nightly, ranks what it finds — using your own store's data, which a public-catalogue read like this one can't see — then writes the edit against your live catalogue and holds it for your approval. Nothing ships until you approve it, and any edit can be undone in one click.

The list was never the hard part. You could have generated it from that one URL in the first two minutes of this post, for nothing. An audit tool that hands you a list of problem pages has not written a single description.

The same fields, checked nightly, with the edit already written

Everything in this article was read from public endpoints. Arvio reads your own store instead, ranks what it finds, drafts each change against your real catalogue and holds it until you approve. Any edit can be undone in one click.

Install Arvio on the Shopify App Store →

When this isn't your problem

Your catalogue is small. The median store we read had 140.5 products; if you have thirty, an afternoon in the admin beats every tool on this page and you'll write better copy than any of them.
You fill every field as you add the product. Then steps 1–4 all pass, your question is discovery or demand rather than data, and this post measured neither.
You already know the exact values you want in a column. A tag migration, a vendor rename, a price change — that's a spreadsheet operation, and a bulk editor is the right tool for it. That isn't what Arvio is for.
Every word needs legal or clinical sign-off. An approval queue that fills up nightly just moves the bottleneck.

FAQ

Why can't ChatGPT see my Shopify store?
There are at least four different reasons, and they produce nearly identical symptoms: the page doesn't come back, there's no product node in it, the node is there with empty fields, or everything is readable but out of date. Ask it the three questions at the top of this post and the shape of the wrong answer tells you which one you have. On our own demo store the first two checks passed on every page and the third one still failed on 19 products.

Is an empty field the same as a missing field?
No. Two of our four pages publish category with an empty string in it. Anything checking whether the field is present gets a yes, so this failure arrives without an error message, a warning, or a red dot anywhere in the admin.

Does the product type field actually matter for AI?
We measured whether it's filled and nothing else — 19 of 67 products in our demo store have it empty, and the two pages we checked with no product type also published an empty category in their markup. We have no data on what that does to traffic or to how often you get recommended, and anyone quoting you a figure for that from a public catalogue read is guessing.

How long should my product descriptions be for AI to use them?
We didn't test length against any outcome, so we can't give you a target. We used 120 plain-text characters as the line between "thin" and "has something on it" — roughly a sentence. One of our own pages publishes a 52-character description. The threshold is a smoke alarm; don't write to it.

What percentage of Shopify stores have this problem?
We can't tell you. What we have is 42 storefronts drawn from a public list, where 35.8% of 31,767 variants had no SKU — and those 42 were, by how they ended up in our sample, a tidier-than-average group, so that figure is a floor for them, not a figure for Shopify.

Can I check a competitor's store the same way?
The three questions, yes. The catalogue checks read public endpoints too, which is how we read 42 stores without an account on any of them. Be considerate about request volume, and note that alt text and the SEO title tag aren't exposed there, so the two fields people most want to compare are the two you can't.

If I fill all these fields in, will I get recommended by ChatGPT?
We can't promise that. This post measured the state of the data, not an outcome — no rankings, no traffic, no sales. What it does establish is the order to work in: there's no point arguing about how you get recommended while two of your product pages are publishing an empty category and a 52-character description.

Everything passed all four checks. Now what?
Then your store isn't the bottleneck and this post is done helping you. That's a genuinely different question — discovery and demand — and you should be suspicious of anyone who answers it with the same checklist they just sold you.

Single-store figures: all 67 products and 4 product pages of our own demo store fashionmore-3397.myshopify.com, read anonymously 2026-09-13. Multi-store figures: 42 public storefronts read 2026-08-31, first 250 products each. Sampling frame, truncation and what we could not measure are described in full in "What we measured, and what we could not" above. Last updated: 2026-09-13.

Arvio: AI Store Operator — install it on the Shopify App Store. It goes through every product in the catalogue.

Originally published at https://arvio.a.xyz/blog/chatgpt-cant-see-shopify-store. More Shopify bulk-editing writeups are on the Arvio blog.

Shopify Product Page Optimization: The 95% You Never Scroll To

Arvio — Fri, 11 Sep 2026 01:15:47 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/shopify-product-page-optimization. The canonical URL points back there.

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.

See Arvio on the Shopify App Store →

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.

Install Arvio on the Shopify App Store →

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.

Originally published at https://arvio.a.xyz/blog/shopify-product-page-optimization. More Shopify bulk-editing writeups are on the Arvio blog.

Your Shopify store gets traffic but no sales — start with the pages you never scroll to

Arvio — Fri, 11 Sep 2026 01:15:42 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/shopify-store-not-converting. The canonical URL points back there.

Published September 8, 2026 by Adot Technologies Inc, the team behind Arvio. The store list was drawn at random from a public source on August 26, 2026. We have read it twice since: field completeness on September 1, 2026, and catalogue depth on September 8, 2026.

Key takeaways

The advice you have already read — homepage, theme, cart, checkout — is about the pages you look at every day. This piece is about the ones you don't.
Your catalogue is deeper than that. On the stores we could measure, the biggest collection ran a median of 7 pages and the deepest ran 241.
How many products fit on a page is set by your theme, not by Shopify. We measured 10–48 products per page across those stores, so "page 3" means a different depth on every store.
The fix is to sort your catalogue by what is missing and read the end of that list rather than the top.
What we did not measure: whether fixing those pages moves your conversion rate. We haven't run a controlled test, and nothing below claims a number for it.

You can only fix what you can see

Arvio reads your product data past the first page, shows you where it comes up empty, and drafts the fill for you to approve.

See Arvio on the Shopify App Store →

The quick version

Check where your traffic actually lands before you change anything. If it's landing on product pages you can't remember writing, that's the case this article is about — and it is the one most checklists skip, because those pages are also the ones the person writing the checklist never sees.
Find those pages by sorting, not by scrolling: the Shopify admin can filter your product list by what is missing, and a CSV export can sort by it.
Fix the data on the pages people actually land on first, then work down the list. The order matters more than the volume.

Your catalogue is longer than anything you look at

On the 18 live storefronts where we could count it, the biggest collection ran a median of 7 pages of products, and the deepest ran 241. Advice about a store that is not converting is written for the pages an owner sees — and almost none of that depth is one of them.

(If what you want is the per-page checklist rather than the depth argument, we published one with base rates from live stores: a Shopify product page audit checklist.)

We took live Shopify storefronts from a public list, opened the biggest collection on each one, and counted how many products the theme puts on a single page. Then we divided the size of that collection by that number.

The five deepest of the 18 stores we could count — not a typical store; the median is four rows below:

Products in the biggest collection	Products per page (measured)	Pages
2,883	12	241
1,838	12	154
1,919	16	120
1,489	20	75
403	17	24

Across all 18 stores we could count, the median was 7 pages and 13 of them ran deeper than three pages.

Page size is a theme decision, not a Shopify decision. Shopify's own Liquid paginate documentation describes the tag as taking "The number of array items to include per page, between 1 and 250." (read August 29, 2026) — that is a ceiling, not a default. In our reading, stores landed anywhere between 10 and 48 products per page. So "it's on page 2" is not a fixed amount of scrolling; on one store page 2 starts at product 11, on another at product 49.

If products seem to be missing from a collection entirely rather than just sitting deep in it, that is a different problem with a different cause — we wrote it up separately in why a Shopify collection isn't showing all its products.

Where a product sits in your collection is not where a visitor enters. Someone arriving from search lands on whichever product page matched their query. That page may be one you have read a hundred times, or one you last saw the day you imported it — the collection position that decides whether you ever scroll to it does not decide which page they land on.

How we measured this

Sample. 18 live Shopify storefronts, read on September 8, 2026, taken at random from a public list of stores whose owners had posted their own URL on the Shopify Community's Store Feedback board. Everything here came from endpoints any browser can fetch.

Whether it looks like you. These are stores whose owners posted their own URL asking for feedback, so they skew newer and less established than a random Shopify store. On the September 1 reading of all 39 of them, the median catalogue held 130 products — but the 18 deep enough for us to count pages on ran larger than that, so the depth figures below describe the bigger end of the list, not a typical small store. Stores that had already stopped serving a storefront dropped out when the list was built, so what is left is the ones still trading.

The funnel. 39 storefronts in the public list carried products; we opened the biggest collection on each. 18 let us count page size from the storefront itself and are the basis for every page-depth number below. The other 21 could not be counted — 15 returned overlapping products on both pages, 2 rendered no product links we could read, 2 returned nothing on page two while the collection was larger, 2 ignored the page parameter — and are excluded rather than counted as one page.

The exclusion rule, fixed before we looked at the results. If we could not confirm from the storefront itself how many products a page holds, that store does not get a page count — which happens when the theme ignores the ?page= parameter, when it loads more products by scrolling instead of paging, or when the store rate-limited us.

Method 1: use the admin's filters instead of scrolling

The Shopify admin can narrow your catalogue by the fields it indexes. It filters on values that exist, not on emptiness — so use it to cut the catalogue into slices, then read the end of each slice, which is where the products you forgot about sit.

Open Products in the admin.
Use the search-and-filter bar to filter by Product type, Vendor, Tagged with, Collection, or Status.
Sort the result by Product title A–Z and jump to the last page rather than reading from the top.

What this method is good at: it costs nothing extra, it is immediate, and it works on any plan. What it is not good at: the admin filters on fields that exist. There's no filter for "the description is two sentences long", or for "this description was written for a different product".

Method 2: export a CSV and sort by what is missing

For anything the admin cannot filter on, export and sort.

Products → Export, then choose "CSV file for Excel, Numbers, or another spreadsheet program" (exporting products, read September 8, 2026).
Open the file and add a column with a formula for the thing you care about — for example the character length of the description column (Description in the current template; older exports call it Body (HTML)).
Sort ascending. The rows at the top are the product pages a visitor is most likely to bounce off of.

This is where CSV work usually goes wrong:

Each variant gets its own row. Shopify's product CSV guide describes it from the writing side: "enter all the fields for the product in the first row along with the URL for the first image. In the following rows, enter the URL handle. Then skip the **Title, **Description, **Vendor, and **Tags* columns."* (read September 8, 2026) So the rows after the first one are blank in exactly the columns you want to measure. Keep only the first row of each Handle before you sort.
That column holds HTML, so a "200-character" description can be mostly markup. Strip tags before you measure length, or you'll rank a <p><br></p> above a real sentence.
Re-importing matches on Handle: "when the handle in the import CSV file matches an existing handle in your products list, the values in the CSV file overwrite the values in the matching columns." (product CSV guide, read September 8, 2026.) Shopify also warns that "sorting your CSV file in a spreadsheet program can cause product variants or image URLs to become disassociated" (exporting products, read September 8, 2026) — so sort a working copy for analysis, and never re-import that copy.

Method 3: have something walk the whole catalogue

Both methods above have the same ceiling: you still have to decide what to look at, and you still have to write the fix yourself. For a catalogue that runs 7 pages that is an afternoon; for one that runs 241 it is not something you do once a quarter.

This is the part Arvio does. It reads the catalogue on your live store, flags where product data is missing or thin, and drafts the replacement text for you to approve — product by product. It's an operator you review, not a bulk find-and-replace you run and hope about.

It drafts; you approve. If you want something that rewrites 2,000 products without you reading any of them, this is the wrong shape of tool. And it only sees your product data — it can't tell you your pricing is wrong or that your photography is the problem.

See Arvio on the Shopify App Store →

Five things that quietly go wrong past page one

A separate reading of the same stores on 2026-09-01 — 20,659 products across 39 storefronts — says something more useful than an average. Missing product data is not spread thinly across a catalogue. It is closer to a switch that is either on or off for the whole store.

36% of all those products had no product type, while the median store was missing it on 9% of its catalogue. Both numbers are true, and the gap between them is the finding: three stores accounted for 75% of every missing value, and inside those three the field was empty on 85–99% of the entire catalogue. Counting stores instead of products splits them: of the 39, 15 were missing it on more than half their products and 18 on under 5% — only 6 sat anywhere in between. Catalogue size sorts those two groups the opposite way to the raw count — stores holding 72 products or fewer were missing it on a median of 46% of their catalogue, stores above that on 2%. Thin descriptions follow the same shape rather than being sprinkled evenly.

Before you start reading individual products, check whether a field is empty on everything — that is usually one import that did not carry the column, and it is one fix rather than a thousand.

Descriptions that stop after one line. (Product description examples if you want a shape to copy.) Usually the product was added in a hurry, or imported from a supplier feed that had nothing in the description field.
No product type. (How to add a product type in Shopify covers the field itself.) An empty Product type keeps the product out of every filter and automated collection rule built on that field — other filters, like Vendor or Status, still find it, but the merchandising that depends on type does not.
Images that were never re-checked. A product that has one photo has one chance to answer "is this the thing I searched for".
Copy written for a different variant. Very common after a catalogue import: the description describes the parent product, and every size or colour repeats it word for word.
Products that are still listed but no longer supplied. They keep their search ranking, take the click, and answer with a page nobody maintains.

None of these are conversion tricks. They are the reason a visitor who arrived with intent leaves without a reason to stay.

Three situations where this really is the problem

You get search traffic to product pages but the homepage numbers look fine. Check the landing pages in your analytics, not the sessions total. If the product pages taking the traffic are ones you can't remember writing, that's this problem.

Your catalogue arrived in bulk. Imported from another platform, a supplier feed or a CSV — we have a longer piece on cleaning up product data after an import. Whatever the source file did not carry, your store does not have — and the gaps are distributed across the whole catalogue, not the front of it.

Sales are concentrated in a handful of products. If most of your revenue comes from the products you personally wrote, that is not proof the rest are bad products. It is what you would expect if the rest were never finished.

Is there public data on how deep Shopify catalogues run?

We are not aware of a published figure, which is why we measured it ourselves. On September 8, 2026 we read 39 live Shopify storefronts taken from a public list and counted page size directly from the storefront on the 18 that let us: the biggest collection ran a median of 7 pages, the deepest ran 241, and themes were putting between 10 and 48 products on a page. The exclusion rule and the full funnel are in the method section above — 21 of the 39 could not be counted and are left out of every depth figure rather than counted as one page.

When this is not your problem

Which of these are you? The fix is different for each.

Small catalogue. If your whole store fits on one or two pages, you've already read all of it. Your conversion problem is somewhere else — price, shipping, trust, or the traffic itself being the wrong traffic.
No traffic to product pages at all. If visitors land on the homepage and leave, deeper product pages are not what is stopping them. Work on where the traffic comes from first.
Traffic that was never going to buy. If the visitors arriving were never in the market, better product pages won't turn them into buyers — check what the traffic is before you rewrite what it lands on.
You already have complete product data. Some stores do. In that case the catalogue is not where your answer is, and nothing in this article will help.

If you want the catalogue walked for you

Everything above is doable by hand, and for a store of a few dozen products doing it by hand is the right call. The reason to automate it is depth: the further your catalogue runs past what you can read, the less likely it is that you will ever get to the end of the list on your own.

That is the case Arvio is built for: it works down the list you would never reach, and you approve each draft before it goes anywhere.

See Arvio on the Shopify App Store →

FAQ

Why is my Shopify store getting traffic but no sales?

The usual answers — price, trust, shipping cost, checkout friction — are all real. This article is about the one that is hardest to see: visitors landing on product pages the owner has never read, because those pages sit past the first page of a collection. Check which pages your traffic actually lands on before assuming it is the homepage.

How many products does Shopify show on a collection page?

Shopify doesn't set it — your theme does. The Liquid paginate tag takes "The number of array items to include per page, between 1 and 250." (read August 29, 2026) In our September 2026 reading of live storefronts, themes were using between 10 and 48.

How do I find products with missing descriptions in Shopify?

The admin can't filter on description length. Export your products to CSV, strip the HTML from the description column, add a length column and sort ascending. Keep one row per Handle first — each variant gets its own row, and the rows after the first are blank in the description column.

Does thin product copy actually affect conversion?

It affects whether a visitor who landed with intent has a reason to keep reading. We haven't tested that. What we measured is how deep a catalogue runs — 7 pages at the median, on the stores where we could count it.

What else is usually empty down there?

Meta descriptions, most often — they are invisible on the page itself, so nothing prompts you to write them. We measured how many were missing across live stores in Shopify meta descriptions.

Should I rewrite my whole catalogue?

No. Sort by what is missing and start with the products that already take traffic. A product page nobody lands on doesn't get more valuable because it's well written.

Is this a Shopify problem?

No — it is a consequence of pagination, which every catalogue on every platform has. Shopify's admin filters are good at the fields that exist; the gap is that "thin" and "empty" are not the same thing, and only one of them is filterable.

What is the fastest way to see how deep my own catalogue goes?

Open your largest collection, count the products on its first page, and divide the number of products in that collection by that number. That is the number of pages your store has. Most owners have read the first one.

Originally published at https://arvio.a.xyz/blog/shopify-store-not-converting. More Shopify bulk-editing writeups are on the Arvio blog.

How to Add Product Type in Shopify When the Field Is Not on the Product Page

Arvio — Sun, 06 Sep 2026 13:10:36 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/shopify-product-type-missing. The canonical URL points back there.

If you opened a product, scrolled to the Organization card, and found Category, Vendor and Tags but no Product type, you did not miss it. On 2026-09-05 we read the full text of a product page in the current Shopify admin, including the content inside its shadow roots, and the string "Product type" appeared zero times anywhere you could see or click. That is one admin, on one store, on one day: if yours still shows the field, you are on an admin that has not changed yet, and the one-product route still works for you.

The field still exists. Products still carry a product_type value, and the endpoint that publishes a storefront's catalogue still returns it. The input box is still in that page's markup, but on the day we looked it sat inside a popover set to visibility:hidden — present, and not something you can click. The place it still has one is the bulk editor, which is the better place anyway: nobody with a real catalogue has one product to fix.

Key takeaways

The Product type field was not reachable on the product page in the admin we read on 2026-09-05. If that matches what you are seeing, the one-product-at-a-time route is closed to you.
The bulk editor still has a Product type column: /bulk?resource_name=Product&edit=product_type.
Sorting the Products list by Product type ascending floats every blank one to the top. That finds the gaps without exporting a CSV.
Product type and the newer Category (Shopify's taxonomy) are two separate fields. Filling one does not fill the other.
In 42 public storefronts we read on 2026-09-05, 2,054 of 5,937 products had no product type — 34.6% by product, and 13.5% at the median store, and 24 of the 42 stores had some products typed and some not. The two rates answer different questions and are not interchangeable — see the measurement section.

The quick version

Three steps, then you start typing.

Size the job. Open Products in your admin and sort by Product type, ascending. Products with no type sort first, so you can see how many there are and whether they arrived together.
Open the bulk editor on that one field. Your admin URL looks like admin.shopify.com/store/your-store/products. Replace everything from /products onward with:

   /bulk?resource_name=Product&edit=product_type

That opens a spreadsheet-style grid with a Product type column that accepts typing. It loads its own list of products — the sort you just did does not carry over, so keep the Products tab open if you want to refer back to it.

Type and save. Type the value into the Product type cell, then save.

That is the mechanism. The rest of this page covers the parts that go wrong: which field you are actually editing, how to avoid inventing a pile of near-duplicate types on the way through, and how much of a catalogue this usually affects.

Your catalogue already knows which types are missing

Arvio reads your live catalogue, finds the products with no product type, and proposes one for each based on that product's own title, tags and variants. Nothing is written until you approve it.

See Arvio on the Shopify App Store →

Product type and Category are two different fields

This is the single most common way the job gets done wrong, and it costs you the session, because you finish and the blanks are still blank.

Category is Shopify's standard taxonomy. You pick from a controlled tree, the values are the same in every store, and the platform uses it for things that need a shared vocabulary across all of Shopify. Category is on the product page, which is part of why people assume it replaced the older field.

Product type is your own user-defined label. You type whatever you want. Nobody validates it, nothing autocorrects it, and no two stores need to agree on it. It is the field that ends up in your automated collection conditions and in whatever internal filtering you have built for yourself over the years.

Two things follow:

Setting a Category on a product does not give it a product type. If you spent a session filling in categories and your collections still look wrong, this is why.
A product with a blank product type is not an uncategorised product. It may well have a Category. Those are different columns, and this page is only about one of them.

So: if your store has automated collections, theme filters or exports that read Product type, the blank rows are the ones behaving strangely. If nothing in your store reads it, blank costs you nothing. Check before you spend the afternoon.

Finding which products are blank without exporting a CSV

The usual advice is to export to CSV, filter the empty column, fix, re-import. That works, and it is also the route with the most ways to damage a catalogue: a re-import writes every column in the file, not the one you meant to change.

The Products list already does the finding part.

Sorting ascending puts empty values first. You now have three things you did not have a minute ago: how many blanks there are, which products they are, and whether they cluster (one supplier, one import, one collection) or are scattered at random. That clustering question decides how you fill them. A block arriving from one supplier feed usually wants a single type applied down the block. The same products scattered across the catalogue are that many separate decisions.

Sorting only changes what you are looking at. The list still holds everything else, so check the order is still the one you set before you trust the top of it.

The bulk editor is where the field still has an input box

Open the URL from the quick version. The edit=product_type part is what makes the grid show that column rather than the default set, which matters: a bulk editor showing every column it can show is that many columns of accidents waiting for a mistyped paste.

Product title is there so you can tell what you are typing about. Product category is there so you can see the taxonomy value beside the user-defined one: a row can carry a Category and still have no Product type, which looks broken until you know the two fields are unrelated.

What to actually type. The value is your answer to "what is this", in the noun a customer would use, at the level that groups several products. Mug groups things; Blue 350ml Stoneware Mug groups nothing. If the label describes an attribute instead of the thing (Sale, New, Summer), it belongs in Tags, because each product gets one product type and spending it on a season leaves nothing durable behind.

How to work the grid without making it worse:

Reuse before you invent. Check the types your catalogue already uses and copy one of them exactly. Every fresh string you type creates a new product type, and nothing in the store will tell you that you meant the one you created last month.
Fill in clusters. If a block of products came from one supplier or one import, do that block in one pass while the decision is still loaded in your head.
Save as you go. Save in batches instead of at the end. The further you get before saving, the more there is to redo if the tab goes.

It gives you the grid, not the answers. Every row still needs a human to decide what this product is and type it. For a short list that is fine. The grid is easy. The list is long. That is where people stop.

The bulk editor gives you the grid. The typing is still yours

Arvio proposes a type for every product that has none, drafted against that product's own title, tags and variants, so the job becomes reviewing a list instead of filling one in. You approve or discard each one.

Install Arvio on the Shopify App Store →

The same rows, after

Same grid, same rows, after typing and saving. The store in these three screenshots is our own demo store: 19 of its 68 products had no type, 27.9%, and it is not part of the 42-store denominator in the next section.

Two things to check after a save, because the grid says it saved and stops there:

Go back to the Products list and sort by Product type ascending again. The rows you just filled should no longer be at the top. That is the check that the write actually landed.
If you have automated collections with a Product type condition, look at their product counts. Filling in types moves products into collections, and that is usually what you wanted, but it should not be a surprise.

How often catalogues actually leave product type blank

How it was measured. On 2026-09-05 we requested /products.json?limit=250 from 43 public storefront domains. That endpoint is anonymous: no login, no browser, nothing authenticated. Of the 43, one did not respond and was excluded, leaving 42 stores and 5,937 products counted. A product counts as blank when its product_type is missing or empty once surrounding whitespace is trimmed.

Whether it looks like you. These 43 domains were collected because they publish machine-readable storefront metadata (UCP / agents.md), which skews the group toward newer and more technically tidy stores. For this particular question that pushes in the conservative direction: if anything, a group like this should have fewer blanks than a random store, not more. This is not a random sample and it is not the web. It is the same batch of public storefronts we used for our other catalogue measurement, not a second independent test of the same thing.

Measure	Value
Stores read	42 of 43 (1 excluded, no response)
Products counted	5,937
Products with no product type	2,054
Blank rate, by product	34.6%
Blank rate, median store	13.5%
Stores with nothing typed	9 of 42
Stores with some typed and some not	24 of 42
Stores with everything typed	9 of 42
Stores whose catalogue hit the 250-product read cap	16 of 42

The two rates are not interchangeable. 34.6% is per product, so large catalogues dominate it. 13.5% is the median store, so every store counts once. If you want "how much of the world's product data is untyped", use the first. If you want "what does a typical store look like", use the second. Quoting one as if it were the other is the mistake this table exists to prevent.

What the numbers do not cover. 16 of the 42 stores hit the 250-product cap on that endpoint, and those 16 account for 67% of the counted products, so for two thirds of the products here we read the front of the catalogue rather than all of it. And /products.json does not return the newer taxonomy Category at all, so this measures blank product type only. It is not evidence that these products are unclassified.

The row that matters most is the middle one. 24 of 42 stores had some products typed and some not. Somebody was doing this properly. Then a supplier feed, a migration or a busy month landed a batch of untyped products in the middle of the catalogue. That is the shape the bulk editor is built for, and it is also the shape that is hardest to notice, because the field looks filled in everywhere you happen to look.

Five ways this goes wrong in practice

Near-duplicate types. T-Shirt, T-shirt, Tshirt and Tees are four different product types as far as the store is concerned, and nothing warns you. The cost surfaces later, when a collection condition matches three of the four. Copy an existing value exactly instead of retyping it from memory.

Typing the category into the type column. They sit next to each other in the grid, and the taxonomy values are tempting because they sound official. Copying taxonomy strings into your user-defined field gives you a second, worse copy of a field you already have.

Types that are really tags. If a value describes an attribute rather than what the product is (Sale, New, Summer, Gift), it belongs in Tags. Product type is one label per product, so spending it on a temporary attribute means the product has no durable answer to "what is this".

Too many types. A type that fits one product is just a longer title. If you are creating a type per product, the useful level is one step up.

Assuming the fix propagated. Filling product type does not backfill Category, does not touch tags, and does not rebuild anything you exported earlier. A downstream system that took a copy of your catalogue yesterday still has the blanks.

Three catalogue shapes where this shows up

The supplier feed. Products arrive from a dropshipper or a supplier sheet where the type column was never mapped. They land in one contiguous block, which is the easy case: sorted list, bulk editor, one type down the block, done in a pass.

The migration. A store moves from another platform. The importer maps titles, prices and images cleanly, but has nowhere to put a field the old platform did not have. The result is a catalogue split at the move date, typed on one side and blank on the other. Sorting ascending makes that boundary visible immediately.

The catalogue that outgrew the habit. The early products were typed by hand by whoever built the store. Later, adding a product became something done in a hurry, and this field is the first thing a hurried person skips, because nothing on the product page asks for it any more. This is the 24-of-42 shape above: some products typed, some not, in the same store.

FAQ

Where is the Product type field in the new Shopify admin?
It is not on the product page. When we read the full text of a product page in the current admin on 2026-09-05, including inside its shadow roots, "Product type" did not appear. The field still exists on the product and still has an input box in the bulk editor at /bulk?resource_name=Product&edit=product_type.

Is Product type the same as Category?
No. Category is Shopify's standard taxonomy, chosen from a fixed tree and shared across all stores. Product type is your own user-defined label. Setting one does not set the other, and a product can have either, both, or neither.

Can I edit product type in bulk without touching a CSV?
Yes. That is what the bulk editor URL above does. It edits one field across many products in place, which avoids the main risk of the CSV route, where a re-import writes every column in the file rather than the one you intended to change.

How do I find every product with no product type?
Sort the Products list by Product type, ascending. Empty values sort first, so the blanks collect at the top. No export needed.

Do I have to fill product type in at all?
Only if something in your store reads it: automated collection conditions, theme filtering, exports, or your own reporting.

How many product types should a catalogue have?
Few enough that each one groups several products. A type matching a single product groups nothing. We have not measured this, so treat it as a rule of thumb, not a benchmark.

Is a blank product type the same as an uncategorised product?
No, and our own measurement cannot tell you about the second one. The /products.json endpoint we read does not return the taxonomy Category, so all we can say is that the user-defined product type was empty.

Will filling in product types change my collections?
It can, if you have automated collections whose conditions use Product type. Products that suddenly match a condition will join that collection. Check the product counts on those collections after a bulk save so the change is something you saw rather than something you discovered later.

If the grid is the part that stops you

The bulk editor solves the access problem: the field has an input box again, and you can reach a screenful of products at a time. It does not solve the volume problem. Every row is still a decision, and the decision does not get faster with repetition.

One screen of the grid is quick. The rest of the catalogue is why people stop

Arvio is an AI store operator: it reads the catalogue you already have, proposes the change per product, and waits for you to approve it.

Install Arvio on the Shopify App Store →

Not ready to install anything? Run the free store audit on your storefront. It needs no account. It does not look at product type — it checks the storefront side: speed, SEO, mobile, checkout, conversion, and how ready the store is for AI shopping surfaces.

Product page field check and the 43-domain catalogue read were both done on 2026-09-05.

Originally published at https://arvio.a.xyz/blog/shopify-product-type-missing. More Shopify bulk-editing writeups are on the Arvio blog.

Product description examples, and what 8,019 live products actually look like

Arvio — Sun, 06 Sep 2026 13:08:35 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/product-description-examples-shopify. The canonical URL points back there.

Every article about product descriptions shows you an example, and almost none of them say where it came from. Usually somebody wrote it for the article. That demonstrates a style perfectly well, but it tells you nothing about what a description on a real store looks like, or how yours compares.

So we read some. Using the public catalogue endpoint that most Shopify storefronts expose, we read 225 live storefronts and measured the description on all 8,019 products they returned. The most common problem was not the one we went looking for. Empty descriptions turned out to be fairly rare, at 389 of 8,019. What is everywhere is repetition: 1,613 products, one in five, carry a description that another product in the same store carries word for word.

One thing to be straight about, since the first paragraph makes an issue of it: the worked example further down is written for this article too, and it is invented on purpose, because holding up a real store's page as the bad one is not something we are willing to do. What the 8,019 products give you is the measurement, which is to say how common each failure actually is, and therefore which one is worth your afternoon.

This applies to any catalogue with more products than patience, on Shopify or anywhere else. The measurement happens to come from Shopify storefronts, because that is the platform where the catalogue is usually readable without asking anyone's permission.

Key takeaways

1,613 of 8,019 products (20.1%) repeat another product's description word for word in the same store, ignoring case and whitespace. This showed up on 111 of the 225 storefronts.
1,265 (15.8%) run under 200 characters, and 389 (4.9%) are completely empty. The empty ones are counted inside the 1,265.
The empty page is not the main event. 184 of the 225 storefronts had no empty description anywhere, and only 3 had nothing written on any product.
Length is not quality. The median description ran to 701 characters, and a long paragraph of adjectives is worse than 200 characters of specifics.
A description is doing three jobs at once, and the fill-in template below separates them: what the thing is, who it suits, and the specifics a buyer would otherwise have to email you about.

The descriptions at the end of the product list are the ones that never get written

Arvio reads your live catalogue, tells you which products have an empty or one-line description, and drafts each one against that product's own title, type, tags and variants. Nothing is saved until you approve it.

See Arvio on the Shopify App Store →

Check your own catalogue first

Before copying anyone's example, look at what you already have. Most Shopify storefronts publish their catalogue as JSON, with no login and no app:

https://your-store.com/products.json?limit=250

This script runs the same two tests, in the same order, that produced the numbers below. Two differences are worth knowing before you compare: we stopped at 50 products per store and this walks your whole catalogue, and our sample is 225 stores while yours is one.

# save as descriptions.py, then: python3 descriptions.py your-store.com
import json, re, sys, time, urllib.request
from collections import Counter

host = sys.argv[1]
products, page = [], 1
while True:                            # 250 at a time, until the catalogue runs out
    url = "https://%s/products.json?limit=250&page=%d" % (host, page)
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    batch = json.load(urllib.request.urlopen(req))["products"]
    products += batch
    if len(batch) < 250:
        break
    page += 1
    time.sleep(1)

def plain(html):                       # length test: strip the tags, decode the
    text = re.sub(r"<[^>]+>", " ", html or "")     # entities a browser would have
    for a, b in (("&nbsp;", " "), ("&amp;", "&"), ("&lt;", "<"),
                 ("&gt;", ">"), ("&#39;", "'"), ("&quot;", '"')):
        text = text.replace(a, b)                  # rendered, then collapse the
    return re.sub(r"\s+", " ", text).strip()       # whitespace and count

def norm(html):                        # duplicate test: the same, then lowercased
    return plain(html).lower()

lengths = sorted(len(plain(p.get("body_html"))) for p in products)
# empty descriptions are counted once as empty, not as copies of each other
seen = Counter(norm(p.get("body_html")) for p in products if plain(p.get("body_html")))

print("products read   ", len(lengths))
print("empty           ", sum(1 for n in lengths if n == 0))
print("under 200 chars ", sum(1 for n in lengths if n < 200))
print("same as another ", sum(1 for p in products
                             if seen[norm(p.get("body_html"))] > 1))
print("median length   ", lengths[len(lengths) // 2] if lengths else 0)

for p in products:
    text = plain(p.get("body_html"))
    if not text:
        print("  fix (empty):", p["handle"])
    elif seen[norm(p.get("body_html"))] > 1:
        print("  fix (copy): ", p["handle"])
    elif len(text) < 200:
        print("  fix (thin): ", p["handle"])

That last loop prints the handles, labelled by which problem they have, which is your work queue.

What we measured

Two tests, run over every product we could read. Length is characters after tags and whitespace are stripped. Duplication is that same text lowercased, then compared against every other product in the same store.

Finding	Products	Share
Same text as another product in the same store	1,613	20.1%
Under 200 characters	1,265	15.8%
Description completely empty	389	4.9%

The first row is scored on a different test from the other two, so a product can land in more than one of them. Inside the second row, 389 are empty and 876 have somewhere between 1 and 199 characters. Read those as two separate problems wearing the same symptom: pages that were never written, and pages where somebody typed one sentence and moved on.

The store-level view is what changed our mind about which problem matters:

At the store level	Stores
Have at least one description repeated on another product	111 of 225
Have no empty description anywhere	184 of 225
Have nothing written on any product	3 of 225

We expected the empty page to be the story. It is not. Four out of five of these stores have written something on everything they sell, and only 3 of 225 had left the whole catalogue blank. Meanwhile half of them have at least one description sitting on two products at once, which is a different kind of failure: not a missing page, a page that was filled in by copying the one above it.

Here is the length spread, for context rather than as a target:

Measure	Chars
Shortest quarter, below	347
Median	701
Longest quarter, above	1,285
Longest single product	23,335

What this sample does not tell you:

We read up to 50 products per store. 126 of the 225 storefronts hit that ceiling, and those stores account for 79% of the products counted. So the shares above describe the front of a catalogue, not the whole of one. If the unwritten pages cluster at the end of the product list, which is where they usually collect, this measurement misses them.
The stores chose themselves. They come from a public list of merchants who posted their own storefront URL asking strangers for a review. That is not a random draw from Shopify, and these stores skew newer and smaller.
That self-selection runs one way. Somebody who asks the internet to critique their store is paying attention to it. Whatever these numbers say about sloppy descriptions, the wider population is unlikely to be tidier.

The template

Copy this. It is deliberately short, because the failure modes we measured are absence, thinness and repetition, and no amount of styling advice fixes any of the three.

[One sentence: what the thing is, in the words a buyer would use.]

[Two or three sentences: who it suits and what for. Name the situation.
"Fits a 13-inch laptop and a water bottle" beats "spacious and versatile".]

Details
- [Material / composition]
- [Dimensions or size, with units]
- [What is included in the box]
- [Care, compatibility, or anything a buyer would otherwise email to ask]

[One sentence: the thing that would make somebody return it. Say it
plainly. This is the line that stops the return, and it is the line
most descriptions leave out.]

The first sentence is doing most of the work, because on a phone the description often sits collapsed behind a tap and that line is all anyone sees. The bullet block underneath is where the specifics live, and specifics are exactly what a buyer cannot get from the photo.

The bullets are also what makes the template survive being reused. The prose at the top can be similar across a product family without much harm. The moment the dimensions, the contents and the care line are copied across as well, you have two pages that a buyer cannot tell apart, which is the shape 1,613 of the products we read are in.

The last line looks like it is talking people out of buying, and it is. Naming who the product is wrong for costs you a few sales you would have refunded anyway, and it is what makes the four lines above it believable.

None of this is a keyword slot. The search side of a product page lives in different fields, which we wrote about separately in Shopify meta descriptions.

The same product, written twice

Both of these are written for this article. The product is invented so that no real store is being held up as a bad example.

Before:

Beautiful handmade ceramic mug. Perfect for coffee lovers. Order yours today!

After:

A 350 ml stoneware mug, thrown and glazed by hand, so no two are the
same shade.

It is heavier than a standard mug, which is the point if you drink
coffee slowly and hate a cold last mouthful. The handle takes two
fingers, so it sits differently in the hand than a standard mug.

Details
- Stoneware, food-safe reactive glaze
- 350 ml, 9 cm tall, 8.5 cm across the rim
- 460 g empty, roughly a third heavier than a thin-walled mug
- Dishwasher and microwave safe
- Sold singly, not as a set

If you want a matched set of six, this is the wrong mug. Colour varies
between firings, so two of these will rarely be an exact match.

The second version is longer, but that is a side effect. What actually changed is that six questions got answered: capacity, weight, dimensions, care, whether it is a set, and whether the colour is consistent. The first version answers none of them and asks for the order anyway.

Notice what happens if you paste that second version onto the same mug in a different glaze. Five of the six answers still hold, one of them is now wrong, and the page has stopped being about the product in the photo. That is how a description ends up on two products at once, and it rarely happens on purpose.

You now have the template. The catalogue is the hard part

Arvio takes the same shape you just filled in by hand and applies it product by product, using each product's own data instead of a generic paragraph. You review every draft and can undo any of them.

Install Arvio on the Shopify App Store →

Where the work actually is

Writing one good description is a pleasant afternoon's work. Writing them until the product list runs out is a different activity, and that gap is where both the empty pages and the copied ones come from. A copied description is what an empty one looks like after somebody decided the page could not ship blank.

Three ways through it, in the order most stores try them:

One at a time in the admin. Workable while the product list still fits on a screen or two. Open the product, write, save, back to the list, and repeat. The cost is all in the switching, and duplicating an existing product to save that cost is exactly what puts the same paragraph on two pages.

A CSV round trip. Export, edit Body (HTML) in a spreadsheet, import with overwrite. Faster for a large batch, and it is the route where the mistakes are expensive: a column present in the file but left blank will write an empty value over your live one. Delete the columns you are not changing before you import. A spreadsheet is also the fastest place to spot repetition, because sorting on the description column stacks the identical ones next to each other.

The bulk editor. Shopify's bulk editor shows one field across many products at once, which suits this job better than the product page does. We covered how to open it and which fields it can reach in bulk editing product descriptions.

If the thin or repeated descriptions all arrived on the same day, they probably came in together from a supplier feed or an import. That has its own pattern and its own fix, which we measured in cleaning up after an import.

FAQ

Which products should I fix first?

Empty ones, then the repeated ones, then the thin ones, and inside each group start with whatever you actually sell. The script prints handles in catalogue order, so it is worth re-sorting that list against your own sales before you begin.

Is it a problem if two products share the same description?

It was the most common thing we found: 1,613 of 8,019 products, on 111 of 225 storefronts. The cost is not a penalty handed down by anybody, it is that two pages a buyer cannot tell apart force them to work out the difference themselves, and some of them will not bother. The fix is usually small. Keep the shared paragraph, replace the specifics underneath it.

How long should a product description be?

There is no target. In what we read, half of the products sat between 347 and 1,285 characters, with a median of 701, and the longest single description ran to 23,335. That spread is context, not a benchmark. A 200-character description that answers the size question beats an 800-character one that does not.

Do I need a description on every product?

Search engines and shopping surfaces read the description field, so an empty one is a page with less to work with. The stronger argument is simpler: a product page with no description asks a visitor to guess, and some of them will guess wrong and return it.

Should I write the description or let a model draft it?

A model drafting against a product's own title, type, tags and variants gives you something to edit, which beats an empty box. A model writing from the product name alone will invent specifics. The difference is what you feed it.

What about alt text on the product images?

Worth doing, and a separate job, and the script above cannot audit it. In a different and much smaller read, 41 storefronts on 4 September 2026, the public catalogue endpoint listed 391 product images and returned no alt value on any of them. Read that as a fact about what the endpoint hands back, not as a count of stores that left the field blank, since the admin holds alt text the endpoint does not publish. It is also not the sample described above, so the two should not be added together.

Method

Sample. 225 live Shopify storefronts, read on 5 September 2026, taken from a public list of stores whose owners had posted their own URL on the Shopify Community's Store Feedback board. Everything here came from endpoints any browser can fetch. Store names, domains and product names are deliberately not published.

The funnel. 230 stores on the list, 225 answered, 5 did not and are in no denominator. We requested up to 50 products from each and read 8,019 in total. 126 stores returned the full 50, which is the ceiling we set, and those stores hold 79% of the products counted, so treat every share above as describing the front of a catalogue rather than all of it.

Definitions. Length is the character count after HTML tags are stripped and whitespace is collapsed. Duplication is that same text lowercased and compared with every other product in the same store, so it is a separate test from length and a long description can still be a copy. Both are the definitions the script above uses.

Whether it looks like you. Stores that post their URL asking for feedback skew newer and smaller, and the list was built from stores still trading at the time, so anything that had already gone dark is missing. It is a convenience list, not a random draw from Shopify, and it leans one way we should say out loud: a merchant who invites strangers to critique their store is more likely than average to have tidied it first.

One page is a pleasant afternoon. The rest of the catalogue is why people give up

Arvio is an AI store operator: it reads the catalogue you already have, proposes the change per product, and waits for you to approve it.

Install Arvio on the Shopify App Store →

Not ready to install anything? Run the free store audit on your storefront. It needs no account, and it reports empty and thin descriptions alongside the rest of your catalogue's data.

Originally published at https://arvio.a.xyz/blog/product-description-examples-shopify. More Shopify bulk-editing writeups are on the Arvio blog.

Sold out products still showing on Shopify: which of the two problems you have

Arvio — Sat, 05 Sep 2026 01:31:00 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/shopify-sold-out-products-still-showing. The canonical URL points back there.

Published September 3, 2026 by Adot Technologies Inc, the team behind Arvio: AI Store Operator. We read the public catalogue and the default collection listing on 30 live Shopify storefronts on September 3, 2026. Every measurement of those storefronts below comes from the 20 that returned a complete list; where this article gives numbers about the sampling frame itself — how many candidate domains there were, how many were dropped — those describe the frame, not the 20.

Two people type this phrase, and they have opposite problems.

One has a product sitting in a box in the back room, and the storefront says sold out. The other has products that really are gone, and they are still on the collection page, above the things a shopper could actually buy.

The fixes have nothing in common, so the first job is telling them apart. That takes one request.

Key takeaways

If something you have in stock reads as sold out, look at locations before you look at your theme. Shopify's rule is inventory-level based, and an item can sit at a location that does not fulfil online orders while your online store still calls it out of stock.
If they really are sold out, Shopify does not remove them from your collections for you. On the 20 stores where we could read the whole list, every sold-out product was still in /collections/all: 211 of 211.
42 of those sold-out products sat in the first 24 positions of the default collection, and 9 of the 20 stores had at least one that high. The earliest sat in slot 1.
Catalogue size is the one thing that separated these stores — as a direction, not a rate. The 16 stores under 100 products had a median of 0.0% sold-out products on the shelf. The four stores over 100 had a median of 28.2% — four stores, so read that as a direction, not a rate.
Shopify documents the fix, and documents the way it silently fails: an automated collection condition on inventory, which does nothing at all if the collection is set to match any condition instead of all.

Your collection page is showing customers things they cannot buy

Finding them costs nothing — the script further down does it, and you should run it either way. Deciding what each one should say afterwards is the part that takes an afternoon: Arvio reads your catalogue's text fields, drafts the changes and applies nothing you have not approved.

Install Arvio on the Shopify App Store →

The check that tells you which problem you have

Your store publishes its catalogue as JSON, to anyone, with no app and no login. Open this in a browser tab:

https://yourstore.com/collections/all/products.json?limit=250

That returns 250 products at most. If your catalogue is bigger, add &page=2, &page=3 and so on until a page comes back empty — this is the same ceiling that made us throw out ten of our own thirty reads, and a truncated list looks exactly like a clean one.

Search that page for "available":false. Then:

A product you believe is in stock comes back with available: false on every variant → problem 1. It is a stock or location setting, not a display bug.
Products you know are sold out are present in the list at all → problem 2. They are still on your shelf, and the list order is the order shoppers scroll.

Same request, piped through python3, prints the slot number and handle of each one:

python3 -c "
import json, time, urllib.request
store = 'yourstore.com'          # <- your domain
slot = 0
for page in range(1, 21):        # 20 pages = 5,000 products
    url = 'https://%s/collections/all/products.json?limit=250&page=%d' % (store, page)
    req = urllib.request.Request(url, headers={'User-Agent': 'shelf-check/1.0'})
    products = json.load(urllib.request.urlopen(req))['products']
    if not products:
        break
    for p in products:
        slot += 1
        v = p.get('variants') or []
        if v and all(x.get('available') is False for x in v):
            print(slot, p['handle'])
    time.sleep(1)
print('read %d listed products' % slot)
"

The last line is the check on the check: if it reports fewer products than your collection holds, the pages ran out early and everything above it is a partial answer.

Slot 1 to 24 is roughly a first page: we could not find a documented platform default, and the first collection page on eight of these stores came back holding anywhere from 5 to 42 products, so treat 24 as our cut rather than as your theme's. That is the same read we ran against 30 storefronts; the numbers below come from the 20 whose lists came back complete.

Problem 1: it says sold out and you are sure you have stock

Shopify's definition is narrow, and both halves of it carry weight: "An item is out of stock when inventory is tracked and the inventory level is at zero or below." (Selling out of stock products) Two conditions, and both have to hold. So there are three places this goes wrong, in the order to check them.

Inventory tracking is on, and the number really is zero. The storefront is reporting your data correctly. Adjust the quantity, or let it sell anyway: the Continue selling when out of stock setting lives in the Inventory section of a product or variant, and Shopify only offers it when the Inventory tracked setting is on.

The stock is at a location that does not fulfil online orders. This is the one that wastes afternoons, and Shopify (Selling out of stock products) states the behaviour plainly: if an item is at a location that fulfils online orders with an inventory level of zero or below, and at another location that has stock but does not fulfil online orders, "then that item is still displayed as out of stock to customers on your online store." The quantity in your admin looks fine. The storefront is not wrong.

A dropshipping app location is missing shipping rates. Shopify's own note (Selling out of stock products) points here when products show out of stock while inventory is available: "If you're using a dropshipping app and your products display as out of stock even though inventory is available, then your app location might be missing shipping rates." Check the app's location before you touch the theme.

For the location case above, Shopify also states the fix in one sentence: "You need to add stock to your location that fulfills online orders to allow customers to purchase that product." That is the whole repair — it is a stock move, not a theme change, and no setting in your theme will substitute for it.

None of those three? Then the product is genuinely unavailable, and you are in problem 2.

Problem 2: they really are sold out, and they are still on the page

Here is what live stores do, rather than what the setting descriptions imply.

We read two public endpoints on each store: the catalogue at /products.json and the default collection at /collections/all. Both cap out at 250 rows, so a store whose list hits the cap has products we never saw, and we dropped those stores. That leaves 20 stores where both lists came back complete.

	Stores	Products listed	Sold out	Still listed in the collection	In the first 24 slots
Complete reads	20	920	211	211	42
Hit the 250-row cap	10	excluded	excluded	excluded	excluded

Every sold-out product was still on the shelf — all 211 of them. Across 20 stores, not one had been taken out of the default collection. Read the shape of that evidence before you carry it: only 10 of the 20 had any sold-out product to hide, so the other 10 neither support this nor contradict it, and two of those 10 account for 166 of the 211.

The totals hide the spread. The median store has 2.2% of its collection taken up by things nobody can buy, which is a rounding error. The worst share in the sample was 82 of 156 listed products sold out — 52.6%, more than half the shelf; the biggest pile by count was 84 sold-out products in a catalogue of 176. Ten of the 20 stores had any sold-out product listed at all, and in 9 of them a shopper meets one before scrolling: across those nine the earliest sat in slot 1 and the median first hit was slot 3. In the tenth, the first one sat in slot 31, past the first screen.

Whether this looks like you

Sixteen of these 20 stores carry fewer than 100 products, and their median sold-out share is 0.0%. We cannot see why from outside — a small catalogue may simply never have had much sitting in it. The four stores with 100 or more products have a median of 28.2% — and that median describes none of them. Their four values are 4.6%, 8.7%, 47.7% and 52.6%: two stores with a little and two with half the shelf, with nothing in between. The median sits in the gap.

Four stores is not a rate you should plan against, and 100 products is a cut point we chose after looking at the data, not before. So we moved it — with one thing said plainly: cutting at 75 selects the same four stores as cutting at 100, so that is not a second test. The cuts that do change the grouping are 50 (six stores, median 8.1%) and 150 (two stores, median 50.1%). The smaller side has a median of 0.0% at every one of them, and the direction holds every time; what moves is how much you can say about the larger side, which never gets above six stores. What that says is where to look: if your catalogue is small, run the command above and you will probably close this tab. If you carry hundreds of products, assume the shelf has gone stale until you have checked it.

What Shopify's help page says, and what we read

Shopify's own documentation describes the default listing this way: "By default, your store comes with a collection that displays all your in stock products at the URL your-store.myshopify.com/collections/all." (Hiding out of stock products)

Read that sentence as a merchant and you would not expect what we found. Both are on the record: that sentence is what the help page says, and the JSON above is what the endpoint returned. The Catalog collection is a Shopify-managed default, and it may mean something looser than a shopper would read into it. If that sentence is your model of your own storefront, open the JSON and look.

How to hide them, the way Shopify documents

The mechanism is a collection condition, and it is the same three steps for every collection:

Turn on inventory tracking for the products. Without it there is no inventory level to test, and the condition below cannot fire.
In the collection, add the condition Inventory stock is greater than 0.
Set the collection to match all conditions. This is the step that fails silently: Shopify's page on hiding out of stock products carries the note "This solution for hiding out of stock products won't work if you set Products must match to any condition." No error, no warning, and the collection keeps listing everything.

Two more things from that same page:

The default Catalog page needs its own treatment. You take control of /collections/all by overriding it with your own collection, then set that collection's automated conditions the same way.
It reverses itself when stock comes back. "Any out of stock products display in your collections again after you receive inventory." This is a display rule, not a decision about the product.

If you would rather it happen on a schedule than as a condition, Shopify Flow has a Publish and unpublish products based on inventory level template, which acts on the product rather than on the collection. That is a different outcome: a collection condition hides the product from a list, while unpublishing takes the product page down. Whether you want the second one is a real question with SEO consequences on both sides, and we worked through it separately in unpublishing out-of-stock products on Shopify.

Turning the condition on takes two minutes. Working through the catalogue behind it does not.

Arvio goes through your products one at a time. What it changes, what it leaves alone and what it got wrong on a real store, we wrote up separately in what Arvio actually does.

Install Arvio on the Shopify App Store →

What this article does not know

We have no admin access to any of these stores. So we cannot tell you whether a store shows sold-out products by accident or on purpose, and plenty of stores do it on purpose: a sold-out product page keeps the URL that already ranks, and it keeps collecting demand signal.
We read the JSON list, not the rendered page. A theme can grey out or visually hide a product that is still present in the list. Everything above is about what the collection publishes, not about what pixels a shopper sees.
Ten of the 30 stores hit the 250-row cap on the collection list and are excluded from every number here. Bigger catalogues are exactly where this problem concentrates, so what we measured is the smaller half of our own sample.
"First 24 slots" is our cut, not a platform constant. We could not find a documented Shopify default; shopify.dev only says a paginated list holds "between 1 and 250" items. When we counted what the first collection page actually returned on eight of these storefronts we got 5, 12, 16, 16, 16, 20, 24 and 42 products. So read "the first 24" as the first two dozen positions in the listing — for some themes that is more than one screen, for others less.
One read, one day. A collection is a live object; a store that looked clean on September 3 may not be clean next week.

How this was measured

Sample. The frame is built from store URLs their owners posted publicly on the Shopify Community asking for feedback: 720 topics, 474 distinct store domains, of which 230 still served a catalogue on August 26, 2026. From those 230 we drew 60 at random with a recorded seed (20260826), then asked the first 35 in alphabetical order; 30 answered, and 20 of those returned complete lists. Only the 230 to 60 step is random — the 35 is a prefix of that draw, so the seed reproduces the 60, not the 35.

The biggest bias is survivorship. Of the 474 candidate domains, 244 no longer served a catalogue at all. Stores that closed are missing from every number here, and a closed store is not a store that kept its shelf clean. The frame also skews newer and smaller than the Shopify population.

Endpoints, September 3, 2026. Per store: one GET /products.json?limit=250 and one GET /collections/all/products.json?limit=250, one request per second, with a user agent identifying our research crawler and carrying a contact address. No authentication, no app, nothing that is not public.

Sold-out definition. A product counts as sold out when it has variants and every variant reports available: false. Products with some variants available are not counted. We never see inventory quantities — available is what the storefront publishes.

Position. We take the collection order as returned and record the 1-based slot of each sold-out product. First screen is slots 1 to 24.

Exclusion rule. Both endpoints return at most 250 rows. Any store whose collection list came back at 250 rows is excluded from every denominator, because the sold-out products we found in its catalogue may simply be past the cut. That rule removes 10 of the 30 stores. It also removes an artefact: counted naively across all 30 stores, 163 sold-out products look as though they were kept out of the collection, and on the 20 complete reads that number is zero, store by store.

FAQ

Does Shopify hide sold-out products automatically?
No. Nothing in the default setup removes a sold-out product from a collection. Hiding it is a collection condition you add, an app, or a Flow workflow — and on the 20 stores we could read completely, every sold-out product we found was still listed.

Why does a product show as sold out when I have stock?
Because Shopify calls an item out of stock when inventory is tracked and the level is zero or below at the locations that fulfil your online orders. Stock at a location that does not fulfil online orders does not count, and Shopify says such an item is still displayed as out of stock on your online store.

Should I hide sold-out products or unpublish them?
Different outcomes. Hiding removes the product from a collection while its product page stays up. Unpublishing takes the page down, along with whatever that URL had earned. We went through that trade-off in unpublishing out-of-stock products.

Will the condition hide products I want to keep visible?
It hides everything at or below zero inventory, including things you are happy to keep listed for preorder. If you want those to stay purchasable, turn on Continue selling when out of stock for them, which keeps them buyable rather than merely visible.

How do I know it worked?
Re-run the command at the top of this article. It reads the same list a shopper's browser reads, so if a handle still prints, the product is still on the shelf.

Does any of this affect Google?
Only indirectly, and not through this file. What Google reads is your product pages and structured data, and a sold-out product publishes an availability value there too. That is a separate check, and we measured it separately in products missing from Google Shopping.

Arvio: AI Store Operator — install it on the Shopify App Store. The condition is one setting; the catalogue behind it is the work.

Originally published at https://arvio.a.xyz/blog/shopify-sold-out-products-still-showing. More Shopify bulk-editing writeups are on the Arvio blog.

Shopify structured data errors: which ones actually occur

Arvio — Sat, 05 Sep 2026 01:29:20 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/shopify-structured-data-errors. The canonical URL points back there.

Published September 3, 2026 by Adot Technologies Inc, the team behind Arvio: AI Store Operator. The counts below come from parsing every JSON-LD block on 84 product pages across 30 live Shopify storefronts on September 3, 2026.

The obvious way to attack a structured data problem is product by product: audit the catalogue, fix the bad ones, keep auditing.

We went to check that. Seven things that can go wrong, 84 product pages, 30 distinct storefronts. Four of the seven never happened once. Two of the three that did were store-wide: every store that published no product markup published none on every page we read, and every store with an unparsable block had one on every page. The third — a product node with no image — varied from page to page inside the same store.

So checking gets cheaper. If your markup is broken, one product page will tell you.

Key takeaways

23 of the 30 stores had none of the three failures, on every page we read — two or three pages each, from a convenience frame of stores that asked a public forum for feedback, not a random sample of Shopify.
Seven pages published no product markup at all — four of them carried no JSON-LD whatsoever, three carried only a business block. All seven came from three stores.
Six pages carried a JSON-LD block that will not parse. All six still had valid product markup: the broken block sits beside the product node, not on top of it. Two stores, every page.
Four errors people are warned about did not occur once: no page carried competing product nodes, no price was non-numeric, no availability value was unrecognised, and every variant-group node carried its variants.
The one place the page and the catalogue disagreed, the page was the pessimistic one. Prices agreed on all 77 pages that had a product node. Availability disagreed on exactly one page: the markup said out of stock for a product the catalogue said you could buy.

Structured data breaks by store, not by product

Structured data comes from your theme. The fields it publishes come from your catalogue — and that half is what Arvio reads, drafts, and hands back for your approval.

Install Arvio on the Shopify App Store →

Check your own store in one request

Structured data is in the HTML your storefront serves anyone. Pick any product page and run this. It prints one line per JSON-LD block, says whether the block parses, and names the types inside it:

curl -s "https://yourstore.com/products/your-product-handle" \
| python3 -c "import sys,re,json
html = sys.stdin.read()
blocks = re.findall(r'<script[^>]*application/ld\+json[^>]*>(.*?)</script>', html, re.S)
print('%d JSON-LD block(s)' % len(blocks))
products = 0
for i, b in enumerate(blocks, 1):
    try:
        data = json.loads(b)
    except Exception as err:
        print('  block %d  DOES NOT PARSE  %s' % (i, err))
        continue
    nodes = data if isinstance(data, list) else [data]
    if isinstance(data, dict) and isinstance(data.get('@graph'), list):
        nodes = data['@graph']
    for n in nodes:
        if not isinstance(n, dict):
            continue
        t = n.get('@type')
        keys = sorted(k for k in n if not k.startswith('@'))
        print('  block %d  %-14s %s' % (i, t, ', '.join(keys)))
        if t not in ('Product', 'ProductGroup'):
            continue
        products += 1
        offers = n.get('offers') or []
        if isinstance(offers, dict):
            offers = [offers]
        for o in offers[:3]:
            if isinstance(o, dict):
                print('      offer %-14s price=%r low=%r high=%r availability=%r'
                      % (o.get('@type'), o.get('price'), o.get('lowPrice'),
                         o.get('highPrice'), o.get('availability')))
        if t == 'ProductGroup':
            print('      hasVariant: %d' % len(n.get('hasVariant') or []))
print('product nodes on this page: %d' % products)"

Six of the seven checks below are in that output. Whether a Product or ProductGroup type appears at all, and whether any block says DOES NOT PARSE, are the first two lines you read. Whether image is in the key list next to the product type is the third. The last line — product nodes on this page — is the competing-nodes check: anything above 1 is two product nodes fighting over the same page. And the indented offer lines are the format checks: price should be a bare number, not $24.00, and availability should be one of the schema.org values. A ProductGroup prints its hasVariant count, and a group that publishes no variants prints 0. The seventh check, whether the markup agrees with your catalogue, needs a second request — to your own /products.json.

One caveat on running it once: our sample is at most three product pages per store, and one store gave us only one. So when we say a failure was the same on every page of a store, that means the two or three pages we read, not the catalogue.

What we tested, and what we found

What we checked	Pages	Stores
No product markup on the page at all	7 of 84	3
A JSON-LD block that will not parse	6 of 84	2
Product node with no `image` property	5 of 77	3
Two or more competing product nodes	0 of 84	0
A price that is not a number	0 of 77	0
An availability value outside the vocabulary	0 of 77	0
Variant group published without its variants	0 of 27	0

Of the 84 pages, 50 published a Product node, 27 published a ProductGroup, and 7 published neither. The typical page carries two JSON-LD blocks; 44 of the 84 do.

The three that occurred

Product pages with no product markup

Seven pages, three stores. One store served no JSON-LD at all on all three pages we read; a second served exactly one block on each of its three pages, describing the business rather than the product; the third had only one page in our sample, and that page carried no JSON-LD either.

Those seven pages are not all the same failure. Four of the seven served no JSON-LD at all — not a business block, not a breadcrumb, nothing. The other three served exactly one block describing the business, and nothing describing the thing for sale. Those three pages do have something a validator can approve of — an organisation block — and nothing at all describing the thing for sale. We did not run a validator against them, so what any specific tool reports is not something this survey can tell you.

This looks like a theme-level property: in all three stores it held on every page we read. We did not record which theme or app each store runs, so we cannot say which of those explains it.

What that costs, stated the only way we can state it. We have no traffic data for these stores, so we cannot tell you what those seven pages lost. What we can tell you is what Google publishes as the rule. Its product structured data documentation says: "You must include the required properties for your content to be eligible for display as a rich result." — and the required properties for a product snippet are "Product snippets require either review or aggregateRating or offers", with the page needing "You must include one of the following properties: review aggregateRating offers". A page with no product node has none of them. So the seven pages are not a style problem with an unknown cost: on the platform's own written rule they are outside the door, and the three that publish an organisation block instead are outside it in exactly the same way. What we cannot tell you — and nobody can from the outside — is how much traffic was on the other side of that door for these particular stores.

A JSON-LD block that will not parse

Six pages, two stores, every page we read from each. On all six, the page still carried a valid product node.

The combination matters more than either half. One store's pages carried four blocks each — a breadcrumb, a website block, the product, and one that would not parse. The other's carried three — a business block, the product, and the broken one. On all six pages exactly one block was malformed. A parser that stops at the first error reports the page as broken. A parser that reads block by block gets the product fine and discards only the block that failed. We have no Search Console for these stores, so which of those any given search engine does is outside what we measured.

So the practical severity depends on which block broke. Losing a breadcrumb block costs you a breadcrumb. The reason to fix it anyway is what it says about the template: the same template renders the product block, and on both of these stores the broken block appeared on every page we read. We did not capture what was inside the broken blocks, so we cannot tell you what put them there.

A product node with no image

Five pages, three stores. One store missed it on all three pages we read; two others on one page each.

Three of those five products have a real photo in the catalogue — main images that fetch fine at 1308 by 1308, 1308 by 1308 and 1000 by 1000 pixels. The photo is in the catalogue and fetches fine, and the machine-readable description of the product does not mention it. We did not render these pages, so what a shopper sees is outside what we measured. The other two products have no image in the catalogue either, which is a different problem with a different fix.

"Add an image" is therefore the wrong instruction for three of these five: the image is already there, and the markup is what needs fixing.

The four that never occurred

We picked these seven because each one is visible in the page's own markup, without a validator, a login or a guess about what any search engine does with it. In 84 pages:

Two competing product nodes on one page. Zero. This is the classic outcome of installing a schema app on a theme that already emits markup, and we did not find it once.
A non-numeric price — a currency symbol or a comma inside the price field. Zero, on all 77 pages with a product node.
An unrecognised availability value. Zero. Every page used a value from the standard vocabulary.
A variant group published without its variants. Zero, across all 27 pages that used the group shape.

And the one check that needs the catalogue as well as the page: on all 77 pages with a product node, the price in the markup matched the store's own catalogue price for that product. Availability disagreed on exactly one page, where the markup said out of stock and the catalogue said the product was available — the direction that costs a shopper nothing on the page itself, and the wrong direction for anyone reading your page to decide whether to show it.

Prices agreeing on 77 of 77 is not a compliment to anyone's diligence. That is what you would see if both sides were rendered from the same product record; we did not verify that mechanism, only that the two never disagreed. It is worth knowing precisely because so much advice assumes otherwise.

The pattern that matters

Twenty-three of the 30 stores had none of the three failures on any page. Of the seven stores that did fail, five failed on every page we read from that store. Both exceptions are the image check: two stores missed the image on one page out of the three we read.

Structured data that comes from the theme rather than from the product would look exactly like this, and it has a practical consequence: auditing product by product is the wrong unit of work. Check one page. If it is clean on the two checks that come from the template — a product node exists, and every block parses — that is evidence about your template, and templates do not usually vary product by product. Our own evidence for that is narrow: every store in our sample was identical on both checks across the pages we read, and "the pages we read" is two or three per store. It is a reason to start with one page, not a reason to stop there. If it is broken, you are looking at a template, and fixing the template fixes the catalogue.

The exception is the one thing that does vary per product: whether the fields on that product are filled in at all. That is a different survey, and it is linked below.

One page tells you whether your markup is broken. The catalogue behind it is the other job.

Arvio goes product by product through your live catalogue, drafts what it would change, and applies nothing you have not approved.

Install Arvio on the Shopify App Store →

What to do about each one

No product markup. Check whether your theme is current and whether the product template has been customised. If an app owns your product page, the markup question belongs to that app. Re-run the command above afterwards: the Product or ProductGroup line either appears or it does not.

A block that will not parse. Find which block, then find the field. Unescaped quotes and line breaks in merchant-entered text are the usual cause, so look at the product or store fields the broken block is rendering.

Missing image in the product node. Check whether the product has an image at all. If it does, the markup is not rendering it and that is a template fix; if it does not, upload one.

Everything else. Four of the seven checks came back empty — competing product nodes on 0 of 84 pages, non-numeric prices and unrecognised availability values on 0 of 77, variant groups missing their variants on 0 of 27. If you are working from a list of structured-data errors to hunt down, these four can come off it until a validator on your own store says otherwise.

What this article does not know

We have no Search Console for these stores. Nothing here says whether any of these pages lost a rich result, a Shopping placement or an impression. We measured what the pages publish, and stopped there.
We read three pages from 26 of the 30 stores, two pages from two stores and one page from two more. That is enough to catch a store-wide property and not enough to estimate how many products in a catalogue are affected.
We did not render the pages. Markup injected by JavaScript after load is invisible to this method, and a page that looks empty here may not be empty to a renderer.
Field coverage is a different question. What Shopify emits and which fields it fills — ratings, barcodes, shipping, returns — we measured separately on a larger sample in what 58 live stores actually serve as schema markup.

How this was measured

Sample. A public frame of 230 live Shopify storefronts, and the frame is public in the sense that matters: you can rebuild it. We read 24 pages of the Shopify Community's store-feedback board (community.shopify.com/c/store-feedback/125) on August 26, 2026 — 720 topics — and took the hostnames linked in each topic's first post, the one written by the merchant asking for feedback; links in replies do not count. That produced 474 candidate hosts. Each was checked with a single GET /products.json?limit=1, and 244 failed it — 118 domains that no longer resolve, 56 returning 404, 31 returning HTTP 402 (Shopify's unpaid freeze), 18 password-protected or no longer Shopify, and 21 more spread across 401, 409, 403, 308, 500, 429 and one dropped connection. The 230 that answered are the frame, which makes it a frame of stores that survived. random.Random(20260826).sample() drew 60 of the 230; we then went alphabetically down that list of 60 and asked the first 35, of which 30 answered. The seed reproduces the 60, not the 35: the last step is a prefix, not a second draw. The frame skews newer and smaller than the Shopify population, and it is a frame of stores that are still trading.

Pages, September 3, 2026. Up to three product pages per store, taken at even intervals through the store's own catalogue order rather than picked by us. 88 fetches, 84 HTTP 200 responses, one request per second, with a user agent identifying our research crawler and carrying a contact address.

Parsing. Every application/ld+json block on the page, parsed independently. A block that raises on parse is counted as unparsable and does not disqualify the others. Nodes are read through @graph where present, so a product nested in a graph counts as a product node.

The catalogue comparison. For each page with a product node, the price and availability in the markup are compared with that product's current values in the same store's /products.json. Both sides were read within the same run.

Exclusion rule. The four fetches that did not return HTTP 200 are excluded from every denominator. No page is counted twice, and no store contributes more than three pages.

FAQ

How do I check my Shopify structured data?
Run the command above on one product page, or paste the page URL into Google's Rich Results Test. The command tells you exactly what your server sends. Start with it, because in our sample the two theme-level failures were identical on every page of a store.

Does Shopify generate product structured data automatically?
In our sample, 77 of 84 pages carried a product node. The seven that did not came from three stores. We did not record what those three stores run, so we cannot say why.

Is one broken JSON-LD block a serious problem?
Less serious than a validator makes it sound. On all six pages where we found one, the product markup was intact and parsed fine. Fix it because of what it says about the template, not because the product node is at risk.

My product has a photo but the markup has no image. Which do I fix?
The markup. Three of the five image-less product nodes we found belong to products with a perfectly good main image in the catalogue, so uploading another photo would change nothing.

Do I need to audit every product?
For two of the three, our data says no — with the sample size stated: no product markup and unparsable blocks were the same on every page we read of a store, every single time, and 23 of 30 stores were clean everywhere. That is two or three pages per store, not a catalogue. The image check is the one that changed from page to page even inside a store, so that is the one that still belongs to the product. Check one page per template first, then the products.

Arvio: AI Store Operator — install it on the Shopify App Store. The template is one fix; the fields behind it are the catalogue's job.

Originally published at https://arvio.a.xyz/blog/shopify-structured-data-errors. More Shopify bulk-editing writeups are on the Arvio blog.

Product images not showing on Shopify: which of the three failures you have

Arvio — Sat, 05 Sep 2026 01:28:32 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/shopify-product-images-not-showing. The canonical URL points back there.

Published September 3, 2026 by Adot Technologies Inc, the team behind Arvio: AI Store Operator. We read the public catalogue of 30 live Shopify storefronts on September 3, 2026 and fetched a sample of their main image URLs directly. Every count below is from the 25 of those whose catalogue we read to the end; five stores hit our 1,000-product ceiling, so their totals are partial and are excluded rather than mixed in.

"Product images not showing" is three different problems wearing one sentence.

The image file does not load, and the shopper gets a grey box. Or the product genuinely has no image, and the theme is showing a placeholder. Or — the common one nobody searches for by name — the shopper picks a colour and the photo does not change, because that variant has no image of its own.

Three causes and three fixes. The one request below tells you which of them you are looking at.

Key takeaways

The image files themselves came back fine every time we asked for one. We fetched up to five main image URLs per store — 119 across 25 stores — and all 119 returned HTTP 200. Read that for what it is: an anonymous request to the CDN succeeded. It says the file exists and is being served; it cannot tell you the image renders on the page, and five products per store is a spot check, not a survey of the file layer. If your image is not loading, the suspect list starts with your theme and your cache, not Shopify's CDN.
Products with no image at all are rare. 38 of 3,689 products, and 35 of those 38 belong to one store. This is an import problem when it happens, not a background rate.
The variant layer is where it goes wrong at scale. 2,442 products out of 3,689 have more than one variant, and 807 of them (33.0%) have no variant-level image at all.
It is a per-store habit, not a random defect. Six of the 25 stores had no variant images on any multi-variant product. Six others had them on every one. The median store sits at 20.5%.
One script tells you which of the three you have. It walks the same public catalogue JSON we read, page by page: whether the product has no image at all, or has variants and no image on any of them.

Two thirds of the products we read have variants. A third of those carry one photo for every option a shopper can pick.

The script above already finds them, at no cost to you — keep using it. What it cannot do is the rest of the catalogue it walks past: the titles, descriptions, metadata and alt text on those same products. Arvio reads that surface, drafts the changes, and applies nothing you have not approved.

Install Arvio on the Shopify App Store →

The one request that tells you which failure you have

Your catalogue is public JSON. Open this in a browser tab, no app and no login:

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

That URL gives you the first 250 products only. If your catalogue is bigger, &page=2, &page=3 and so on give you the rest — a 400-product store needs two pages, and reading one of them and calling it a catalogue is the most common way to get a clean-looking wrong answer.

Or get it as a task list. This prints one line per product that is missing an image somewhere — either the product itself has none, or it has variants and not one of them carries its own image:

python3 -c "
import json, sys, time, urllib.request
store = 'yourstore.com'          # <- your domain
seen = 0
for page in range(1, 21):        # 20 pages = 5,000 products
    url = 'https://%s/products.json?limit=250&page=%d' % (store, page)
    req = urllib.request.Request(url, headers={'User-Agent': 'catalogue-check/1.0'})
    products = json.load(urllib.request.urlopen(req))['products']
    if not products:
        break
    for p in products:
        seen += 1
        imgs = p.get('images') or []
        vs = p.get('variants') or []
        if not imgs:
            print('NO IMAGE AT ALL   ', p['handle'])
        elif len(vs) > 1 and not any(v.get('featured_image') for v in vs):
            print('NO VARIANT IMAGES ', p['handle'], '(%d variants)' % len(vs))
    time.sleep(1)
print('read %d products' % seen)
"

The last line is the one to read first. If it says fewer products than your admin does, the pages ran out early and the list above is incomplete — raise the page range and run it again.

That is the same rule we ran across 30 storefronts — 25 of which we read to the end, and those 25 are the ones every count in this article comes from. If it prints nothing and shoppers still report grey boxes, you are in failure 1 below and the answer is not in your catalogue.

Failure 1: the image does not load

This is the one people assume, and it was the one we could not reproduce.

We took a sample of main image URLs straight from the catalogues — 119 of them across 25 stores — and requested each one directly, reading only the first kilobyte. Every single one came back HTTP 200 with an image content type. Not one 404, not one 403, not one timeout.

That does not mean your image is fine. It means the file was there and serving every time we asked, so the failure sits somewhere between the file and the shopper's screen. We did not measure that stretch; the list below is not from our data, it is the order worth checking in:

Your theme's lazy-loading. A blank slot that fills in when you scroll, or never fills in on a slow connection, is theme code, not a missing file.
A cached page. You replaced the image and the shopper has the old HTML. Hard-reload before you debug anything else.
A blocked request. Ad blockers and corporate proxies eat CDN requests. Try a different network before you rebuild your product.
The URL you are checking is not the URL the page uses. Themes rewrite image URLs to add size suffixes. Copy the broken image's URL out of the page, not out of your admin.

The check that separates these from a real catalogue problem is the one at the top: if the handle does not print, the product has an image and the file will serve when requested directly.

Failure 2: the product has no image at all

Rare, and concentrated. 38 of 3,689 products across 25 stores had zero images — 1.0% — and 35 of them were in a single store, a catalogue of 176 products.

That shape is worth reading. Thirty-five of the 38 sitting in one catalogue is not a background rate; it is one batch. Which batch, we cannot see. Twenty-one of the 25 stores had zero products with no image.

If the command above prints a long list of NO IMAGE AT ALL lines, treat it as an import artefact and go looking for the batch it came from. We wrote up that cleanup separately in fixing a Shopify catalogue after a messy import.

Failure 3: you pick a variant and the photo does not change

Nobody files this one as a bug. On the page it does not look like one.

Two thirds of the products we read have variants: 2,442 out of 3,689, or 66.2%. Among those multi-variant products, 807 (33.0%) have no variant-level image at all. Not a missing image on one colour: no image assigned to any variant of the product.

What a shopper sees is one photo that does not respond. What the catalogue hands the theme is one photo for the whole product. Pick Green and there is no Green photo to hand over, because that variant carries none; a theme doing the standard fallback has nothing but the product's first image to show. On a mug that is a nuisance. On paint, apparel, or anything where the variant is the thing being chosen, it is the whole decision they came to make.

The distribution says this is a workflow, not an accident:

Multi-variant products with no variant image	Stores
All of them (100%)	6
Some of them	13
None of them (0%)	6

The median store sits at 20.5%. The extreme case in our sample was a 151-product catalogue in which all 150 multi-variant products had no variant image.

Why Shopify lets this happen: a variant image is optional. When a variant has none, the theme falls back to the product's first image, which is a sensible default and a silent one. There is no warning, no validation error, and nothing in the admin that lists products where variants share a single photo.

The fix, per product: open the product, open each variant, and give it an image from the product's media. The check afterwards is the same script as before — a handle that stops printing is a product that is fixed. It is per variant, though: a product with 4 colours × 3 sizes has 12 variants, and the images are assigned one at a time. That is why a third of multi-variant products in the sample never got them.

Finding the products is one request. Assigning images to a few hundred variants is the afternoon.

Assigning a photo to a variant is media work, and it stays yours — no tool in this article does it for you. Arvio works the text side of the same catalogue item by item. What it changes, what it leaves alone and what it got wrong on a real store, we wrote up separately in what Arvio actually does.

Install Arvio on the Shopify App Store →

What about image size?

Separate problem, separate audience. Google's product data specification asks for images of at least 500 x 500 pixels — and its own wording is that "Enforcement of the new requirements will begin January 31, 2027", so as of today it is a deadline, not a live rule. It is also about whether your products can serve in Shopping, not about whether a shopper sees a picture on your own store. In our sample 188 of the 3,651 products that have a main image (5.1%) carried one under 500 pixels on one side, 20 were under 250, and one was under 100. The denominator is 3,651 rather than 3,689 because 38 products have no main image to measure. We measured that requirement properly, against Google's own wording and enforcement date, in why your products are missing from Google Shopping.

And if your question is how many images a product should have in the first place, we counted that across a larger sample in how many product images Shopify stores actually use.

What this article does not know

We never rendered a page. Everything here is the JSON your storefront publishes. Theme bugs, lazy-loading, CDN behaviour and caching are exactly where failure 1 lives, and they are invisible to this method.
featured_image is what we read. A theme can associate images with variants by other means — metafields, naming conventions, alt-text matching — and a store doing that would look like a failure here and behave correctly for shoppers.
Five of the 30 stores hit the 1,000-product read cap and are excluded from every number above. Large catalogues are where variant counts get big, so the honest version is that we measured the smaller half.
We have no admin access. Nothing here says a merchant forgot anything. A store can have good reasons to show one photo per product.
One read, one day.

How this was measured

Sample. The frame is built from store URLs their owners posted publicly on the Shopify Community asking for feedback: 720 topics, 474 distinct store domains, of which 230 still served a catalogue on August 26, 2026. From those 230 we drew 60 at random with a recorded seed (20260826), then read the first 31 in alphabetical order; 30 answered, and 25 of those returned a complete catalogue. Only the 230 → 60 step is random.

The biggest bias is survivorship. Of the 474 candidate domains, 244 did not return a public catalogue when we asked — 118 domains that no longer resolve, 56 returning 404, 31 returning HTTP 402 (Shopify's unpaid freeze), 18 password-protected or no longer running Shopify, and 21 other refusals. Most of those look like stores that are gone, but "we could not read it" is not the same finding as "it closed", and the password-protected ones are plainly still someone's store. What is fair to say is that stores which have stopped serving a catalogue are missing from every number here, and they are unlikely to be the stores that got their variant images right. The frame also skews newer and smaller than the Shopify population.

Catalogue read, September 3, 2026. Per store, GET /products.json?limit=250 for up to four pages or 1,000 products, one request per second, with a user agent identifying our research crawler and carrying a contact address.

What was counted. A product has no image when its images array is empty. A product counts as multi-variant when it has more than one variant, and as having no variant image when none of those variants carries a featured_image. Main image dimensions come from the width and height the endpoint reports.

Image fetches. For a subset of products we requested the main image URL directly and read the first kilobyte, recording status, content type and content length. 119 fetches, 119 HTTP 200 responses.

Exclusion rule. Any store whose catalogue read reached the 1,000-product cap is excluded from every denominator, because the products past the cap could change any share we quote. That removes 5 of the 30 stores.

FAQ

Why does my Shopify product image not change when I select a variant?
Because that variant has no image assigned, so the theme falls back to the product's first image. It is the default state, not a fault: 33.0% of the multi-variant products we read across 25 stores were in it. Assign an image to each variant in the product editor, then re-run the check above.

Are Shopify product images broken or is it my theme?
Request the image URL directly. In our sample all 119 main images we fetched returned HTTP 200, so a file that serves on request and does not appear on the page points at the theme, the cache, or the network — not at the catalogue.

Why is my product showing a placeholder image?
The product has no images at all. That was 1.0% of the products we read, and 35 of the 38 cases were in one store, which is the signature of an import rather than of forgetting.

Do I need an image for every variant?
Not technically — Shopify treats it as optional, which is why so many stores skip it. It matters when the variant is what the shopper is choosing. If your options are sizes of the same object, one photo is honest. If they are colours or materials, one photo answers the wrong question.

Does a missing variant image affect Google?
Not through this route. What Google reads is the product page and its structured data, and the image requirement it enforces is about size, not about variants. That is the article linked above.

Can I check this without running a script?
Yes: open https://yourstore.com/products.json?limit=250 and search for "featured_image": null. The script only saves you the scrolling.

Arvio: AI Store Operator — install it on the Shopify App Store. Finding the products is a single request; putting an image on the variants behind them is the part that needs a hand.

Originally published at https://arvio.a.xyz/blog/shopify-product-images-not-showing. More Shopify bulk-editing writeups are on the Arvio blog.

Shopify redirects: the one rule that decides whether yours will work

Arvio — Sat, 05 Sep 2026 01:27:58 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/shopify-redirects. The canonical URL points back there.

Published September 3, 2026 by Adot Technologies Inc, the team behind Arvio: AI Store Operator. The measurements below come from requesting nine URL shapes against 20 live Shopify storefronts on September 3, 2026, and from Shopify's own redirect documentation read the same day.

There is a particular kind of Shopify thread that never gets resolved. Someone set up a URL redirect, saved it, tested it, and nothing happened. No error. The old URL still loads. They check the spelling four times, clear the cache, ask the forum, and the thread dies.

In these threads there is one rule worth ruling out first, and it is stated plainly in Shopify's documentation without ever being made prominent:

You can redirect only from broken URLs. Broken URLs display error messages, such as Page not found or 404, on a page or in the page title. If the URL still loads a valid webpage, then the URL redirect won't work.

Read it twice, because it inverts the mental model most people bring. A redirect on Shopify is not a rule that overrides a page. It is a rule that fills a hole. If there is no hole, the rule never fires.

Which turns the useful question into one you can answer with a single request: is the URL I am pointing at actually broken? That turns out to be answerable, and the answer is not obvious.

Key takeaways

Redirects only fire on URLs that already 404. A redirect whose source URL still loads does nothing — that is Shopify's own rule, and its troubleshooting list says as much: "Ensure the Redirect from URL doesn't have an active page." It is the first thing to check when a redirect appears to do nothing.
The URL shapes people most want to redirect are not broken. An uppercase handle, a trailing slash, and a junk ?variant= parameter all returned 200 on all 20 stores we tested. They are duplicates, not holes, so a redirect will not touch them.
What is handling those duplicates is the canonical tag, not a redirect — correctly, on 19 of the 20 stores. On the twentieth, the one product we read pointed its canonical at the store's home page instead — a real defect, and not one a redirect would fix. We read one product per store, so that is one page on one storefront, not a measured rate.
The genuinely broken shapes are consistent. A missing product, a missing collection, and a valid handle requested under the wrong resource type each returned 404 on 20 of 20 stores. Those are the ones redirects are for.
/collections/all/products/<handle> is the one Shopify collapses for you — 16 of 20 stores redirected it to the plain product URL. The other 4 served the product at the collection path, where the canonical still pointed at the plain product URL.
Shopify's own page contradicts itself on international subfolders — it says both that redirects do not automatically apply to market subfolders and that they do. Test yours rather than trusting either sentence.

Redirects fix URLs. They do not fix the page you land on

A redirect decides where the visitor lands. What is on that page comes from your catalogue — descriptions, product type, metadata, images — and that half is what Arvio reads, drafts, and hands back for your approval.

Install Arvio on the Shopify App Store →

Which URLs on your store are actually broken?

We took the first product and the first collection each of 20 live Shopify storefronts lists, and requested nine URL shapes for each, following redirects and recording where each one landed. Every shape is one a merchant genuinely runs into — from a bad paste, an old link, a mistyped handle, or a theme that builds URLs a second way.

URL shape	200	404	Path changed	Redirectable?
`/products/<handle>` (control)	20	0	0	—
`/collections/all/products/<handle>`	20	0	16	No — it is a fixed Shopify path
`/products/<handle>/` (trailing slash)	20	0	6	No — all 20 serve it
`/products/<HANDLE>` (uppercase)	20	0	0	No — all 20 serve it
`/products/<handle>?variant=1` (junk variant)	20	0	0	No — all 20 serve it
`/products/<handle>-typo` (missing product)	0	20	0	Yes
`/collections/<handle>` (control)	20	0	0	—
`/collections/<handle>-typo` (missing collection)	0	20	0	Yes
`/pages/<product-handle>` (wrong resource type)	0	20	0	Yes

"Path changed" counts the final URL landing on a different path than the one requested, which is not the same as a store running a redirect for that shape. The trailing-slash row is where the difference matters: 14 of the 20 stores serve the slashed URL exactly as it stands, and the other 6 are the host-normalising stores described under Where this stops — their single 301 drops the slash while it moves the host. No store in the sample ran a slash-stripping redirect of its own.

Two things fall out of that table, plus one detail about the redirects themselves.

Every redirect in the run was a permanent one: 70 redirect hops in total, all 70 returning 301, including the 22 that changed the path rather than just normalising the host.

The 404s are clean. Every one of the three broken shapes returned an honest 404 on every store — no soft 404s, no "helpful" 200 landing pages, no silent bounce to the home page. That is good news, and it is the precondition for a redirect to work at all. If your platform returned 200 for missing products, redirects would never fire.

The other half of the table is the part that frustrates people: none of the duplicate shapes is broken, so none of them is within reach of a redirect. An uppercase handle returns the product. A trailing slash is served as-is on 14 of the 20 stores, and stripped with a 301 on the other 6 — either way the URL never 404s. A junk variant parameter returns the product on all 20. All three are the same page on a second URL, and because none of them is broken, there is nothing a redirect can do about them.

That is where a lot of frustration comes from. Someone sees the same product at two URLs, reasons "I'll redirect one to the other," writes the redirect, saves it, and the second URL keeps loading. It always will.

What is handling the duplicates instead

The canonical tag. On 19 of the 20 stores, the product page emits a <link rel="canonical"> pointing at the plain /products/<handle> URL — and it keeps pointing there on the uppercase version, the trailing-slash version, the collection-path version, and the version with the junk variant parameter. That is the mechanism telling search engines which URL is the real one, and on 19 of the 20 storefronts we read it was already in place — we changed nothing on those stores, and we did not look at how their themes were configured.

One store out of 20 is the exception, and it is worth naming as a shape rather than a domain: on the one product we read there, the canonical points at the store's home page — and it does that on all five shapes where we captured the tag. We read one product per store, so whether the rest of that catalogue does the same is something we did not test. What is safe to say is that a redirect is the wrong tool for it: that product URL loads fine, so there is no hole for a redirect to fill.

If you want to check yours, it is one request:

curl -s https://yourstore.com/products/some-handle | grep -i 'rel="canonical"'

You want to see that product's own URL come back. If you see the home page, or a different product, that is the thing to fix — before you spend an afternoon on redirects that were never the problem.

The one duplicate Shopify does collapse

/collections/all/products/<handle> — the URL a theme produces when a product link is built from inside a collection — behaved differently from the rest. 16 of the 20 stores redirected it to the plain /products/<handle> URL. The remaining 4 served the product at the collection path, with the canonical still pointing at the plain product URL.

You cannot manage that either way from the redirect tool. Shopify's documentation lists the paths that are off limits: "You can't redirect URLs that use fixed Shopify paths: /products, /collections, /collections/all." The platform handles this shape itself, and where it does not, the canonical covers it.

When you change a product handle

A handle change is what people reach for redirects for, and the same rule decides it: if the old URL returns 404 after the change, it is redirectable; if anything still serves it, no redirect you write will fire.

We did not test this. We created no redirects and changed nothing on any store, and Shopify's redirect page does not mention product handles at all — so do the one check that settles it on your own store. Change the handle on a low-stakes product, then curl -I the old URL. A 404 means you can create the redirect; a 200 means a redirect there would be a no-op no matter how you write it.

The same goes for a change that arrives through an import or an app rather than by hand: the question is never how the change was made, it is what the old URL returns now.

When you delete or hide something

Deleting a product produces a 404 at its URL. That is correct behaviour, and it is not automatically a problem — though whether to archive or delete in the first place is a decision worth making before you get here: a product that never had inbound links or traffic does not need a redirect, and an internet full of redirects to vaguely-related pages is not better than an honest 404.

Redirect when the old URL had something worth preserving — a link from somewhere, a page in the index, a run of traffic. Send it to the nearest genuinely equivalent page, which is usually the collection the product sat in rather than a random other product.

Hiding rather than deleting has a wrinkle that is easy to get bitten by, and it is documented: hiding a collection — or setting a product to Draft, or removing it from all sales channels — makes its URL return 404, which makes it eligible for a redirect — and then, per Shopify, "If you later change the collection's Online store visibility back to Visible, the URL redirect is automatically deleted because redirects only work for URLs that return 404 errors."

So a seasonal collection you hide each summer and redirect elsewhere will lose that redirect the moment you make it visible again. The redirect does not sit dormant. It is deleted, and you recreate it next season.

Creating them, one at a time and in bulk

From the admin, redirects live under Content → Menus → URL redirects. Creating one is: Create URL redirect, fill in Redirect from with the old (broken) URL and Redirect to with the destination, then Save redirect. To send something to the home page, the destination is just /.

Destinations inside your own store should be relative (/collections/t-shirts); a full URL is for sending traffic off your domain.

For a batch — a migration, a bulk delete, a taxonomy change — the same page has Import, which takes a CSV. Shopify provides a sample redirect CSV to use as a template; fill that in, then Import → Add File → Upload file → review → Import redirects. Shopify's stated ceilings are 100,000 redirects on standard plans and 20,000,000 on Plus, so the limit is not what will stop you.

What does stop people is further down the same page:

Some prefixes cannot be the source of a redirect at all. Shopify's list is /apps, /application, /cart, /carts, /orders, /services, /shop, plus the fixed paths above.
Collection tag-filter URLs are not redirectable — a URL like /collections/name/tag-name is considered valid even when no product carries that tag, so it never 404s.
.html endings cannot be redirected to the same URL without .html. Shopify treats those as the same URL.
Query strings are unreliable as redirect sources. The documentation says URLs containing them "might not work as expected."

The source really is a 404 and the redirect still does nothing

The rule at the top of this article answers one half of "my redirect isn't working" — the half where the old URL still loads. If your
source URL genuinely returns 404 and the redirect still does not fire, Shopify's own troubleshooting list has three more steps, and they
are the whole list:

"Review both Redirect from and Redirect to URLs for any typos."
"Ensure that the Redirect from URL isn't a fixed path or contains a prefix that you can't redirect." — this is the trap our own measurement walked into: /collections/all/products/<handle> 404s for nobody, and 16 of the 20 stores we read redirect it themselves. A fixed path is not yours to redirect even when it looks broken.
"Clear your browser's cache and test the redirect again or try on another device."

Cache cuts the other way too, and it is the reason a redirect you deleted can appear to still work: "301 redirects are cached by
browsers and search engines. If you remove a redirect after customers have accessed it, then the redirect might continue to work in
their browsers until the cache expires." Test in a private window, or with curl -sIL, before concluding anything from your own
browser.

One thing this list does not include is waiting: Shopify's page says "URL redirects start working immediately." If it did not
work a minute after you saved it, more minutes are not the fix.

You have the redirects. Is the page they land on worth landing on?

A redirect moves a visitor to a page. What that page says comes from your catalogue — and Arvio reads your live catalogue, drafts the gaps, and applies nothing you have not approved.

Install Arvio on the Shopify App Store →

The documentation contradicts itself on international subfolders

If you sell into market subfolders — /en-ca, /en-fr — you need to know whether one redirect covers all of them. Shopify's page answers it twice, in opposite directions, in two different sections. Both were on the page when we read it on September 3, 2026.

In the considerations near the top:

URL redirects don't automatically apply to all market subfolders. If you need to redirect specific locales (such as yourstore.com/en-ca/old-page to yourstore.com/en-fr/new-page), then you must create individual redirects for each subfolder.

And in the section headed Redirects and subfolders, with a worked example that walks through a Canadian shopper being redirected inside /en-ca from a single redirect created at the root:

Creating a URL redirect applies to all language or market subfolders set up using international sales tools.

Neither sentence is dated, and we have no way to tell which one is current. So settle it on your own store: create one redirect at the root, then request the subfolder URL and see where you land. One curl -I per market takes a minute; re-reading the page takes longer and still leaves you with two answers.

Where this stops

We did not create any redirects. Everything in the table is a read of what these stores already serve. The redirect behaviour described in the second half comes from Shopify's documentation, not from our own write test.
The 301s above are what these stores did on the day. Every hop we recorded was one, but we sampled 20 storefronts on one morning — that is not a statement about how Shopify behaves in general.
Six of the 20 stores redirect every request once at the host level — the usual www-to-apex or apex-to-www normalisation. A hop that only moves the host is not counted as a redirect in the table, because counting it would have made all nine shapes look like they redirect. Those same six stores are the 6 in the trailing-slash row, and the reason they are there is worth being exact about: on that shape their host hop and the dropped slash are one 301, not two, so the path genuinely changes — but no store in the sample ran a slash-stripping redirect of its own. On the collection-path shape the same six take two hops; the trailing slash costs them none.
20 stores is a small sample, and the frame behind it is biased toward stores that are still trading. It was built from 474 publicly posted store URLs, of which 244 no longer served a public catalogue and were dropped before the draw — so this describes storefronts that are alive today, not Shopify as a whole. Nothing here describes Shopify Plus stores behind a CDN, where a rule at the edge can change any of this.

How this was measured

The sample. A public frame of 230 live Shopify storefronts, built on August 26, 2026 from store URLs their owners posted publicly. Sixty hostnames were drawn from that frame with a recorded seed (random.Random(20260826).sample), and this article reads the first 20 of those 60 in alphabetical order. The cut to 20 was ours, not the data's: nine shapes per store at one request per second is 180 requests, and we capped the survey there. So the draw is random and the prefix is not — alphabetical order has nothing to do with anything measured here, but it is a convenience cut and you should read the counts as 20 stores, not as a random 20 of the 60. All 20 answered, so no store dropped out at this step.

The requests (September 3, 2026). For each store we read /products.json and /collections.json and took the first product handle and the first collection handle each one returned, then issued one GET per URL shape at one request per second with a user agent identifying our research crawler and carrying a contact address. We followed redirects and recorded the full hop chain, the final URL, the final status code, and — on five of the nine shapes — the <link rel="canonical"> href from the response body. On the other four we did not read the body at all, so their canonical count is zero because we did not look, not because the tag is absent.

"Redirected" means the path changed. Six stores normalise host or scheme on every request. Counting those as redirects would have reported all nine shapes as redirecting on those stores, which is true and useless, so the table counts only redirects where the URL path differs from the one requested.

Rerunning this on your own store takes one line per shape. We have not published the raw hop chains — they name 20 real storefronts — but nothing here needs our copy: curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' "https://yourstore.com/products/your-handle/" prints the same two facts we recorded (where it landed, and with what status), and the nine shapes are listed in the table above.

The uppercase and junk-variant shapes were fetched twice. The first pass did not read the response body for those two, so we refetched both the same day purely to capture the canonical tag. That refetch is recorded separately from the first pass, and the canonical counts in this article come from it for those two shapes only.

The documentation was read on the same day. help.shopify.com returns 403 to a plain scripted request, so the page was read through a normal logged-in browser session and the rendered text — 10,173 characters — was stored whole alongside the numbers. Every quoted sentence in this article is copied verbatim from that capture.

Exclusion rule. A store enters the table only if all of /products.json, /collections.json and the control product page answered. Stores that failed any of those would be absent from every count rather than counted as zeros. In this run the rule never fired: all 20 answered all three requests, so every row's denominator is the full 20.

FAQ

Why isn't my Shopify redirect working?
The first thing to rule out is that the URL you are redirecting from is not actually broken. Shopify's rule is that redirects only fire on URLs that return an error: "If the URL still loads a valid webpage, then the URL redirect won't work." Open the old URL in a private window. If it loads a page, the redirect will never run, and no amount of editing it will change that.

Can I redirect the uppercase version of a product URL to the lowercase one?
No. In our test all 20 stores returned 200 for the uppercase handle, which makes it a working URL and therefore not a redirect source. It is also not the problem it looks like: the page's canonical tag points at the lowercase URL on 19 of the 20 stores, which is the mechanism that resolves it for search engines.

If I change a product handle, do I need a redirect?
That depends on one thing: whether the old URL is broken afterwards. We did not test handle changes, and Shopify's redirect documentation does not mention them, so check rather than take anyone's word — curl -I the old URL after the change. A 404 means you can create the redirect. Anything that still serves a page means a redirect would never fire.

How many redirects can I have?
Shopify documents 100,000 on standard plans and 20,000,000 on Plus. In practice the constraints that bite are the ineligible prefixes and fixed paths, not the ceiling.

Do I need a redirect for every deleted product?
No. A 404 is a correct answer for a product that is genuinely gone and had nothing pointing at it. Spend redirects on URLs that had inbound links, index presence, or traffic, and send those to the nearest real equivalent — usually the collection, not an unrelated product.

Will one redirect cover my /en-ca storefront?
Shopify's documentation says both yes and no on the same page, so test it. Create the redirect at the root, then request the subfolder URL and see where you land. That takes a minute and beats either sentence.

Arvio: AI Store Operator — install it on the Shopify App Store. It reads your live catalogue and drafts the product fields that are missing.

Originally published at https://arvio.a.xyz/blog/shopify-redirects. More Shopify bulk-editing writeups are on the Arvio blog.

GPTBot and your Shopify store: what your robots.txt actually says

Arvio — Sat, 05 Sep 2026 01:27:11 +0000

This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/shopify-gptbot. The canonical URL points back there.

Published September 3, 2026 by Adot Technologies Inc, the team behind Arvio: AI Store Operator. The counts below come from reading robots.txt on 58 live Shopify storefronts on September 3, 2026, plus a user-agent test run on our own domain.

Search "GPTBot" and page 1 is OpenAI explaining its own crawler, plus a row of bot-detection vendors explaining why you should buy bot detection. All of it is about GPTBot in general. None of it answers the question a Shopify merchant is actually holding: what is my store telling it right now, and did I choose that?

That question has a checkable answer, and it is public. We read it on 58 live Shopify stores.

Key takeaways

Shopify ships every store a robots.txt you did not write. It is 116 lines, and it names exactly two user agents: * and adsbot-google. GPTBot is not one of them. 53 of the 58 stores we could read were serving a file that matches its shape exactly.
One store in 58 names GPTBot at all, and that one allows it. Zero of the 58 disallow GPTBot at the site root. Whatever the debate about AI crawling looks like online, it has not reached these stores' robots.txt files.
A robots.txt asks; nothing enforces it. We could only test that on a server we are allowed to test — ours, which blocks nobody. A request carrying a GPTBot user agent and one carrying a normal browser user agent came back identical across all 36 URLs in our sitemap: same status, same byte count, same visible character count. That is one server, and it shows a server that does not discriminate — not that no server does.
"Blocking GPTBot" is not "keeping my store out of ChatGPT." OpenAI runs separate agents for training, for search, and for user-triggered fetches, and its documentation is explicit that the robots.txt settings are independent of each other. Disallowing the training crawler does not remove you from ChatGPT's search answers; disallowing the search crawler does.
Whichever way you want it, the fix is one template file in your theme, and you can verify it from a browser in one request. The syntax is the easy part. What takes thought is which of the three agents you actually meant.

Your robots.txt is a decision your store already made for you

Arvio audits what your storefront publishes about your products: catalogue fields, product metadata, page descriptions. It shows you what is there before you change anything — the robots.txt above is a theme file, and that one is yours to edit.

Install Arvio on the Shopify App Store →

First, read your own file

Open https://yourstore.com/robots.txt in a browser tab. That is the whole diagnostic. It is a plain text file, it is public, and it is the file every well-behaved crawler reads before it reads anything else on your store.

You will almost certainly see a long list of Disallow: lines covering /cart, /checkout, /orders, /account, and a pile of /collections/*sort_by* variants. That is Shopify's default, and it is a sensible default — it keeps crawlers out of the pages that are per-visitor or infinite.

What you will not see, unless someone put it there, is any mention of GPTBot.

What Shopify ships you

We fetched robots.txt from all 60 hostnames in a public sample of live Shopify storefronts. 58 answered.

53 of those 58 were serving a file with the platform default's exact shape. We tested the shape, not the bytes — we did not diff the whole file, so "same shape" is not the same claim as "never touched": swapping a Disallow path or adding a Sitemap line changes neither number we counted. What we can say is that on both counts the file was indistinguishable from the default: 109 non-blank lines (116 including blank lines) and exactly two User-agent groups — * and adsbot-google. Every one of the 53 matched on both counts. The same default ships two other agent-facing things nobody installed either — an agents.md instruction file and a live MCP endpoint.

The five that differed, by non-blank line count:

Lines	What it looks like
193	Seven groups: the default's `*` and `adsbot-google`, plus five named ones — Ahrefs (two), MJ12bot, Nutch, Pinterest
165	Default plus eight named groups, including GPTBot. The only file in the sample that names it
159	A different store, the same seven groups as the 193-line file, fewer rules inside
159	A third store, the same seven groups again — but every group header is malformed. See below
20	Far shorter than the default; not the same kind of edit as the other four

Three days earlier, on August 31, we ran a narrower version of the same read against the same 60 hostnames: 59 answered, 54 were on the platform default, 5 were customised. The picture is stable. (That earlier file counted total lines including blanks, which is why its default is 116 and this one's is 109. Same file, two ways of counting — we re-fetched one default store to confirm both numbers describe it.)

The one store that names GPTBot allows it

Of all 58, exactly one has a User-agent: GPTBot group. That group carries no Disallow line at all, which means: crawl anything.

So the count that matters is the boring one. Stores in this sample that block GPTBot from the site root: 0 of 58.

That may not be what you expected. We measured these 58 storefronts and nothing else — we have no reading on what publishers outside this sample are doing, and this survey cannot give you one. Inside it, the file is untouched on this question.

One of the five customised files is broken

One store's robots.txt has every group header collapsed onto one line with the rule that should follow it:

User-agent: *Disallow:

All seven of its groups look like that — the same seven the other two customised stores have — including the * group that carries the cart and checkout rules. Our parser, which requires the header to be its own line, finds no valid User-agent group in the file at all; we did not test it against Google's or OpenAI's parsers, so what any of them does with it is not something this survey measured. What the file does do is return 200 across 159 non-blank lines that look fine at a glance, which is the part worth knowing: nothing about it tells you it is broken.

A robots.txt does not report errors. Nothing turns red. Nobody emails you. If you edit yours, the only way to know it worked is to read it back and check the shape.

robots.txt is a request, not a lock

robots.txt is a file you publish saying what you would like crawlers to do. Well-behaved crawlers read it and comply. It is not enforced by your server, and it does not stop anything from arriving. If you want an actual block, that lives somewhere else — a rule at your CDN or firewall that refuses the request.

We wanted to know whether a server treats a GPTBot request differently from a browser request, and our own domain is the only place we can ask that. Our sitemap has 36 URLs. We requested each one twice: once with OpenAI's published GPTBot user-agent string, once with an ordinary desktop Chrome user-agent string. Then we compared status code, response size in bytes, and the visible character count after stripping tags and scripts.

All 36 came back identical on all three measures. Same 200, same byte count, same visible text. The server does not know or care which one is asking.

We did not send a GPTBot user agent to anyone else's store. Impersonating another company's crawler against servers that may be trying to filter it is a different act from testing your own property, and we did not do it. Every third-party number in this article comes from reading a public robots.txt with our own clearly-identified research agent. So this article can tell you what 58 stores say, and what one server (ours) does. It cannot tell you what those 58 servers do.

The three agents are not one switch

This is where most "how to block AI crawlers" advice quietly gives you the wrong outcome.

OpenAI does not run one crawler. Reading its bot documentation on September 3, 2026, the relevant ones are:

Agent	What OpenAI says it is for
`GPTBot`	Crawling content that may be used in training its generative AI foundation models
`OAI-SearchBot`	Surfacing websites in search results in ChatGPT's search features
`ChatGPT-User`	Visiting a page because a user in ChatGPT asked something that required it

And the documentation is explicit that these are independent controls: "Each setting is independent of the others – for example, a webmaster can allow OAI-SearchBot in order to appear in search results while disallowing GPTBot to indicate that crawled content should not be used for training OpenAI's generative AI foundation models."

It also states the consequence of the one people rarely mean to pick: "Sites that are opted out of OAI-SearchBot will not be shown in ChatGPT search answers, though can still appear as navigational links."

So the two mistakes are symmetric, and both are common:

You block GPTBot because you do not want your product copy in a training set. Fine — that is exactly what it does, and it does not take you out of ChatGPT search.
You block everything with openai in the name because you want "AI out of my store." That includes OAI-SearchBot, and it does take you out of ChatGPT search results.

For most stores selling things, those two sentences point in opposite directions, and the decision is genuinely yours to make.

How to change it on Shopify

Shopify lets you edit the file through a theme template. The steps, from the admin:

Online Store → Themes → ⋯ → Edit code on your live theme.
Under Templates, click Add a new template, choose robots.txt from the template-type list, and create it. Shopify creates robots.txt.liquid prefilled with the default rules — it renders the same file you are serving today.
Add your own User-agent groups above or below the default block. Do not delete the default block; those Disallow rules are keeping crawlers out of carts and checkouts.
Save.
Read it back: open https://yourstore.com/robots.txt in a browser and confirm your group is there, on its own line, spelled the way you meant.

A group that disallows the training crawler while leaving search alone looks like this:

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

The opposite decision, letting everything in, is simply the absence of any Disallow for those agents. That is what all 58 stores we read have today: 57 because the file never mentions these agents, and one because it names GPTBot and allows it.

Three things that bite people at step 5:

Agent names are exact tokens. GPTBot is the agent name. GPT-Bot, OpenAI and ChatGPT are not that agent, and a group headed by one of them silently matches nothing.
Disallow: with nothing after it means "allow everything." Disallow: / is the block. The empty one is the opposite of what it looks like.
The group header has to be its own line. That malformed store above is what happens when it is not: 200 back, 159 non-blank lines, nothing that looks wrong.

You changed the file. Did the rest of the store follow?

A crawler that is allowed in still only reads what your storefront publishes. Arvio audits that surface: catalogue fields, product metadata, page descriptions. It drafts the changes and you approve them before anything goes live.

Install Arvio on the Shopify App Store →

So should you block it?

We make a Shopify app, and an app that helps you fill in catalogue fields does better in a world where assistants read catalogues. What the measurement supports is narrower:

Right now these agents get whatever you give every other crawler. The default file has no opinion about them, so they fall through to the * group, and 53 of 58 stores look untouched.
If your reason is "I don't want my writing used for training," GPTBot is the agent that maps to that, and blocking it costs you nothing in ChatGPT's search surface.
If your reason is "I want to be findable when someone asks an assistant for what I sell," blocking is the wrong move. Being allowed in is the floor, not the finish — what an assistant actually reads out of a Shopify catalogue is a separate question from whether it is allowed to read it.
If you want a block that holds against traffic that ignores robots.txt, this file will not do it. That is a CDN or firewall rule, and a different piece of work.

What this article does not know

We have no server logs for these stores, so nothing here says whether GPTBot has ever visited any of them, how often, or what it took.
58 stores is a sample, drawn from a public list of stores whose owners posted their own URL asking for feedback. We did not measure their age, their revenue or their catalogue size, so we cannot tell you how that frame skews — only what it is: stores whose owners posted their own URL asking strangers for feedback. It is not the Shopify population, and certainly not the large-merchant population, where a CDN in front of the store makes all of this look different.
robots.txt changes the day someone edits it. Our two reads are three days apart and agree. That is stability over three days, not a law.

How this was measured

The sample. 60 hostnames drawn from a frame of 230 live Shopify storefronts, built on August 26, 2026 from 474 publicly posted store URLs — 244 of those no longer served a public catalogue and were dropped, so the frame is what survived. The draw is random.Random(20260826).sample(frame, 60); 58 of the 60 answered. We have not published the frame file or the per-store readings, because they name 58 real storefronts — but nothing here depends on our copy: robots.txt is public on every Shopify store, and one curl -s https://anystore.com/robots.txt reproduces the unit of measurement we used.

The robots read (September 3, 2026). One GET /robots.txt per host, at one request per second, with a user agent that identifies itself as our research crawler and carries a contact address. 58 of 60 returned a readable file; 2 did not answer. For each, we parsed the file into User-agent groups and recorded: non-blank line count, the agent names present, whether any group names GPTBot, and the Disallow rules inside that group if it exists.

"Platform default" is a shape test, not a diff. A file counted as default if it had 109 non-blank lines and exactly the two agent groups * and adsbot-google. 53 of 58 matched. We separately fetched one of those files whole to confirm the line counts reconcile with the August 31 read (116 lines including blanks).

The user-agent test (September 3, 2026, our domain only). Every <loc> in our own sitemap — 36 URLs — requested twice, once with OpenAI's published GPTBot user-agent string and once with a desktop Chrome user-agent string, one second apart. Recorded: HTTP status, response bytes, and visible characters after removing <script>, <style> and all tags. Three of the 36 needed a re-request on the first pass. Final: 36/36 identical on all three measures.

The OpenAI documentation (platform.openai.com/docs/bots) was fetched the same day (HTTP 200) and the quoted sentences are copied verbatim from that response. That page is public, so every quotation in this article is one you can check yourself.

Exclusion rule. Two hosts that did not return a readable robots.txt are excluded from every denominator in this article. They are counted in "60 asked", never in "58 read."

FAQ

Does Shopify block GPTBot by default?
No. The default robots.txt Shopify serves does not mention GPTBot in any way. It names two user agents — * and adsbot-google — and the rules under * are about carts, checkouts, accounts and sorted collection URLs. In our sample, 53 of 58 were serving a file with that exact shape.

If I block GPTBot, do I disappear from ChatGPT?
Not from its search answers. Per OpenAI's own documentation, GPTBot governs crawling for model training and OAI-SearchBot governs appearing in ChatGPT's search results, and the two settings are independent. If disappearing from ChatGPT search is what you want, OAI-SearchBot is the agent you would disallow — and OpenAI states that opted-out sites "will not be shown in ChatGPT search answers, though can still appear as navigational links."

Will blocking it actually stop anything?
It stops crawlers that read robots.txt and comply, which is what the named, documented ones do. Nothing enforces it. Our own-domain test found the server returning identical responses to a GPTBot user agent and a browser user agent across all 36 sitemap URLs — nothing at the server layer was distinguishing them. If you need enforcement, that is a CDN or firewall rule, not this file.

How do I check whether my edit worked?
Open https://yourstore.com/robots.txt in a browser and read it. Confirm your User-agent: line is on a line by itself, that the agent name is spelled exactly, and that Disallow: / is present if a block is what you meant — an empty Disallow: allows everything. One store in our sample of 58 has a malformed group header and still serves a 200 that looks entirely normal.

Does any of this affect Google?
Not directly. Google's crawlers are separate agents with separate rules, and the Shopify default names only * and adsbot-google, no Google AI agent of any kind. Nothing in this article changes how Googlebot sees your store.

Arvio: AI Store Operator — install it on the Shopify App Store. Once a crawler is allowed in, what it reads is your catalogue fields — and that is the part Arvio works on.

Originally published at https://arvio.a.xyz/blog/shopify-gptbot. More Shopify bulk-editing writeups are on the Arvio blog.