Most merchants carry one assumption about AI crawlers that quietly breaks everything built on top of it: if Google can see it, the AI crawlers can see it too.

For most of these crawlers, and for most of the period anyone has measured, that has not held. They fetch your raw HTML and stop. Consequently, anything your store draws in afterwards with JavaScript never reaches them.

That said, the evidence here has a date on it, and it has started to move. Both halves are below, because acting on the headline without the caveat is how you end up solving last year’s problem.

The data behind the GPTBot claim

This is measured rather than theorised. Vercel, working with MERJ, analysed AI crawler traffic across nextjs.org and two job-board sites, and published the results on 17 December 2024. That date matters, and we come back to it.

That second figure is the interesting one. These crawlers do fetch your scripts. However, fetching a script and running it are different things, and only the second one would reveal what the script builds.

Vercel noted two exceptions: Google’s Gemini, which draws on Googlebot’s infrastructure, and Apple’s AppleBot, which uses a browser-based crawler.

Gemini is less settled than that suggests today. Independent tests in 2026 disagree about what actually happens when a URL is pasted into the app. Two of them saw raw HTML only; an earlier October 2025 test saw it return a price that had been written by script. So treat Gemini as disputed rather than confirmed. AppleBot, meanwhile, has been observed fetching scripts across several thousand page reads, which is consistent with Vercel’s finding.

What changed in September 2026

Here is the part most write-ups of the Vercel study leave out, and it is the reason the headline above is hedged.

On 25 September 2026, a developer reported that OAI-SearchBot and GPTBot stopped simply fetching HTML on their sites and began executing JavaScript and rendering pages. The detection method is specific rather than impressionistic: Next.js emits a prefetch request carrying a ?_rsc= parameter that only exists once client-side JavaScript has run, and those requests started appearing in the logs.

Three caveats, and they are substantial. Firstly, this is one developer’s server logs, not a study. Secondly, OpenAI has not confirmed it, and it has not been reproduced at scale. Thirdly, the pattern may indicate OpenAI re-rendering stored HTML in a separate pass well after the original crawl, rather than rendering live as it crawls — which would be a meaningfully different thing.

Meanwhile, not everything moved. ChatGPT-User, the agent that fetches a page when someone asks ChatGPT about a specific URL, was still HTML-only in independent testing through September 2026: tens of thousands of page reads with no script downloads at all.

So the honest state of play is this. Treating your client-side content as invisible to AI crawlers is still the safe assumption, but it is no longer a permanent law. If OpenAI is rendering now, the stores that already had their facts in the HTML lose nothing. The stores that did not were exposed for the whole period before the change, and remain exposed to every crawler that still does not render.

Why Googlebot is a misleading benchmark for GPTBot

Googlebot renders JavaScript, but it does so in a second pass, separately from the initial crawl. We covered that two-stage behaviour in our guide to what Google actually sees on a Shopify store.

Because Googlebot eventually catches up, merchants reasonably conclude their client-side content is fine. Unfortunately, that conclusion only holds for Google. For GPTBot there is no second pass to wait for. There is one fetch, and whatever was in the response is the whole picture.

So “it ranks fine on Google” tells you nothing about whether an assistant can read the page.

What GPTBot misses on a Shopify store

Shopify themes render most core content server-side, which is good news. The product title, description and price generally sit in the HTML. Nevertheless, the parts most likely to be injected afterwards are precisely the parts an assistant would want to quote.

• Reviews and star ratings. Many review apps inject their widget client-side, though not all — several now render stars server-side through theme app blocks and metafields. Check yours rather than assuming either way, because when it is client-side, the social proof that would make an assistant recommend you is simply absent.
• Currency and dynamic pricing. If a converter rewrites the displayed price after load, the crawler keeps whatever was in the HTML.
• Product recommendations and related items. Usually fetched after load, so the internal connections between your products are invisible.
• Tabbed content and size charts. Specifications hidden behind app-injected tabs may never be in the source at all.
• Infinite-scroll collections. If products load as the visitor scrolls, a single fetch sees only the first batch.

Notice the pattern. The things at risk are the differentiators, not the basics. Your product exists in the HTML; the reasons to choose it often do not.

How to check in two minutes

You do not need a crawler emulator for a first answer.

1. Open a product page and view source, rather than using inspect element. View-source shows the raw HTML; the inspector shows the rendered DOM after scripts have run.
2. Search that source for your star rating, your review count, and a specification you care about.
3. Anything you cannot find is, in all likelihood, invisible to GPTBot.

For a second opinion, request the page with JavaScript disabled in your browser and read what remains. Admittedly that is a rough proxy, but it is an honest one.

What to actually do about it

The instinct is to rebuild everything server-side. In reality that is rarely proportionate, and there are cheaper moves.

Put the facts in structured data — but verify where it comes from. JSON-LD is read without rendering, so if your review app writes aggregateRating into the page’s structured data, the rating survives even when the visual widget does not. This only works if the JSON-LD is in the server’s HTML. Plenty of apps inject their structured data with JavaScript too, and schema added that way is exactly as invisible as the widget it was meant to rescue. Check it in view-source, the same way you check everything else here. If you can’t find the JSON-LD in the raw source, it isn’t helping you.

Put key specifications in the description. Attributes living only in an app-injected tab should also exist in the product description, where they are server-rendered. Duplication is acceptable here.

Check your review app’s settings. Several offer a server-rendered or SEO-friendly output mode that is not enabled by default.

Do not break pagination for crawlers. Infinite scroll should still have real paginated URLs behind it.

One honest caveat from the same research: content delivered inside the initial HTML response, even as raw JSON rather than visible markup, may still be usable, because models can interpret non-HTML content. So the line is not quite “visible to a human in the source”. Instead it is “present in the response at all”.

Across a catalogue, the hard part is knowing which pages are thin in the source rather than on screen, since the two look nothing alike. Plug In SEO audits the stored on-page fields across your store, which is where that gap shows up first.