Start free trial
AI visibility for headless commerce

An AI audit that renders your JavaScript first.

Headless storefronts inject JSON-LD via JavaScript. Most AI audit tools do static fetches and miss it entirely. eCommerce Insights offers ScrapingBee-rendered audits via the Force JavaScript rendering toggle on Analyze a Page.

Audit a page free Start free trial

Hydrogen · Next Commerce · PWA Studio · Catalyst · Saleor · Remix · Nuxt · custom React

Analyze a Page · render mode
Static fetch
JSON-LD: not found
Rendered fetch (default 2.5s wait)
JSON-LD: 1,840 bytes
Rendering layer
ScrapingBee, headless Chrome
Cost per audit
1 credit · vs 0 static
Toggle
Force JavaScript rendering: ON

Illustrative output. Default wait is 2.5s; adjustable up to 10s.

A headless storefront ships a thin HTML shell and hydrates everything else in the browser. The product title, the description, the JSON-LD, the breadcrumbs: all injected by React, Vue, or Svelte after the page loads. A static HTTP fetch sees none of it. Google AI Overviews renders JavaScript and sees all of it. The other AI engines render selectively and are catching up fast. If your audit tool is doing a static fetch, your headless store looks empty to the audit and full to the engines. The numbers won't agree. eCommerce Insights's rendered audit closes that gap.

The headless problem

Five reasons static audits fail on a hydrated storefront.

Empty shell

The static HTML is mostly empty.

A typical Hydrogen, Next Commerce, or PWA Studio response is a few KB of HTML, a head with critical meta, and a script tag pointing at the bundle. The product content is rehydrated client-side. A static audit reads the shell and reports "no PDP content." That's not a finding. That's a measurement error.

JSON-LD injection

JSON-LD is added after hydration.

Most React-based headless stores emit Product JSON-LD via next/script, react-helmet, or a useEffect on a component mount. The blob is in the DOM after the page loads. A static fetch never sees it. AI engines that render JavaScript do. Your audit and your AI engines should be reading the same thing.

Streaming SSR

Streaming SSR splits the content.

Hydrogen ships streaming server-side rendering. Parts of the PDP arrive in the initial response, others stream in later. A static fetch that doesn't wait for the stream to complete reads partial content. The rendered audit waits for the full stream and reads what the engine reads.

Edge personalization

Edge functions rewrite the page.

Vercel Edge Middleware, Cloudflare Workers, and Shopify Oxygen routes can rewrite the response based on geo, AB tests, or feature flags. A static audit from a fixed IP sees one variant. eCommerce Insights's rendered audit can be pinned to a geography to match what the AI crawler likely sees.

Client-side routing

SPA navigation skips real page loads.

Headless storefronts with single-page-app routing transition between PDPs without a full page reload. Some AI crawlers handle this well; others get stuck on the first page. The rendered audit loads each PDP as a fresh navigation, the way a crawler actually sees it.

Render budget

Some engines have a render budget.

Search engines don't render every page indefinitely. The render budget gets spent on the heaviest pages. eCommerce Insights flags PDPs where critical content (price, availability, JSON-LD) doesn't render within a 2.5-second window, because those PDPs are at risk of being indexed by their static shell only.

How it works

From toggle to scored DOM in four steps.

  1. 01

    Open Analyze a Page.

    Paste your headless storefront URL into eCommerce Insights's Analyze a Page tool. Static fetch runs by default for speed. If the audit reports unusually thin content (a tell-tale sign of a hydrated frontend), eCommerce Insights prompts you to enable Force JavaScript rendering.

  2. 02

    Toggle on Force JavaScript rendering.

    The toggle routes the fetch through a headless-browser layer (ScrapingBee under the hood) that loads the URL in real Chrome, executes JavaScript, waits the configured time, and returns the rendered DOM. Default wait is 2.5 seconds. You can extend to 10 seconds for very heavy hydration paths.

  3. 03

    Audit runs against the rendered DOM.

    Every eCommerce Insights scoring rule (JSON-LD completeness, content depth, answerability, entity clarity) runs against the rendered output. The score reflects what the AI engines see, not what the static shell ships. Side-by-side, the report shows static vs rendered so you can quantify the gap.

  4. 04

    Apply diffs to your headless build.

    Recommendations land as code-level changes: add a JSON-LD script via next/script with strategy='beforeInteractive', emit the brand entity from your loader, surface the offers block in your product fetch. Your engineering team applies the diff through the normal PR flow. Re-audit on the staging URL before merge.

Why this beats a generic tool

Static-fetch audit tools vs. eCommerce Insights on a hydrated storefront.

Generic tool

"No structured data found."

Audit fetches the URL with a simple HTTP client. The shell comes back. No JSON-LD in the static response. Report says you have no schema. Your engineering team, who shipped JSON-LD via next/script last quarter, files the report under "incorrect."

  • Static HTTP fetch only
  • Misses every JS-injected JSON-LD
  • No render budget analysis
  • Wrong answer on hydrated storefronts
eCommerce Insights

"JSON-LD present in rendered DOM. Missing offers block."

