Google can render JavaScript and index client-generated content. The useful question for a Next.js website is how reliably each public URL supplies its content, links, metadata and HTTP status. Choosing SSR does not itself guarantee indexing; choosing a Client Component does not itself mean the page ships empty HTML.
How Google processes a JavaScript page
Google describes crawling, rendering and indexing as separate stages. After fetching a URL, it processes the response and can discover links in the HTML. Its rendering service can execute JavaScript and process the resulting HTML. Rendering may be queued, and necessary resources must be accessible.
Google's JavaScript SEO documentation still recommends server-side or pre-rendering as useful for users and crawlers, including bots that cannot execute JavaScript. That is a reason to reduce unnecessary dependencies, not evidence that every CSR page is excluded from search.
Distinguish rendering strategy from component boundaries
| Approach | What it does | A suitable starting point |
|---|---|---|
| Static rendering | Produces reusable HTML ahead of a request or through regeneration | Articles and public pages whose content can be cached |
| Dynamic server rendering | Builds the response using request-time data | Public content that needs current or request-specific data |
| Client-side data fetching | Loads some content through browser JavaScript | Interactive or personalised application areas |
| Streaming | Sends parts of a response progressively | Pages where independent sections have different loading costs |
In the App Router, Server Components can load data without shipping their component code to the browser. Client Components provide state, event handlers and browser APIs. On an initial load, Next.js can pre-render HTML for both, then hydrate the interactive parts. The component documentation explains this distinction.
The use client directive is therefore not an SEO failure by itself. Fetching all public page content in useEffect creates a different dependency: JavaScript and the API must succeed before that content exists.
Streaming and edge delivery require verification
Streaming is not inherently an indexing defect. An early network chunk may contain a fallback while later parts contain the content. Inspect the completed response and the rendered page before concluding that content is absent. Check what happens if a dependency fails or the connection is interrupted.
Metadata handling also depends on the framework version and bot behaviour. Next.js documents streaming metadata and bot-specific handling. Verify your deployed version rather than assuming that one rule applies to every crawler.
Edge execution changes where a response is produced. It does not automatically improve or damage indexing. Audit cache keys, invalidation and variants: a public product page should not unpredictably become an empty or private state because of cookies, location or an uncached dependency. Cache correctness and stable content matter more than the label on the hosting feature.
Common failures to look for
Content requires an interaction. Googlebot does not conduct an arbitrary user journey to reveal API-backed content. Tabs and accordions are not inherently problematic when their content is already present; content fetched only after a click introduces a discovery dependency.
Navigation has no crawlable link. Use real anchors with an href for public destinations. A clickable element with a routing handler is not a reliable substitute.
A missing resource returns a successful page. An app displaying “not found” with HTTP 200 can become a soft 404. Test the actual response as well as the visible message. Streaming can affect when response headers are committed, so verify the framework behaviour on the deployed route.
Metadata changes into a conflicting state. Check title, canonical, robots and hreflang in the response and rendered output. A noindex in initial HTML should not depend on JavaScript removing it later; Google may skip rendering after seeing that instruction.
Required resources fail for crawlers. Blocked scripts, unavailable APIs, authentication, rate limits or consent-dependent content can prevent a complete render. A page working in an authenticated developer browser is insufficient evidence.
A practical rendering audit
- Fetch representative URLs directly and record status, redirects and the completed HTML response.
- Check that the main content, links and metadata are available without a user action.
- Compare a clean browser's initial load, rendered DOM and client navigation.
- Test missing resources, empty results and failed dependencies.
- Use Search Console URL Inspection to inspect the live rendered result and available indexed-page evidence. The live test does not prove that Google has indexed the current version.
- Review server logs where available, including failed requests and resource availability.
Disabling JavaScript is a useful robustness check, not an exact simulation of Googlebot. Lighthouse is useful for diagnosing a browser load; it is not proof of indexing or ranking.
Choose the least fragile implementation for the page
For an article or service page, static or server-rendered main content is usually a straightforward foundation. Keep browser code for the interactions that need it. An authenticated dashboard can make different trade-offs because its private content has no public search purpose.
Measure performance alongside content availability. Slow data sources can make SSR slow; a large hydration bundle can add browser work; unstable placeholders can cause layout shifts. Use field and lab performance evidence rather than treating a rendering method as a performance score.
If the problem is a migration or relaunch, our SEO migration service covers URL mapping, rendering checks and release verification. For implementation work, frontend development and performance is the relevant scope.