SEO Technical: インデックス

インデックス関連のトラブルシューティングと修正アクションについてのガイドです。GSC での問題の見つけ方と診断については、google-search-console を参照してください。

実行時: 初回使用時 は、このスキルの説明と重要性を 1～2 文で述べた後、メイン出力を提供すると役に立つ場合があります。2回目以降の使用時 またはユーザーがスキップを要求した場合は、メイン出力に直接進んでください。

スコープ (テクニカル SEO)

• 修正アクション: noindex、canonical、コンテンツ品質、URL Inspection; robots.txt がブロックしていないことを確認 (robots-txt 参照)
• Noindex: ページレベルのインデックス制御; 除外するページと方法。robots-txt (パスレベルのクロール制御) と google-search-console (カバレッジ診断) を補完

初期評価

プロジェクトコンテキストを先に確認: .claude/project-context.md または .cursor/project-context.md が存在する場合、サイト URL とインデックス目標について読み込みます。

GSC から問題を特定し (google-search-console のカバレッジレポート、問題タイプ、診断ワークフロー参照)、下記の修正を適用します。

クロール済み - インデックス未登録

原因	アクション
低品質、重複、関連性なし	コンテンツ改善、重複修正、正しい canonical を設定
静的アセット (CSS/JS)	下記を参照
フィード、パラメータ付き共有 URL	通常は無視しても OK; または noindex、main URL への canonical
重要なコンテンツページ	URL Inspection を使用、canonical/内部リンク/sitemap を確認、インデックス登録をリクエスト

静的アセット (Next.js / Vercel)

Vercel はデプロイごとに静的アセットに一意の dpl= パラメータを追加し、多くの「クロール済み - インデックス未登録」URL を生成します。

すること	してはいけないこと
robots.txt で /_next/ を許可	/_next/ をブロックしない (CSS/JS 読み込みが壊れる)。robots-txt 参照
GSC の静的アセットを想定通りとして受け入れる	/_next/static/css/ または ?dpl= をブロックしない
X-Robots-Tag を静的アセットに使用	CSS/JS はインデックス登録されるべきではない; SEO への影響なし

静的アセットの「クロール済み - インデックス未登録」は 正常で期待通り です。

その他の問題タイプ (GSC カバレッジから)

問題	修正
「noindex」タグで除外	不注意な場合は noindex を削除; 意図的な場合は保持
robots.txt でブロック	robots-txt 参照; 重要なパスの Disallow を削除
リダイレクト / 404	URL を修正またはリダイレクトを追加
重複 / Canonical	正しい canonical を設定; 通常は OK
Soft-404	ページが 200 を返すがコンテンツが「見つかりません」または空白—Google は 404 として処理する可能性があります。修正: 実際に存在しないページは 404 ステータスを返す; または 200 ページに実際のコンテンツを追加

Soft-404

Soft-404 は、ページが HTTP 200 を返すが、コンテンツがページが存在しないことを示している場合に発生します (例: 「ページが見つかりません」メッセージ、空の状態)。Google はこれを 404 として処理し、インデックスから除外する可能性があります。

修正	対象
404 を返す	ページが実際に存在しない; 適切な 404 ステータスを使用
コンテンツを追加	ページが意図的 (例: 空の検索結果); 実質的なコンテンツを確認または noindex を使用
リダイレクト	URL が移動した場合、301 で正しい宛先にリダイレクト

Noindex の使用法

• 方法: metadata.robots = { index: false } または <meta name="robots" content="noindex"> または X-Robots-Tag
• 根拠: すべてのサイトコンテンツがインデックス登録されるべきではなく、noindex は多くのページで有効な選択肢です
• 注意: 重要なコンテンツページで noindex を避ける
• robots.txt との組み合わせ: robots.txt = パスレベルのクロール制御; noindex = ページレベルのインデックス制御。noindex ページを robots.txt でブロック しない—クローラーは noindex ディレクティブを読むためにページにアクセスする必要があります。両方を使用: /admin/、/api/ には robots.txt を、/login/、/thank-you/ などには noindex を。robots-txt でどちらを使用するかを参照してください。
• nofollow ≠ noindex: nofollow はリンクエクイティのみを制御し、インデックス登録を 妨げません。検索から除外するには、noindex を使用します。メタロボット実装については page-metadata を参照してください。

