Is my Shopify store visible to ChatGPT?

The short version

If you sell on Shopify, the platform is doing the hard part for you. Product pages render on the server, so a crawler that never executes JavaScript still receives your product title, your price and your description. That is the opposite of a single-page React app, and it is the most useful thing to know before you let anyone sell you a fix.

We measured it rather than assuming. We requested 12 live Shopify stores with the OAI-SearchBot user-agent, executed no JavaScript, and read the raw bytes. Eleven returned measurable results. In all 11, the product content was there in the HTML.

The real failures are narrower and more boring than the advice you will read elsewhere: a domain variant that sends crawlers somewhere useless, and content that lives inside third-party apps. Both are below.

What we measured

For each store we fetched the homepage under both an AI crawler user-agent and an ordinary browser user-agent, read robots.txt, then fetched a real product page and checked whether the product title, the price and the description appeared in the raw HTML. Every number below is reproducible with curl.

Shopify’s default robots.txt does not block AI crawlers

None of the 11 stores blocked GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot or Google-Extended. Ten did not mention AI crawlers at all, which under the robots standard means allowed. One named GPTBot explicitly, with "Allow: /".

There is a trap here that causes a lot of needless panic, and cheap audit tools walk straight into it. Shopify's default robots.txt does contain a bare "Disallow: /", and grepping for that string finds it on most stores. It belongs to Nutch, an open-source crawler, and on one store to MJ12bot as well. It has nothing to do with AI crawlers. Directives apply only inside the User-agent block they sit under. Read the block, not the line.

# Wrong: finds Shopify's default Nutch rule and looks alarming
curl -s https://yourstore.com/robots.txt | grep "Disallow: /$"

# Right: show which user-agent each rule belongs to
curl -sL https://yourstore.com/robots.txt | grep -B1 -A15 -i "user-agent"

Headless storefronts passed too

Three of the stores were headless builds rather than standard Liquid themes. Their /products.json endpoint returned 404, which is the quickest way to spot one. The received wisdom is that headless means client-rendered and therefore invisible. The received wisdom is wrong.

All three server-rendered their product pages: a real h1, the price, and richer JSON-LD than several of the standard themes managed. Going headless on Shopify costs you nothing in AI visibility. It would only hurt if the build fetched product data in the browser, and none of these did.

The failure we did find: a domain variant that goes nowhere

One store in the sample had a total reachability failure, and it had nothing to do with rendering. Requesting the apex domain, gymshark.com without the www, 301-redirects to a checkout subdomain serving a JavaScript redirect page. The raw HTML contains exactly one word: "Redirecting…". The www hostname served a complete 2,426-word page.

Understand how invisible this is to the store owner. You type www, or you click an internal link, and everything looks perfect. A crawler that learned your apex domain from a link, a citation or an old directory entry gets a blank page and no reason to ever come back.

This is not bot-targeting. An ordinary Chrome user-agent follows the identical redirect chain to the identical interstitial. It is a domain configuration fault that happens to punish crawlers hardest, because a browser executes the redirect and a crawler does not.

# Compare both hostnames. A large gap means one of them is a dead end.
for h in yourstore.com www.yourstore.com; do
  printf "%-28s " "$h"
  curl -sL -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot" \
    "https://$h/" | sed 's/<script[^>]*>.*<\/script>//g; s/<[^>]*>/ /g' | wc -w
done

What consistently does not survive: your reviews

This is the one place Shopify stores reliably lose content, and apps cause it, not the platform. We checked three stores running review apps, with Yotpo, Okendo and Loox appearing across them. On all three, review body text was absent from the readable HTML. The widget loads its content in the browser, so a crawler sees an empty container.

What survives depends entirely on whether the app also writes JSON-LD, and the three stores landed in three different places. One exposed five full review bodies in JSON-LD, so a crawler that parses structured data gets them even though nothing is visible in the text. One exposed an aggregate rating only, a score with no reasons behind it. One exposed neither, so its reviews do not exist as far as an assistant is concerned.

This costs more money than it looks like it should. When someone asks an assistant whether a product is any good, the answer gets built from whatever text is reachable. Your reviews are the most persuasive content on the page and they are the part most likely to be missing.

# Do your reviews exist for a crawler? Compare the three answers.
URL=https://yourstore.com/products/your-product
UA="Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot"

# 1. review text visible in the HTML at all?
curl -sL -A "$UA" "$URL" | sed 's/<[^>]*>/ /g' | grep -ci "reviewer\|verified buyer"

# 2. review bodies in structured data?
curl -sL -A "$UA" "$URL" | grep -o '"reviewBody"' | wc -l

# 3. only an aggregate score?
curl -sL -A "$UA" "$URL" | grep -o '"AggregateRating"' | wc -l

Check your own store in one command

Fetch a product page as a crawler and confirm the three things that matter are in the bytes: the product name, the price, and the description. If they are there, your rendering is fine and you should stop paying anyone to optimise it.

curl -sL -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot" \
  https://yourstore.com/products/your-product \
  | sed 's/<script[^>]*>.*<\/script>//g; s/<[^>]*>/ /g' | tr -s ' \n' ' ' | head -c 1200

Cloudflare is not blocking your Shopify store

Edge bot rules rejecting AI crawlers is a real failure mode, and it is repeated everywhere as a Shopify problem. Across these 11 stores it did not happen once. Every store returned the same status code to an AI crawler user-agent as it did to Chrome. If someone is trying to sell you a Cloudflare allowlist for your Shopify store, ask them to show you the 403 first.

One store, bombas.com, returned HTTP 429 to every request including an ordinary browser user-agent, which is IP-level rate limiting on a repeat automated client rather than anything to do with crawlers. It is excluded from every 11-store figure above.

One technical trap if you write your own robots.txt checker: RFC 9309 permits CR, LF or CRLF as line separators, and at least one store in this sample uses bare carriage returns. Split on /\r\n?|\n/ or you will parse zero rules and think you found a blocked store.

Re-run this after every replatform

Eleven stores is a sample, and it is more than enough to settle the question people actually ask: Shopify's rendering is not your problem. What it cannot tell you is whether your store has the redirect fault, because that one is specific to your DNS and your theme.

These numbers are also one day's snapshot. Themes change, review apps get swapped, and a domain redirect arrives with a migration nobody flagged as risky. The commands above cost you thirty seconds. Run them after any replatform, theme change or domain move, and trust a result from this morning over a result from March.

Crawlable does all of it on a schedule and emails you when the answer changes.

Frequently asked