optimise-seo

SEO を最適化する

• 対象： クロール可能性、メタデータ、構造化データ、canonical、リダイレクト、ステータスコード、hreflang、AI クローラーのポリシーと抽出可能なページ構造、Core Web Vitals、プログラマティック SEO、セキュリティおよびプライバシー関連のヘッダー、エラーページの動作を、Next.js App Router のコードベースに実装します。
• 対象外： ビジュアルの再設計、レイアウト、ページ単位の UI 品質（ui-design の Direction、Build、Audit モード）、需要調査、ブリーフ、質問マップ、Search Console のモニタリング（seo-program）、robots.txt と sitemap.xml のテナントルーティング（multi-tenant-architecture）、記事の執筆（外部の ghostwriter）。

対応範囲：metadata と generateMetadata、JSON-LD、セマンティック HTML、内部リンク、alt テキスト、app/sitemap.ts、app/robots.ts、app/feed.xml/route.ts、app/llms.txt/route.ts、proxy.ts、next.config.ts のリダイレクトとヘッダー、エラーページ、パフォーマンスの改善です。コンポーネントのスタイルとレイアウトは変更しません。修正にレイアウト変更が必要な場合は、ui-design への引き継ぎ事項として明記してください。

コードを書く前に、node_modules/next/dist/docs/ にある該当するガイドを読みます（アプリのディレクトリを基準に解決してください。モノレポでは、リポジトリのルートから next パッケージを参照できません）。同梱ドキュメントはインストール済みのバージョンに対応しています。references/nextjs-implementation.md のメモは 16.3 を基準に確認されており、動作が変更された箇所も記載されています。

リファレンス

ファイル	読むタイミング
references/indexing-policy.md	リダイレクト、重複 URL、インデックス登録の判断、または大規模に生成されるページを扱う場合
references/nextjs-implementation.md	ステップ 2〜4 でコードを書く前：メタデータ、サイトマップと robots、リダイレクト、インデックス登録、ストリーミングされる 404、JSON-LD、OG 画像、CSP
references/answer-engines.md	AI クローラー、GPTBot または ClaudeBot 向けの robots.ts ルール、llms.txt、Content-Signal、または「なぜ引用されないのか」を扱う場合
references/internationalisation.md	サイトに複数のロケールがある場合
references/technical-hardening.md	ヘッダー、Cookie、同意、GPC、security.txt、またはメンテナンスとエラーステータスに関するタスク
references/validation-evidence.md	ステップ 5：配信ページのコマンドと証拠に関する要件
references/seo-checklist.md	ステップ 5：レポートにコピーし、各行に証拠を付記する

ワークフロー

このチェックリストをコピーして進捗を記録してください。

SEO progress:
- [ ] Step 1: Inventory routes and decide index intent per route
- [ ] Step 2: Fix crawl/index foundations (sitemap, robots, canonicals, redirects, status codes)
- [ ] Step 3: Implement metadata and structured data
- [ ] Step 4: Improve semantics, extractable answers, internal links, and Core Web Vitals
- [ ] Step 5: Validate with references/seo-checklist.md and report evidence

ステップ 1 では、ルート、インデックス登録の有無、canonical、理由をまとめた表を作成します。以降のすべてのステップでこの表を参照し、表にないルートには対応しません。

すべてのサイトで必須

