Client-Side vs Server-Side Rendering: Which Is Better for SEO?

Server-side rendering (SSR) is better for SEO on any page you want found, because Google, AI crawlers and social bots get the full HTML on the first request. Google can index client-side rendering (CSR) after a render delay, but most AI crawlers do not run JavaScript. Use CSR for logged-in apps and dashboards.

CSR vs SSR for SEO: the short answer

For public pages, SSR or static rendering wins, because the content is in the HTML before any script runs. CSR still has a place, but only on pages that do not need to rank. The table below sums up the trade-offs before we go into each one.

Factor	CSR	SSR	SSG (static)
Content in the first HTML	No, an empty shell	Yes	Yes
Google indexing	After the render queue	On the first crawl	On the first crawl
AI crawlers (GPTBot, ClaudeBot, PerplexityBot)	Miss JavaScript content	See the content	See the content
Time to First Byte (TTFB)	Fast shell	Can be slower, the server works per request	Fast from a CDN
Largest Contentful Paint (LCP)	Often slower	Often faster	Often fast, served from a CDN
Interaction to Next Paint (INP)	Depends on JavaScript weight	Heavy hydration can hurt it	Heavy hydration can hurt it
Server cost	Low	Higher	Low
Best for	Logged-in apps, dashboards	Pages that change often	Pages that change rarely

Google’s Martin Splitt puts it well. As reported by Search Engine Journal, he said “It’s not one or the other. It is two tools.” You pick the tool by what the page has to do. For content sites, he added, “requiring JavaScript is a drawback” (Search Engine Journal).

What each method sends to Google: raw HTML vs rendered HTML

CSR means the browser builds the page with JavaScript. SSR means the server builds it and sends finished HTML. SSG, static site generation, builds that HTML once in advance.

The real difference for SEO is what the first response contains. With SSR, the server sends a finished page with the headings, text and links already in place. With CSR, the server sends a near-empty HTML shell plus a JavaScript bundle that builds the page in the browser.

What a CSR page looks like in View Source

Open a CSR page, right-click and choose View Source. You usually see a title, a few script tags and one empty div, often with an id such as “root” or “app”. The product name, price and description are missing, because they arrive later through API calls.

What an SSR page looks like in View Source

Do the same on an SSR page and you see the H1, body copy, internal links and structured data in plain HTML. Any bot can read that on the first fetch. The browser then loads JavaScript to make the page interactive, a step called hydration.

The gap between those two versions is what Google calls raw HTML and rendered HTML. We explain it in detail in our guide to rendered HTML vs source HTML.

How Google handles each: crawl, render queue, index

Google can index both, but CSR pages take an extra step. Google processes JavaScript in three phases: crawl, render and index. SSR content can be read in the first phase, while CSR content has to wait for the render phase.

Google’s JavaScript SEO basics says pages may sit in the render queue “for a few seconds, but it can take longer”. It also says server-side rendering or pre-rendering is “still a great idea”, because not all bots run JavaScript.

How long the render delay really is

Vercel and MERJ measured this. They studied over 100,000 Googlebot fetches on nextjs.org in April 2024 (Vercel). The good news is that 100% of indexable HTML pages were fully rendered.

The timing is the catch. The median render delay was 10 seconds and the 75th percentile was 26 seconds. At the 90th percentile it was about 3 hours, and at the 99th it was about 18 hours. For a news story, a flash sale or a new product, a long tail like that matters.

If you want the full pipeline, from the Web Rendering Service to headless Chromium, read our post on how Google renders JavaScript pages. For where rendering fits in the bigger picture, see our guide to how search engines crawl, index and rank content.

Where client-side rendering breaks SEO

CSR rarely fails because Google cannot run JavaScript. It fails because of small mistakes that only matter when the page depends on scripts. Google’s documentation and the Vercel and MERJ study point to four of them.

A noindex tag in the raw HTML

Google says a noindex in the original HTML can stop rendering. Some apps ship noindex by default and remove it with JavaScript once the page loads. That does not work: the Vercel and MERJ study confirms that removing noindex with client-side JavaScript fails.

Soft 404s on single-page apps

In a single-page app, a missing product often still returns a 200 status with a “not found” message. Google can treat that as a soft 404. Its JavaScript SEO guidance is to redirect to a URL that returns a real 404, or to add a noindex tag to error views.

Links without href

Google only reliably follows a link written as an a tag with an href. Buttons and click handlers that change the route do not count. Google also advises using the History API for routing, not URL fragments, to load different content.

Blocked JavaScript files and failed API calls

If robots.txt blocks your script files, Google will not render JavaScript from them. The same goes for an API that times out or blocks bots during rendering. In both cases Google can end up indexing an empty shell.

Our JavaScript SEO fix list for React and Next.js covers how to fix each of these in code.

AI crawlers do not run JavaScript

This is a major reason CSR has become riskier. Vercel’s December 2024 analysis found that the crawlers of OpenAI, Anthropic and Perplexity (GPTBot, ClaudeBot and PerplexityBot) do not render JavaScript. If your content only appears after scripts run, those crawlers cannot read it.

Google’s Gemini is the exception, because it uses Googlebot’s rendering.

The volume is not small either. On Vercel’s network in one month, GPTBot made 569 million fetches and Claude made 370 million, against 4.5 billion for Googlebot (Vercel). All of that AI crawling reads only your raw HTML.

So a CSR page can rank in Google and still be invisible to the crawlers behind ChatGPT, Claude and Perplexity. SSR and static pages avoid this, because the text is there on the first fetch. We cover which bots do what in our post on whether AI crawlers render JavaScript.

SSR is not automatically faster

SSR often shows content sooner, but it has real costs. The server does work on every request, which can raise Time to First Byte. Then hydration can make the page look ready before it responds to taps and clicks.

