Does client-side rendering hurt SEO?

It can. Client-side rendered content depends on Google's deferred rendering pass, which adds delay and risk versus server-rendered or statically generated HTML. For pages you need indexed reliably, SSR or SSG is the safer choice.

Your site looks fine in a browser. Googlebot sees something different.

Q: Can Google read JavaScript?

Yes, but in two stages. Googlebot first crawls the raw HTML, then queues the page for rendering, where it runs the JavaScript with a headless Chromium and sees the final content. The gap can be days, and anything that only appears after JavaScript runs is at risk of being missed or indexed late.

Q: Does Googlebot execute JavaScript?

Yes. Googlebot uses an evergreen Chromium to render pages, so it executes most modern JavaScript. But rendering is deferred and resource-limited: scripts that fail, time out, or depend on user interaction may never produce indexable content. Execution does not guarantee reliable indexing.

Q: What is fetch and render, and how do I use it?

It's the check that shows what Googlebot sees. In Search Console, the URL Inspection tool fetches a page and renders it the way Googlebot does, then shows the rendered HTML and a screenshot. Compare that against your browser: anything missing from the rendered view is content Google may not be indexing.

Q: Does Next.js fix JavaScript SEO automatically?

No. Next.js makes SSR and SSG easy to implement, but a Next.js site using purely client-side rendering has the same problems as any other CSR site. The framework is a tool; how you configure rendering determines the outcome.

B2B SaaS products are almost universally built on JavaScript frameworks. React, Next.js, Angular, Vue - the marketing site often inherits the same stack as the product, or gets rebuilt on one because the engineering team is already fluent in it. This creates a specific SEO problem that most teams don't discover until a technical audit surfaces it: content that looks perfectly rendered in a browser may be invisible or delayed for Googlebot.

Understanding the rendering pipeline is not optional if you're serious about B2B SEO in 2026. This post covers how Googlebot renders JavaScript, what can go wrong, and how to test what Google actually sees.

Content that looks fine in a browser can be invisible or delayed for Googlebot. These are not the same environment.

How Googlebot renders JavaScript: the two-wave model.

Wave one: the initial fetch

When Googlebot first crawls a URL, it fetches the HTML response and processes it immediately. For a static HTML page, this is essentially the whole page. For a client-side rendered JavaScript application, the initial HTML response may be a nearly empty shell - a <div id="root"></div> and a bundle of JavaScript files. The content the user sees doesn't exist yet at this point; it exists only after the JavaScript executes in a browser.

Wave two: rendering

Google processes JavaScript rendering separately, using a queued headless Chromium renderer. This happens after the initial crawl, with a delay that can range from hours to weeks depending on crawl queue pressure and the site's crawl budget allocation. Once rendered, the processed version is what gets indexed.

The practical implication: for a client-side rendered SaaS site, there can be a significant lag between a page going live and its content being indexed. For new content on a large site, this lag can affect time-sensitive SEO work. For content that only appears after user interaction (logged-in states, JS-gated content), Googlebot may never see it at all.

Rendering approach	What Googlebot sees in wave one	SEO risk level
Static HTML	Full content immediately. No rendering queue required.	None
Server-side rendering (SSR)	Full HTML delivered from server. Rendering queue not needed for content.	Low (if implemented correctly)
Static site generation (SSG)	Pre-built HTML per page. Equivalent to static HTML for Googlebot.	None
Client-side rendering (CSR)	Empty or near-empty HTML shell. Content arrives only after JS executes.	High

Common failure modes on JavaScript-heavy sites.

Navigation menus that don't render in wave one

JavaScript-rendered navigation menus are a crawl signal problem as much as an indexation problem. Googlebot discovers new pages partly by following links. If the navigation is rendered client-side and not available in wave one, Googlebot may not discover the pages those links point to until a later crawl cycle. For a new site, this can mean significant indexation delays for everything beyond the homepage.

Meta tags set by JavaScript

Title tags, meta descriptions, and canonical tags set dynamically via JavaScript rather than delivered in the server response may not be available in wave one. If Googlebot indexes the page before wave two rendering completes, it may use a default or empty meta title. The fix is ensuring these tags are available in the initial HTML response - which SSR and SSG frameworks handle correctly but CSR frameworks do not by default.

Content behind interaction events

Content that appears only after a click, scroll trigger, or form submission is unlikely to be indexed. Googlebot doesn't interact with pages in the way a user does. If your key differentiating content lives in a JavaScript tab, accordion, or modal that requires a click to open, it may not be visible to Googlebot at all - even in wave two rendering.

Lazy-loaded images and content

Images and content blocks loaded lazily (only when they enter the viewport) may not be rendered by Googlebot, which doesn't scroll. Use the loading="eager" attribute for above-the-fold content, and consider whether critical text content is being lazy-loaded unnecessarily.

SSR, CSR, SSG: what each means for SEO.

Server-side rendering (SSR)

The server generates full HTML for each request and sends it to the browser. Googlebot receives the complete content in wave one. This is the most SEO-friendly approach for dynamic content - the server does the work that would otherwise require client-side JavaScript execution. The tradeoff is server load and time-to-first-byte. Next.js, Nuxt, and SvelteKit all support SSR.

Static site generation (SSG)

