Can AI crawlers read your store if they can’t run JavaScript? I checked what real stores serve

The advice going around right now is that AI crawlers cannot run JavaScript, so they land on your store, see a blank page, and skip your products. The recommended fix is to server-render everything. Most of that is wrong, and the part that is right has nothing to do with JavaScript.

Two things are true and they are separate. First, your products do not reach ChatGPT or Google’s AI answers through a crawler at all, so whether a crawler runs JavaScript is irrelevant to whether your products appear. Second, for the different question of being quoted as a source, I fetched real stores with no JavaScript and a crawler user-agent, and a standard Shopify store already serves the full product data in the raw HTML. The page is not blank. What actually varies between stores is whether the server sends machine-readable structure, and you can check yours in one command.

Your products travel on a feed, not a crawl

Product discovery, the carousel of items an assistant shows when someone asks for a recommendation, runs on a feed you supply. OpenAI’s commerce docs say it plainly: “Merchants provide a secure, regularly refreshed feed (CSV or JSON) containing key details such as identifiers, descriptions, pricing, inventory, media, and fulfillment options.” Onboarding “involves sending an initial sample feed for validation, and daily snapshots.” Nowhere does it describe crawling and rendering your web pages.

Shopify is even more direct about it. Its agentic-storefronts documentation states: “Blocking AI crawlers at the /robots.txt or network layer affects only open-web discoverability. It doesn’t stop your product data from being sent by Shopify Catalog to the agentic storefronts that you’ve activated.” The data that goes to those channels is “title, description, options, images, price, availability, and other key attributes, all structured in a way that AI agents can parse and understand.”

So for the outcome most merchants actually care about, getting your products into the AI shopping surfaces, a crawler never touches your page. JavaScript, rendering, blank pages: none of it is in this path. It is a feed.

The other path is citation, and I checked what a no-JavaScript fetch really gets

There is a second path where a crawler does fetch your page: being cited as a source in an assistant’s prose answer, the “according to…” kind of mention. This is where the “cannot run JavaScript, sees a blank page” fear lives. So I tested it. I requested live product pages with a plain request and again with a GPTBot user-agent, no browser, no JavaScript executed, and looked at the raw bytes the server returned.

On a standard Shopify store (Brooklinen’s Classic Core Sheet Set), the raw HTML already carries the whole product entity: a JSON-LD block with "@type": "Product", a symbol-free "price":15900, "priceCurrency": "USD", and "availability": "https://schema.org/InStock". Requesting it as GPTBot returned byte-for-byte the same document a browser gets: 2,863,164 bytes, identical. Nothing was waiting on JavaScript. A crawler that never runs a line of script still receives the name, the price, the currency and the stock status, structured exactly the way schema.org intends.

That is the common case for Shopify, and it quietly kills the blank-page claim.

The real gap is structure, and it is not always there

WooCommerce is where the honest caveat lives. On a live WooCommerce store (Porter and York, running the Elementor page builder with the Rank Math SEO plugin), the raw HTML did contain the price, but only as visible text inside woocommerce-Price-amount spans. There was no JSON-LD Product block and no schema.org Product microdata. The page builder had replaced WooCommerce’s default product template, and with it the structured markup WooCommerce normally emits on the server.

Notice what that means. The page is still not blank. A human, and a language model reading the text, can see the price sitting there in plain HTML. But there is no machine-readable Product entity for a crawler to lift cleanly. The thing that was missing was structure, not JavaScript. Rendering more script would not have added a single schema.org field, because the theme simply never output one.

This is the case the blank-page advice gets backwards. The stores that are genuinely thin to a crawler are not thin because a bot refused to run JavaScript. They are thin because their template does not ship a Product entity in the first place, or because a fully client-side build injects the facts after load. The fix for the first is to restore server-side product structured data through your theme or an SEO plugin. The fix for the second is the same idea: put the facts in the HTML the server sends, not in a script that runs later.

Check your own store in one line

You do not have to take anyone’s word, mine included. Fetch your own product page the way a crawler would, with no browser and no JavaScript, and read what comes back:

curl -A "GPTBot" https://yourstore.com/your-product

Then look in the output for "@type":"Product" together with a price and a priceCurrency. If they are there, a crawler already sees your product and JavaScript was never your problem. If they are missing, that is your actual task: get a structured Product entity into the server response. Editing robots.txt or blaming JavaScript changes neither outcome.

The blank-page story is compelling because it comes with a tidy fix to sell. The reality is less dramatic and more useful: your products ride a feed that no crawler touches, and for the pages a crawler does read, the question is simply whether your server ships a structured Product entity. One command tells you which side of that line you are on.

If you would rather see it checked and explained for your store without running anything yourself, the free scan at pollen.elytron.in reads exactly what a no-JavaScript fetch returns and shows you what is, and is not, in your HTML.