SSR/SSG impact

Rendering strategy affects what crawlers and users receive on first response. **SSR** renders per request; **SSG** pre-renders at build; **ISR** revalidates static pages; **CSR** ships a shell and fetches content in the browser. Modern Google renders JavaScript, but delayed or empty first HTML still hurts discovery and snippets.

| Strategy | SEO angle | |----------|-----------| | SSG/ISR | Fast HTML, great for stable marketing/docs | | SSR | Fresh personalized HTML when caching is hard | | CSR + hydration | Risk empty meta/body until JS runs | | Streaming SSR | Earlier bytes; ensure critical meta in head |

					Crawler-visible checklist:
- Title and canonical in initial HTML
- Main textual content not gated behind client fetch
- Internal links as real <a href>
- Status codes correct (200 vs soft-404)
				

On interviews: when Next.js App Router chooses static vs dynamic; hydration mismatch; soft 404 in SPAs; prerender service vs native SSG.

Common pitfalls: client-only `useEffect` document.title; infinite scroll without paginated fallbacks; blocking rendering on slow third-party scripts; A/B tests that hide content from bots against guidelines.

The trade-off is personalization and build simplicity versus immediate crawlable HTML.

Checklist:

• Critical SEO tags in server-rendered head.
• Test with URL inspection and view-source.
• Provide stable URLs for indexable state.
• Measure LCP alongside crawl completeness.