• app/sitemap.ts にインデックス可能なすべての URL と、コンテンツから導出した lastModified を記載し、app/robots.ts でサイトマップを指定します
• ページごとに正規 URL を 1 つ、ホストを 1 つ、表記を 1 つ、末尾スラッシュのルールを 1 つに統一し、ルートレイアウトの metadataBase と alternates.canonical で設定します。Next.js は末尾スラッシュのルールを自動的に適用します。デフォルトでは /about/ を /about に 308 リダイレクトし、trailingSlash: true にすると逆になります（どちらの場合も、拡張子のあるファイルと .well-known/ パスは対象外です）
• 既存のプロパティ所有権の確認を維持します。metadata.verification は、トークンが提供されていて、選択した確認方法で使う場合にのみ設定します。DNS 検証では重複する meta タグは不要です
• ルートレイアウトの robots で Google のデフォルトのプレビュー上限を解除します：googleBot: { 'max-snippet': -1, 'max-image-preview': 'large', 'max-video-preview': -1 }。これを設定しないと、Google はスニペットと画像プレビューを切り詰めます。また、AI がページの引用可能な範囲を判断する際に参照するのはスニペットの上限です
• authors と creator をルートレイアウトで明示的に設定し、人物レベルの帰属情報がフッターの HTML と JSON-LD だけに依存しないようにします
• ページごとに固有のタイトルと説明を設定します。タイトルと H1 はブランド名よりも主キーワードを先に置き、意図を一致させます（カテゴリページでブランド名を先に置いたタイトルにすると、そのサイトがすでに獲得しているナビゲーションクエリだけを狙うことになります）
• すべてのページの冒頭に、そのページが答えるべき質問への短く簡潔な回答をプレーンテキストで記載し、h2 は実際にユーザーが尋ねる質問にします
• 1200x630 の画像を使った Open Graph と Twitter Card のタグ
• JSON-LD：安定した @id を持つ Organization と WebSite をルートの @graph に 1 回だけ記述し、下層ページには BreadcrumbList を配置します。さらに、コンテンツの種類に応じて Article、Product、ProfilePage、LocalBusiness を追加します。エンティティは一度だけ定義し、@id で参照します
• h1 は 1 つにし、h2 から h6 まで論理的に構成します。説明的な alt テキストを付け、関連ページ間に内部リンクを設けます
• CrUX のフィールドデータにおける p75 で、Core Web Vitals を目標値以内に収めます：LCP 2.5 秒、INP 200 ms、CLS 0.1（INP は 2024 年 3 月に FID に代わりました。今も FID と記載しているガイドは古いものです）

リダイレクトとインデックス登録ポリシー

ルートを移動する場合、重複を統合する場合、またはページのインデックス登録ポリシーを変更する場合は、references/indexing-policy.md を読み込んでください。インストールされている Next.js のバージョンと、実際に配信されるレスポンスに照らして動作を確認してください。

AI クローラーと回答エンジン

Google に特別なファイルは不要です。AI Overviews と AI Mode は Googlebot と中核的なランキングシステムで動作し、オプトアウトできるのは nosnippet または max-snippet:0 だけです（通常のスニペットも削除されます）。それ以外はすべて、クローラーの種類ごとに robots の判断が必要です。検索・引用ボット（OAI-SearchBot、Claude-SearchBot、PerplexityBot）はサイトを回答に含めますが、学習用ボット（GPTBot、ClaudeBot、CCBot）は含めません。Google-Extended と Applebot-Extended は利用目的を示すトークンであり、その背後にクローラーはありません。llms.txt はルートを 1 つ消費する一方で、測定可能な効果はほとんどありません。完全な表、robots.ts のルール、Content-Signal、Markdown 代替のパターンについては references/answer-engines.md を参照してください。

プログラマティック SEO

大規模に生成するページについては、references/indexing-policy.md を読み込んでください。新しいパターンをインデックス登録する前に、需要の根拠とページ固有の価値を必須とします。

監査のトリアージ順序

1. クロールとインデックス登録：robots、サイトマップ、紛れ込んだ noindex、canonical、リダイレクトチェーン、ソフト 404
2. 技術面：HTTPS、Core Web Vitals のフィールドデータ、モバイル版とデスクトップ版の同等性、CDN 経由の AI クローラーアクセス
3. ページ内：title と H1 の一意性および冒頭の非ブランド要素、抽出可能な回答、内部リンク、内容の薄いページ
4. 孤立ページ：内部リンクもサイトマップへの掲載もないインデックス可能なページ。クロール経路を設けるか、noindex を付けて削除します。権威性の低いドメインでは、サイト全体のフッターリンクはクロール経路になりません。Google はフッターの定型コンテンツを軽視するため、フッターからしかリンクされていないセクションは、隣接するナビゲーションリンク付きのページが毎日クロールされる一方で、数か月間「URL は Google に認識されていません」のままになることがあります

