The storefront that does not exist without JavaScript

The major AI crawlers do not execute JavaScript. Anthropic states it in its own documentation: the web fetch tool does not support websites rendered dynamically with JavaScript. Measurements from Vercel and MERJ across more than 500 million fetches point the same way.

So the only thing that counts is what your server puts in the first response. Anything that appears only after a browser has run a script does not exist for an assistant.

What it looks like

We fetched the homepage and a couple of category pages from 135 Norwegian sites in August 2026, without executing a single line of JavaScript. Some of the answers:

• bohus.no returned a 9,953-byte shell. No prices, no product data, no JSON-LD — on the homepage and the category pages alike. Nothing across 74 cached pages.
• norli.no returned 13,429 bytes of the same shape, without a single price.
• platekompaniet.no returned a homepage consisting of one word: "Platekompaniet".
• norrona.com returned 606 characters. All 606 were a skip link, a footer, contact details and legal small print — identical on every page. Only 51 characters were unique to the page we asked for.
• apotek1.no answered every path we tried with the same navigation shell, and the category labels carried no href at all.

None of these are badly built sites. They look completely normal in a browser. That is exactly what makes the failure hard to notice: everything works for everyone you can ask.

How to check your own

Ask for your homepage the way an assistant does — one request, no browser:

curl -sL https://yourshop.no/ | wc -c
curl -sL https://yourshop.no/ | grep -c "ld+json"

The second number only becomes interesting once the first is large enough. Then take a category page and look for something you know is on it:

curl -sL https://yourshop.no/a-category/ | grep -o "kr" | wc -l
curl -sL https://yourshop.no/a-category/ | grep -oE "href=\"[^\"]*\"" | head -40

If you get zero prices and a handful of links that all go to the homepage, the login and the privacy policy, your answer is a shell.

A faster trick: turn JavaScript off in your browser and load the category page. What you see is roughly what the assistant sees. It is not exactly the same — the assistant reads the source and can also see data sitting in script blocks it never executes — but it is close enough to decide whether you have a problem.

One important exception

A page can look empty to the eye and still be full of data. farmasiet.no puts 34 products — name, SKU, link, price and stock — inside a ReactDOM.hydrate blob in the HTML. A language model reading the raw source sees all of it. Our own link parser saw none of it, and we reported a blocker. That was our bug, not theirs, and it is fixed.

So before you rebuild anything: look for the data in the source, not only for visible text.

What to change

1. Render listings and product pages on the server. That is the one change that fixes this. Every modern framework can do it; it is usually a decision someone made early and never revisited.
2. If full server rendering is too big a lift, prerender the pages that matter — the homepage, the category pages and the product pages — and leave the rest. You do not have to do all of it.
3. Do it for everyone. Prerendering only for named bots is its own trap, covered in Your site answers differently depending on who asks.
4. Put the links in an href. A category that is a div with a click handler does not exist for anything that does not click.

How to verify the fix

Run the same curl again. You should see product names, prices and links deeper into the catalogue as plain text. A concrete target: a category page where curl alone gives you at least ten product names with a price and a link to each.

This is achievable, and it is achieved. fjordkraft.no puts every electricity plan and its monthly fee in the HTML the server sends, and scores 94/100 with us. norrona.com was 606 characters of footer when we ran the corpus; when we re-fetched it on 8 August 2026 we found 9,222 URLs and real content. It is not a small site that managed it. It is just a decision about where pages get assembled.

Where these numbers come from

Every figure above comes from our own scan of 135 Norwegian sites in August 2026, documented in docs/findings.md. The byte counts for bohus.no, norli.no and platekompaniet.no were taken live with curl on 8 August 2026 and are pinned as ground truth in the scanner's validity harness. Anthropic's wording is quoted from its own web fetch documentation. The Vercel/MERJ measurement is not ours; it is published by them.

We measure whether an assistant that reaches your site can use it. We do not measure whether assistants reach you at all.