If your product pages, prices, or reviews only appear after JavaScript runs, you’re making every crawler — Google, GPTBot, ClaudeBot, and Perplexity alike — do extra work to see what a human sees instantly. Some do that work. Most don’t. This guide shows you exactly how to check which camp your site falls into, and how to fix it.

1. Why JavaScript Rendering Is Still a Technical SEO Problem in 2026

Most modern e-commerce stacks — Shopify with heavy app/theme customization, headless commerce on Next.js or Nuxt, and custom React/Vue storefronts — rely on JavaScript to build some or all of the page a user sees. That’s fine for the browser. It’s a genuine risk for search and AI visibility, because crawlers don’t all execute JavaScript the same way, or at all.

The core problem hasn’t gone away just because tooling has improved: there is a real gap between what’s in your raw HTML response and what appears after the browser (or a crawler’s rendering engine) finishes executing your scripts. Everything in this guide is about finding and closing that gap.

The 2026 shift The stakes changed with the rise of AI answer engines. Google eventually renders JavaScript. GPTBot, ClaudeBot, and PerplexityBot largely do not render it at scale today — they fetch raw HTML. If your key facts (price, availability, specs, FAQ answers) only exist after hydration, you may rank fine on Google while being functionally invisible to AI Overviews, ChatGPT, Claude, and Perplexity answers.

2. The Three Rendering Models You Need to Know Cold

2.1 Client-Side Rendering (CSR)

The server sends a near-empty HTML shell — usually a single <div id=”root”>, or your Shopify theme’s minimal scaffold — plus a JavaScript bundle. The browser downloads that bundle, executes it, fetches data (often from an API), and builds the actual page in the DOM after load. Pure React, Vue, or Angular single-page apps without a rendering layer work this way by default.

• Fastest to build, cheapest to host
• Worst default for SEO — the raw HTML crawlers first receive contains little to no content
• Common failure point for headless storefronts bolted onto a JS framework without a rendering strategy

2.2 Server-Side Rendering (SSR)

The server executes the JavaScript framework at request time and returns fully-formed HTML with the content already in place. The same JS then “hydrates” in the browser to make the page interactive. Next.js, Nuxt, and Remix all support this natively.

• Crawlers of every kind receive complete content in the very first response — no rendering required on their end
• Slightly higher server cost and response time than CSR, since rendering happens per-request
• The safest default for e-commerce and content sites that care about both Google and AI crawler visibility

2.3 Dynamic Rendering (the workaround, not the fix)

The server detects the user-agent of the request. Real users get the normal CSR/JS experience. Recognized bots get a separately pre-rendered, static HTML snapshot instead — typically generated by a headless browser service like Rendertron or Prerender.io sitting in front of the app.

• Useful as a stop-gap on legacy CSR sites where a full SSR rewrite isn’t feasible right now
• Introduces a second version of your site to maintain — content drift between the “bot version” and “user version” is a real, common failure mode

 VENDOR CLAIM   Google has described dynamic rendering as an acceptable interim solution for JS-heavy sites, but frames it explicitly as a workaround rather than a long-term recommendation, and has not extended that endorsement to non-Google crawlers.

 DISPUTED   Because dynamic rendering serves different HTML to bots than to users based on user-agent, it sits close to what cloaking guidelines warn against. Google’s own position is that user-agent-based dynamic rendering is not cloaking as long as the rendered content matches what a user would eventually see — but the margin for error (stale snapshots, mismatched content) is a genuine risk practitioners disagree on managing.

2.4 Static Site Generation / Prerendering (the strongest option for content pages)

Pages are rendered to HTML at build time, not request time, and served as flat files (optionally rehydrated with JS for interactivity). Next.js’s Static Generation, Astro, and Shopify Hydrogen’s static/edge rendering modes fall here. For blog posts, category pages, and FAQ content, this gives every crawler — human, Googlebot, or AI bot — the exact same complete HTML, with no rendering step required anywhere.

3. How Googlebot Actually Renders JavaScript

Google doesn’t index your site in one pass. It uses a two-wave process:

• Wave 1 — Crawling and initial indexing: Googlebot fetches the raw HTML and indexes what’s immediately available — links, basic text, meta tags present without JS execution
• Wave 2 — Rendering: the URL is queued for Google’s Web Rendering Service (WRS), which uses an evergreen, regularly-updated Chromium engine to execute JavaScript much like a real browser, then re-indexes the resulting DOM

The gap between wave 1 and wave 2 is not instant. It can range from seconds to days depending on crawl budget and site-level rendering demand, which is exactly why large JS-heavy sites can see delayed indexing of new or changed content even when the content itself is technically correct once rendered.

 VERIFIED   Google has confirmed the two-wave indexing process and the evergreen Chromium-based Web Rendering Service directly in its official developer documentation and multiple Search Central conference talks.

