Vercel's own infrastructure team analysed AI crawler behaviour across the traffic passing through its network and confirmed a finding independently replicated by Passionfruit's analysis of more than 500 million GPTBot fetches specifically: zero evidence of JavaScript execution. Not partial execution. Not execution with a timeout. None at all, across every major AI crawler measured, GPTBot, ClaudeBot, PerplexityBot, Meta's ExternalAgent, and ByteDance's Bytespider all download the initial HTML response and process only what is already present in it.
This creates what several 2026 technical analyses describe plainly as a two-tier web. A React single-page application that renders beautifully in a browser, and that Googlebot's headless Chrome-based rendering pipeline indexes perfectly well, can be simultaneously and completely invisible to every other major AI discovery surface, ChatGPT, Perplexity, and Claude included. The gap is not a minor performance penalty. It is the difference between existing in an AI-generated answer and not existing at all, for a channel that already represents a meaningful and rapidly growing share of how buyers discover products and information.
What Exactly Happens When an AI Crawler Encounters a Client-Rendered Page?
A client-side rendered application sends the browser a nearly empty HTML shell, typically a single container element and a script tag referencing the JavaScript bundle that will build the actual page once it runs. To a browser, this becomes a fully rendered page within moments, invisibly, as the JavaScript executes and populates the DOM. To an AI crawler that does not execute JavaScript, that empty shell is the entire visible content of the page. Every product description, every article, every FAQ answer that only exists after client-side rendering completes, simply does not exist from that crawler's perspective.
Vercel's data adds an important nuance that is easy to miss: these crawlers do fetch JavaScript files as part of their crawl. GPTBot's own fetch data shows it spending roughly 11.5% of its requests on JavaScript files specifically, and Claude spends closer to 23.84% of its fetches on the same file type. But fetching a file and executing it are entirely different operations, the crawlers appear to be collecting the raw JavaScript source code as text, likely as additional training material, not running it to see what content it would eventually produce. The distinction matters because it explains a pattern some teams find confusing: server logs showing heavy JavaScript file access from an AI crawler does not mean that crawler is seeing your rendered content.
Gemini is the documented exception, and understanding why clarifies the whole landscape rather than complicating it. Because Gemini, Google's AI Overviews, and AI Mode all run on Google's own infrastructure, they inherit Googlebot's mature, headless Chrome-based rendering pipeline, the same one that has handled JavaScript-heavy sites reasonably well for years. This means a client-side rendered site can perform acceptably in Google's AI surfaces specifically, while being entirely blank to ChatGPT, Perplexity, and Claude simultaneously. A team seeing reasonable Google AI Overview performance can easily and incorrectly conclude their JavaScript rendering situation is fine everywhere, when in fact they are measuring the one engine where the underlying problem happens to be invisible.
How Do You Check, in Under a Minute, Whether Your Own Site Has This Problem?
Right-click any important page on your site and select View Page Source, which shows the raw HTML exactly as it arrives from the server, before any JavaScript has had a chance to run. If your actual text content, product descriptions, article body copy, pricing, FAQ answers, is visible in that raw source, your content is server-rendered and reachable by every major AI crawler. If instead you see only an empty container div and a handful of script tags, you are running pure client-side rendering, and every AI crawler except Gemini currently sees nothing of substance on that page.
For a more precise, crawler-specific version of the same check, fetch the page directly with a specific user-agent and inspect the raw response: curl -A "GPTBot" https://yourpage.com. This is the definitive test, because it shows you exactly what GPTBot receives, with no browser rendering layer to mask the underlying problem. The AI crawlers guide covers this same verification technique applied more broadly across schema and access-control checks; this article focuses specifically on the rendering layer itself.
What Are the Actual Rendering Strategy Options, and What Does Each One Solve?
Modern frameworks offer several distinct rendering strategies, and picking the right one for a given page type matters more than picking a single strategy for an entire site.
Server-side rendering (SSR). The server executes the necessary JavaScript on every single request and sends fully-formed HTML to whoever asks for it, a browser, Googlebot, or GPTBot, all receiving the same complete content with no rendering ambiguity. This is the correct choice for content that changes frequently and needs to be both current and immediately crawlable, such as an ecommerce product page with a live price or a rapidly-updated news article. In Next.js's App Router, this looks as simple as an async server component that fetches its data directly on the server before returning markup, no client-side data-fetching round trip required for the crawler to see the content.
Static site generation (SSG). Content is pre-rendered into complete HTML files at build time, then served instantly from a CDN with no server computation needed on each request. This is ideal for content that does not change on every request, marketing pages, documentation, most blog posts, and it delivers both the fastest possible load time and guaranteed, zero-ambiguity crawlability, since the HTML file an AI crawler receives is identical to what a human browser receives, generated once in advance. The trade-off is staleness: the site must be rebuilt and redeployed to reflect any content change, which makes SSG a poor fit for real-time pricing or rapidly changing inventory data.
Incremental static regeneration (ISR) and hybrid rendering. Next.js and similar frameworks increasingly default to a hybrid model, using SSR or SSG for the critical initial page load, the content an AI crawler will actually see, while allowing client-side JavaScript to handle subsequent, non-critical interactivity after that first load. Industry analysis anticipates this hybrid approach dominating production React applications by the end of 2026, precisely because it captures the crawlability benefit of server rendering without sacrificing the rich interactivity that client-side JavaScript still does best for logged-in, interactive features that no crawler needs to see anyway.
Dynamic rendering, explicitly deprecated, not a viable strategy going forward. Serving a different, pre-rendered version of a page specifically to detected bots while serving the standard client-rendered version to regular users. Google deprecated this as a recommended long-term SEO approach back in 2022, and current 2026 guidance is unambiguous that it should be treated purely as a temporary migration workaround for teams already committed to it, not as a deliberate strategy for a new build. It still functions mechanically, but it is fragile, and any AI crawler that is misidentified or that changes its user-agent string can fall through the cracks entirely.
Which Framework Choices Make This Easiest to Get Right?
The framework itself does not determine SEO or AEO outcomes directly, the rendering configuration within it does. But some frameworks make the correct configuration dramatically easier to reach and harder to accidentally break than others. Next.js is the dominant choice for React-based projects specifically because it treats SSR, SSG, and its increasingly sophisticated React Server Components model as first-class, well-documented defaults rather than optional add-ons requiring separate configuration. Nuxt provides the equivalent server-rendering-by-default behaviour for Vue applications. Astro takes the most AI-crawler-friendly architectural stance of any mainstream framework by default, through what it calls Islands Architecture: pages ship as static HTML with zero client-side JavaScript unless a specific component genuinely requires interactivity, at which point only that isolated component hydrates on the client. From a pure AI crawler visibility standpoint, this is about as clean an approach as currently exists.
Plain React or Vue, used without any of these server-rendering frameworks layered on top, defaults to pure client-side rendering and is, as of 2026 technical consensus, no longer a defensible choice for any content that needs to be visible to AI crawlers or indexed by search engines. The one legitimate exception, called out consistently across every technical source on this topic, is purely internal or authenticated applications, admin dashboards, logged-in SaaS product interfaces, internal tools, where no crawler of any kind should be indexing the content in the first place, and the entire rendering-visibility question is moot.
What Content Patterns Beyond Full CSR Also Create Invisible-Content Risk?
Two related but distinct patterns produce a similar failure even on a site that has correctly implemented SSR or SSG for its main content architecture. Content loaded via a separate client-side data fetch after the initial page render, a common pattern for personalised recommendations, dynamically loaded comment sections, or lazy-loaded product specification tables, exists nowhere in the initial HTML response an AI crawler receives, even though the surrounding page shell was server-rendered correctly. And content technically present in the DOM but deliberately hidden through CSS, inside a collapsed accordion panel, an inactive tab, or a hidden FAQ answer awaiting a click, creates a subtler problem: Googlebot can technically access this content since it is present in the underlying markup, but the semantic relationship between that content and its visible context can be lost when an AI crawler parses raw HTML without the visual layout information a human or a rendering browser would use to understand which hidden content belongs with which visible heading.
Both patterns are worth specifically auditing on any site that has already migrated its core pages to SSR or SSG, since a team can reasonably believe its rendering strategy is solved at the architectural level while these more granular content-loading patterns quietly continue to hide specific, valuable content, an FAQ section, a detailed specification table, a pricing breakdown, from every non-Google AI crawler.
How NotionCue Confirms Whether Your Rendering Strategy Is Actually Working
The gap between believing your rendering is correctly configured and confirming it actually is, across every AI crawler that matters, is exactly the kind of silent failure that costs teams months of invisible citation potential before anyone notices. A page can look perfect in a browser, pass a casual manual spot-check, and still be sending an empty shell to GPTBot because of one specific template, one specific lazy-loaded component, or one specific edge-rendering configuration that differs from the rest of the site.
The NotionCue AI Crawler Audit fetches your key pages using the actual declared user-agent strings of GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Claude-SearchBot, and Googlebot-Extended, and confirms exactly what content, schema, and text each one receives in the raw response, distinguishing precisely between pages that are fully server-rendered and reachable, pages with partial client-side content gaps, and pages that are effectively empty shells to every crawler except Google's. Rather than manually curling each page and each user-agent combination by hand, the audit surfaces this across your full page inventory at once, prioritised by which pages carry the most citation value.
Start your free NotionCue trial and run the AI Crawler Audit on your ten highest-value pages this week. A React or Vue site that ranks well on Google while quietly being invisible everywhere else is one of the most common and most expensive gaps this audit surfaces.
If a full SSR or SSG migration is not immediately feasible for your architecture, prioritise the pages that actually matter for AI citation first: primary content pages, product descriptions, documentation, and FAQ sections. Client-side rendering remains genuinely fine for non-essential, purely interactive elements no crawler needs to understand, view counters, live chat widgets, social feed embeds, and similar enhancement features that add nothing to an AI-generated answer either way.
Frequently Asked Questions About SSR, CSR, and AI Crawler Visibility
Does React hydration break AI crawler visibility?
No, and this is a common point of confusion. Hydration is the process of a client-side framework attaching interactive event handlers to HTML that was already fully rendered by the server. The HTML content itself is delivered complete and readable before hydration ever occurs, so hydration affects only user interactivity, not what an AI crawler sees when it fetches the raw response. The confusion typically arises when a team conflates hydration, which is safe, with full client-side rendering from an empty shell, which is not.
Will AI crawlers eventually add JavaScript rendering capability like Googlebot has?
Current technical guidance is explicit that this should not be assumed or waited for as a near-term solution. As of the most recent 2026 analysis, OpenAI, Anthropic, and Perplexity have made no public commitment to building JavaScript rendering infrastructure at scale, and the operational cost of doing so, at the volume these crawlers already operate, is substantial. Teams that treat their rendering fix as a one-time architectural investment with permanent returns, rather than waiting for crawlers to eventually catch up, are the ones gaining a durable visibility advantage in the meantime.
Is it worth migrating an existing large client-rendered site to SSR, or should I start over?
A full rebuild is rarely necessary. Most modern frameworks, including Next.js, Nuxt, and Angular with Universal added, support incremental migration, where the highest-priority, most citation-relevant pages are converted to server rendering first, while lower-priority interactive sections remain client-rendered in the interim. Prioritise by citation value rather than attempting the entire site at once: the pages currently earning, or that should be earning, the most AI-referral traffic are the correct starting point for a phased migration.