Modern websites are increasingly built as JavaScript applications with frameworks such as React, Vue, Angular and Svelte. That brings rich interactivity, but it raises a basic SEO question: when a search engine requests your page, does it receive the content, or an empty shell and a bundle of JavaScript that it must run first?
The answer depends on where your pages are rendered: on the server, in the browser, at build time, or a mix of all three. The choice affects how quickly and reliably Google indexes your content, how fast pages feel for users, and how well other crawlers, including AI systems, can read your site.
This guide explains server-side rendering (SSR), client-side rendering (CSR), static rendering and hydration in plain terms, compares their SEO trade-offs, and gives a practical checklist for choosing and testing a rendering approach in 2026.
Key Takeaways
- With server-side or static rendering, crawlers receive complete HTML immediately; with client-side rendering they must execute JavaScript to see content.
- Google can render JavaScript, but it still describes server-side or pre-rendering as a great idea because it is faster for users and crawlers.
- Dynamic rendering (serving bots a different version) is a workaround Google does not recommend.
- Most sites are best served by a hybrid: static or server rendering for indexable pages, client-side rendering for logged-in or highly interactive areas.
- Whatever you choose, titles, meta tags, canonicals, links and status codes must be correct in the HTML Google renders.
Rendering Approaches Explained
Rendering is the process of turning code and data into the HTML a browser displays. The question is where and when it happens.
- Client-side rendering (CSR): the server sends a minimal HTML file and JavaScript; the browser fetches data and builds the page.
- Server-side rendering (SSR): the server builds the full HTML for each request and sends it to the browser.
- Static rendering (static site generation): HTML is generated at build time, one file per URL, and can be served from a CDN.
- Hydration: JavaScript runs on server-rendered HTML in the browser to attach interactivity.
- Dynamic rendering: the server detects bots and serves them pre-rendered HTML while users get the client-side app.
Here is the difference a crawler sees before any JavaScript runs:
<!-- What a crawler receives from a client-side rendered page -->
<html>
<head><title>Loading...</title></head>
<body>
<div id="root"></div>
<script src="app.4f9c2.js"></script>
</body>
</html><!-- What a crawler receives from a server-rendered page -->
<html>
<head>
<title>Trail Running Shoes for Wide Feet | Example Store</title>
<meta name="description" content="Compare 24 wide-fit trail shoes...">
<link rel="canonical" href="https://www.example.com/trail-shoes/wide-fit">
</head>
<body>
<h1>Trail Running Shoes for Wide Feet</h1>
<a href="https://www.example.com/trail-shoes/wide-fit/product-1">...</a>
<script src="app.4f9c2.js"></script> <!-- hydrates the page -->
</body>
</html>How Google Handles JavaScript
Google processes JavaScript sites in three phases: crawling, rendering and indexing. After crawling a URL, pages wait for rendering, where a headless Chromium executes the JavaScript; Google then uses the rendered HTML for indexing. Our guide to how Googlebot works explains the pipeline.
So Google can index client-side rendered content, but there is extra work and potential delay between crawling and rendering, and anything that fails during rendering (blocked resources, errors, timeouts, content that needs user interaction) may never be seen. Google's own guidance is clear about the better option:
“server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers”
— Google Search Central, Understand JavaScript SEO basics
Other crawlers matter too. Search engines and AI systems differ in how much JavaScript they execute, and many fetch HTML without fully rendering it. Content present in the initial HTML is the safest way to be readable by all of them, which is one reason it appears on our AI search optimization checklist.
SSR vs CSR vs Static: SEO Comparison
| Factor | Client-side rendering | Server-side rendering | Static rendering |
|---|---|---|---|
| Content in initial HTML | No (shell only) | Yes | Yes |
| Dependence on crawler rendering | High | Low | Low |
| Time to First Byte | Usually fast (small HTML) | Can be slower; server builds each page | Fast, especially from a CDN |
| Largest Contentful Paint | Often slower; waits for JS and data | Usually faster | Usually fastest |
| Interaction to Next Paint | Risk from large JS bundles | Good if JS is limited; hydration can add cost | Good if JS is limited |
| Fresh or personalised data | Easy | Easy | Needs rebuilds or incremental regeneration |
| Infrastructure complexity | Low | Higher (server runtime, caching) | Low to medium |
| Best for | Dashboards, logged-in apps | Large dynamic catalogues, news, search pages | Marketing pages, blogs, docs |
The performance columns reflect the trade-offs described in web.dev's Rendering on the Web: SSR gives a fast first paint and ships less JavaScript, but generating pages on request can raise Time to First Byte, while hydration can make a page look ready before it responds to input. For more on these metrics, see our Core Web Vitals guide.
What About Dynamic Rendering?
Dynamic rendering was popular when Google's JavaScript rendering was less capable. Google now discourages it:
“Dynamic rendering is a workaround and not a recommended solution”
— Google Search Central, Dynamic rendering as a workaround
Google recommends server-side rendering, static rendering or hydration instead. If you still run a pre-rendering service for bots, plan a migration and make sure bots and users receive equivalent content in the meantime.
How to Choose a Rendering Strategy: Step by Step
- Classify your page types. Separate pages that must rank (home, category, product, article, location) from pages that do not (account, checkout, dashboards).
- Decide per type. Static rendering for content that changes rarely; SSR for large or frequently changing catalogues; CSR only for non-indexable app screens.
- Pick a framework that supports hybrids. Next.js, Nuxt, SvelteKit, Astro, Remix and Angular SSR all let you mix approaches per route.
- Render SEO-critical tags on the server. Title, meta description, canonical, robots, hreflang and structured data should be in the HTML response.
- Use real links and real URLs. Google discovers links in
<a href>elements and recommends the History API rather than URL fragments for routing. - Return correct status codes. Missing pages should return a 404 from the server, or use one of Google's suggested fixes to avoid soft 404s in client-side routing.
- Control JavaScript cost. Code-split, defer non-critical scripts and limit hydration to interactive components.
- Test what Google sees. Compare raw HTML with the rendered HTML in URL Inspection and the Rich Results Test.
Framework Caveats Worth Knowing
Frameworks change quickly, so check current documentation for your version. One example: Next.js documents that for dynamically rendered pages it can stream metadata into the HTML after the main content, and that it disables this for crawlers it identifies as expecting metadata in the <head>, configurable through its htmlLimitedBots option. That is the kind of detail that should be verified in testing rather than assumed. If your content comes from a headless CMS, read our headless CMS SEO guide; if images load on scroll, see lazy loading best practices.
Common Mistakes
| Mistake | Symptom | Fix |
|---|---|---|
| Same title on every page in a CSR app | Duplicate titles in Search Console and crawlers | Render unique titles server-side per route |
| Links built with click handlers | Pages not discovered | Use <a href> with real URLs |
Hash-based routing (#/page) | Only one URL indexed | Use the History API and clean paths |
| Noindex in the HTML template removed by JS | Pages stay out of the index | Set robots tags on the server |
| Blocked JS or API endpoints in robots.txt | Rendered page is empty | Allow resources Google needs |
| Hydration mismatch errors | Content flickers or differs from server HTML | Fix mismatches between server and client data |
| Everything 200, even missing pages | Soft 404s | Return proper 404 status codes |
Our broader JavaScript SEO guide covers more rendering issues and debugging techniques.
How to Test Your Rendering
- View the raw HTML response (view-source or a command-line fetch) and check that main content, links and tags are present.
- Use URL Inspection in Search Console to see Google's rendered HTML and a screenshot.
- Run the Rich Results Test to confirm structured data appears after rendering; see our guide on testing structured data.
- Crawl the site with JavaScript rendering on and off, and compare word counts, links and titles.
- Measure field Core Web Vitals after any rendering change.
Related Guides
Frequently Asked Questions
Is client-side rendering bad for SEO?
Not automatically. Google can render JavaScript, but CSR adds dependence on rendering and can delay or prevent content from being seen. For pages you want to rank, server-side or static rendering is safer.
Does server-side rendering improve rankings?
SSR is not a ranking factor in itself. It makes content easier to crawl and index and often improves page speed, which supports better visibility.
What is hydration?
Hydration is when JavaScript runs on server-rendered HTML in the browser to make it interactive. It keeps the SEO benefits of SSR, but heavy hydration can slow interactivity.
Should I still use dynamic rendering?
Google describes dynamic rendering as a workaround, not a recommended solution. Use SSR, static rendering or hydration for new builds and plan to move away from dynamic rendering.
Which is better for SEO, SSR or static rendering?
Both deliver full HTML. Static rendering is usually fastest and simplest for content that changes rarely; SSR suits large or frequently changing sites. Many sites combine them.
Conclusion
Google can handle JavaScript, but server-side and static rendering remove risk and usually improve speed. For most sites the answer is a hybrid: pre-render everything you want to rank, keep client-side rendering for app-like areas, and test what crawlers actually receive. If you are planning a rebuild or migration to a JavaScript framework, our web development and SEO teams can help you get it right first time, or you can request a free quote.
