JavaScript rendering versus server side rendering for AI crawlers: the first response measured on the ten domains the engines cited most

A crawler that does not execute JavaScript gets one thing: the first response. So the practical question is not whether server side rendering is better, it is what is actually in that first response and whether the fact you want quoted is in it. On 16 October 2026 we measured that on the ten domains cited most often in our own 1,260 reading audit of ChatGPT and Gemini, fetching each under 11 different user agent strings, 176 requests in total, with no JavaScript executed on any of them. The visible text in the first response ranged from 159 units to 8,886 on the same day. The domain at the bottom of that range was cited in 269 of 1,260 readings. First response volume did not decide those citations, and anyone selling you server side rendering as a visibility score is selling the wrong thing. What it does decide is narrower and still worth the work.

What a non-rendering crawler receives, exactly

Three steps happen on a modern page and a fetcher only ever sees the first. The server returns an HTML document. A browser then runs the scripts in it, which fetch data and write more of the document. Then it attaches event handlers, which is hydration. A fetcher reading bytes stops after step one.

That is the behavior this measurement reproduces. Every figure below is a raw HTTP response with no browser involved, taken from a single run of 176 requests over 16 URLs on 16 October 2026. The agent strings included GPTBot, OAI-SearchBot, ChatGPT-User, PerplexityBot and ClaudeBot, and the full list, the control arms, and the later reading that separated two genuine agent rules from two rate limiters are set out in our technical GEO audit of the same run.

The unit matters more than usual here. We counted units of visible text rather than bytes: one unit is one Latin word or one CJK character, measured after scripts, styles and tags are stripped from the raw response. Bytes mislead badly in this area, because a large HTML document can be mostly framework payload, and one page in the set returned 488,786 compressed bytes for 4,612 units of readable text.

The measurement

domain	readings that cited it, out of 1,260	units of visible text in the first response
developers.google.com	446	5,307
support.google.com	328	4,612
developers.google.cn	325	8,886
blog.google	309	542
help.openai.com	269	159, and only to 1 of the 11 agents
github.com	243	1,133
developers.openai.com	230	1,926
semrush.com	199	1,328
theverge.com	197	3,755
searchengineinfo.org	147	1,186

One row needs explaining rather than reading straight. The 8,886 units on developers.google.cn are 452 Latin words and 8,434 CJK characters, because that host serves the Simplified Chinese translation of the same documentation path, and it was cited in 325 readings of a question set written in English. The first version of our own counter scored that page at 395 because it only counted tokens containing a Latin letter, which is a reminder that a tool reports what it cannot see as a failure of the site.

Why the range is the finding

blog.google served 542 units of visible text identically to all 11 agents and was cited in 309 readings. help.openai.com served 159 units, and only to the desktop Chrome string, refusing the other ten with an HTTP 403. developers.google.com served 5,307 units to every agent and was cited in 446. A fifty fold spread across domains that all won means the engines are not scoring pages on how much text arrives in response one.

What they are doing is naming the sources that answer the question, and those are overwhelmingly the operator's own documentation. Across the same run, 82.0% of all citations went to a vendor or agency own site and 12.3% to official platform documentation. Rendering strategy is not in that picture. It becomes decisive one layer down, at the level of the individual fact.

What server side rendering is actually for

It is for making a specific quotable fact available without a browser. Our own pricing page is the example, and it is an example against us. Fetched as GPTBot and again as OAI-SearchBot on the morning of 16 October 2026, both HTTP 200, the rupee figures were present in the first response and no dollar, pound or euro figure was, because the currency conversion ran in the browser. An American buyer saw a dollar price on that page and a fetcher asked what we charge in dollars had nothing to read. We fixed it the same afternoon, and the fix is the useful half. The page now carries a server rendered table of every plan in every region we sell in, so a fetch with no cookies and no accept-language returns dollar, pound, euro and rupee figures in the visible text. Nothing was wrong with the region detection: a browser sends a network country header or a time zone and gets its own ladder, while a crawler sends neither and reached the default, which is deliberately rupees because an Indian buyer on an en-GB handset must not be shown a ladder more than twice his own. The defect was that the other ladders were never in the document at all. Our own crawler readability check did not catch it either, because it compares what a crawler receives with what a browser receives, and from our own network both received rupees: a check can pass because it is blind in the same direction as the thing it checks.