報告も同じ順序にし、まずインデックス登録を妨げる要因、次にページ内とスキーマの不足点、最後に次に行うべき修正を 1 つ記載します。同じ重みの指摘を 20 件並べても、どれも解決できません。報告の長さはセクションの一覧ではなく、判明した内容に合わせます。サードパーティの監査ツールによる指摘は、調査の手掛かりとして扱い、確定した問題とはみなしません。Next.js の出力を誤って検出するツールが複数あります（<title> が存在するのに <meta name="title"> がないと指摘する、「重複した」theme-color タグとしてライト版とダーク版を検出する、article:tag の繰り返しを指摘するなど）。また、明示的なモジュール一覧を渡さないとモジュールを黙ってスキップするエージェントスキル監査ツールや、回答が一度もレンダリングされない FAQPage を合格にするツールも少なくとも 1 つあります。報告に含める前に、各指摘を配信された HTML と照合して確認します。

注意点

• cacheComponents: true（scaffold-nextjs のデフォルト）では、dynamic、dynamicParams、revalidate、fetchCache のセグメント設定はビルドエラーになります。たとえば、app/sitemap.ts の export const revalidate、robots.txt/route.ts ハンドラーの dynamic = 'force-static'、どこであっても fetchCache が該当します（runtime、maxDuration、instant、prefetch は引き続き有効です）。コンテンツの取得処理を、cacheLife('hours') と cacheTag を指定した別の 'use cache' ヘルパーに移し、ページまたは GET から呼び出してください（ディレクティブを GET エクスポート自体に置くことはできません）。公開 webhook から revalidateTag(tag, 'max') を呼び出してください。再検証ではアプリの前段にある CDN はパージされないため、同じ webhook でパージしてください。
• generateSitemaps() は /product/sitemap/0.xml、/product/sitemap/1.xml を書き出しますが、インデックスファイルは書き出しません。生成されたファイルをそれぞれ robots.ts に列挙する（sitemap は配列を受け取ります）か、app/sitemap.xml/route.ts にインデックスを手書きしてください。そうしないと、Google が偶然見つけたファイルしか認識しません。
• サイトマップの各行に毎回 lastModified: new Date() を指定すると、デプロイのたびにサイト全体が変更されたことになります。その結果、Google はサイト全体で lastmod を無視するようになります。priority と changeFrequency は最初から無視されるため、出力しても何の利点もなく、差分を無駄に増やすだけです。
• robots.txt に Host: の行を入れないでください。Yandex は2018年にこのディレクティブを廃止し、優先ホストへの 301 リダイレクトを使うようになりました。これはすでに next.config.ts で提供されています。また、監査ツールはこの残存行を未知のディレクティブとして警告します。robots.ts の戻り値に host を含めないでください。
• Next.js は、子セグメントでキーが宣言されると、オブジェクト値のメタデータ（openGraph、twitter、robots、alternates）を丸ごと置き換えます。ディープマージはしません。ページで openGraph: { title } を追加すると、継承した siteName、images、locale が失われます。また、images: undefined も宣言として扱われます。ルートにこれらのブロックを追加するときは、親が指定したすべてのフィールドを改めて指定する必要があります。スカラー値（title、description、authors、creator）は通常どおりマージされます。
• title.template が適用されるのは <title> だけです。og:title は別の仕組みである openGraph.title.template に基づいて解決されるため、ページタイトルから手作業で付けたサフィックスを削除すると、シェアカードからプロダクト名まで誤って削除されます。両方のテンプレートをレイアウトに設定するか、どちらも設定しないでください。また、ネストされたレイアウトで文字列だけの title を指定すると、そのサブツリーの親テンプレートが null にリセットされます。代わりに { default, template } を返してください。
• ルートレイアウトで openGraph.url を設定しないでください。ページごとの値ではないため、すべてのルートがこれを継承し、すべてのシェアリンクがホームの URL に集約されます。子セグメント側で修正することもできません。openGraph を宣言すると、ブロックの残りの内容が失われるためです。誤った値より、値がないほうが適切です。利用側は取得元の URL にフォールバックし、alternates.canonical はすでにページごとに設定されます。
• Next.js 16 では middleware.ts は非推奨です。スラッグチェック、CSP nonce、Accept ネゴシエーションなど、新しいリクエスト時のロジックは、エクスポートされた proxy 関数を持つ proxy.ts に記述します。既存のファイルは npx @next/codemod@canary middleware-to-proxy . で移行できます。Proxy が使えるのは Node.js のみです。そこで runtime をエクスポートすることはできません。
• next.config.ts のリダイレクトは配列の順序で照合され、:path* はその配下すべてを捕捉します。そのため、キャッチオールより後に置かれた個別のソースは到達不能になり、単独の /old を /old/:path* より後に置くと /new/ に転送されます。Vercel ではルールの上限が1,024件です。それを超える場合は、マップを proxy.ts に移してください。
• Next は App Router の HTML レスポンスの Vary ヘッダーを管理し、RSC 用のリスト（rsc, next-router-state-tree, ...）で置き換えます。proxy.ts で NextResponse.next() に設定した Vary: Accept も、headers() で設定したものもクライアントには届きません。自分で生成する Response に設定した場合のみ維持されるため、コンテンツネゴシエーションで Markdown を返す場合は、リライトではなく直接返す必要があります。
• Suspense 境界または loading.tsx の後に notFound() を呼ぶと、404 ではなく、noindex メタタグ付きの200が返ります。Cache Components を使わない場合は、最初にサスペンドする await より前に呼び出してください。Cache Components を使う場合、ドキュメントでは、すべての動的ルートがまず静的シェルをストリーミングすると明記されているため、存在確認を proxy.ts に移す必要があります。そうしないと、存在しないページでもアナリティクスや稼働監視は正常な200として認識します。実際の404に付く noindex メタタグは global-not-found を含め Next.js が自動挿入するため、404ページに robots を追加しても何も変わりません。
• ストリーミング開始後に redirect() または permanentRedirect() を呼ぶと、307や308ではなく、200レスポンスにクライアント側の <meta> リダイレクトが出力されます。Cache Components 使用時にページ内で変更済みスラッグを処理すると、200と meta refresh が返されます。恒久的な移動は next.config.ts または Proxy で処理してください。
• HTML に制限のあるボット（Twitterbot、Bingbot、facebookexternalhit、Next のデフォルトリスト）は、プリレンダリング済みのシェルをスキップし、リクエスト時にページ全体を動的にレンダリングします。ビルド時にしか読み込まないシェルの内容（デプロイ済み関数に存在しない fs の読み取りや、ビルド時の環境変数など）は、一般ユーザーには表示されてもクローラーでは失敗することがあります。curl -A Twitterbot でこの経路を確認できます。ファイルシステムにアクセスするすべてのルートで実行してください。
• 動的な generateMetadata を使うページで curl -s <url> | rg canonical を実行すると、Next.js がボット以外のユーザーエージェント向けにメタデータをストリーミングするため、タグが <body> 内に見つかることがあります。これは Googlebot にとって有効です。ブロッキングされる <head> 形式を確認するには、-A Twitterbot を指定してください。
• nonce CSP を設定すると、すべてのページが動的になります。静的生成、ISR、プリレンダリング済みシェルは使えなくなり、Partial Prerendering も完全に非互換です。スキャナーの警告を修正するために追加すると、サイトのキャッシュが失われます。コンプライアンス要件で 'unsafe-inline' が禁止されていない限り、静的な next.config.ts ヘッダーを使ってください。
• キャッチオールの headers() ルールで Cross-Origin-Resource-Policy: same-origin を設定すると、クロスオリジンで取得するすべてのソーシャルメディアスクレイパーに対して OG 画像がブロックされます。/opengraph-image に cross-origin を設定する後続ルールを追加してください。ヘッダーキーごとに、最後に一致したルールが優先されます。
• app/opengraph-image.tsx は /opengraph-image で配信され、/opengraph-image.png ではありません。openGraph.images に拡張子をハードコードすると、マークアップは正しく見えてもカードが表示されません。basePath を設定すると、静的な app/opengraph-image.png には Next がベースパスを付加しますが、生成される .tsx ルートには付加しません。そのため、ベースパスを含む metadataBase を使うと、PNG 形式ではプレフィックスが二重になり（/glide/glide/opengraph-image.png）、生成形式では正しくなります。next dev ではなく、next build の出力から実際に出力された og:image を確認してください。next dev は metadataBase を開発用オリジンに書き換えます。
• .well-known ディスカバリーファイルのドキュメント上の配置先は、app/.well-known/<name>/route.ts のルートハンドラーです。また、trailingSlash は .well-known/ 配下をすべて例外扱いします。機能しない方法は、public/.well-known/ から配信すること（静的パイプラインでドットファイルが除外されます）と、next.config.ts のリライトを通して /.well-known/mcp.json のような単一セグメントのドット付きパスに到達することです。16.x のあるデプロイでは、2セグメントの /.well-known/mcp/server-card.json は正常にリライトされた一方、こちらはプリレンダリング済みの404が返されました。リライトが避けられない場合は、マッチャーにパスをリテラルで指定して proxy.ts で行ってください。
• Proxy のマッチャーは両端でアンカーされています。単独の /about エントリーが一致するのは /about のみで、その配下には一致しません。/writing/:slug は1セグメントに一致します。ドキュメントのマッチャーページには /about が /about/team にも一致するとありますが、16.3.0 で getMiddlewareMatchers がコンパイルする正規表現は [\/#\?]?$ で終わります。ネゴシエーション対象のパスをすべて列挙するか、:path* を使ってください。
• 静的にプリレンダリングされるルートハンドラー（sitemap.ts、robots.ts、llms.txt）はビルド時に実行され、その後はキャッシュの再検証時にのみ再実行されるため、その中のアナリティクス記録はデプロイごとに1回しか発生しません。リクエストごとの記録は、event.waitUntil() または after() の背後で proxy.ts に実装してください。また、GET ハンドラー内の try/catch はプリレンダリング中断も捕捉します。experimental.hideLogsAfterAbort: true を設定しないと、キャッシュされたすべてのハンドラーがビルド中にスタックトレースを出力します。
• next/image では、16で priority が非推奨となり、代わりに preload が導入されました。LCP ヒーローには、ドキュメントでは loading="eager" または fetchPriority="high" が推奨されており、HTML の解析完了前に読み込みを開始しなければならない画像1枚に限って preload を使います。LCP 要素はすべての <Suspense> 境界の外側または上に置き、スケルトンのサイズを置き換えるコンテンツに合わせ、フィールドデータは小さなクライアントコンポーネントから useReportWebVitals で送信してください。
• ChatGPT の回答に掲載されないように GPTBot をブロックしても、意図とは逆の結果になります。GPTBot は学習用のみで、ChatGPT 検索にページを掲載するのは OAI-SearchBot、ユーザーの質問時にライブ取得を行うのは ChatGPT-User です。ClaudeBot と Claude-SearchBot、Claude-User も同じ関係です。
• Google-Extended を拒否しても、AI Overviews からページが除外されるわけではありません。対象となるのは Gemini の学習とグラウンディングのみです。AI Overviews のオプトアウトには nosnippet または max-snippet:0 を使いますが、通常のスニペットも表示されなくなります。
• 2025年7月以降に作成された Cloudflare のゾーンでは、既知の AI クローラーはデフォルトでブロックされ、robots.txt には Cloudflare 独自の Content-Signal ブロックが先頭に追加されます。robots.ts を編集する前に、稼働中のホストに対して curl -A OAI-SearchBot を実行してください。コードが正しくても、サイトが引用できない状態のままということがあります。
• Vercel は、本番以外のブランチではカスタムドメインへの X-Robots-Tag: noindex の付与を省略します。headers() ルールで追加しないと、staging.example.com はインデックスに登録されます。
• 重複ページに noindex と本番ページへの canonical を併用すると、目的に反します。Google はインデックスしないよう指示されたページから正規化しません。重複ページには canonical のみ、プレビューには noindex のみを使ってください。
• Lighthouse の合格は、1台のデバイスで行うラボ計測です。Google が評価するのは CrUX フィールドデータの p75 であり、Lighthouse がグリーンでもフィールド評価に失敗するのはよくあります。両方を報告し、フィールドで失敗している指標を明記してください。
• 監査で Search Console のカバレッジ数、クロール統計、トラフィック数を決して捏造しないでください。修正対象が誤ったページになります。「データなし」と記載し、不足しているアクセス権限を明示してください。
• 実態のないページに構造化データ（表示される質問がない FAQPage、名前付きの著者がいない Person、レビューがない Review など）を付与すると、スパムとして扱われます。FAQPage のリッチリザルトは2026年5月7日に廃止されたため、以前はこのリスクを埋め合わせていた利点もなくなりました。JSON-LD の各記述は、配信される DOM で検証可能でなければなりません。回答が一度もレンダリングされない FAQ や、表示されるパンくずに存在しない項目を示す BreadcrumbList は、構造化データのポリシー違反です。また、回答エンジンはスクリプトではなく DOM を引用します。ソースではなく、ビルド済み HTML を確認してください。"@type":"FAQPage" の部分文字列を検索するテストでは、壊れたページも合格してしまいます。
• JSON.stringify は < をエスケープしません。Next.js の JSON-LD ガイドに従い、毎回 JSON-LD シリアライザーで \u003c エスケープに置き換えてください。フィールドに HTML が含まれる可能性を都度判断する方法では、後のコンテンツ変更がスクリプトインジェクションにつながります。
• Google の Article ドキュメントには必須フィールドがなく、publisher も任意です。指定する場合は、logo を持つ Organization にしてください。Person を publisher にすると、Rich Results Test の警告チェックで失敗します。
• インデックス可能なコンテンツを "use client" の背後に移し、useEffect で取得するようにすると、JavaScript を実行しないすべてのクローラーから見えなくなります。これにはすべての AI エージェントと、Googlebot の最初のクロールが含まれます。Server Components はすでにサーバー上でレンダリングされます。これは自分で持ち込むリグレッションです。
• 相互関係のない hreflang（一方のページに別ページへの代替指定がない場合）は、セット全体が無効になります。別の言語を指す canonical を指定すると、ローカライズされたページは除外されます。
• すべてのサブドメインが HTTPS になる前に preload 付きの Strict-Transport-Security を設定すると、実質的に元に戻せなくなります。解除がブラウザーに反映されるまで数か月かかります。まず max-age を 300、604800、2592000 と段階的に引き上げてください。
• EEA／英国からのトラフィックに対し、ad_user_data と ad_personalization の同意シグナルなしで Google Ads または GA4 のタグを配信すると、コンバージョン計測が気付かれないまま劣化します（Consent Mode v2 は2024年3月から必須です）。バナーが完璧でも、データは誤ったままです。
• 長期の停止中にメンテナンスページを200または404で配信すると、サイトがインデックスから除外されます。503と Retry-After を返してください。

関連スキル

• seo-program：キーワードとプロンプトの検索ボリューム調査、質問マップ、ライター向けブリーフ、Search Console のモニタリングを行います。ページで何を狙うべきかを決定し、このスキルはページを作成して公開内容を報告します。
• ui-design：ビジュアルの方向性とランディングページの CRO（Direction モード）、ページの構築（Build モード）、レンダリングされた i18n の動作を含むページ単位の UI 品質（Audit モード）を担当します。このスキルは hreflang とローカライズされたメタデータを管理します。
• multi-tenant-architecture：テナントごとの robots.txt、sitemap.xml、llms.txt のルーティングを担当します。これらは動的に配信する必要があり、/public から配信してはいけません。ルーティングが機能した後のコンテンツは、このスキルが管理します。
• docs-writing：ドキュメントサイトの llms.txt に掲載する内容と、Markdown 代替ページを用意する価値のあるページを決定します。このスキルはルートとクローラーのポリシーを管理し、掲載する価値のあるドキュメントは docs-writing が決定します。
• scaffold-nextjs：最初のデプロイ後、ここに引き継ぎます。デフォルトでは Cache Components が有効になり、サイトマップの再検証方法が変わります（注意点を参照）。
• copywriting：このスキルがキーワードの優先順位と長さを設定した後、メタディスクリプションとタイトルをコピーとして作成します。
• 外部の ghostwriter は blog プロファイルを使って記事を執筆します。

検証

references/validation-evidence.md にある該当するチェックを、配信中の本番ビルドに対して実行します。コマンド、結果、正確な URL、残っているブロッカーを記録します。検証リファレンスと references/seo-checklist.md はどちらもステップ 5 で読み込まれます。

メンテナンス専用：evals/evals.json には、このスキルへの変更に対する回帰シナリオが含まれます。ユーザータスクの実行時には読み込まれません。