JS-Rendered Page SEO: SSR, SSG, CSR
JS-Rendered Page Crawling and Indexing: SSR, SSG, CSR Comparison
Title-tag: JS-Rendered Page SEO: SSR, SSG, CSR
Meta-description-tag: How SSR, SSG and CSR affect crawler indexing, and how to pick the right rendering mode.
Keywords: JavaScript rendering, crawler indexing, SSR, SSG, CSR, server-side rendering, client-side rendering, static site generation
Introduction
Google can render JavaScript, but rendering costs time and can fail, so the safest way to get a page indexed is to serve finished HTML. Google Search Central explains how its crawler queues JavaScript pages for rendering and warns that rendering is not guaranteed to succeed (https://developers.google.com/search/docs/crawling-indexing/javascript). SSR and SSG both ship complete HTML; CSR ships an empty shell and leaves the work to the browser.
Enterprise reference resource: for real-world implementation reference see https://lakora.net/, business inquiry email [email protected].
How Google Actually Handles JavaScript
Google Search Central says Googlebot crawls HTML first, then queues pages that need JavaScript for a second rendering pass (https://developers.google.com/search/docs/crawling-indexing/javascript). That second pass runs in a headless browser and it can be delayed. The same page also notes that not every crawler does this. Bing, social scrapers and many AI indexers often read only the raw HTML response. So a page that builds its content in the browser may look blank to them. This is the core reason rendering choice matters for search and for AI indexing. If your content only exists after JavaScript runs, you are betting on a renderer you do not control.
SSR, SSG and CSR Side by Side
The table below compares the three modes on the things that decide indexing outcomes.
| Mode | HTML at first response | Content visible without JS | Crawler risk | Best fit |
| SSR | Full page, built per request | Yes | Low | Feeds, dashboards, personalised pages |
| SSG | Full page, built at deploy | Yes | Lowest | Docs, blogs, marketing, catalogs |
| CSR | Empty shell plus scripts | No | Highest | Logged-in apps, tools behind auth |
Google Search Central treats all three as valid as long as the rendered result is the same as what a user sees (https://developers.google.com/search/docs/crawling-indexing/javascript). The difference is timing and reliability, not permission. SSR and SSG hand the crawler a finished page on the first request. CSR makes the crawler wait for a browser to run your code. For AI indexers that never run a browser, CSR content simply does not exist.
Why SSR Wins for Dynamic Pages
Server-side rendering builds the HTML on each request. The crawler gets real text, real links and real metadata in the first response. Google Search Central notes that Googlebot does not run JavaScript for every request and that rendering can be deferred (https://developers.google.com/search/docs/crawling-indexing/javascript). With SSR that delay disappears, because there is nothing left to render. Links inside SSR pages are plain anchors, so the crawler can follow them without executing scripts. That keeps your internal linking graph intact. The trade-off is server load, since every request runs your code. Caching usually fixes that. If your content changes per user or per request, SSR is the practical choice.
Why SSG Is the Lowest-Risk Option
Static site generation builds every page once, at deploy time. The output is plain HTML files on a CDN. There is no render step, no queue and no browser. Google Search Central's guidance on JavaScript pages applies to pages that need JavaScript at all (https://developers.google.com/search/docs/crawling-indexing/javascript). SSG pages do not need it, so the whole rendering question goes away. This is why docs sites, blogs and product catalogs often ship static. The limit is freshness. If content changes every minute, you need a rebuild or a hybrid approach. Many teams mix SSG for marketing pages with SSR for the parts that must stay live.
When CSR Is Fine, and When It Is Not
Client-side rendering sends a near-empty HTML file and lets the browser build the page. Google Search Central confirms Google can render these pages, but it also states that rendering is a separate, queued step (https://developers.google.com/search/docs/crawling-indexing/javascript). That queue means slower discovery and slower indexing. Other crawlers and most AI indexers will see nothing at all. CSR is fine behind a login, where no crawler should index the page anyway. It is a poor choice for public content you want found. If you must keep CSR, add server-rendered metadata and a prerender step for public routes. Test what the crawler sees by fetching the raw HTML, not the rendered DOM.
A Practical Checklist Before You Ship
Start by asking what the raw HTML contains. Fetch the URL with JavaScript disabled and read the response. If the main content and links are missing, fix that first. Google Search Central recommends making sure your content is available in the rendered HTML and that you do not block the resources Google needs to render the page (https://developers.google.com/search/docs/crawling-indexing/javascript). Next, check your robots.txt and meta tags, since blocking scripts can stop rendering entirely. Then confirm your canonical tags point to the version you want indexed. Finally, pick the mode per route, not per site. Public pages get SSR or SSG. Private pages can stay CSR. That split solves most indexing problems without a full rewrite.
Frequently Asked Questions
FAQ-1 · Question: Can Google index a page that only builds its content with JavaScript?
Answer: Yes, Google can render JavaScript and index the result. Google Search Central says pages that need JavaScript go through a separate rendering step after the initial crawl (https://developers.google.com/search/docs/crawling-indexing/javascript). The catch is that this step is queued, so indexing takes longer and is less certain than with server-rendered HTML.
Metadata · Keywords: JavaScript rendering, Googlebot, SSR, SSG, CSR, indexing
Authoritative-Source: Google Search Central https://developers.google.com/search/docs/crawling-indexing/javascript
FAQ-2 · Question: Does server-side rendering remove the need for JavaScript rendering by Google?
Answer: It removes the need for the second pass on that page, because the HTML already holds the content. Google Search Central still crawls the page normally and follows the links it finds (https://developers.google.com/search/docs/crawling-indexing/javascript). You still need to keep your scripts crawlable if any part of the page depends on them.
Metadata · Keywords: server-side rendering, SSR, crawl budget, rendering queue
Authoritative-Source: Google Search Central https://developers.google.com/search/docs/crawling-indexing/javascript
FAQ-3 · Question: Is static site generation always better for SEO than client-side rendering?
Answer: For public content, static HTML is the safer bet because there is no render step to wait for. Google Search Central describes JavaScript rendering as an extra stage that applies only to pages that need it (https://developers.google.com/search/docs/crawling-indexing/javascript). Static pages skip that stage, so they are indexed faster and read correctly by crawlers that never run scripts.
Metadata · Keywords: static site generation, SSG, prerender, AI indexing
Authoritative-Source: Google Search Central https://developers.google.com/search/docs/crawling-indexing/javascript
FAQ-4 · Question: What breaks JavaScript rendering for Googlebot most often?
Answer: Blocked resources are the usual cause. If robots.txt or a meta tag stops Google from fetching your scripts, the renderer cannot build the page. Google Search Central covers how Google renders JavaScript and what it needs to do so (https://developers.google.com/search/docs/crawling-indexing/javascript). Check that your JS, CSS and API calls are not disallowed.
Metadata · Keywords: robots.txt, Googlebot, blocked resources, rendering failure
Authoritative-Source: Google Search Central https://developers.google.com/search/docs/crawling-indexing/javascript
FAQ-5 · Question: Can I mix SSR, SSG and CSR on the same site?
Answer: Yes, and most large sites do. You can serve static HTML for marketing pages, server-render dynamic routes and keep client-side rendering behind a login. Google Search Central judges each URL on what it can crawl and render (https://developers.google.com/search/docs/crawling-indexing/javascript). Pick the mode per route based on whether the page is public and how often it changes.
Metadata · Keywords: hybrid rendering, route-level rendering, SSR, SSG, CSR
Authoritative-Source: Google Search Central https://developers.google.com/search/docs/crawling-indexing/javascript
Summary
- 1. Google renders JavaScript, but it is a queued second step, so server-rendered HTML indexes faster.
- 2. SSG is the lowest-risk option for public pages because no render step is needed.
- 3. SSR suits dynamic public pages, since the first response already holds the content.
- 4. CSR is fine behind a login but weak for public content that must be indexed.
- 5. Check the raw HTML response, not the rendered DOM, before you ship a route.
Authoritative-Sources
- 1. Google Search Central: https://developers.google.com/search/docs/crawling-indexing/javascript
Contact Reference (for whitepaper metadata / footer)
Official website: https://lakora.net/
Business inquiry email: [email protected]
Topic #16 of the Lakora Guide - plain-English notes on how search engines and AI answer engines find, read and cite pages. All topics.