SSR, SSG or CSR: which rendering mode should you choose for good SEO?
Server-side rendering, static generation, client-side rendering: what these acronyms change for Google, for AI tools and for your website’s speed, explained simply.
By Léo Chuzel · Published on · 3 min read
Your provider talks about React, Next.js, “SSR” or a “static site” and you switch off? That’s normal: these are technical choices. But they have a very concrete consequence for your business: do Google and AI assistants actually see your website’s content? This article gives you the keys to understand and ask the right questions.
The problem: a page built in the browser
A classic website sends visitors a complete HTML page: text, headings, links, everything is already there. Many modern websites work differently. The server sends an almost empty page and a large JavaScript file, then the browser builds the page. This is called client-side rendering, or CSR.
For a human with a recent phone, the difference is barely visible. For a bot, it’s another story: if it doesn’t run JavaScript, it finds a blank page.
The four rendering modes, explained
CSR: client-side rendering
The page is built by the browser. It’s how a “simple” React or Vue application works by default. Ideal for a customer area or a tool behind a login, much less so for pages you want to see on Google.
SSR: server-side rendering
The server builds the complete page on every visit, then sends it. The content is immediately readable by all bots. Useful for pages that change constantly: stock, prices, availability.
SSG: static generation
Pages are built once, at publication time, then served as they are. It’s the fastest and most robust option: no computation on each visit, simple hosting, stronger security. Perfect for a showcase website, a blog or service pages.
ISR and hybrid rendering
Modern frameworks like Next.js let you mix: static pages regenerated automatically when content changes (ISR), server pages for dynamic content, and client-side JavaScript only where there’s interaction. It’s the best approach for most projects today.
Google can read JavaScript… within limits
Google runs JavaScript, but in two stages: it first crawls the raw HTML, then places the page in a queue to “render” it. This delay can slow the indexing of your new pages, and any JavaScript error can make content disappear. Links generated only in JavaScript, without a real link tag, are sometimes ignored.
The impact on speed
Client-side rendering forces the visitor’s phone to download and run a lot of code before displaying anything. The result: a slower first paint and degraded Core Web Vitals. A static or server-rendered page displays almost instantly.
How to check your website in two minutes
- Open your website, right-click and choose “View page source”.
- Search (Ctrl+F or Cmd+F) for a sentence visible on screen, for example your main heading.
- If the sentence is in the source code, the content is served as HTML: that’s a good sign.
- If you only see an empty structure and scripts, your content depends on JavaScript.
- To confirm, use the URL inspection tool in Google Search Console and view the page as Google rendered it.
What should you choose for your project?
- Showcase website, blog, service pages: static generation, with regeneration when you edit content.
- Online store: static or server-rendered product pages, dynamic cart and customer account. That’s the principle of a headless Shopify store.
- Customer area, back office, business tool: client-side rendering works very well, since these pages aren’t meant to be on Google.
- Mobile app: that’s a different topic, see our article mobile app or PWA.
Our approach
At SOBO, we build our websites with Next.js, favouring static generation: every page arrives complete for visitors and bots alike, then interactivity is added where it’s useful. That’s what lets us deliver websites that are fast, easy to rank and readable by AI tools. If you have doubts about your current website, we check it for free during our audit, and we can support you with its redesign.