ssrchecker
BlogThe rendering gap is widening: why AI crawlers changed the math on client-side rendering

The rendering gap is widening: why AI crawlers changed the math on client-side rendering

Abdul Mannan Soomro
20 January 2026 · 4 min read
ai-crawlersrenderingindexing
The rendering gap is widening: why AI crawlers changed the math on client-side rendering

For most of the last decade, the debate about client-side rendering had a comfortable off-ramp. Someone would point out that a React SPA serves crawlers an empty shell, and someone else would reply: Google renders JavaScript now. It's fine. And they were mostly right. Google has executed JavaScript in a second rendering pass since 2019, and for a site willing to wait out the delay, client-side rendering usually resolved into an indexed page eventually.

That reply is quietly becoming wrong. Not because Google changed — because Google stopped being the only reader that matters.

The short version

The crawlers behind AI answers and chat assistants mostly fetch raw HTML and do not execute JavaScript. A client-rendered page that Google eventually indexes after its second pass can be permanently invisible to them, because there is no second pass. As more discovery shifts to those systems, "Google handles it" stops being a sufficient defense of client-side rendering.

The assumption that used to hold

The "Google handles it" position rested on two things being true at once: that the dominant source of discovery was Google, and that Google was unusually good at rendering JavaScript. Both were true, so the conclusion followed. A page assembled in the browser would be seen — late, and at some crawl-budget cost, but seen.

What made this workable was Google's two-pass model. The first pass reads the raw HTML. The second pass, some time later, runs a headless browser, executes the JavaScript, and indexes the result. Client-rendered content lives or dies on that second pass. It's slower and less reliable than being in the HTML from the start, but for a patient site it worked.

What changed underneath it

The channels through which people find things have started to fan out. A growing share of queries never reach a traditional results page at all — they're answered by an assistant that synthesizes from sources it fetched itself. And the crawlers those systems use to fetch sources are, as a rule, not full browsers. They request the URL, take the HTML that comes back, and work with what's in it.

There is no second pass. There is no render queue to wait in. If your content isn't in the raw HTML, it isn't in what these systems read — not late, not partially, just not at all.

That's the shift. The old defense assumed the reader would eventually run your JavaScript. A rising fraction of readers never will.

Why this is easy to miss

The failure is invisible from inside Google Search Console, which is where most people look. Your pages still get indexed on the delay you're used to. Your Google traffic looks normal. Nothing in the tooling you check daily flags that an entirely separate class of crawler visited, found an empty shell, and moved on with nothing.

It's the same underlying problem client rendering always had — content absent from the first response — but with the safety net removed. Google's patience was papering over the gap. The systems that don't render don't offer that patience, and they don't tell you they came.

What it doesn't change

Worth being precise, because it's easy to overcorrect. This is not a reason to server-render everything reflexively, and it's not a claim that JavaScript is bad for SEO. A JavaScript site that puts its content in the first response competes on completely equal terms — the framework was never the problem, the render location was. Static generation, server rendering, and incremental regeneration all produce complete first-pass HTML, and all three are equally fine here.

What's changed is only the cost-benefit of the client-rendered case specifically. The argument for tolerating it was "Google will handle it." That argument is weaker every quarter, and the pages it was protecting are the ones now missing from a growing slice of discovery.

How to know if it affects you

The test hasn't changed even though the stakes have. Fetch one of your important templates as raw HTML — no JavaScript — and see whether the content is there. If a meaningful part of the page only appears after the browser runs its scripts, that's the part these crawlers don't see. The checker on this site does exactly that comparison and shows you which elements are missing before JavaScript runs.

If you want the mechanics in full — the two-pass model, the render queue, why client-rendered pages sit longest in it — the JavaScript SEO guide covers the whole picture, and the piece on AI crawlers and JavaScript goes deeper on the specific behavior of the non-rendering crawlers. But the one-line takeaway is smaller than it sounds: the old escape hatch is closing, and first-pass completeness is no longer optional the way it used to be.

ShareXLinkedIn
Want to see where your own site stands? Run a check, or read the JavaScript SEO guide for the full picture.