SSR, SSG, ISR or CSR: choosing a rendering strategy per route
Rendering strategy is a per-route decision, not an architectural religion. A single Next.js app can and should use all four.
Googlebot executes JavaScript, but rendering happens in a separate, later queue with no guaranteed timing. Content that only exists after client-side rendering may be indexed slowly or incompletely, and most other crawlers — including several AI systems — do not execute JavaScript at all. Server-render anything that needs to be found.
The queue delay is not published and varies. For a news site or an ecommerce catalogue where freshness matters, waiting for the render queue is a real disadvantage. For a stable page it matters less — but there is no upside to relying on it either.
| Content | Render where |
|---|---|
| Main body content | Server — always |
| Title, description, canonical | Server — always |
| Structured data | Server |
| Navigation and internal links | Server |
| Product price and availability | Server |
| Personalised recommendations | Client is fine |
| Interactive widgets | Client is fine |
| Comments | Server for the first page, client for more |
# What the crawler receives before any JavaScript runs
curl -s https://rovqix.in/blog/example | grep -o "<h1>.*</h1>"
# Compare against the rendered DOM in the browser
# If the h1 is missing from curl output, it is client-renderedServing crawlers materially different content from users is cloaking and is against guidelines. Serving the same content, rendered differently, is not — the distinction is whether the content differs.
Usually yes, eventually. The delay and inconsistency are the problem, along with other crawlers that do not render at all. Server-rendering removes the uncertainty entirely.
Google now describes it as a workaround rather than a recommendation. Server-side rendering or static generation is the durable solution.
Not for indexing, since the server HTML is already complete. It affects Core Web Vitals — particularly INP — which is a separate but real concern.
Provide real paginated URLs that render server-side, and layer infinite scroll on top for users. Crawlers follow the links; users get the smooth experience.
ROVQIX Growth
SEO & growth team, ROVQIX
The ROVQIX growth team handles technical SEO, Core Web Vitals and AI-search visibility for the sites we build. Recommendations here are the ones we apply to client projects and to rovqix.in itself.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
Rendering strategy is a per-route decision, not an architectural religion. A single Next.js app can and should use all four.
'Discovered – currently not indexed' is Google saying your page is not worth the crawl. That is a content problem wearing a technical costume.
AI systems do not read your page. They retrieve chunks of it. Write so that any single chunk still makes sense alone.
No spam. Just the occasional case study and craft breakdown.