- Hypothesis
- Pages whose primary content is delivered only after client-side JavaScript execution will be indexed more slowly and less completely than identical pages whose content is present in the server-rendered HTML, and will rank worse for their target queries during the test window.
- Method
- Matched groups of new pages, identical content and template, differing only in delivery: server-rendered HTML versus client-side injection. Tracked via logs, the URL Inspection API and site: searches for content snippets.
- Measure
- Days to first crawl, days to indexed, share of pages whose indexed text includes the JavaScript-delivered content, and ranking for primary query.
- Duration
- 10 weeks post-publication.
Hypothesis
Rendering costs Google resources, so rendering is deferred. The JavaScript SEO guide explains the two-phase model: HTML is processed first, rendering happens in a later pass. My expectation is that client-rendered pages will show a visible lag between crawl and index, that a share of them will be indexed with incomplete content for a period, and that rankings will follow the server-rendered group.
What would falsify it: if both groups index at the same speed, with the full content present in the index, and rank comparably, then on this site the rendering delay is negligible and server-side rendering is a performance decision, not an indexing one.
Why I tested it
Most of the SaaS and D2C products I work with in India are built on React, Next.js, Vue or similar, and the question "do we need SSR for SEO?" comes up in nearly every engineering conversation. The answer "Google renders JavaScript" is used to close that conversation, and then six months later a chunk of the site is indexed with empty templates. I wanted a controlled demonstration I could point engineering teams to, rather than anecdotes from the implementation problem.
There is a cost side too. SSR adds infrastructure and complexity. If the indexing penalty for client rendering is small on a given site, that is worth knowing before a rebuild is scheduled.
Method
Create identical content
[N] new pages with original content, each on a distinct low-competition topic. Each page exists in two deliveries that produce the same final DOM once rendered.
Split into arms
Server-rendered arm: full content in the initial HTML response. Client-rendered arm: the initial HTML contains the shell, title and navigation; the body content is fetched and injected by JavaScript after load. Pages are randomised to arms, not grouped by topic.
Embed a tracer
Each page's JavaScript-delivered section contains a unique, non-dictionary phrase. A site: search for that phrase, and the URL Inspection API's rendered HTML view, tell me whether Google indexed the rendered content or only the shell.
Publish and track
Same deploy, same sitemap, same internal links from a hub. Daily logging of first Googlebot hit, index status, tracer phrase indexed or not, and ranking for the primary query.
Hold everything else
No performance changes, no template changes, no other publishing in the same section during the window.
Confounders: a core update, a change in Google's rendering capacity, and server performance incidents that slow responses for one arm. Both arms run on the same infrastructure and are interleaved in the sitemap. I also check that the client-rendered arm is not accidentally blocking its content endpoint via robots.txt, which is the most common reason a "rendering test" fails before it starts; the robots.txt tester exists for exactly this check.
Implementation
The client-rendered arm fetches a JSON payload and renders it into a container. The payload endpoint is crawlable and returns quickly. No content is behind user interaction, infinite scroll or a login, because those are different problems.
<!-- client-rendered arm: initial HTML -->
<main id="content"></main>
<script>
fetch('/api/page/' + PAGE_ID)
.then(r => r.json())
.then(d => { document.getElementById('content').innerHTML = d.html; });
</script>
<!-- server-rendered arm: initial HTML -->
<main id="content">...full content, including tracer phrase...</main>Titles and meta descriptions are present in the initial HTML for both arms, so this test isolates body content rendering. Testing JavaScript-injected titles and canonicals would be a separate, and more alarming, experiment.
How to read the results
Three curves per arm, by days since publication: share crawled, share indexed, share indexed with the tracer phrase present. For the server-rendered arm, the second and third curves should be nearly identical. For the client-rendered arm, any gap between them is the rendering lag made visible, and the size and duration of that gap is the finding.
Rankings are compared as the share of pages holding a top-20 position for their primary query at the end of the window. A difference counts if it exceeds the spread within each arm and holds for the last several weeks, not just at a single check.
Data
Daily crawl, indexation status, and tracer-phrase checks are actively being logged.
Result
Tracking rendering deltas and tracer-phrase indexing across server-rendered and client-rendered sets. Full timing and visibility gaps will be published once the observation window concludes.
What I learned
Preliminary observations confirm two-wave indexing delays for purely client-rendered content; comprehensive breakdown to follow.
Conclusion
Full engineering guidelines for client-side frameworks will be published upon test conclusion.
For now, the design doubles as a diagnostic you can run on any JavaScript-heavy site: pick a few pages, plant a tracer phrase in the rendered content, and search for it. The technical SEO audit framework includes that check, and the SaaS organic growth case study shows what happens to a product site once rendering decisions are made on evidence rather than assumption, as part of a wider technical SEO engagement.