SEO
CSR vs SPA for SEO: Why Client-Side Rendering Hurts Rankings
Client-Side Rendering and Single Page Applications hurt SEO. Learn why CSR and SPA sites struggle with Google indexing and what to do instead.
See your site's AI visibility grade
Free instant scan — the same checks this article talks about, run on your own site.
Quick Answer
Client-Side Rendering (CSR) and Single Page Applications (SPAs) hurt SEO because they send empty HTML to search engines. Google must run JavaScript to see your content, which causes indexing delays, missing pages, and poor Core Web Vitals. Server-side rendering or static site generation solves these problems by delivering complete HTML on the first request.
If your website is built with a JavaScript framework like React, Vue, or Angular and you deployed it as a CSR or SPA, there is a good chance Google is not seeing all of your content. The SEO impact of Client-Side Rendering is well documented, and it remains one of the most common technical SEO mistakes in 2026. This post breaks down exactly why CSR and SPA architectures cause ranking problems and what you can do about it.
Not sure if your site has CSR indexing issues? We can run a free check and show you exactly what Google sees.
Key Takeaways
- CSR sends an empty HTML shell to search engines, forcing them to render JavaScript
- SPAs are an architecture pattern that almost always uses CSR by default
- Google’s two-wave indexing creates hours or weeks of delay for CSR pages
- SSG and SSR produce complete HTML that search engines index immediately
- Core Web Vitals suffer under CSR due to large JavaScript bundles and slow paint times
What CSR and SPA Actually Mean for SEO
These two terms get used interchangeably, but they describe different things. Client-Side Rendering (CSR) is a rendering strategy. The server sends a minimal HTML file (usually just a <div id="root"></div> tag), and the browser downloads JavaScript that builds the entire page. Nothing is visible until the JS finishes running.
A Single Page Application (SPA) is an architecture pattern. Instead of loading a new HTML page for every URL, the browser handles all routing internally. Clicking a link swaps content without a full page reload. SPAs almost always use CSR as their default rendering method.
The SEO problem is the same for both: search engine crawlers receive an empty HTML document. There are no headings, no paragraphs, no meta descriptions, no structured data, and no internal links in the raw response. Everything depends on JavaScript execution.
Why Both Are Bad for Search Rankings
The core issue is that Googlebot and other crawlers see a blank page on their first pass. Here is what goes wrong:
Empty HTML means no content to index. The raw HTML of a CSR page contains almost nothing. Title tags may be hardcoded, but meta descriptions, Open Graph tags, and structured data are often injected by JavaScript. If the crawler does not execute JS, those elements do not exist.
JavaScript dependency creates a single point of failure. If any API call fails, if a third-party script throws an error, or if the JS bundle exceeds the render timeout, the page stays blank. Google gives each page a limited rendering budget.
Crawl budget gets wasted. Google allocates a crawl budget to every site. When Googlebot visits a CSR page and gets empty HTML, it still uses crawl budget. The rendering step happens later in a separate queue. For large sites, this means Google may crawl thousands of pages but only render a fraction of them.
Core Web Vitals suffer. CSR forces the browser to download, parse, and execute a large JavaScript bundle before any content appears. This results in poor First Contentful Paint (FCP) and Largest Contentful Paint (LCP). Since Google uses Core Web Vitals as ranking signals, slow paint times directly hurt your position.
If you are concerned about your site’s performance and Core Web Vitals, these rendering problems are often the root cause.
Want to know if CSR is costing you rankings? Book your free session and get 3 months free and we will show you the gaps.
How Google Handles JavaScript Rendering
Google uses a two-wave indexing process for JavaScript-heavy pages:
Wave 1: HTML crawl. Googlebot fetches the raw HTML. For server-rendered pages, this HTML contains all content, and indexing happens immediately. For CSR pages, the HTML is nearly empty. Google notes the page needs rendering and moves on.
Wave 2: JavaScript rendering. Google places the page in a render queue. A headless Chromium instance executes the JavaScript and captures the final DOM. This rendered HTML is then sent back to the indexing pipeline.
The problem is the gap between Wave 1 and Wave 2. That gap can be hours, days, or even weeks depending on how busy the render queue is and how large your site is. During that entire period, your content is invisible in search results.
Real-World SEO Problems Caused by CSR and SPA
Here are the most common issues businesses encounter with CSR/SPA sites:
- Missing pages from Google’s index. You publish 200 pages but only 40 appear in Search Console. The rest were never rendered.
- Blank or generic meta tags. The title says “React App” and the description is empty because JavaScript did not run.
- No structured data. FAQ schema, product schema, and organization schema injected by JS are invisible to the initial crawl.
- Broken internal link discovery. Google finds links by parsing HTML. If your navigation and internal links are generated by JavaScript, the crawler may miss entire sections of your site.
- Stale content in search results. Google caches the rendered version. If your content changes but Google does not re-render the page, search results show outdated information.
These are not edge cases. They are the default behavior of CSR/SPA sites that do not implement server-side rendering. Our indexing and monitoring service catches exactly these kinds of gaps before they become ranking problems.
CSR vs SPA vs SSG vs SSR: SEO Comparison
| Metric | CSR | SPA (default) | SSG | SSR |
|---|---|---|---|---|
| Crawlability | Poor (empty HTML) | Poor (empty HTML) | Excellent (full HTML) | Excellent (full HTML) |
| TTFB | Fast (tiny HTML) | Fast (tiny HTML) | Very fast (static files) | Moderate (server processing) |
| FCP / LCP | Slow (JS must execute) | Slow (JS must execute) | Fast (HTML ready) | Fast (HTML ready) |
| Indexing Speed | Days to weeks | Days to weeks | Immediate | Immediate |
| Core Web Vitals | Poor (large bundles) | Poor (large bundles) | Excellent (minimal JS) | Good (hydration cost) |
| Structured Data | JS-dependent | JS-dependent | In source HTML | In source HTML |
| Internal Links | JS-dependent | JS-dependent | In source HTML | In source HTML |
| Best For | Dashboards, apps | Dashboards, apps | Blogs, marketing sites | Dynamic content sites |
What to Use Instead: SSG, SSR, and Hybrid Approaches
The solution to CSR SEO problems is moving rendering to the server or the build step. Here are your options:
Static Site Generation (SSG) pre-renders every page to HTML at build time. The result is a collection of static files served from a CDN. No server processing happens at request time. This is the fastest and most SEO-friendly approach for content that does not change frequently.
Server-Side Rendering (SSR) generates HTML on the server for every request. This works well for pages with dynamic data that changes frequently, like search results or personalized content. The trade-off is higher server costs and slightly slower TTFB compared to SSG.
Incremental Static Regeneration (ISR) is a hybrid approach. Pages are pre-rendered at build time, but they can be regenerated in the background after a set time interval. This gives you the speed of SSG with the freshness of SSR.
Hybrid rendering lets you mix strategies within the same application. Use SSG for blog posts and landing pages. Use SSR for product pages with live inventory. Use CSR only for logged-in dashboard features.
How vaza.ai’s Approach Solves These Problems
At vaza.ai, we build with Next.js using static export. Every page is pre-rendered to complete HTML at build time. When Googlebot (or any AI search engine) crawls the site, it receives full content, structured data, meta tags, and internal links in the initial response. No JavaScript execution is required for indexing.
This approach, combined with Cloudflare Pages CDN delivery, produces sub-second TTFB globally and excellent Core Web Vitals scores. Our modern website service uses this architecture by default for every client site.
The static HTML also means AI search engines like ChatGPT, Perplexity, and Gemini can extract and cite your content without running a browser. As AI-powered search grows, having crawlable HTML becomes even more important.
When CSR and SPA Are Acceptable
CSR is not always wrong. It is the right choice when SEO does not matter for a specific page:
- Internal admin dashboards that only employees access
- Logged-in application interfaces behind authentication
- SaaS product UIs where users arrive through login, not search
- Interactive tools embedded within a server-rendered page (hybrid approach)
The key rule: if users find the page through a search engine, it needs server-rendered HTML. If users find the page through a login screen or a direct link, CSR is fine.
- CSR and SPA send empty HTML to search engines, causing indexing delays and missing content
- Google’s two-wave indexing means CSR pages may wait days or weeks before appearing in results
- Core Web Vitals suffer because large JavaScript bundles slow down FCP and LCP
- SSG produces the best SEO results for content pages by delivering complete HTML from a CDN
- Use CSR only for pages that do not need search engine visibility, like dashboards and logged-in apps
If your website runs on a CSR or SPA architecture and you are seeing indexing problems or ranking drops, the rendering strategy is likely the cause. Moving to a server-rendered or statically generated setup fixes the root issue rather than patching symptoms.
Frequently Asked Questions
What is the difference between CSR and SPA?
CSR (Client-Side Rendering) is a rendering strategy where the browser builds the page using JavaScript after downloading an empty HTML shell. SPA (Single Page Application) is an application architecture where all routing happens in the browser without full page reloads. Most SPAs use CSR by default, but they are not the same thing. A SPA describes the navigation model, while CSR describes how content appears on screen.
Can Google index Client-Side Rendered pages?
Google can index CSR pages, but the process is delayed and unreliable. Googlebot first crawls the raw HTML (which is mostly empty for CSR sites), then places the page in a render queue. The rendering step can take hours, days, or even weeks. During that delay, your content is invisible to search results. Pages with JavaScript errors or timeouts may never get rendered at all.
Why do SPAs have poor Core Web Vitals?
SPAs typically ship large JavaScript bundles that must download, parse, and execute before any content appears. This causes slow First Contentful Paint (FCP) and Largest Contentful Paint (LCP). The browser shows a blank screen or loading spinner while JavaScript runs, which directly hurts Core Web Vitals scores. Google uses these metrics as ranking signals.
Is React bad for SEO?
React itself is not bad for SEO. The problem is how React apps are rendered. A default Create React App project uses Client-Side Rendering, which is bad for SEO. However, React with Next.js uses server-side rendering or static generation, which produces full HTML that search engines can crawl immediately. The framework and rendering strategy matter more than the UI library.
What is two-wave indexing?
Two-wave indexing is Google's process for handling JavaScript-heavy pages. In the first wave, Googlebot crawls the raw HTML source code. For CSR pages, this HTML is mostly empty. In the second wave, Google renders the JavaScript to see the final content. The second wave can be delayed by hours or weeks, and pages with JS errors may never complete the second wave.
Should I use SSG or SSR instead of CSR?
For content that does not change on every request (blog posts, landing pages, product descriptions), use Static Site Generation (SSG). For pages that need fresh data on every request (search results, user dashboards), use Server-Side Rendering (SSR). Both strategies produce full HTML that search engines can index immediately without waiting for JavaScript.
When is Client-Side Rendering acceptable?
CSR is acceptable for pages that do not need to appear in search results. Internal admin dashboards, logged-in user portals, SaaS application interfaces, and any page behind authentication are good candidates for CSR. If users reach the page through a login screen rather than a search engine, CSR works fine.
How does Next.js static export solve CSR SEO problems?
Next.js static export pre-renders every page to full HTML at build time. When Googlebot crawls the site, it receives complete content, metadata, structured data, and internal links in the initial HTML response. There is no JavaScript rendering required. This eliminates the two-wave indexing delay and ensures every page is immediately indexable.
About the author
vaza.ai Team
SEO & AEO Specialists
The vaza.ai team helps small businesses modernize their websites and eliminate the cost, maintenance, and security headaches of legacy platforms.
Related reading
Want this running on your own site?
Run the free scan and see what Google and the AI answer engines actually find — then watch the platform monitor, fix and publish on autopilot.
Free instant grade · No signup · See what Google & AI see on your site