Choose a rendering strategy around how fresh a page must be and how reliably you can deliver its content. Static generation, request-time rendering, and cached regeneration can all support search visibility when the resulting page is accessible and useful. The choice becomes clearer when you separate public content from request-specific interactions.
What the familiar labels mean
Static site generation, or SSG, prepares page output ahead of a visitor's request. It suits content whose published version can be shared by everyone: an article, a service explanation, or a stable product description.
Server-side rendering, or SSR, produces content when a request arrives. It is useful when the result needs request-time data. The tradeoff is that delivery can depend on the availability and response time of the services used during rendering.
Incremental static regeneration, or ISR, describes updating cached or generated page output without rebuilding the entire site for every content change. The implementation needs a freshness policy and a way to refresh content after important edits.
These are useful conceptual labels, but they do not fully describe a current App Router page. One URL can contain cached public content, request-time content, and interactive browser components. A spreadsheet with one rendering label per route may hide the decisions that actually matter.
Check the Next.js caching model first
Next.js 16 documentation distinguishes apps using Cache Components from apps using the previous caching model. Check the installed version and configuration before copying a recipe. Examples based on a route-level revalidation setting should not be mixed casually with guidance for a different model.
With Cache Components enabled, use cache defines cached work, while cacheLife describes its lifetime. Uncached request-time work can stream through Suspense boundaries. This allows a page to combine a reusable shell with content that needs a live request.
The current caching documentation explains this model. For an existing application, document which model it uses beside the freshness rules. That small note prevents future contributors from treating every fetch as if it inherited an old default.
Decide what may be stale
Start with business meaning rather than a timer. A company's service description can usually tolerate an editorial publishing workflow. An available appointment slot cannot be treated as confirmed inventory merely because it appeared in a cached page.
For a property marketplace, a public description and a live availability check have different requirements. The description can be shared, while an enquiry or booking action should check the current state before promising anything. That distinction lets you preserve a readable landing page without pretending every element has the same freshness requirement.
Make a short table for the pages you own:
| Content | Freshness decision | Verification |
|---|---|---|
| Published article | Refresh after an approved edit | Edit, publish, then fetch the public URL |
| Service description | Change through the normal release or CMS flow | Compare public copy with the approved version |
| Public directory | Define an acceptable delay and removal policy | Add and remove an entry, then inspect results |
| Private account state | Resolve for the authenticated request | Test separate users and authorization failures |
A cache policy is incomplete until deletion works. Teams often test new content and forget withdrawn offers, removed staff profiles, or unpublished articles. Include those transitions in acceptance criteria.
Refresh deliberately after publication
Time-based refresh is appropriate when a small delay is acceptable. Event-driven refresh can fit editorial publishing, where the CMS knows exactly when an approved record changes. Keep the publishing event and the public refresh connected with observable logs and retry behavior.
The current revalidation APIs have distinct purposes. revalidateTag with a profile such as max supports stale-while-revalidate behavior. updateTag immediately expires tagged data for read-your-own-writes flows and is limited to Server Actions. Choose based on the user-visible behavior you need, rather than treating both names as equivalent cache clearing.
A CMS callback also needs authentication and failure handling. Test what happens if delivery fails, the same event arrives twice, or related list pages depend on the edited record. These are application design decisions; the rendering label does not solve them.
Keep the public answer independent of personalization
A visitor should be able to understand a public page before signing in or choosing preferences. Put account controls, saved searches, and personalized recommendations around that public answer. Avoid a full-page loading shell while waiting for a visitor-specific API that has no bearing on the page's main subject.
Client Components are useful for interactions. They do not automatically mean that a page is rendered only in the browser. Inspect how content is produced on a direct load, especially when a component fetches its meaningful text after mounting. The JavaScript SEO article covers that delivery risk in more detail.
For public search pages, decide which states deserve stable URLs. A city page with a useful introduction and relevant listings has a different purpose from every temporary combination of filters. Rendering all combinations successfully is not a reason to index them all.
Test content delivery and failure paths
Use a production build on a representative deployment. Development behavior is useful for debugging but should not be the sole evidence for caching behavior.
Fetch a route directly, inspect the complete response, and compare it with the rendered page. Repeat after a content edit. Check that metadata and visible content refer to the same published record, including its current URL. Streaming requires you to examine the complete delivery sequence rather than only the first chunk.
Simulate an unavailable data service. Decide whether the page should keep a previously published version, show an honest temporary failure, or report that content no longer exists. Never make a missing detail page look like a successful generic page merely to avoid an error screen.
Measure the user experience too. An uncached server dependency may slow content delivery; a large client bundle may delay interaction even when HTML arrives promptly. The performance guide explains how to diagnose these separately.
Make the decision reviewable
For each public template, record the content source, acceptable staleness, refresh trigger, failure behavior, and verification URL. That record is more useful than declaring the entire site static or dynamic.
Return to the Next.js SEO checklist before release. Rendering is one part of the work; discoverable links, coherent URLs, useful content, and accurate indexing controls still need their own checks.