SSR vs. CSR Page Rendering and SEO

Will Google see your website's content if it only appears after JavaScript executes? The short answer is: usually yes, but later, at the cost of more resources and with a higher risk of errors. How big that risk is depends on where the final HTML is generated. With server-side rendering (SSR), the browser and the crawler receive a document with content, headings, and internal links in the very first response. With client-side rendering (CSR), the server sends an almost empty HTML shell and JS files, while the entire DOM structure (Document Object Model, the tree of page elements built by the browser) is built only by the user's or crawler's device.

This difference directly impacts SEO. In CSR, the initial code contains neither text nor links, so Google's JavaScript indexing can be delayed. Rendering is more resource-heavy for Googlebot than parsing plain HTML (reading the code structure), and JS files as well as API requests fetched during rendering consume the crawl budget - the number of URLs Googlebot will crawl on a site within a given timeframe. Large websites feel this the most. A script error or a timeout can result in a skipped subpage or an indexed blank version. On top of that, it can lead to a worse LCP (Largest Contentful Paint, the render time of the largest content element) score in Core Web Vitals - Google's set of metrics describing loading speed, responsiveness, and visual stability - because the main content element only appears after JavaScript bundles are downloaded and processed. Below, we explain how web page rendering works in both models, what exactly changes in indexing and performance, and how to choose between SSR and CSR for SEO.

How Server-Side and Client-Side Rendering Work

Web page rendering is the process of turning HTML, CSS, JavaScript, and data into a view displayed in the browser. The two models differ in who does this work and what the initial HTML response - the server's very first response - contains.

In SSR, the server receives a request, executes the application code, fetches data from a database or API, and sends the ready-made HTML back to the browser or bot. This typically happens on every request, but modern frameworks can combine a static shell, cached fragments, dynamic content, and streaming. In CSR, the server sends a minimal HTML file with an empty container, such as <div id="root">, and a JS bundle. Only then does the user's browser download the script, execute it, and build the DOM structure.

The consequence is higher infrastructure costs with SSR, because every request not served by cache requires server compute. SSR can also increase TTFB (Time to First Byte, the time until the first byte of the server response is received) if the backend (the server-side part of the application) and cache are slow.

The model also affects link sharing. With SSR, Open Graph tags (the meta tags that social platforms use for the title, description, and preview image of a link) are in the source HTML, so social media previews generate properly. With CSR, if the tags are added by a script, scrapers (tools that fetch page content, including for link previews) that do not execute JavaScript might not see them.

How Search Engines and AI Bots Index JavaScript Websites

Two-Wave Indexing in Google and the Rendering Queue Trap

Googlebot's process is simplified and described as two-wave indexing: HTML is read immediately, while JavaScript execution goes into the Web Rendering Service (WRS) queue. Google queues all pages returning a 200 code (a successful server response) for rendering, unless a robots meta tag blocks indexing. With SSR, however, content and links are already available at the crawling stage. According to Google, a page can wait in the queue for a few seconds, though sometimes longer. The wait time depends on available resources. Google describes crawling, processing, and rendering as interconnected stages, so this model is not a rigid rule. WRS executes scripts in an up-to-date version of Chromium running in headless mode.

Here is what the bot's path looks like:

1. Crawling. The bot downloads HTML. In SSR, it already contains content, headings, links, and Schema.org structured data (tags describing page content in a way bots can understand), while CSR only has a skeleton.
2. Rendering queue. The page waits for available WRS resources. With CSR, Google only sees content and links after this stage.
3. Rendering and indexing. WRS executes scripts, and Google indexes the rendered DOM.

Googlebot does not perform interactions such as onClick or infinite scroll (clicks, loading content on scroll). Internal links therefore require native <a href="..."> tags, which is especially critical for e-commerce SEO with listings loaded via scrolling.

Googlebot does not perform interactions such as onClick or infinite scroll (clicks, loading content on scroll). Internal links therefore require native <a href="..."> tags, which is especially critical for e-commerce SEO with listings loaded via scrolling.

Google recommends placing Product structured data in the initial HTML code, as tags generated by JavaScript may make crawling for shopping results less frequent and less reliable. However, Google does allow JSON-LD (a format for writing structured data) injected via JavaScript.

Invisibility of CSR Content to Artificial Intelligence Crawlers

AI crawlers such as GPTBot, ClaudeBot, or PerplexityBot, in a Vercel test from December 2024, fetched HTML code, sometimes JS files too, but did not execute JavaScript. A Resoneo test from January 2026 confirmed the same for bots that ChatGPT, Claude, and Perplexity dispatch on user demand. A website built on pure CSR is an empty skeleton to them, so its content might not make it into the responses of AI tools using these crawlers. The exception is Applebot, which does render JavaScript.

