AI Search Client-Side Rendering: What Works

Server-side rendering (SSR), in this context, means the HTML a server sends in response to the first request already contains the page's actual content — headline, body text, links, structured data — rather than an empty shell that JavaScript fills in after the browser loads it. Static generation is the build-time cousin of this: the same fully-formed HTML, pre-built and served from cache instead of assembled per request. Both stand in contrast to client-side rendering (CSR), where the initial HTML response is a near-empty document and a JavaScript bundle builds the visible page in the browser. That distinction — content in the HTTP response versus content built after the fact — is the entire question this article is about, because most AI crawlers cannot run the second half of that process.

What the research actually shows

The clearest data on this comes from a study Vercel ran with the SEO consultancy MERJ, published July 31, 2024, which instrumented nextjs.org and two other sites with edge middleware to measure exactly how Googlebot handles JavaScript-heavy pages. It found Google renders virtually everything it crawls — 100% of HTML pages in the sample got a full-page render — but with a real time cost: a median render delay of about 10 seconds after initial crawl, a 90th-percentile delay of roughly 3 hours, and a long tail stretching to about 18 hours at the 99th percentile (Vercel, "Javascript SEO: How Google Crawls, Renders & Indexes JS," Jul 2024).

Vercel followed that with a much larger analysis of AI crawler traffic across its network, published December 17, 2024 by Giacomo Zecchini, Alice Alexandra Moore, Malte Ubl, and Ryan Siddle. Its finding is blunt: "Most AI crawlers don't execute JavaScript. We tested the major ones (ChatGPT, Claude, and others), and the results were consistent: none of them render client-side content." In the same dataset, GPTBot generated 569 million requests in a month, Claude 370 million, AppleBot 314 million, and PerplexityBot 24.4 million. ChatGPT's crawler fetched JavaScript files in 11.5% of requests and Claude's in 23.84% — but fetching a script and executing it are different things, and the study found no evidence of execution in either case (Vercel, "The rise of the AI crawler," Dec 17, 2024).

The one consistent exception is Google's own AI surface: Gemini can piggyback on Google's existing rendering infrastructure, so pages that are only fully visible after client-side JavaScript still have a path into Google's index and into Gemini's answers, subject to the render-queue delay above. OpenAI's, Anthropic's, and Perplexity's crawlers have no equivalent rendering step — a page that depends on JavaScript to produce its content is, to them, functionally blank.

This isn't a stale 2024 finding that's since been overtaken. Search Engine Land revisited the question in April 2026 and reported the pattern holding: "Most AI crawlers don't execute JavaScript... and] none of them render client-side content," concluding that no-JavaScript fallbacks for critical content and links are "still strongly recommended" even as Google's own rendering pipeline has gotten more forgiving ([Search Engine Land, "No-JavaScript fallbacks in 2026: Less critical, still necessary," Apr 17, 2026).

How Google's pipeline differs — and why that's not a safety net

It's worth being precise about Google here, because "Google can render JavaScript" gets misread as "so this doesn't matter." Google's own documentation describes a three-phase pipeline: crawling (fetch the URL, check robots.txt), rendering (queue the page for a headless browser to execute JavaScript, unless a noindex directive says not to), and indexing (process the rendered output). Google's guidance is explicit that this is a real queue with real delay, not an instant step, and that certain things — like a canonical tag or a noindex directive set only by JavaScript after the fact — can be missed or misread because the crawl phase reads the pre-render HTML first (Google Search Central, "Understand JavaScript SEO Basics").

Even for the one crawler family that does render, Google's own developer guidance still recommends against relying on it: "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript" (Google Developers, "Rendering for Content-Driven Web Apps"). That's Google — the one search engine with a working JavaScript renderer — telling developers not to depend on it. For every AI crawler without that rendering step, the recommendation isn't a best practice; it's the only way in.

Rendering strategies compared

Next.js's own documentation frames the SEO-relevant line the same way: pages built with Server or Client Components split rendering work so that server-rendered output — including data fetched on the server — is delivered as HTML the browser can show immediately, while interactive behavior is layered on afterward through hydration (Next.js, "Server and Client Components"). Next.js's own SEO guide states the principle plainly: "page data and metadata must be available on page load without JavaScript," which is why SSG and SSR are its recommended defaults for anything meant to be indexed, and CSR is flagged as not appropriate for content that needs to be found (Next.js, "SEO: Rendering Strategies").

The practical check

Direct answer: This isn't a framework question — a site can misfire on rendering regardless of what it's built with, including static generators, if a widget, personalization layer, or A/B test tool injects content only in the browser. Here's how to verify what's actually being served, independent of what the stack claims to do.

