Next.js App Routerは、設計思想を理解すると非常に強力ですが、実際の開発では「ドキュメント通りに書いたのにうまく動かない」「SEOやDiscoverを意識すると急に難しくなる」と感じる場面が少なくありません。
特に layout.tsx / metadata / Server Actions は、初見では分かりにくく、実装ミスがそのまま検索評価やUX低下につながりやすい領域です。

本記事では、実際に詰まりやすかったポイントを整理しつつ、検索（SEO）とGoogle Discoverの両立という観点から、定番かつ再現性の高い考え方をまとめます。

App Routerで最初に混乱しがちな全体像

Pages Routerとの最大の違い

App Routerでは、以下が暗黙の前提として求められます。

• レイアウトは階層構造で「自動的に合成」される
• head 操作は metadata に集約される
• クライアントとサーバーの境界が明確に分離される

この前提を知らずにPages Router感覚で書くと、後述する問題にほぼ確実に遭遇します。

layout.tsxで詰まるポイント

すべてのUIをlayoutに書いてしまう問題

layout.tsxは「共通レイアウト」を定義する場所ですが、以下のような設計は避けるべきです。

• ページ固有の状態管理をlayoutに持たせる
• クライアント専用UIを無理にlayoutへ押し込む

なぜ問題になるのか

layoutは 基本的にServer Component として扱われます。
そのため、以下の制約が発生します。

• useState や useEffect が使えない
• クライアント専用ライブラリが動かない

実務的な回避策

• layout.tsx：構造と共通枠のみ
• 各page.tsx：UIロジックや状態管理

この分離を徹底すると、後工程が一気に楽になります。

metadataで起きやすい勘違い

「動的にすればSEOに強い」は誤解

metadataは便利ですが、万能ではありません。

よくある誤解

• generateMetadataを使えば何でもSEO的に有利になる
• CSR的に変わる情報もmetadataに反映できる

実際の仕様

• metadataは サーバー実行時に確定
• クライアント側の状態変化は反映不可

Discoverを意識した現実解

• title / description：静的またはURLパラメータ依存で生成
• OGP画像：URL固定＋更新頻度を抑える

頻繁に変わる情報は本文側に寄せるのが無難です。

Server Actionsで詰まるポイント

「API Routeの代替」と考えると失敗する

Server Actionsは確かに便利ですが、万能APIではありません。

よくある詰まり

• クライアントから直接大量データを送ろうとする
• 認証・認可を軽視する

Server Actionsの適性

• フォーム送信
• 小さな更新処理
• セッション前提の安全な操作

注意点

• キャッシュとの相互作用が分かりにくい
• 再実行タイミングを誤ると二重処理が起きやすい

大量データや公開API用途では、従来のRoute Handler併用が安全です。

検索とDiscoverを両立する設計の考え方

Discoverで評価されやすい要素

一般的に以下が重要とされています（公式に詳細アルゴリズムは非公開）。

• 明確なトピック
• 安定したURL構造
• 過度に動的でないOGP

App Routerでの実装指針

• metadataは「安定・明示的」に
• layoutでの共通構造を整理
• Server Actionsは補助的に使う

この設計にすると、SEO向けクローラビリティとDiscover向け視認性のバランスが取りやすくなります。

まとめ：詰まりポイントは「役割の誤解」から生まれる

• layout.tsx：構造専用
• metadata：サーバー確定情報のみ
• Server Actions：小さく安全に

この役割分担を守るだけで、App Routerの難易度は大きく下がります。
まずは「やりすぎない設計」を意識し、検索とDiscoverの両立を狙いましょう。

App Routerは今まさに進化の途中にあり、仕様理解の差が成果に直結するタイミングです。今のうちに基本を押さえておくことが、長期的な安定運用につながります。