Pages are pre-built at deploy time as static HTML files. Googlebot sees the same complete HTML any user would. Ideal for content that doesn't change frequently - marketing pages, blog posts, documentation. Build times increase with page count but the SEO outcomes are excellent. This site is built with Astro in SSG mode for this reason.

Client-side rendering (CSR)

The server sends a JavaScript bundle; the browser builds the HTML. Fast for logged-in product experiences, problematic for public-facing marketing pages. Pure CSR on a B2B marketing site is inadvisable from an SEO standpoint. If your product is built in CSR, at minimum ensure the marketing pages (homepage, product pages, blog) are statically generated or server-rendered.

Hydration and islands

Modern frameworks increasingly use hybrid approaches: static or server-rendered HTML with selective JavaScript hydration for interactive components. Astro's "islands" architecture, Next.js App Router's server components, and similar patterns can deliver excellent SEO outcomes while preserving interactivity. The principle is straightforward: serve the content statically, hydrate the interactive parts.

How to test what Google actually sees.

The three tools that give you the most accurate picture of how Google sees your pages:

URL Inspection in Search Console

Enter any URL and click "Test live URL." The tool shows the rendered HTML - what Google's crawler actually sees after wave two rendering, including JavaScript-executed content. Compare this to the page's actual source HTML. Any content visible in the browser but absent from the URL Inspection rendered view is at risk of not being indexed.

View source vs. inspect element

View source (Ctrl+U / Cmd+U) shows the raw HTML response from the server. Inspect element (browser developer tools) shows the DOM after JavaScript has executed. If your key content, meta tags, or navigation appear in inspect element but not in view source, they're JavaScript-dependent and subject to wave two rendering delays. This is the fastest diagnostic check.

Google's Rich Results Test

Available at search.google.com/test/rich-results, this tool renders the page and shows the structured data Google can extract. Useful specifically for confirming that schema markup added via JavaScript is actually being read.

The three render states diagnostic.

View source (Ctrl+U): the raw server response - what Googlebot sees in wave one. Check: is your main content, H1, title tag, and canonical here?
URL Inspection (Search Console): the rendered HTML after wave two - what gets indexed. Check: does it match what a user sees in the browser?
Browser (DevTools): the fully hydrated DOM - what users see. Any gap between this and URL Inspection is content that may not be indexed.

NOTES

Google's JavaScript SEO documentation is at developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics. It covers the two-wave rendering model and the specific limitations of Googlebot's JavaScript execution.
The rendering queue delay is not a fixed number - Google has said it can range from "hours to weeks" depending on site signals and crawl demand. High-PageRank pages on well-crawled sites get processed faster.
Google confirmed in 2022 that its headless Chromium renderer was updated to Chromium 112, meaning modern CSS and JavaScript features are supported. The constraint is not what JS Googlebot can execute but when it executes it.

Frequently asked

Can Google read JavaScript?

Yes, but in two stages, and that's where sites get caught out. Googlebot first crawls the raw HTML, then queues the page for rendering, where it runs the JavaScript with a headless Chromium and sees the final content. The gap between those stages can be days, and anything that only appears after JavaScript runs is at risk of being missed or indexed late. It helps to understand how Google crawls and indexes in the first place.

Does Googlebot execute JavaScript?

It does. Googlebot uses an evergreen Chromium to render pages, so it executes most modern JavaScript. The catch is that rendering is deferred and resource-limited: it isn't guaranteed to run quickly, and scripts that fail, time out, or depend on user interaction may never produce indexable content. Don't assume execution means reliable indexing.

What is fetch and render, and how do I use it?

It's the check that shows you what Googlebot actually sees. In Search Console, the URL Inspection tool fetches a page and renders it the way Googlebot does, then shows you the rendered HTML and a screenshot. Compare that against what loads in your browser: anything missing from the rendered view is content Google may not be indexing.

Does Next.js fix JavaScript SEO automatically?

Next.js makes it much easier to implement SSR and SSG, but it doesn't automatically solve JS SEO. A Next.js site using the App Router with server components and static generation will be fine. A Next.js site using purely client-side rendering (the pages directory without getServerSideProps or getStaticProps, or the App Router with client components only) will have the same problems as any other CSR site. The framework is a tool; how you configure it determines the outcome.

How do I tell if my JavaScript content is being indexed?

URL Inspection in Search Console is the most reliable check. Compare the rendered HTML it shows against the actual page content. Any text, headings, or structured data present in the browser but absent from the URL Inspection rendered view is at risk. You can also do a site: search in Google for specific text phrases from pages you suspect are not indexed - if Google can't surface the phrase in a site search, it likely wasn't indexed.

Is dynamic rendering still a valid approach?

Dynamic rendering (serving a pre-rendered static version to bots, the JS version to users) was a Google-sanctioned workaround for CSR sites. Google officially removed it from its recommendations in 2023, noting that SSR and SSG are the preferred solutions. The underlying technique still works - serving different HTML to Googlebot isn't inherently penalised - but it introduces cloaking risk if implemented incorrectly and creates maintenance overhead. SSR or SSG is the cleaner solution.

What about Angular and Vue?

Angular Universal provides SSR for Angular applications; Nuxt provides SSR and SSG for Vue. Both are well-supported approaches with good SEO outcomes when configured correctly. The same principles apply: server-render or statically generate the pages Googlebot needs to index, hydrate interactivity client-side. The framework choice matters less than the rendering strategy.