Rendering for SaaS: how Google sees your marketing pages
Written by Olayinka Olayokun·Published ·Updated ·Verified
Rendering for SaaS is the decision of where each marketing URL's HTML is generated — server-side at request time (SSR), at build time (SSG), or in the browser after fetch (CSR) — and the consequences each choice has for indexation and ranking.
Summary and key takeaways
Googlebot renders JavaScript, but with a delay and a budget — and on commercial templates (pricing, comparison, feature pages) the delay is enough to silently break indexation. SSR or SSG those templates; CSR is acceptable only behind a login wall. The single most common SaaS rendering bug is a Next.js or Vite app that ships marketing pages as 'use client' by default.
- •Googlebot renders JavaScript in a deferred second pass — never assume parity with what Chrome shows.
- •Server-render or static-generate every marketing template; reserve client-side rendering for authenticated app surfaces.
- •URL Inspection → View tested page → Rendered HTML is the only reliable verification of what Google sees.
- •Hydration mismatches in Next.js / Remix / Vite leak server HTML and client HTML disagreements straight into Google's index.
- •Third-party scripts (chat widgets, A/B tools) that mutate the DOM before Googlebot's render budget expires are a top cause of empty-shell bugs.
In plain English ·Rendering for SaaS is the template-level decision of whether each marketing URL is server-rendered, static-generated, or client-rendered. SSR or SSG is required for commercial templates because Googlebot's two-pass JavaScript rendering introduces delay and failure modes that CSR pages cannot reliably survive.
- 2-pass
- Googlebot's JavaScript rendering model — initial HTML first, then deferred JS render Google Search Central
- 5 commercial templates
- Pricing, comparison, feature, integration, landing — the only ones rendering work is worth on SERPNAUT playbook
How this compares
| Rendering mode | Generated when | Indexation reliability | Use for |
|---|---|---|---|
| SSG (static) | Build time | Highest — plain HTML | Marketing pages with stable content |
| SSR (server) | Each request | High — plain HTML per request | Personalised pricing, geo content, A/B |
| CSR (client) | In the browser after JS load | Low — Googlebot may miss content | Authenticated app surfaces only |
Part of the Technical SEO for SaaS: The Founder's Checklist guide
Rendering for SaaS is the decision of where each marketing URL's HTML is generated — server-side at request time (SSR), at build time (SSG), or in the browser after fetch (CSR) — and the consequences each choice has for indexation and ranking.
A SaaS pricing page that renders correctly in Chrome and loads in 1.2s on a fast laptop can be silently invisible to Google. The cause is almost always rendering: 'use client' applied as the framework default, hydration that depends on a network fetch, or a third-party script that overwrites content after Googlebot's render budget expires. Fixing the rendering decision once at the template level usually moves more pages out of 'Crawled — not indexed' than a quarter of content work does.
What this chapter covers: render mode, hydration, render budget, rendered html view, per-route choice.
Why Googlebot's two-pass render is the trap
Googlebot processes pages in two passes: the initial HTML pass (immediate) and the JavaScript render pass (deferred, sometimes by days). The first pass is what indexes the page; the second pass updates what's indexed if it ever runs.
Googlebot processes pages in two passes: the initial HTML pass (immediate) and the JavaScript render pass (deferred, sometimes by days). The first pass is what indexes the page; the second pass updates what's indexed if it ever runs. Pages that rely on the JS pass for their H1, product copy, or CTA enter the index missing those elements — sometimes permanently.
This is not a bug Google plans to fix. The render queue exists because rendering JavaScript at web scale is expensive, and it always will be. Treat the deferred render as an optimization tier, not a base case.
Which pages to SSR/SSG (and which not to)
The five SaaS templates that have to be SSR or SSG: home page, pricing page, comparison/alternative pages, feature pages, integration pages. These are the pages that earn ranking and that lose the most when rendering breaks.
The five SaaS templates that have to be SSR or SSG: home page, pricing page, comparison/alternative pages, feature pages, integration pages. These are the pages that earn ranking and that lose the most when rendering breaks.
Blog and documentation: SSG is the default and the right choice — static, cacheable, fast. SSR is overkill unless you personalise content per-visitor.
Authenticated app surfaces: CSR is fine and often preferable. Google doesn't index logged-in screens regardless of how they render, so render mode is purely a UX decision there.
How to verify rendering for any URL
Open Search Console → URL Inspection → enter the URL → 'Test live URL' → 'View tested page' → Rendered HTML tab. Read the actual HTML Googlebot constructed after its render pass. If the H1, product copy, pricing table, or CTA is missing, the page is broken for Google.
Open Search Console → URL Inspection → enter the URL → 'Test live URL' → 'View tested page' → Rendered HTML tab. Read the actual HTML Googlebot constructed after its render pass. If the H1, product copy, pricing table, or CTA is missing, the page is broken for Google.
Compare against the rendered HTML in Chrome DevTools (Elements panel). Differences between the two are the bugs — usually a script that runs in Chrome but times out in Googlebot's render environment, or content that mounts after a network fetch Googlebot didn't wait for.
Hydration mismatches and third-party scripts
Next. js / Remix / Vite warn loudly about hydration mismatches in development but ship them silently to production. A common SaaS pattern: the server renders the pricing table with a default currency, the client re-renders it with a geo-detected currency, and Googlebot indexes one version while users see another.
Next.js / Remix / Vite warn loudly about hydration mismatches in development but ship them silently to production. A common SaaS pattern: the server renders the pricing table with a default currency, the client re-renders it with a geo-detected currency, and Googlebot indexes one version while users see another.
Third-party scripts (Intercom, Drift, Optimizely, Hotjar) that mutate the DOM after page load are the most common cause of empty-shell bugs on otherwise well-built SaaS sites. Defer them past Googlebot's render window or load them conditionally on user interaction.
The checklist for this chapter
- ✓Every commercial template (home, pricing, comparison, feature, integration) verified in URL Inspection rendered-HTML view
- ✓No 'use client' on marketing route components in Next.js App Router
- ✓Hydration warnings in dev treated as production bugs, not noise
- ✓Third-party DOM-mutating scripts deferred past initial render or loaded on interaction
- ✓Render mode chosen per template, not as a framework default
- ✓SSR/SSG decision documented so framework upgrades don't silently change it
- ✓Quarterly spot-check of 5 commercial URLs via rendered-HTML view
Where this chapter sits in the guide
most of the 'Crawled — currently not indexed' bucket on a SaaS site. Read the saas indexation: why your pages aren't in google chapter →
Core Web Vitals — render mode affects LCP, INP, and CLS directly. Read the core web vitals for saas: field data, not lab scores chapter →
frontend performance — render mode is about who builds the HTML; performance is about how fast it loads. → Server-side rendering
URL Inspection rendered-HTML view, not by visual inspection in Chrome. → Google Search Console
Google's two-pass JavaScript rendering model, the official documentation for how Googlebot handles JS. → JavaScript SEO basics (Google)
Quick answers about javascript rendering for saas: ssr, ssg, and the empty-shell bug
- Can Googlebot render JavaScript on SaaS pages?
- Yes, in a deferred second-pass render — but with a render budget and known failure modes. Pages that depend on JavaScript to insert the H1, product copy, or pricing table routinely lose those elements when Googlebot's render budget expires. SSR or SSG those templates; never rely on the JS pass for commercial copy.#
- SSR or SSG for a SaaS marketing site — which should I pick?
- SSG when the content rarely changes (homepage, feature pages, comparison pages) — fastest and cheapest. SSR when the page composes per-request data (logged-in state, geo pricing, A/B variants). Mixed in the same app is normal; Next.js, Remix, and Astro all support per-route choice.#
- How do I verify Google sees the same HTML I see?
- Open Search Console URL Inspection → enter the URL → 'Test live URL' → 'View tested page' → Rendered HTML tab. If the H1, product copy, or call-to-action is missing there, the page is broken for Google regardless of how it looks in Chrome. This is the only diagnostic that matters.#
- Can I run my SaaS marketing site as a single-page React app?
- Technically yes; in practice it consistently underperforms a server-rendered equivalent. SPAs leak indexation issues that compound: missing H1s after hydration, scripts that fail under Googlebot's CPU constraints, third-party widgets that overwrite content after render. If you're starting fresh, choose Next.js, Astro, Remix, or TanStack Start — not a Vite SPA — for the marketing site.#
Questions about javascript rendering for saas: ssr, ssg, and the empty-shell bug
- Yes, in a deferred second pass. But the render budget is finite, the queue is sometimes days deep, and content that depends on the JS pass routinely enters the index missing. Server-render anything that must rank.
- Google's documentation of JavaScript SEO basics and the two-pass render model. Google Search Central — JavaScript SEO basics
- URL Inspection rendered-HTML view as the ground-truth check. Google — URL Inspection tool
- Next.js rendering documentation (Static, Dynamic, Streaming). Next.js — Rendering
This chapter is one node in the founder-led playbook. To see which nodes your specific URLs are bleeding traffic from, get a founder-grade SEO audit of your URLs. Same six disciplines, applied to the pages you actually own.
Related concepts
Adjacent entities this chapter touches on. Each is a separate concept worth knowing even if it isn't a chapter on its own.
- Hydration
- The client-side process of attaching React (or similar) state to server-rendered HTML. Hydration mismatches leak two versions of the page to Google.
- Edge SSR
- Server-rendering executed at a CDN edge node rather than an origin server. Cuts LCP for global SaaS traffic without changing render mode.
- Dynamic rendering
- Serving pre-rendered HTML to bots and SPA HTML to users. Deprecated by Google in 2022 as a long-term recommendation.
- Streaming SSR
- Sending HTML to the browser in chunks as it's generated, reducing time-to-first-byte. Supported by Next.js App Router and Remix.
What's changed on this page
- First published with the SSR/SSG/CSR decision table and the five-commercial-templates rule.
- Added the Invoicemonk day-12 indexation result after switching from CSR to SSR and a hydration-mismatch section.
- Bound rendering to Google's two-pass JS render documentation and added neighbouring-concept block (hydration, Edge SSR, Web Worker).
Olayinka Olayokun
Founder, SERPNAUT and Invoicemonk
Written by Olayinka Olayokun. I run SERPNAUT, a founder-led SEO service for B2B SaaS, and Invoicemonk, the SaaS I grew from zero to 300+ organic visits and a paying customer in 28 days using the same playbook. Everything below is what worked on my own URLs and on the audits I've shipped since.
More chapters in this guide
Rendering is upstream of indexation, which is upstream of everything. A SaaS site that ships SSR or SSG on its commercial templates rarely has the indexation gaps the previous chapter diagnosed. The next chapter covers Core Web Vitals — the user-experience signal that turns a correctly rendered page into one Google ranks above its peers.
See the full guide at technical seo for saas: the founder's checklist. The commercial bridge above is the canonical path from this chapter to your URLs.