1. Fetch the raw response, not the browser view. Use curl or a plain HTTP request against the page URL and read the response body directly — this is the closest approximation to what a non-rendering crawler receives.
2. Diff it against the rendered DOM. Open the same page in a browser, use the inspector's "Elements" view (the post-JavaScript DOM), and compare it line by line against the raw response from step 1. Anything present in one but not the other is JavaScript-dependent.
3. Check that the core content is text, not a reference. Headline, body copy, key facts, pricing, and any claim you want cited should appear as literal text in the raw HTML — not as a JSON blob inside a script tag that a client-side script later parses and injects.
4. Confirm metadata is server-rendered. Title, meta description, canonical link, and Open Graph tags all need to be present in the raw response. If a script tag sets these after load, a non-rendering crawler never sees them.
5. Test with JavaScript disabled. Most browsers let you turn off JavaScript execution for a tab; reload the page this way to see, directly, the degraded experience that maps closely to what GPTBot or ClaudeBot receives.
6. Verify structured data is in the raw HTML. Schema.org markup that both search engines and AI systems lean on for extraction needs to be present pre-render, for the same reason as metadata.
7. Check for a single-bundle failure mode. If the entire body of the raw response is effectively one reference to a JavaScript file with no fallback content, that's a hard failure — there is nothing for a non-rendering crawler to read at all.
8. Cross-check with Google's URL Inspection tool. This shows what Googlebot's own renderer produced, which is useful for validating the "Google can eventually see this" case — but note it says nothing about crawlers that don't render at all, so it can't stand in for steps 1-4.
9. Re-run this after any change to the rendering path. New A/B testing tools, personalization scripts, CMS migrations, or third-party embeds are common places where content quietly moves from server-rendered to client-injected without anyone deciding that on purpose.

What this doesn't guarantee

Direct answer: Passing every step above means an AI crawler's basic fetch will receive real content. It does not mean that content gets cited, summarized, or ranked well by the AI system consuming it. A few things this check is silent on:

• Crawl access is a separate gate. Robots.txt rules, crawl budget, and outright blocking (deliberate or accidental) all happen before rendering is even relevant. Serving perfect HTML to a crawler that's disallowed from fetching the page changes nothing.
• Content quality and authority still do the actual work. Making content visible is a prerequisite for being cited, not a substitute for it being accurate, well-organized, or trustworthy enough for an AI system to want to use.
• Freshness and re-crawl frequency vary by system, and none of them are published with the reliability of a fixed schedule — a rendering fix doesn't tell you when a crawler will next revisit the page.
• Crawler behavior changes. The research cited here spans mid-2024 through early 2026 and the pattern has held, but these are third-party companies' internal systems; there's no guarantee GPTBot or ClaudeBot won't add a rendering step in the future, the way Google's own crawler already has.
• This is a visibility check, not a ranking or citation audit. It tells you whether the door is open, not whether what's inside is good enough to be picked.

Where nqzai fits

Direct answer: nqzai's AI-search visibility tooling includes checks that fetch a site's key pages the way a non-rendering crawler would, compare that against what a real browser renders, and flag pages where content, metadata, or structured data only exist after JavaScript runs — folding that gap directly into the broader GEO and AI-search audit rather than treating it as a separate technical afterthought. The goal is the same as the checklist above: catch the difference between what a page looks like and what it actually serves, before it shows up as an unexplained absence from AI answers.

FAQ

Do all AI crawlers skip JavaScript?

No, but the exception is narrow. Vercel's research found GPTBot, ClaudeBot, and PerplexityBot do not execute JavaScript at all, while AppleBot and Google's Gemini can, because Gemini uses Google's existing Web Rendering pipeline. For OpenAI, Anthropic, and Perplexity's crawlers specifically, there is currently no rendering step.

Does server-side rendering guarantee my content gets cited by ChatGPT or Perplexity?

No. It removes a specific technical blocker — the crawler being unable to see the content at all — but citation depends on content quality, relevance to the query, crawl access, and how the AI system's retrieval layer ranks and selects sources. See the Limitations section above.

Is Next.js (or any specific framework) required to fix this?

No. The requirement is that content exists in the raw HTTP response, which any server-rendered or statically generated site can satisfy regardless of framework. Next.js is referenced here because its documentation is explicit and well-sourced on the SSR/SSG/CSR distinction, not because it's the only way to solve this.

How is this different from the "JavaScript SEO" problem search engines have dealt with for years?

The underlying technical issue is the same — content not present in the initial HTML — but the stakes differ. Google eventually renders most pages, just with a delay measured in seconds to hours. AI crawlers that don't render at all don't have an "eventually"; the content is simply absent from what they process.

How often should I re-run this check?

Anytime the rendering path changes — a CMS migration, a new personalization or A/B testing tool, a redesign, or a framework upgrade. These are the most common places content quietly moves from server-rendered to client-only without a deliberate decision behind it, so the check is worth treating as a regression test, not a one-time audit.