TTFB and LCP

The web.dev guide Rendering on the Web explains the trade. SSR gives a fast First Contentful Paint, but on-demand server work can push TTFB up. A slow server or a slow database call can wipe out the gain, so caching matters.

Hydration and INP

Hydration means the browser downloads and runs the same app again to attach event handlers. The web.dev authors call this “one app for the price of two”. Heavy hydration ties up the main thread and hurts Total Blocking Time and INP.

INP replaced First Input Delay as a Core Web Vital in March 2024. A good INP is under 200 milliseconds for 75% of visits (web.dev). If a guide still talks about FID, it is out of date.

The fix is to send less JavaScript, not to drop SSR. Hydrate only the parts that need it, and keep static text static.

Between the two: SSG, ISR, prerendering, streaming and React Server Components

You do not have to choose pure CSR or pure SSR. Modern frameworks mix methods, often per route. Each option below puts content in the HTML while cutting server or browser work.

• Static site generation (SSG): pages are built once at deploy time and served from a CDN. Best for blogs, guides and service pages.
• Incremental static regeneration (ISR): static pages that rebuild in the background on a schedule or on demand. Useful for large catalogues.
• Prerendering: a build step saves the HTML of each route, so bots get full content even from a CSR app.
• Streaming SSR: the server sends HTML in chunks, so the top of the page arrives before slower parts finish.
• React Server Components: parts of the page render only on the server and ship no JavaScript, which cuts hydration cost.

Frameworks such as Next.js, Nuxt, SvelteKit and Astro support some mix of these. Next.js, for example, prerenders every page by default and lets you choose static generation or SSR for each page. The right setup for you depends on how often each page changes, which brings us to the decision table below.

Why dynamic rendering is no longer the answer

Dynamic rendering means serving prerendered HTML to bots and the CSR app to users. Some older guides still recommend it. Google does not.

Google’s page on dynamic rendering as a workaround says it “was a workaround and not a long-term solution”. Google recommends server-side rendering, static rendering or hydration instead. Running two versions of every page also adds cost and the risk of content drifting apart.

If your site still uses a dynamic rendering service, plan a move to SSR or static rendering at your next rebuild.

Which rendering to use, page by page

Most advice stops at “SSR for content, CSR for apps”. Real sites have many page types, and each needs its own choice. Use this table as a starting point.

Page type	Best rendering	Why
Blog posts and guides	SSG or ISR	Text changes rarely, needs full HTML for Google and AI crawlers
Service and landing pages	SSG or SSR	Must rank and load fast, little live data
Product pages	SSR or ISR	Price and stock change, content must be indexed quickly
Category pages	SSR or ISR	Need crawlable links to products in the HTML
Listings with filters (property, cars, jobs)	SSR for the main view, CSR for filters	Index the core listing, let filters run in the browser
Search results inside the site	CSR, usually noindex	Rarely worth indexing
Account, cart, checkout, dashboards	CSR	Behind a login, no SEO value

If a page should appear in Google or AI answers, its main content and links belong in the first HTML. If a page sits behind a login, CSR is fine and often cheaper.

For UAE sites: Arabic and English, RTL and hosting region

Bilingual UAE sites raise three rendering issues most guides skip. The language switcher, the RTL layout and the server location all affect what bots see and how fast pages load.

Language switchers

Some React sites swap Arabic and English text in the browser on the same URL. Bots then see only one language, usually the default. Give each language its own URL and render it on the server. Google accepts hreflang in HTML tags, HTTP headers or the sitemap, with codes such as ar-AE and en-AE. Put it in the raw HTML head or the sitemap, so Google does not depend on rendering to find it. Our international and multilingual SEO team sets this up for Gulf brands.

RTL layouts

If JavaScript sets the dir=”rtl” attribute after load, or Arabic web fonts swap in late, the layout can jump. That can raise Cumulative Layout Shift. Set direction and language on the html tag in the server response.

Hosting region

SSR moves work to your server, so the distance between server and visitor matters more. If your origin is far from the Gulf, cache SSR pages at a CDN edge close to UAE users. Static pages help here too, because a CDN serves them without a trip to the origin.

How to check what your site uses and what Google sees

Check View Source first, then confirm with the URL Inspection live test in Search Console. Run these four steps on one page of each type, not just the homepage.

1. View Source: search the page source for your H1 and a line of body text. If they are missing, the page relies on CSR.
2. URL Inspection live test: in Search Console, run the live test and open the HTML tab. Google says content missing from the rendered HTML there cannot be indexed.
3. JavaScript-disabled crawl: crawl with Screaming Frog or Sitebulb with rendering off, then on. Compare word counts, links and titles.
4. Status codes: load a URL that should not exist. A 200 with a “not found” message means soft 404s.

If the steps show content missing from the raw HTML, our technical SEO services team can audit the site and map the fix. When the answer is a rebuild on a framework with SSR or SSG, our web development services team builds it with SEO in place from day one.

Our verdict

For SEO, SSR and static rendering beat CSR on every page that needs to be found. Google will usually index CSR content in the end. But the render delay, the common failure modes and AI crawlers that skip JavaScript make CSR a poor bet for public pages.

Keep CSR for logged-in areas, keep hydration light, and choose the method page by page.

FAQ

Sources

• Google Search Central: Understand the JavaScript SEO basics
• Google Search Central: Dynamic rendering as a workaround
• Vercel: How Google handles JavaScript throughout the indexing process
• Vercel: The rise of the AI crawler
• web.dev: Rendering on the Web
• web.dev: Interaction to Next Paint becomes a Core Web Vital
• Next.js docs: Rendering
• Google Search Central: Tell Google about localized versions of your page
• Search Engine Journal: Server-side vs client-side rendering, what Google recommends