Renders the page in headless Chrome, waits for hydration, reads the actual DOM. The recommendation is grounded in what the AI engines see. The engineering team gets a real diff to ship.

  • Static and rendered audits both available
  • Reads JSON-LD injected at any time
  • Flags render-budget risk
  • Geography-pinnable for edge-personalized stores
Brand profile

A footwear brand on Shopify Hydrogen, $30M GMV, four-person frontend team.

The team had migrated from a Liquid theme to Hydrogen the year before. The DTC site felt faster. ChatGPT citations dropped quarter over quarter, with no obvious cause. The first eCommerce Insights audit run with Force JavaScript rendering showed the new Hydrogen build was emitting Product JSON-LD via a streaming React component that took 3.4 seconds to hydrate on mobile. AI crawlers operating on a 2.5-second budget were indexing the shell. A two-line change to move the JSON-LD into the initial server response restored the visibility. Static fetches now match rendered fetches on PDPs.

Illustrative brand profile. eCommerce Insights does not publish customer case studies without permission.

Audit · Hydrogen PDP
Static fetch     JSON-LD: 0 bytes
Render @ 2.5s   JSON-LD: 0 bytes (still hydrating)
Render @ 5.0s   JSON-LD: 1,840 bytes
→ Move JSON-LD to root loader.
Estimated lift: re-enter render budget for all crawlers.

If your storefront is hydrated, your audit should be too.

Audit a page now

Drop your headless PDP URL, get a rendered audit.

Free audit covers one URL. The free trial includes 500 rendered audits per month and unlimited static audits.

Related

Keep reading.

Channel

For Shopify (and Hydrogen)

Headless Shopify on Hydrogen gets the rendered audit plus the Shopify Admin API reads.

 Feature

PDP optimization

How eCommerce Insights turns an audit finding into a shippable diff, including for code-level changes.

 Guide

Schema for AI search

What Product JSON-LD fields the AI engines look for, and how to emit them from a headless loader.

See per-SKU tracking across hydrated storefronts

Further reading: Google's JavaScript SEO basics, which describes the render budget model the rendered audit is designed to surface.

Ask AI about eCommerce Insights for headless storefronts

Have your favorite AI engine summarize this page for your specific use case.

Frequently asked questions

Why do most AI audit tools fail on headless storefronts?
Most audit tools do a static HTTP fetch. They get the initial HTML shell that the headless frontend ships, which on a typical Hydrogen, Next Commerce, or PWA Studio build is mostly an empty body, a script tag pointing at the bundle, and minimal SEO meta. The product content (title, description, JSON-LD) gets injected by JavaScript after hydration. A static fetch reports "no content found." AI engines that render JavaScript (Google AI Overviews, increasingly the others) see the content. The audit and the AI engines disagree.
How does the Force JavaScript rendering toggle work?
On the Analyze a Page tool, a Force JavaScript rendering toggle is exposed in the audit settings. When enabled, eCommerce Insights routes the fetch through a headless-browser rendering service (ScrapingBee under the hood) that loads the page, executes JavaScript with a configurable wait time, and returns the fully hydrated DOM. The audit then runs against the same content the AI engines see. There is a per-audit cost for rendered requests, which is why the toggle is opt-in rather than default.
Which headless storefront frameworks does eCommerce Insights support?
Any framework, in principle, because the audit runs against the rendered DOM, not the source code. In practice the most-tested frameworks are Shopify Hydrogen, Next Commerce (Vercel Commerce), Adobe Commerce PWA Studio, BigCommerce Catalyst, Saleor with Next.js, commercetools with various frontends, and custom Next.js or Nuxt builds. The audit works on Remix and SvelteKit storefronts too. If the page renders in a headless browser, eCommerce Insights can score it.
Can eCommerce Insights read JSON-LD that's injected client-side via next/script?
Yes, when Force JavaScript rendering is enabled. The audit waits for the configured time (default 2.5 seconds, adjustable), then reads every script tag of type application/ld+json from the rendered DOM. JSON-LD injected via next/script with strategy='afterInteractive' or via a useEffect on a React component is picked up the same way.
Does the rendered audit work for category and search pages, not just PDPs?
Yes. The rendering layer is page-type agnostic; it loads any URL and returns the rendered DOM. The eCommerce Insights scoring rules differ by page type (PDPs are scored against Product schema and PDP answerability, category pages against ItemList and BreadcrumbList), but the underlying fetch is the same. Search and faceted-navigation pages on headless storefronts are often heavy with client-side state; the rendered fetch handles them.
Are there cases where Force JavaScript rendering still misses content?
Yes, two. First, content that requires user interaction (a click, a scroll, a region selector) before rendering will not appear in the audit unless that interaction is automated; eCommerce Insights flags pages where AI engines also can't see the content for the same reason. Second, content gated behind authentication or a server-side personalization layer that requires session state will not render in a clean browser. The audit reports on what's publicly visible, which is what AI crawlers see anyway.

Audit a hydrated PDP in 60 seconds.

Force JavaScript rendering reads the same DOM the AI engines do. Hydrogen, Next Commerce, PWA Studio, Catalyst, and beyond.

Audit a page free Start free trial