What this means practically: Google can see your JS-rendered content, eventually. The cost isn’t visibility, it’s speed and crawl budget — every URL that requires rendering consumes more of Google’s finite resources on your site than one that arrives fully formed.

4. How AI Crawlers Handle JavaScript — the Part Most Guides Skip

This is where the gap widens sharply, and where most JS SEO advice written for Google alone falls short for GEO/AEO purposes.

Crawler	Renders JavaScript?	Practical implication
Googlebot	Yes (two-wave, deferred)	Content is eventually seen; indexing may lag
Bingbot	Yes (limited scale)	Similar deferred-render risk, historically slower rollout than Google
GPTBot (OpenAI)	No / minimal at scale	Content not present in raw HTML is effectively invisible to it
ClaudeBot (Anthropic)	No / minimal at scale	Same risk — relies on served HTML, not a rendered DOM
PerplexityBot	No / minimal at scale	Same risk — fetches HTML directly

 VENDOR CLAIM   Rendering behavior for GPTBot, ClaudeBot, and PerplexityBot is not exhaustively documented by any of the three vendors, and their crawling infrastructure can change without public notice. Treat the “no JS rendering at scale” position as the current, reasonable operating assumption based on available documentation and third-party crawl testing, not a permanent guarantee — recheck this periodically the same way you’d recheck bot IP ranges.

The practical rule for GEO work: if a fact needs to be cited correctly by an AI answer engine, it needs to exist in the raw HTML response, not only after client-side hydration. This is the single most consequential difference between optimizing for Google and optimizing for AI answer engines.

5. Where to Actually Check This — Step by Step

Don’t take rendering behavior on faith. Here is exactly where and how to verify what each crawler is seeing, on your own site, in order of speed.

5.1 Check the raw HTML — what non-rendering bots see

This is the fastest and most important check. It shows you exactly what GPTBot, ClaudeBot, and PerplexityBot receive.

# Fetch raw HTML exactly as a non-rendering bot would
curl -A “Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)” https://yourstore.com/products/example -o raw.html

# Then open raw.html in a text editor and search for your key facts:
grep -i “price” raw.html
grep -i “in stock” raw.html

If the price, availability, or core product description are missing from raw.html, that content only exists after JavaScript execution — invisible to today’s major AI crawlers, and delayed for Google.

5.2 Compare against the browser-rendered DOM

In Chrome, open the page, then open DevTools (F12 or right-click → Inspect) and go to the Elements panel. This shows the live DOM after all JavaScript has executed. Compare it against View Source (Ctrl+U / Cmd+U), which shows the original, unrendered HTML response — the same thing curl retrieved above. Any content present in Elements but absent from View Source is JS-dependent content.

5.3 Google Search Console — URL Inspection Tool

This is the exact location to check what Google itself rendered:

• Open Google Search Console for the property
• Use the URL Inspection Tool (top search bar) and enter the specific URL
• Click “Test Live URL” to force a fresh render
• Open “View Tested Page” → “Screenshot” tab to see what Googlebot’s renderer displayed
• Open the “HTML” tab in the same panel to see the rendered HTML Google indexed — compare this against your raw curl output from step 5.1

5.4 Rich Results Test / Schema Markup Validator

Google’s Rich Results Test (search.google.com/test/rich-results) renders the page using the same WRS engine and additionally validates structured data against the rendered DOM — useful for confirming that schema injected via JS (a common pattern in Shopify apps) is actually present after rendering, not just in your theme’s source template.

5.5 Screaming Frog — JavaScript rendering mode

Under Configuration → Spider → Rendering, switch from “Text Only” to “JavaScript” to crawl the site the way Google’s renderer would, then run the same crawl again in “Text Only” mode. Export both crawls and diff the extracted titles, meta descriptions, and word counts between the two — any page with a meaningful gap between the two crawls is rendering-dependent content.

Screaming Frog path:
Configuration > Spider > Rendering > JavaScript
(then re-crawl in “Text Only” mode for comparison)

Export both:
Internal > Export (JS render crawl)
Internal > Export (Text Only crawl)

Diff word count / title / meta description columns between the two exports

6. Common JS SEO Failures on Shopify and Headless Commerce

6.1 Infinite scroll without paginated fallback URLs

Product listing pages that load additional products via JavaScript scroll events, with no crawlable paginated URL structure underneath, hide entire product catalogs from crawlers that don’t execute JS and slow discovery even for ones that do.

6.2 Lazy-loaded images and content without noscript fallbacks

Lazy loading is good for performance, but implementations that rely purely on scroll-triggered JavaScript (rather than native `loading=”lazy”` or IntersectionObserver with proper fallback markup) can leave images and their alt text absent from the initial HTML entirely.