Gemini uses Google infrastructure, but when fetching a page on user demand, it also does not execute JavaScript. In contrast, AI Overviews and Google's AI mode rely on the search engine index: it is enough that a page is indexed and eligible to appear in results with a snippet. Therefore, CSR content that Google has rendered can appear there. With SSR, content, links, and structured data are available to AI crawlers without running scripts. That is why an audit for AI SEO begins with checking whether critical content is in the raw HTML.

The Risk of Indexing Empty States and API Errors

If data from an external API fails to load within the renderer's time window, Google may index an empty page or treat it as a soft 404 (a page returning a 200 code, but empty or with a message stating there is no content, which Google treats as a 404 error). In Google Search Console, open URL Inspection, run a live test, and view the tested page. The HTML and Screenshot tabs show the post-rendering state. Compare them with the raw server response code from view-source (Ctrl+U) or via curl (a command-line tool). Text, links, or structured data present only in the rendered version indicate a reliance on JavaScript.

How Rendering Architecture Impacts Core Web Vitals

Server-Side Rendering usually yields faster FCP and LCP scores because content is already present in the HTML document. However, generating the view on the fly can increase TTFB, and overly heavy hydration can hurt INP. The impact of rendering on SEO is therefore a trade-off of some costs for others, rather than a straightforward advantage of one model. Choosing between SSR and CSR shifts the bottleneck from the browser to the server and back again.

TTFB and FCP are diagnostic metrics rather than Core Web Vitals, but their values help pinpoint where load time is being lost.

TTFB latency can be reduced using HTML streaming. The server then sends ready view fragments as they are generated, which shortens the perceived wait time.

Hydration (client-side hydration) is the process in which JavaScript in the browser attaches event listeners (functions responding to clicks and other user actions) to previously rendered, static HTML. When it is too intensive, it blocks the main thread (the part of the browser handling scripts and interactions). The page looks ready, but a button or menu does not respond - creating a so-called interactivity gap, which is precisely what hurts INP. That is why a good SSR implementation requires controlling the amount of code executed on the client side, especially in dynamic elements.

When to choose SSR and when CSR for your website?

In e-commerce stores and news portals, SSR or a hybrid approach is the standard. Pure CSR works primarily in closed web applications and user dashboards.

Recommended scenarios for SSR and CSR

The choice comes down to three questions: should the subpage be indexed, how often does it change, and can the infrastructure handle rendering on every request?

The wrong choice - for example, pure CSR in an online store - risks loss of visibility and a drop in organic traffic. However, implementing SSR alone does not guarantee high rankings. It is a technical prerequisite, not a ranking factor in itself: rankings are still determined by content, links, and other elements of SEO.

Hybrid alternatives combining the advantages of both methods

Hybrid rendering uses SSR or SSG for public, indexable subpages, and CSR for private, interactive sections such as the shopping cart or customer dashboard.

• Static Site Generation (SSG). HTML files are generated at build time and served from a CDN (Content Delivery Network). This is a solid solution for rarely changed content, but with thousands of products, it significantly lengthens build times.
• Incremental Static Regeneration (ISR). In Next.js, individual static pages refresh without rebuilding the entire site: either after a set period of time or on-demand, e.g., after a price update in the store's admin panel. Until the page refreshes, users and crawlers get the previous cached version. In an e-commerce store, this fits product pages and category listings well. Next.js 16 introduced Cache Components, combining static, cached, and dynamic content within a single route.
• Per-route rules. In Nuxt, route rules define the rendering mode and caching behavior separately for each path.

Dynamic rendering - serving pre-rendered HTML to bots and a CSR version to users - is classified by Google as a temporary workaround. Instead, Google recommends SSR, static rendering, or hydration. This technique increases complexity, and if implemented incorrectly - when bots see different content than human visitors - it carries the risk of a cloaking penalty.

FAQ

Does Google handle indexing CSR-based websites well?

Yes, but with delays and higher risk. Google is capable of executing JavaScript and indexing the rendered DOM. However, CSR content only becomes visible after rendering, and script errors or execution timeouts can lead to skipped subpages or indexing a blank version.

Why do some AI bots fail to see client-side generated content?

AI crawlers such as GPTBot, ClaudeBot, or PerplexityBot fetch the server response but do not execute JavaScript. In CSR, that response contains an empty container, and the text is only rendered in the browser - an action the bot does not perform. As a result, there is nothing for the bot to read. The exception is Applebot, which does render JavaScript.

What is hydration in SSR and how does it affect a website?

Hydration is the process of "bringing to life" the pre-rendered HTML using JavaScript, which attaches event handlers to elements. The page becomes visible right away, but interactive elements may not respond until this process completes. With a large volume of scripts, hydration degrades INP (Interaction to Next Paint) and the overall user experience. Minimizing client-side code helps mitigate this.

What is the easiest way to check if a website uses SSR or CSR?

Open the page in your browser, right-click, and select "View Page Source" (Ctrl+U). If you see the actual text, headings, and links in the HTML, it is SSR or SSG. If you find a nearly empty skeleton with <div id="root"> and JS script tags, it is most likely CSR.