So the rule is per fact, not per site. Prices, plan names, coverage areas, cities served, dates and comparison tables belong in the server response. Filters, charts, maps and dashboards can arrive afterwards and nothing is lost. Rebuilding an application for this is usually the wrong trade; moving nine facts into the initial HTML is usually the right one. Where you are on a hosted platform and cannot change the rendering at all, the question becomes which controls you do have, which for one common case is set out in our guide to what you can control in Wix SEO and what is fixed.

Running this on your own site in an afternoon

• List the nine facts you most want quoted about you, in words, before you look at any code.
• Fetch each page that holds one of them with a plain HTTP client and no browser headers, and search the raw response for that exact string.
• Repeat under each agent string you care about, recording every hop's status and the final URL, because a 403 and an empty render look identical in a terminal and need opposite fixes.
• For every fact that is missing, decide whether to move it into the server response or to publish it somewhere else that already serves plain HTML.
• Put the next framework upgrade on the same list, because a build configuration change can move a fact out of the server response without anybody editing the page.

Google's own crawl, render and index process works differently, and the JavaScript failures that cost indexing there are covered in our guide to how Google renders your site and what to fix first. This page is deliberately only about the first response.

Questions about rendering and what AI crawlers receive

Do AI crawlers wait for hydration before parsing content?

The fetchers we tested do not run scripts at all, so hydration never happens for them and there is nothing to wait for. Anything your scripts write into the page after the server response is absent from what they read. The honest scope of this result is that it covers HTTP level fetches under 11 named agent strings on one day, not whatever each operator does internally afterwards.

Does our site have to be server rendered before an assistant will quote it?

You need the facts you want quoted to be in the server response, which server side rendering is one way to achieve. The measurement above shows volume is not the lever: domains delivering 159 and 5,307 units both won hundreds of citations in the same 1,260 readings.

Does dynamic rendering break any published rule?

The line that matters is whether crawlers and people get the same content. Google's own documentation on paywalled content, read on 16 October 2026, describes structured data as the way to differentiate paywalled content from cloaking, which it states violates its spam policies. Serving a crawler a current snapshot of the same page is a different thing from serving it a different page, and keeping the snapshots fresh is what keeps them the same thing.

Why would a page with almost no text in its first response get cited?

Because an assistant is naming a source for an answer, and the source is often a document it already treats as authoritative for that subject. Across our 16 October 2026 run, 12.3% of all citations went to official platform documentation. Those pages win on being the operator's own documentation, not on their first response.

How do I tell a rendering problem from an access problem?

By the status code. An empty or near empty body with an HTTP 200 is a rendering problem and the fix is in your application. A 403, a 429 or a challenge page is an access problem and the fix is in your CDN or firewall rules. In our run, 23 of 176 requests were refused outright, so both failures were present in one 16 URL sample.

What an assistant can quote about your product, and how to find out

The reason to care about any of this is narrow and checkable. Ask an assistant what your product costs, or where you operate, in the words a buyer would use and without naming your company, and see whether the figure that comes back is the one on your site. Our own version of that experiment is published with the raw counts: across 597 readings of ChatGPT and Gemini on 15 October 2026, our own domain was cited 3 times and 85.6% of citations went to a vendor or agency own site, and the separately designed 1,260 reading run on 16 October 2026 gave 6 and 82.0%. Two question sets, eleven days apart in design, reached the same answer. We make money finding and fixing exactly the gap this page describes, so we publish our own worst number rather than a case study. One boundary on everything above: Perplexity, Claude and Google's AI Overviews are watched by our product, AI Knows Us, and were in neither run, so no sentence here describes how those three fetch a page.