6.3 Client-side routing that never updates meta tags

Single-page app architectures using client-side routing (React Router, Vue Router) sometimes update the visible content on navigation but leave the <title> and meta description tags from the very first page load, because they were only ever set once at initial render, not per-route.

6.4 Price and availability rendered from a separate API call

A very common Shopify headless pattern: the initial HTML contains a product shell, and price/stock are fetched client-side from Shopify’s Storefront API after load. This is efficient for the user experience, but means the exact facts most valuable to a shopping-related AI query — current price, stock status — don’t exist in the HTML any non-rendering crawler receives.

6.5 FAQ and review content behind interaction-gated JS

Accordions and “load more reviews” components that only inject content into the DOM after a click event mean that content is invisible to any crawler that doesn’t simulate the interaction — which is effectively all of them, Googlebot included, since Google’s renderer doesn’t click buttons.

7. Query Fan-Out and Why Rendering Strategy Decides What Gets Cited

Query fan-out is the technique modern AI systems (Google’s AI Overviews, and comparable retrieval-augmented systems behind ChatGPT, Claude, and Perplexity) use to answer a single user question: instead of matching the query to one document, the system decomposes it into several related sub-queries, retrieves relevant passages for each, and synthesizes them into one answer.

For example, a single query like “best running shoes for flat feet” might fan out internally into sub-queries covering shoe types, pronation control, brand comparisons, and price ranges — each resolved against different retrieved passages, potentially from different pages or even different sites.

Why this ties directly back to rendering A fan-out system can only retrieve and cite a passage that exists in the content it has access to. If your comparison table, spec list, or FAQ answer is only present after JavaScript executes, it is structurally unavailable to be selected as a sub-query answer by any system that retrieves from raw HTML or a non-rendering crawl — regardless of how well-written or accurate that content is.

 DISPUTED   The exact mechanics of query fan-out are not fully published by any AI vendor; “query fan-out” is a term used by SEO practitioners to describe observed and partially-documented retrieval behavior, not a formal specification any company has released in full. Treat specific claims about how many sub-queries are generated or how retrieval is weighted as informed inference, not confirmed fact.

8. Making Content RAG-Ready: The Rendering-Level Checklist

RAG-ready content means content structured so a retrieval-augmented system can pull an accurate, self-contained passage without needing the surrounding page for context — and, per this guide, without needing a rendering step it may not perform.

• Render key facts server-side or at build time — price, availability, specs, and direct FAQ answers should exist in the initial HTML response, full stop
• Use semantic HTML, not div soup — proper <h2>/<h3> hierarchy, <table> for comparisons, <dl> for spec lists, so a passage extracted out of context still parses correctly
• Keep answer paragraphs self-contained — a retrieved chunk shouldn’t depend on a preceding paragraph for its subject to be clear (avoid “as mentioned above” without restating what was mentioned)
• Mark up structured data server-side, not injected post-load — Product, FAQPage, and HowTo schema should be present in the raw HTML, not appended to the DOM by a JS tag manager after render
• Chunk logically around one idea per section — headings should map to a single retrievable question or fact, mirroring how a fan-out sub-query would target a specific passage
• Avoid burying facts inside interaction-gated components — if a stat only appears after a click, treat it as content that doesn’t exist for retrieval purposes

9. Decision Framework: Which Rendering Strategy Fits Your Situation

Site type	Recommended approach	Why
Blog / content pages (any stack)	SSG / prerendering	Content is static at publish time — build-time rendering gives every crawler identical, complete HTML
Headless commerce (Next.js/Hydrogen)	SSR for PDP/PLP, SSG for evergreen content	Price/stock changes frequently enough to need per-request rendering; content pages don’t
Legacy CSR app, full rewrite not feasible now	Dynamic rendering as interim step	Faster to implement than a framework migration, with the content-drift risk actively monitored
Shopify (theme-based, not headless)	Audit theme/app JS dependencies directly	Core Shopify Liquid templates are server-rendered by default; the risk is almost always JS apps injecting content post-load

10. A Practical Audit Workflow You Can Run This Week

• 1. Pull raw HTML via curl with a GPTBot/ClaudeBot user-agent for your top 20 product and content pages
• 2. Grep each file for the specific facts that matter most: price, stock status, the FAQ answer text, the primary comparison table values
• 3. Run the same 20 URLs through Screaming Frog in both Text Only and JavaScript rendering modes; diff titles, meta descriptions, and word counts
• 4. Spot-check 5 of the highest-priority URLs in GSC’s URL Inspection Tool, using “Test Live URL” and reviewing the rendered HTML tab
• 5. Validate schema on those same 5 URLs with the Rich Results Test to confirm structured data survives rendering
• 6. Document every page where raw HTML is missing a key fact as a “rendering risk” item in your audit framework, prioritized by traffic/revenue value of the page
• 7. Fix the highest-priority gaps first by moving that specific content server-side or into build-time generation — you rarely need to re-architect the whole site to close the biggest gaps

