Does client-side rendering (CSR) really hurt an Angular site's SEO?

Has Google truly solved the historical issue of client-side JavaScript?

For years, JavaScript frameworks like Angular, React, or Vue.js were seen as SEO hurdles. Why? Because client-generated content did not exist in the initial HTML — Googlebot had to execute JavaScript to discover it, which slowed down or prevented indexing.

Martin Splitt’s statement marks an official turning point: Google claims that CSR (Client-Side Rendering) is no longer an inherent drawback. The search engine has improved its ability to execute JavaScript — but this assertion hinges on two non-negotiable conditions.

What are the two conditions for an Angular CSR site to rank properly?

First condition: the content must be accessible to Googlebot. This means the bot must be able to execute JavaScript, retrieve the complete DOM, and index the text. If errors block execution (resources blocked in robots.txt, timeouts, critical JS errors), indexing fails.

Second condition: the site must not be 'too slow'. Google remains deliberately vague here. It is assumed that it refers to Core Web Vitals, particularly LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift). An Angular site that takes 5 seconds to display the main content risks indirect penalty through user experience.

Why does this statement leave so many gray areas?

The phrase 'not too slow' is characteristic of Google: no numbered metrics, no specific threshold. Is a 2.5-second LCP sufficient? 3 seconds? And what happens if content displays in two stages (skeleton, then actual content)?

Moreover, Google does not clarify whether Googlebot uses the same resources to execute JavaScript as a modern browser. Field tests show that Google's JS execution is sometimes partial or delayed — potentially creating a gap between what the user sees and what the bot sees.

• Angular CSR is no longer an automatic hindrance — but only if the technical implementation is perfect.
• Googlebot must be able to execute JavaScript without errors or resource blocking.
• Performance (Core Web Vitals) becomes an implicit ranking criterion for CSR sites.
• Google remains vague on thresholds — 'not too slow' has no official definition.
• Angular sites must be tested in real conditions with Google Search Console and rendering tools.

Is this statement consistent with what we observe in the field?

Yes and no. Google has indeed made strides in executing JavaScript — tests show that Googlebot (evergreen) correctly executes the majority of CSR sites. But there are still problem cases: timeouts on complex sites, uncaught JS errors, or content loaded after user interaction (infinite scroll, poorly implemented lazy loading).

In practice, a well-designed Angular site can indeed rank — I've seen CSR e-commerce sites ranking on the first page. However, the margin for error is much tighter than with SSR (Server-Side Rendering) or static HTML. Any small bug can block indexing, whereas a traditional site would have absorbed the error.

What nuances should be added to this official statement?

First nuance: 'not too slow' remains subjective. Google provides no figures. We know that Core Web Vitals influence ranking — but a CSR site can have a good LCP AND partial indexing if the content takes too long to display in the DOM. [To verify]: Does Google index only the content visible on first render, or does it wait for all JS to be executed?

Second nuance: not all content is equal. E-commerce products, blog articles, or landing pages can work well in CSR. But what about a news site with hundreds of pages published each day? A directory with millions of entries? CSR introduces a risk of delayed indexing — even if the content is eventually crawled, the delay can crush competitiveness.

In which cases does this rule not apply or become risky?

CSR remains problematic for high-volume sites or those that rely on news (Google News, aggregators). Why? Because Googlebot must allocate more resources to execute JavaScript — which slows down crawling and delays indexing.

Another borderline case: conditionally loaded content. If your Angular site displays certain sections only after a click, a scroll, or an event, Googlebot may never see them. And Google offers no guarantee on the depth of execution of its JS engine.

What should you do if you are using Angular in CSR?

First action: test Googlebot's rendering under real conditions. Use the 'URL Inspection' tool in Google Search Console to verify that content displays correctly. Compare the raw HTML (View Source) and the rendered DOM (Inspect) — if content only appears in the DOM, check that Googlebot sees it, too.

Second action: monitor Core Web Vitals. An Angular CSR site should display its main content in less than 2.5 seconds (recommended LCP threshold). If your JS bundle exceeds 200 KB or the Time to Interactive exceeds 3 seconds, you have a problem.

What errors should you absolutely avoid with an Angular CSR site?

Error #1: blocking JavaScript files in robots.txt. Googlebot must download and execute your .js — if you block them, rendering fails and you only index empty HTML. Also, ensure that CSS files are not blocked (they influence rendering).

Error #2: loading content after user interaction. If your content appears after a scroll, a click, or a hover, Googlebot will probably not see it. The bot does not execute user events — it renders the page as it appears at the initial load.

How can you check that your Angular implementation is SEO-compatible?

Use a tool like Screaming Frog with JavaScript enabled to crawl your site and compare the extracted content with and without JS. If entire sections disappear without JS, they might not be indexed correctly.

Also set up continuous indexing monitoring through Google Search Console. Watch for rendering errors, blocked resources, and pages 'Detected but not indexed' — this status is common on CSR sites and often signals rendering or performance issues.

• Check Googlebot's rendering using the 'URL Inspection' tool in Search Console
• Measure and optimize Core Web Vitals (LCP < 2.5s, CLS < 0.1)
• Never block .js or .css files in robots.txt
• Avoid conditional content (scroll, click) — everything must be visible on first render
• Crawl the site with Screaming Frog (JS enabled) to detect invisible content without JS
• Continuously monitor indexing and rendering errors in Search Console