Your page ranks well on Google, yet ChatGPT never mentions your brand and Perplexity cites a competitor with thinner content. In many cases, the problem is not your content at all. It is your rendering architecture. Most AI crawlers cannot execute JavaScript, which means any content assembled in the browser simply does not exist for them. A React or Angular site can look flawless to a human and read as an empty shell to a large language model. This guide explains how server-side rendering, hydration, and crawler behavior decide what LLMs can actually read, and how to fix the gaps.
Googlebot spent two decades building a rendering pipeline. It fetches a page, queues it, executes the JavaScript in a headless Chromium instance, and indexes the final output. That capability lives inside Google. It did not transfer to the new generation of AI crawlers.
A joint crawl-log study by Vercel and MERJ analyzed close to one billion monthly AI crawler requests and found that none of the major AI crawlers, including OpenAI’s GPTBot and Anthropic’s ClaudeBot, execute JavaScript. They fetch script files, but they never run them. Google’s Gemini is the exception because it rides on Googlebot’s infrastructure.
The practical consequence is blunt. If your pricing table, product descriptions, or FAQ answers only appear after JavaScript runs in a browser, the crawlers feeding ChatGPT, Claude, and Perplexity receive none of it. Your Google ranking and your LLM visibility are now two separate technical problems.
The stakes keep rising. Gartner projects that traditional search engine volume will drop 25 percent by 2026 as users shift queries to AI chatbots and virtual agents. Buyers are asking assistants for vendor shortlists, and assistants can only recommend what their crawlers were able to read.
Three rendering approaches determine what a crawler receives on first fetch. Understanding them is the foundation of any AI visibility audit.
The server sends a near-empty HTML file plus a JavaScript bundle. The browser downloads the bundle, runs it, calls your APIs, and builds the page on the user’s device. Humans see a complete page after a short delay. An AI crawler sees a root div, some script tags, and little else. Single-page applications built with React, Vue, or Angular default to this model.
The server assembles the full HTML before sending it. Every heading, paragraph, and table is present in the initial response. A crawler that never runs JavaScript still receives the complete content. Frameworks like Next.js and Nuxt exist largely to make this practical for modern JavaScript teams. Static site generation (SSG) achieves the same outcome by pre-building HTML at deploy time.
Hydration is the bridge between the two. The server sends rendered HTML, then JavaScript loads in the browser and attaches event listeners so the static page becomes interactive. Done correctly, crawlers get full HTML and users get a dynamic application. Done poorly, hydration quietly removes or replaces the very content the server rendered.
Teams often assume that choosing an SSR framework settles the question. In practice, several specific failure patterns keep server-rendered sites invisible to AI crawlers.
Client-only content injection. Developers fetch “secondary” data after page load: pricing pulled from an API, reviews from a widget, specs from a CMS endpoint. To an AI crawler, that content never arrives. If the data matters for a buying decision, it must be in the initial HTML.
Hydration mismatches that replace server HTML. When the server-rendered markup and the client-rendered markup disagree, React and similar frameworks can discard the server output and rebuild the page in the browser. Users notice nothing. Crawlers that cached the first response may have received correct HTML, but ongoing mismatch errors often push teams to move rendering client-side, which breaks visibility permanently.
Content gated behind interaction. Accordions, tabs, and “load more” buttons that fetch content on click hide that content from any agent that cannot click. If your best answers sit inside a JavaScript-driven FAQ accordion that loads text on demand, LLMs cannot cite them.
Aggressive bot management. CDNs and firewalls frequently challenge unfamiliar user agents with JavaScript checks. An AI crawler that cannot execute JavaScript cannot pass a JavaScript challenge, so it receives a verification page instead of your content. Review your allowlists for GPTBot, OAI-SearchBot, ClaudeBot, and PerplexityBot before assuming a rendering problem.
Broken URL hygiene. The Vercel and MERJ data showed AI crawlers wasting over a third of their requests on 404 pages, compared with roughly 8 percent for Googlebot. These crawlers do not recover gracefully. Stale sitemaps, redirect chains, and dead internal links burn the limited attention an AI crawler gives your domain.
Skeleton screens and placeholders. Loading spinners and skeleton UI patterns ship placeholder markup first. A crawler with a short fetch timeout indexes the placeholder, not the content behind it.
Hydration deserves special attention because it fails silently. A page can pass a Lighthouse audit, render correctly in every browser, and still lose content between the server response and the final DOM.
Common culprits include timestamps and locale-dependent formatting that differ between server and client, components wrapped in client-only guards that render nothing on the server, personalization logic that swaps server content for user-specific variants, and A/B testing scripts that rewrite the page after load. Each pattern produces a gap between what your server sends and what your developers see in the browser, and AI crawlers live entirely on the server side of that gap.
The test is simple and worth running on every template. Fetch the page with JavaScript disabled, or run a plain curl request, and read the raw HTML. If your value proposition, product details, and answers to common questions are not present in that response, they are invisible to LLM retrieval.
A structured audit takes under an hour for most sites and removes guesswork.
Google’s own documentation on JavaScript SEO recommends server-side rendering or pre-rendering as the reliable path even for its rendering-capable crawler. For crawlers with no rendering capability at all, it is the only path.
The engineering direction is consistent across frameworks. Render primary content on the server, and reserve client-side JavaScript for interactivity that adds to the page rather than creating it.
This is where technical SEO and content strategy converge into a single discipline. Our LLM SEO Services team runs rendering audits, crawler log analysis, and content restructuring as one engagement, because fixing the HTML without fixing the answers, or the reverse, leaves visibility on the table.
For CTOs and marketing leaders, the question is no longer if assistants influence the pipeline but how much of the evaluation happens inside them before your sales team hears anything. A rendering architecture chosen three years ago for developer convenience is now a revenue variable, and it deserves the same scrutiny you give to security or uptime. The encouraging part is that the fix is bounded and measurable. Audit the raw HTML, prioritize templates by commercial value, and migrate them to server rendering in order.
If your buyers research vendors through AI assistants, a focused ChatGPT AI SEO program can turn those conversations into a source of qualified demand instead of a blind spot. For teams earlier in the journey, start with the curl test on your homepage today. What you see in that raw response is exactly what the next generation of buyers’ assistants sees.
Content that only appears after JavaScript executes in a browser. Major AI crawlers fetch raw HTML and do not run scripts, so client-rendered pages, delayed API content, and interaction-gated sections are invisible to them.
No. Crawl-log research by Vercel and MERJ found that GPTBot and ClaudeBot download JavaScript files but never execute them. Only Google’s Gemini, which uses Googlebot infrastructure, renders JavaScript fully.
Yes, for any content you want cited. SSR places complete HTML in the initial server response, which is the only version non-rendering AI crawlers ever see. CSR remains fine for logged-in tools with no discovery value.
Hydration itself is safe when the server HTML is complete. Problems arise when hydration mismatches cause frameworks to discard server markup, or when client-only components render nothing on the server, creating gaps crawlers cannot fill.
Fetch your key pages with curl or with JavaScript disabled and read the raw HTML. Then check server logs for GPTBot, ClaudeBot, and PerplexityBot visits, and confirm robots.txt and firewall rules are not blocking them.
As soon as AI assistants form part of your buyers’ research process. Commercial pages with client-side rendering lose citation opportunities daily, and migration effort scales with how long architectural debt accumulates.
© 2026 TIS. All rights reserved.
