日本語

Next.js App Router Pitfalls Developers Actually Hit: Layouts, Metadata, and Server Actions

Next.js App Router pitfalls main visual

Next.js App Router is powerful once you lean into its design, but many teams still hit "I wrote it like the docs and it breaks" or "SEO and Discover got worse" moments. The most common blockers cluster around layout.tsx, metadata, and Server Actions. This article collects the real-world pitfalls and the stable patterns that keep search (SEO) and Google Discover happy.


Why App Router feels tricky at first

Key differences from Pages Router that trip people up:

  • Layouts are composed automatically by directory hierarchy.
  • head is driven by metadata and generateMetadata, not ad hoc JSX.
  • Client and server components have a stricter boundary.

If you write App Router pages the way you wrote Pages Router, you will quickly see hydration warnings, missing metadata, or strange caching.


layout.tsx pitfalls and fixes

Pitfall: putting every UI concern in layout

layout.tsx is a server component by default. When you cram client-only UI or per-page state into it, you get errors like "useState is not supported" and broken client libraries.

Safe pattern

  • Keep layout.tsx for structure: shells, navigation, footer, and slots.
  • Push stateful logic and client libraries into each page.tsx (or a client wrapper component imported from the page).
  • If a layout needs client behavior, wrap only that part in a small client component such as ClientLayoutShell to isolate state.

metadata misconceptions

Myth: "Fully dynamic metadata boosts SEO"

generateMetadata runs on the server. Client-side state changes never reach it, and overly dynamic metadata can hurt cacheability.

What actually happens

  • Metadata is resolved at request time on the server.
  • Client-side changes (filters, tabs, preferences) do not update metadata.
  • Over-dynamic OGP URLs slow down crawlers and can produce inconsistent previews.

SEO and Discover friendly approach

  • Derive title and description from static content or route params; keep them stable across renders.
  • Keep OGP image URLs mostly fixed; version them only when the visual meaning changes.
  • Put frequently changing details in the body text, not the metadata.
  • Align your on-page H1 and opening paragraph with the metadata title and description so Discover sees a clear topic.

Server Actions: where teams stumble

Mistake: treating Server Actions as a drop-in API replacement

They shine for small, trusted writes, not for everything.

Common failures

  • Sending large payloads or heavy FormData directly from the client.
  • Skipping authentication or authorization because "it's server-side anyway."
  • Double executions when revalidation or cache invalidation is mis-timed.

Use them when

  • Handling form submissions or small updates that are tied to a session.
  • You want to avoid an extra API endpoint for simple mutations.

Use a Route Handler instead when

  • You need public APIs, large uploads, streaming, or complex auth flows.
  • You must manage cache headers or HTTP semantics explicitly.

Implementation checklist for SEO and Discover

  • One clear topic per page; keep slug, title, and H1 aligned.
  • Stable metadata: concise title (~55-60 chars), readable description (~150-160 chars), and predictable OGP image.
  • Avoid overly dynamic OGP URLs; keep dimensions around 1200x630 and reuse the same asset until the content meaning changes.
  • Prevent layout shift in the above-the-fold area (pre-size hero images, keep navigation stable).
  • Keep primary content visible without client-side actions; crawlers and Discover prefer immediate, readable text.
  • Use Route Handlers for heavy or public data and leave Server Actions for lightweight, authenticated form flows.

Takeaways

  • layout.tsx: structural shell only; isolate client state in page-level components.
  • metadata: server-resolved and most effective when stable; mirror the topic in your H1.
  • Server Actions: small, session-aware mutations; fall back to Route Handlers for heavier work.

Respect these roles and the App Router stays predictable, while your pages remain crawlable for SEO and consistent enough for Google Discover.

Related posts