Server-Side Rendering and AI Crawlers: The JavaScript Trap

A Page That Ranks Well on Google Can Be Invisible to ChatGPT

A site built in React, Vue, or Angular renders its content after the fact, once the browser has downloaded and executed the JavaScript bundle. Googlebot has handled that step for years: it opens the page in a headless browser, waits for the script to run, then indexes whatever shows up. GPTBot, ClaudeBot, and PerplexityBot skip that step entirely. They fetch the raw HTML the server returns, parse it as-is, and move to the next URL. If that raw HTML is just an empty <div id="root"></div> waiting for React to take over, none of these crawlers see anything at all.

The gap stays hidden for months because the two symptoms never show up in the same place. Google Search Console rankings stay stable, sometimes strong, since Googlebot renders the page correctly. The gap only surfaces once someone asks ChatGPT or Perplexity directly about their own industry, and the company that spent months on content finds out, usually too late, that nobody on the AI side ever actually read it.

The problem is not new, but its stakes have shifted. Between 2015 and 2022, the move toward JavaScript frameworks like React or Vue mostly affected complex web applications, dashboards, internal tools, where SEO barely mattered. The same technical choice then spread to marketing sites and company blogs, often out of team habit rather than necessity, at a time when only Google actually handled deferred rendering. The arrival of AI answer crawlers changes the calculation: an architecture choice that used to cost, at worst, a slightly slower indexing cycle on Google now costs a flat absence from ChatGPT, Claude, or Perplexity answers.

Which Crawlers Read Raw HTML, Which Ones Wait for Rendering

The list of crawlers that skip JavaScript execution is longer than most teams assume, and it goes well beyond OpenAI.

An analysis covering 569 million GPTBot requests across a large hosting network in 2026 found zero JavaScript execution, not from GPTBot, nor from OAI-SearchBot, ChatGPT-User, ClaudeBot, or PerplexityBot. A separate study published by Onely in February 2026 put the figure at 42 percent: the share of JavaScript-rendered content that never gets indexed by AI systems, across all sites measured. This is not an occasional bug. It is a structural limit, documented in each operator’s own technical pages, and it has not moved since these crawlers first launched.

The Five-Minute Test: Seeing What GPTBot Actually Sees

No paid tool required to find out where a site stands. Five steps cover it, run once per important page type: homepage, product page, blog post.

1. Open the page and disable JavaScript in the browser dev tools (Rendering tab). If the main content disappears, an AI crawler sees the same empty page.
2. Right-click and choose "View Page Source" (not the inspector, which shows the already-rendered DOM). Look for the title and first paragraph text: if it is missing from this raw source, no AI crawler will ever read it.
3. Run curl -A "GPTBot" https://yoursite.ch/target-page from a terminal and check whether the expected content shows up in the response.
4. Compare with a plain curl https://yoursite.ch/target-page, no custom user-agent: if both responses match and contain the text, the page is already served as complete HTML.
5. Check server logs over the past few weeks to confirm GPTBot, ClaudeBot, or PerplexityBot actually visit the site. Being technically visible is worthless if no crawler ever shows up in the first place.

Here is the standalone summary worth quoting on its own: a page is visible to AI crawlers if its main text appears in the raw HTML the server returns, before any script runs, and invisible otherwise, regardless of how good the final rendered page looks in a browser.

Three Fixes, From Lightest to Heaviest

Every fix comes back to the same idea: return complete HTML on the very first server response, without waiting for a client-side script to run.

Server-side rendering (SSR)

The server renders the page on every request and returns a fully formed HTML document. Next.js, Nuxt, and Angular Universal all support this natively. It is the most robust option for content that changes often, a live news feed, a product catalog with real-time stock, at the cost of extra server load on every visit.

Static site generation (SSG)

Pages get built once, at build time, then served as-is. It is the simplest choice for editorial content that does not change every second: a blog, a marketing site. A fully static site, like the one you are reading right now, serves complete HTML to every crawler by construction, with no rendering step in between.

Hybrid rendering or prerendering

For an existing client-rendered app that nobody wants to rewrite from scratch, a prerendering service (Prerender.io and similar tools) generates an HTML snapshot of each page and serves it to identified crawlers, while human visitors still get the JavaScript version. It is a useful bridge, not a permanent architecture: it adds an external dependency and one more point of failure.

How to Choose Between the Three

The deciding factor is rarely technical in the first place: it is the size of the team that will maintain the solution afterward. A company without an in-house developer is better off defaulting to static generation at the next redesign, simpler to host and easier for an outside partner to audit later. A business with content that changes constantly, a product catalog or a public member area, gets more out of native SSR. Prerendering stays a fallback for cases where neither option is realistic for several months, while a larger redesign budget gets secured.

When Migrating the Whole Site Is Not Worth It

A login form, an authenticated client portal, an interactive configurator used only by people already committed to a purchase: none of these need to be read by an AI crawler, and moving them to SSR burns budget for zero visibility gain. The practical rule is simple: only pages meant to be found, read, and cited by a crawler, the homepage, service pages, blog posts, public product pages, justify the effort. A company with a limited budget gets more out of migrating its ten most strategic pages than out of rewriting an entire internal application for no measurable benefit.

There is also a case where the full diagnostic changes nothing: a site already built with server-side rendering or static generation, a classic WordPress theme or a static site generator, simply does not have this problem to begin with. The five-minute test remains the right first move before committing budget to an audit or a migration: on a good share of Swiss company websites, the main content is already readable without JavaScript, and the real work sits elsewhere, in data structure or internal linking.

One more edge case is worth naming directly: a site that mixes both patterns, a static marketing shell wrapped around a JavaScript-heavy product area, already gets most of the benefit without a full rewrite. Auditing page by page, rather than treating the domain as one monolithic decision, usually cuts the actual migration scope by more than half.

What This Means for a Company in French-Speaking Switzerland

An accounting firm, an architecture practice, or a private clinic that had a "modern" showcase site built in the past few years has decent odds of having inherited a client-rendered architecture, often without anyone asking the agency about that technical choice at the time. The typical symptom: the site ranks fine on Google for the company name, but never shows up when a prospect asks ChatGPT or Perplexity for a recommendation in their industry and region. The test described above confirms the diagnosis in under an hour, before any development budget gets committed.

This technical fix is a prerequisite, not a full strategy on its own: a perfectly rendered site with no structured data and no genuinely citable content will not gain much visibility either. That is what our overview of the six levers behind visibility in AI answer engines covers, with server-side rendering as just one of the six. Once rendering is fixed, it is still worth checking that crawlers are not blocked elsewhere, a trade-off covered in our method for deciding which AI crawlers to let through, then tracking the effect over time with a method for measuring AI visibility. For a company that wants to know where it stands before investing, the GEO Sprint starts from exactly this kind of technical diagnostic. All of the studio’s articles on the topic stay listed on the blog.