Next.jsのGoogleインデックス：App RouterとPages Routerの完全ガイド

Next.jsには4つのレンダリング戦略があり、それぞれがGooglebotがコンテンツをどのように（あるいは見えるかどうか）見るかに異なる影響を持ちます。

Static Site Generation（SSG）はインデックスのゴールドスタンダードです。ページはビルド時に完全なHTMLにレンダリングされ、静的ファイルとして配信されます。Googlebotは完全なHTMLをすぐに受け取り、JavaScriptの実行は不要です。App Routerでは、動的関数（cookies()、headers()、searchParamsなど）を呼び出さないServer Componentはデフォルトで静的にレンダリングされます。Pages Routerでは、getStaticPropsをエクスポートすることでSSGを実現します。

Server-Side Rendering（SSR）はリクエストごとにHTMLを生成します。GooglebotはSSGと同じく完全なHTMLを受け取りますが、ページはキャッシュされません（キャッシュヘッダーを追加しない限り）。SSRはApp Routerでは、動的関数の使用、またはルートセグメントでexport const dynamic = "force-dynamic"を設定することでトリガーされます。Pages RouterではgetServerSidePropsを使用します。SSRはインデックスにとって信頼性が高いですが、クロールリクエストごとに完全なレンダリングがトリガーされるため、SSGより遅くなります。

Incremental Static Regeneration（ISR）はハイブリッドです。ページはビルド時に静的に生成され、キャッシュから配信され、設定可能な時間間隔の後にバックグラウンドで再生成されます。App Routerでは、ページまたはレイアウトでexport const revalidate = 3600（秒）を設定することでISRを実現します。Pages Routerでは、getStaticPropsの戻り値にrevalidateを追加します。ISRはインデックスに優れています — Googlebotは高速な静的HTMLを取得し、コンテンツは適度に新鮮さを保ちます。

クライアントサイドレンダリング（CSR）はインデックスの問題が発生する場所です。コンポーネントに"use client"が付いており、useEffectフックでデータをフェッチする場合、ブラウザ（およびGooglebot）に送信される初期HTMLにはローディング状態以外何も含まれていません。Googlebotはある程度JavaScriptを実行できますが、JavaScriptは数時間または数日後に行われる可能性のある二次インデックスパスで処理されます。そして複雑なクライアントサイドのデータフェッチは、Googleのレンダリング環境でしばしば静かに失敗します。

ルール： インデックスさせたいコンテンツは、ハイドレーション後にクライアントサイドJavaScriptで読み込まれるのではなく、初期のサーバーレンダリングHTMLに存在しなければなりません。

Next.js App Routerは、appディレクトリに配置された特別なsitemap.ts（またはsitemap.xml/route.ts）ファイルを通じて、プログラマティックなsitemap生成をサポートします。最もシンプルなアプローチは、sitemapエントリの配列を返すデフォルト関数をエクスポートするapp/sitemap.tsを作成することです。

これにより、/sitemap.xmlが自動的に生成されます。関数は開発時にはリクエスト時に、本番時にはビルド時（静的エクスポートの場合）または各リクエスト時（動的レンダリングの場合）に実行されます。

50,000を超えるURLを持つ大規模サイトの場合は、sitemapインデックスパターンを使用します。app/sitemap.tsを作成して、複数のサブsitemapを指すsitemapインデックスを返し、各サブsitemapに対して個別のルートハンドラ（例：app/sitemaps/[id]/route.ts）を作成します。Googleのsitemap仕様は、1つのsitemapファイルあたり最大50,000のURL、インデックス内に最大500のsitemapファイルを許可しています。

開発者が犯す致命的なミスは、動的ルートをsitemapに含めるのを忘れることです。アプリに/blog/[slug]のようなルートがある場合、sitemap関数はデータベースまたはCMSにクエリして、すべての有効なスラッグを取得し、それぞれに対してURLを生成する必要があります。sitemapに単に/blog/[slug]をリストするのは意味がありません — Googleは実際の解決済みURLを必要としています。

Pages Routerには、組み込みのsitemap生成はありません。2つの選択肢があります：

• next-sitemapnpmパッケージを使用する（pagesディレクトリとgetStaticPathsの出力を読み取ることでビルド時にsitemapを生成）
• pages/api/sitemap.tsにカスタムAPIルートを作成して、XMLを動的に生成する

next-sitemapパッケージが最も一般的な選択であり、サーバーサイドsitemap、robotsTxt生成、複数sitemapの分割をサポートします。

App Routerは、/robots.txtをプログラマティックに生成するapp/robots.tsファイルをサポートしています。

robots.txtのNext.js固有の重要な考慮事項：

• /api/ルートを常にブロック（JSONを返し、HTMLではない）
• /_next/data/をブロック（クライアントサイドナビゲーション用のJSONデータで、スタンドアロンページとしてインデックスされるべきではない）
• 認証済みダッシュボードのルートをブロック
• /_next/static/をブロックしないでください — これにはGooglebotがページを適切にレンダリングするために必要なCSSとJSファイルが含まれています

ページレベルのnoindex制御には、Metadata APIのrobotsフィールドを使用します。検索結果から除外したいページのメタデータエクスポートでrobots: { index: false }を設定します。これは以下に適しています：

• 認証ページ（/login、/register）
• ユーザーダッシュボード
• 認証背後のAPIドキュメント
• パーソナライズされたコンテンツを持つあらゆるページ

ミドルウェア（プロジェクトルートのmiddleware.ts）もインデックスに影響を与える可能性があります。ミドルウェアが認証またはロケール検出のためにリダイレクトを実行する場合、Googlebotがリダイレクトループに陥らないようにしてください。

一般的に安全なパターンは、認証されていないユーザーを/dashboardから/loginにリダイレクトするミドルウェアです — これは問題ありません。なぜなら、/dashboardはとにかくnoindexにしたいからです。しかし、地理位置に基づいてリダイレクトするミドルウェアは、Googlebot（米国ベースのIPからクロール）を常に米国版にトラップし、他のロケールバージョンがインデックスされないようにする可能性があります。

Google Search ConsoleのURL検査ツールでミドルウェアの動作をテストし、Googlebotが実際に何に遭遇しているかを確認してください。