SSR, CSR, and why it affects indexing
With client-side rendering (CSR), the server sends a near-empty HTML shell and the browser builds the page with JavaScript. With server-side rendering (SSR), the server sends fully-formed HTML with the content already in it. Static generation (SSG) does the same at build time.
Google can render JavaScript, but it does so on a second pass that can be delayed and isn't guaranteed for every page. Content that only appears after JavaScript runs is more fragile: it may be indexed late, partially, or not at all, and other crawlers handle JS far less reliably than Google.
- CSR ships an empty shell; content depends on JS executing successfully
- SSR and SSG ship real HTML crawlers can read on the first pass
- Google's JS rendering is a deferred, resource-limited second step
- Bing and social/link-preview crawlers handle JS poorly or not at all
- Meta tags, canonical, and structured data injected by JS can be missed
Choosing the right approach for your site
The best choice depends on how your content changes and where it comes from. A largely static marketing site is a strong fit for static generation. A catalog with frequently changing inventory often suits SSR or incremental static regeneration. A logged-in app dashboard doesn't need to be indexable at all.
We map each page type to a rendering mode, and where a full rebuild isn't practical, prerendering or dynamic rendering can serve crawlers real HTML without re-architecting your app.
- Static generation (SSG) for stable marketing and content pages
- SSR or incremental regeneration for frequently updated catalogs
- Prerendering as a bridge when the app is committed to CSR
- Ensure titles, meta, canonical, and JSON-LD are in the served HTML
- Match rendering choice to how often each page type changes
- Verify with the URL Inspection tool's rendered HTML, not just view-source
More on technical seo
Frequently asked questions
Google says it can render JavaScript, so does this still matter?
It does. Google can render JS, but rendering is deferred and resource-limited, so it can be slower and less complete than serving HTML directly. Other search engines and the crawlers behind social previews are far less capable. Serving real HTML removes that risk entirely.
Do I have to rebuild my whole site to fix this?
Not always. If your framework already supports SSR or static generation, it's often a configuration and code change per page type. If it doesn't, prerendering can serve crawlers finished HTML as a bridge. We'll scope the smallest change that solves the indexing problem.
How can I tell if my content is being seen?
The URL Inspection tool in Search Console shows the rendered HTML Google actually sees, which is different from your raw view-source. If your main content and meta tags are missing there, rendering is the likely cause.