11. Hydration Cost, Core Web Vitals, and Where GEO Overlaps With Performance

There’s a second-order problem worth understanding, because it connects your rendering strategy directly to metrics you’re likely already tracking: hydration itself is expensive, and that expense shows up in Core Web Vitals — specifically Interaction to Next Paint (INP) and, indirectly, Largest Contentful Paint (LCP) when the LCP element is JS-dependent content.

SSR and SSG solve the crawler-visibility problem, but a heavy hydration step — where the browser re-attaches JavaScript event handlers to already-rendered HTML — can still leave a page looking complete while remaining unresponsive to input for a noticeable stretch. This matters for two separate reasons that are easy to conflate:

• Crawler visibility is about whether content exists in HTML at all — solved by SSR/SSG regardless of hydration cost
• User-experience performance is about how quickly that already-visible content becomes interactive — a separate problem, measured by INP, that SSR/SSG doesn’t automatically fix

Partial hydration and “islands” architectures (Astro’s approach, and increasingly available in Next.js via React Server Components) address the second problem by shipping JavaScript only for the interactive components on a page — a size selector, a quantity stepper — while leaving static content, like descriptions and specs, as plain HTML with zero hydration cost. For e-commerce pages carrying heavy app-injected JavaScript (reviews widgets, upsell carousels, chat plugins), auditing which scripts are load-bearing for content versus purely interactive is often the fastest way to cut both hydration cost and rendering risk at once.

 VERIFIED   Google has confirmed that Core Web Vitals, including INP, are a ranking signal, and that INP specifically measures responsiveness after the page has become visually complete — a distinct measurement from whether content exists in the DOM at all.

12. Confirming Robots.txt Doesn’t Quietly Block Your Rendering Fix

A surprisingly common failure after a JS SEO fix ships: the rendering problem gets solved, but the JavaScript, CSS, or API endpoints the render depends on are blocked in robots.txt — often left over from an old “block everything in /assets/” or “/api/” rule written for an entirely different reason, like preventing duplicate content or hiding internal tooling.

If Googlebot’s renderer can’t fetch a blocked script or stylesheet, it renders the page without it — which can mean missing content, broken layout detection, or Google concluding the page is lower quality than it actually is. This is worth checking directly rather than assuming your robots.txt is fine because it was fine last year.

# Check what’s disallowed
curl https://yourstore.com/robots.txt

# Look specifically for rules that could block rendering dependencies
grep -iE “disallow.*(\.js|\.css|/api/|/_next/|/assets/)” robots.txt

Cross-check any matches against Google’s URL Inspection Tool — the “Page resources” section of a live test will explicitly flag any resource it couldn’t fetch due to a robots.txt block, which is the fastest confirmation that this specific failure mode is or isn’t affecting you.

13. Key Takeaways

• CSR is the highest-risk default; SSR and static generation are the safest choices for anything you want AI crawlers to see
• Google eventually renders JS via a two-wave process — the cost is speed and crawl budget, not permanent invisibility
• GPTBot, ClaudeBot, and PerplexityBot operate on raw HTML today — content that only exists after hydration is functionally invisible to them
• Query fan-out retrieval can only cite what it can retrieve — rendering strategy directly gates GEO/AEO visibility, not just traditional SEO
• Check this yourself: curl with a bot user-agent, GSC’s URL Inspection Tool, and Screaming Frog’s dual-mode crawl comparison are the three checks that catch nearly every real-world issue
• RAG-ready content is rendering-ready content — self-contained, semantically structured, and present in the very first HTTP response

14. References

1. Google Search Central — “Understanding JavaScript SEO Basics” and the two-wave indexing / Web Rendering Service documentation. developers.google.com/search/docs/crawling-indexing/javascript

2. Google Search Central — “Dynamic Rendering as a workaround” official guidance. developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering

3. Google Search Central — “URL Inspection Tool” documentation. developers.google.com/search/docs/monitor-debug/search-console-start

4. Google — “Rich Results Test” tool. search.google.com/test/rich-results

5. Screaming Frog — “Rendering configuration and JavaScript crawling” documentation. screamingfrog.co.uk/seo-spider (Configuration > Spider > Rendering)

6. OpenAI — “GPTBot” documentation (vendor-published, self-reported crawling behavior). platform.openai.com/docs/gptbot

7. Anthropic — “ClaudeBot” crawler documentation (vendor-published, self-reported). support.claude.com (search “ClaudeBot”)

8. Perplexity — “PerplexityBot” crawler documentation (vendor-published, self-reported). docs.perplexity.ai