The two options
Pages built to HTML ahead of time and served from a CDN.
- Content changes on a predictable schedule
- Page counts are manageable within a build
- Response time and hosting simplicity matter
Pages rendered per request, always reflecting current data.
- Content changes constantly — stock, availability, personalisation
- Page counts are too large to build ahead
- Freshness matters more than response time
How they differ
| Static generation | Server rendering | |
|---|---|---|
| Crawler sees HTML | Yes | Yes |
| Response time | Fastest — a CDN file | Slower — rendered per request |
| Freshness | As of last build | Always current |
| Scales to large catalogues | Build time grows with page count | Yes |
| Infrastructure cost | Low | Higher |
What actually decides it
The important point is what this comparison is not. Neither option creates an indexing problem, because both deliver complete HTML. The choice that actually matters for search is between these two and client-only rendering, which is where content appears after JavaScript executes and where crawlers — particularly AI crawlers with less patient rendering — see nothing.
Build time is the practical constraint on static generation, and it arrives suddenly. A site of a few thousand pages builds in minutes; tens of thousands can take an hour, at which point publishing becomes painful. Incremental regeneration solves most of this by rebuilding only changed pages, and is worth configuring before the problem appears rather than after.
Server rendering earns its cost where data genuinely changes per request. Live stock levels, per-account commercial terms, availability that varies by location. For a marketing site or a documentation set, it adds latency and infrastructure to solve a freshness problem that does not exist.
Questions
Which is better for SEO?
Neither, meaningfully. Both serve complete HTML and both index cleanly. The distinction that matters is against client-only rendering, which is the pattern that actually causes invisibility.
What about incremental regeneration?
It is usually the right answer for large content sites — static speed with rebuilds only for pages that changed. It removes the build-time objection to static generation almost entirely.
Does a slower server response hurt rankings?
It contributes through page experience and, more importantly, through crawl efficiency. A slow response on a large site means fewer pages crawled per visit, which delays how quickly changes are noticed.
Related services
- Headless & Next.js SEO — SEO
- Core Web Vitals — SEO
- Technical SEO Audit — SEO
- Enterprise SEO — SEO
Still not sure?
Thirty minutes with a senior strategist. We pull your live visibility while we talk and tell you which of these two is actually binding for you — including when the answer is neither. Book a discovery call →