Why ChatGPT Can't See Your Shopify Store — and Which Part Is Actually Missing
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
categoryrather 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.
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.
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.