Noindex が通常必要なページタイプ

カテゴリ	ページタイプ	典型的なメタ	理由
認証・アカウント	ログイン、サインアップ、パスワードリセット、アカウントダッシュボード	ログイン: noindex,nofollow; サインアップ: noindex,follow	検索価値なし; ログインインデックス = セキュリティリスク; サインアップフォロー = プライバシー/利用規約へのクロール許可
管理・プライベート	管理、ステージング、テストページ、内部ツール	noindex,nofollow	公開用ではない; 発見を回避
コンバージョンエンドポイント	サンキューページ、確認、チェックアウト完了、ダウンロードゲート	noindex,follow	コンバージョン後; SERP 価値なし; リンクエクイティ許可
システム・ユーティリティ	404、内部検索結果、ファセット/フィルター URL	noindex,follow または noindex,nofollow	シン/重複; 404 = エラー状態
法務	プライバシー、利用規約、クッキーポリシー (オプション)	通常 noindex,follow	インデックス登録の価値低い; 混乱を削減
重複・シン	印刷フレンドリー、パラメータ URL、ほぼ重複	noindex,follow または canonical	重複コンテンツ; 可能な場合は canonical を推奨
低価値	メディアキット、フィードバックボード (外部)、シンプレス	noindex またはブランド検索用にインデックス	ケースバイケース

noindex,follow vs noindex,nofollow: ほとんどの場合 noindex,follow を使用—SERP から除外しますがリンクエクイティは許可します。ログイン (セキュリティ)、ステージング、または一時的なテストページのみに noindex,nofollow を使用します。

ページ削除決定フレームワーク

ページを Web から意図的に削除する場合、関連する代替ページが存在するかどうか、およびページがアクセス可能であるべきかどうかに基づいて方法を選択します。

シナリオ	方法	根拠
関連する置き換えページがある	301 リダイレクト	蓄積されたリンク信号とユーザーフローを保持
コンテンツが新しいページにマージされた	301 リダイレクト	古い URL を新しい canonical ロケーションに直接指向
永続的に削除、代替案なし	410 Gone	検索エンジンへの永続的な削除を明示的に通知
削除、永続的であるか不確実	404 Not Found	セーフなデフォルト; 後で必要に応じて復旧可能
アクセス可能だがインデックス登録されるべきではない	noindex	ページはユーザーに利用可能; SERP から除外

削除前に: URL の検索トラフィック、バックリンク、内部リンク、およびコンバージョン価値を確認します。ページに価値がある場合は、削除ではなく更新またはマージを検討します。

一般的な間違い:

• 関連する代替案がある重要なページを 404 にする (蓄積された信号の無駄)
• 削除されたすべてのページをホームページにリダイレクト (ユーザーの意図を破壊)
• リダイレクトチェーンを作成 (A → B → C) 直接リダイレクトの代わりに
• 削除されたページへの内部リンクをクリーンアップせずにページを削除
• noindex ページを robots.txt でブロック (クローラーは noindex ディレクティブを読むためにページにアクセスする必要があります)

削除後のクリーンアップ:

1. XML サイトマップから削除されたページを削除; 更新して再送信
2. 内部リンクを最終 URL に直接指向するよう更新 (リダイレクトに依存しない)
3. 301 リダイレクトの場合、対象 URL がサイトマップにあることを確認
4. GSC で URL Inspection を使用して重要なページを確認; 削除ツールを一時的にクイックハイドに使用 (永続的ではない — 適切な HTTP ステータスまたは noindex を使用)

Google Indexing API

タイプ	典型的な用途
JobPosting	求人サイト
BroadcastEvent	ライブプラットフォーム

要件: Indexing API を有効化、サービスアカウントを作成、Search Console でオーナーを追加、クォータをリクエスト (デフォルト 200 URLs/日)。

出力フォーマット

• アクションアイテム: 優先順位付きの修正
• 参照: Page indexing report

関連スキル

• google-search-console: GSC でインデックス問題を見つけて診断
• robots-txt: パスレベルのクロール制御; robots.txt と noindex をいつ使用するか; /_next/ または noindex ページをブロックしない
• page-metadata: メタロボット実装; noindex vs nofollow
• xml-sitemap: サイトマップの送信と保守
• indexnow: Bing での高速インデックス登録
• canonical-tag: 重複コンテンツを解決