Search intent this article targets

Developers search for this topic when App Router behavior feels confusing. They want concrete rules for "use client", metadata, data fetching, bundle size, hydration, and SEO. This is high-intent traffic because the answer affects architecture, not just syntax.

• Next.js Server Components vs Client Components example.
• When should I use use client in Next.js?
• Are Server Components good for SEO?
• How to reduce Next.js client bundle size.

The simple rule

Start with Server Components by default. Move to Client Components only when you need browser-only behavior: state, effects, event handlers, DOM APIs, localStorage, media APIs, or client-side libraries that cannot run on the server.

// Server Component by default
export default async function BlogPage() {
  const posts = await getPublishedPosts();
  return <BlogList posts={posts} />;
}

// Client Component only where interaction is needed
'use client';

export function SearchBox() {
  const [query, setQuery] = useState('');
  return <input value={query} onChange={(event) => setQuery(event.target.value)} />;
}

Why Server Components help SEO pages

Public content pages such as blogs, question details, documentation, and landing pages usually benefit from server rendering. The HTML contains meaningful content before client JavaScript finishes loading. Metadata can be generated near the data fetch. Search engines and social previews receive stable page information.

• Article title and content can be present in the initial HTML.
• Canonical URLs and Open Graph tags can be generated server-side.
• Large client-only bundles are avoided on pages that mostly display text.
• Backend secrets and database access stay off the browser.

Where Client Components are the right choice

Client Components are not bad. They are necessary for interactive UI. The problem is using them too high in the tree and accidentally turning large parts of the page into browser-delivered JavaScript.

• Search inputs with live local state.
• Dropdown menus, modals, tabs, and accordions.
• Code editors, whiteboards, charts, and media controls.
• User-specific widgets that depend on browser session behavior.
• Optimistic UI after button clicks or form submissions.

The boundary design pattern

A strong architecture keeps data-heavy and SEO-heavy work in Server Components, then passes clean props into small Client Components. This keeps the client bundle smaller and makes ownership clearer.

export default async function ProductPage({ params }) {
  const product = await getProduct(params.slug);
  const reviews = await getPublicReviews(product.id);

  return (
    <>
      <ProductHero product={product} />
      <ReviewSummary reviews={reviews} />
      <AddToCartButton productId={product.id} />
    </>
  );
}

Only AddToCartButton needs browser interaction. The product title, description, schema, and reviews can remain server-rendered.

Common mistakes

• Adding use client to a page because one small button needs state.
• Importing server-only utilities into Client Components.
• Fetching public SEO content only after hydration.
• Passing huge objects into Client Components when only an id or label is needed.
• Trying to read cookies or headers in the wrong layer.
• Forgetting that client components still render initially but ship JavaScript for hydration.

Interview explanation

A strong answer: Server Components run on the server and are best for data fetching, static or dynamic public content, SEO pages, and keeping secrets out of the browser. Client Components are required for browser interactivity, state, effects, event handlers, and DOM APIs. Good Next.js architecture keeps the client boundary as low as practical.

Quick FAQ

Should every Next.js page be a Server Component?

Pages are Server Components by default in the App Router, and that is usually a good starting point. Add Client Components only for the interactive parts.

Are Client Components bad for SEO?

Not automatically, but relying on client-only fetching for important content can make SEO weaker and performance worse. Public content should usually be available in server-rendered HTML.

Where should data fetching happen?

Fetch public page data in Server Components when possible. Fetch browser-specific or user-interaction data in Client Components only when the server cannot know it safely.

Official references

• React documentation: Server Components
• Next.js documentation: Server and Client Components