Next.js exists largely to solve the rendering problem that plain React creates. It offers server rendering and static generation, which means content can arrive in the initial HTML rather than being built in the browser.
That makes it a good choice for sites that need to rank. It also means the SEO questions shift from “will this be indexed” to “which rendering mode did we choose, and was it the right one”.
The rendering choices
- Static generation: pages built at deploy time. Fastest and most reliable. Correct for content that changes infrequently.
- Server-side rendering: built per request. Correct where content is genuinely dynamic or personalised.
- Incremental regeneration: static pages rebuilt on a schedule or on demand. Suits large catalogues where full rebuilds are impractical.
- Client-side rendering: available, and reintroduces every React problem. Use only for content that does not need indexing.
The common failure is not choosing badly at the framework level but choosing per-page inconsistently, so some templates render server-side and others do not, without anyone tracking which.
What to check
Which pages are actually static
The build output reports the rendering mode per route. Confirm your commercially important templates are static or server-rendered rather than client-rendered, and re-check after significant changes since a single data-fetching change can flip a route.
Metadata
Titles, descriptions and canonicals should be generated server-side. Setting them in a client component means the initial response carries defaults, which is the problem server rendering was meant to solve.
Status codes
A route that does not exist must return 404, not a 200 with a not-found component. This is configurable and frequently left wrong.
Regeneration timing on large catalogues
Where incremental regeneration is used, check how stale pages can become. A product page regenerating daily may advertise a price or availability that changed hours ago, which matters for product markup accuracy.
What Next.js does not fix
- Links implemented as click handlers rather than anchor tags. The framework does not force correct linking.
- Content genuinely loaded on interaction, which is still invisible to crawlers.
- Site structure, internal linking and click depth, which are architectural rather than technical.
- Thin or duplicate content, which no rendering approach improves.
Framework choice removes a category of technical risk. It does not substitute for the rest of SEO, and teams that adopt it sometimes assume otherwise.
Frequently asked questions
Is Next.js good for SEO?
Yes, when its rendering options are used deliberately. Static or server rendering puts content in the initial HTML, which removes the main reliability problem with client-side React.
Static or server-side rendering?
Static wherever content permits, since it is faster and cannot fail at request time. Server rendering where content is genuinely dynamic. Incremental regeneration for large catalogues.
How do I check what mode a page uses?
The build output lists it per route. Verify after any data-fetching change, since routes can silently change mode.
Do I still need to worry about JavaScript SEO?
Less, but not none. Links, status codes and interaction-dependent content remain your responsibility regardless of rendering mode.
Consulting CTA
If your Next.js site has indexing problems despite server rendering, book an SEO consultation for a rendering and structure review.