SEOのインデックス確認、インデックス登録リクエスト、検出・反映遅延に関するよくある質問

公開したのに検索結果に出てこない。URL検査で「インデックス登録をリクエスト」を押したのに変化がない。こうした相談は珍しくありません。ここでは2025年時点のGoogle公式ガイドに整合する形で、確認方法・よくある原因・現場での対処と待ち方をFAQ形式で整理します。

基礎

Q1. インデックスと「掲載（表示）」の違いは？

インデックスは、Googleがページを収集・理解して検索用データベースに登録するプロセスです。掲載（表示）は、登録済みページが実際の検索結果にランク付けされて出現すること。インデックスは掲載の前提ですが、登録されても必ず上位表示されるわけではありません。品質・関連性・ユーザー体験などの評価が別途効きます。

Q2. Google Search Consoleでインデックス状況を確認する基本手順は？

単一URLの詳細は「URL検査」で確認し、必要ならその画面からインデックス登録をリクエストできます。操作と見え方は公式ヘルプ「URL検査ツール」に準拠してください（2025年時点のUIに追従）: URL検査とインデックス登録リクエストの公式解説。

サイト全体の傾向や除外理由の把握には、Search Console の「ページのインデックス登録」レポート（旧カバレッジ）が便利です。除外の種類ごとに件数推移と代表URLを確認できます: ページのインデックス登録レポートの公式説明。

リクエストとサイトマップ

Q3. 「インデックス登録をリクエスト」はいつ使う？効果と限界は？

重要ページを公開・大幅更新した直後など、「早めに再クロールのきっかけを与えたい」場面で使います。ただし、これは再クロールのトリガーに過ぎず、即時のインデックスや掲載を保証しません。リクエストは処理に制限があり、乱発しても効果は伸びません。内部リンク・サイトマップ・ページ品質・サーバーの安定性といった基盤が整っていてこそ、リクエストの価値が生きます。

Q4. 反映までどれくらいかかる？目安は？

数時間で反映されるケースもあれば、数週間、状況次第ではさらに長くかかることもあります。幅があるのは、サイトの信頼性・内部リンクの張り巡らせ方・重複や品質の問題・サーバー応答・レンダリングの難易度など、複数要因が絡むからです。目安に固執せず、Search Consoleの「最終クロール」「取得日時」を見つつ推移を観察しましょう。

Q5. XMLサイトマップのベストプラクティスは？

サイトマップは「発見させる」力を底上げします。基本は次の通りです（2025年時点）。

• lastmodは正確に管理し、自動更新する（クロール判断の参考になります）。
• 1ファイル上限は非圧縮で50,000 URLまたは50MB。超える場合は分割し、インデックスサイトマップで束ねる。
• changefreqとpriorityはGoogleでは参考にされません。 作成・送信の詳細は公式ガイドを参照してください: サイトマップの作成と送信（仕様・上限）。

除外理由と対処

Q6. 「検出–インデックス未登録」と「クロール済み–インデックス未登録」の違いと直し方は？

• 検出–インデックス未登録: URLは見つかっているが、まだクロールされていない状態。内部リンクを強化し、不要なURLの氾濫（無限スクロールのパラメータ、フィルタの組み合わせ）を抑え、サイトマップのlastmodを正しく更新して再発見を促します。
• クロール済み–インデックス未登録: クロールはされたが登録を見送られている状態。薄い・重複コンテンツの統合や品質改善、役割の弱い派生URLの整理（正規化・削除）を進めます。 除外の定義や代表理由は公式レポート解説が整理されています: ページのインデックス登録レポートでの各ステータス。

Q7. noindex・robots.txt・canonicalの役割の違いは？

実務で混同しやすい3要素の役割を、ひと目で比較します。

Q8. 正規URLが選ばれない／重複扱いになるのはなぜ？

canonicalは「希望」を示すシグナルで、Googleは複数シグナル（内部リンクの集中、外部リンク、コンテンツ類似度、サイトマップのURL、リダイレクト等）を総合して正規を決めます。矛盾したシグナル（例: canonicalはAを指すのに内部リンクはBに集中）があると、意図と異なるURLが採用されがちです。方針は1つに統一し、重複URLの派生を抑制しましょう。

Q9. ソフト404になったら、何を直す？

コンテンツが実質的に存在しない、あるいは品質が薄いのに200を返している場合に起こります。本当に存在しないなら404/410を適切に返し、必要なページなら本文や内部リンクを強化して「存在理由」を明確に。テンプレだけの量産や空ページは整理対象です。

技術・運用

Q10. JavaScript依存ページはインデックスされにくい？設計のコツは？

GoogleはレンダリングでJSを実行できますが、重要情報が実行後にのみ出現する構造は、発見や登録が遅れたり欠落したりするリスクがあります。重要な本文と内部リンクは、できるだけ初期HTMLで提供（SSR/SSG/ハイブリッド）。ログイン必須・クッキー前提・無限スクロール頼みの設計は検索用に代替手段を用意しましょう。

Q11. クロールバジェットとは？中規模以上で気をつける点は？

クロールバジェットは、Googleがサイトをどれだけ、どの頻度でクロールするかという配分の考え方です。大規模サイトやURL派生が多いサイトでは、重複や無限空間の抑制、内部リンクの明確化、サーバー応答の安定化が効きます。基本は「クロール需要（コンテンツの価値・更新性）」と「クロール可能量（負荷耐性）」のバランス。詳細は公式解説を参照: クロールバジェットの考え方。

Q12. Indexing APIは使うべき？対象と注意点（2025年）

Indexing APIは、短命で更新頻度の高いコンテンツ（代表例: 求人やライブ配信）を想定した仕組みです。一般的なウェブページには適用されませんし、乱用は推奨されません。対象・使い方の概要は公式のこちらを確認してください: Indexing APIの概要（対象と注意事項）。

実務の運用TIP

Q13. 新規公開や大幅更新時のチェックリストは？

1. 重要ページをサイト内の文脈に組み込む（カテゴリ、関連記事、パンくず、フッター等の内部リンク）。
2. 正確なlastmodを持つXMLサイトマップを自動更新し、Search Consoleに登録。
3. 本当に重要なURLのみ、URL検査からインデックス登録をリクエスト（連打しない）。
4. 重複・派生URL（並び替え、フィルタ、追跡パラメータ）を統制し、正規URLへ評価を集約。

Q14. どこまで待って、いつ原因調査に切り替える？

新規サイトや更新頻度の低いサイトでは、数日〜数週間の幅を見込みましょう。Search ConsoleのURL検査で「最終クロール日時」「取得（レンダリング）の可否」を確認し、進展がない場合は次の順で切り分けます。1) noindex/robots/canonicalの衝突確認、2) サイトマップのlastmod・内部リンクの見直し、3) 薄い・重複の解消、4) サーバー応答の安定化。サイト全体の品質改善が効く領域です。

Q15. よくある落とし穴は？

• robots.txtでブロックしたまま、同ページにnoindexを置く（noindexが読まれません）。
• canonicalでAを指定しつつ、内部リンクやサイトマップでBを推している（シグナル不一致）。
• サイトマップのlastmodが常に同じ、あるいは誤更新で信頼を落とす。
• JSで主要コンテンツが後出しになり、レンダリング依存で評価が遅れる。

---

参考・根拠（公式ドキュメント）

• URL検査とインデックス登録リクエスト: Google Search Console ヘルプ（URL検査）
• インデックス状況の把握: ページのインデックス登録レポート
• クロール制御: robots.txtの基本
• 重複URLの統合: rel="canonical"の原則
• サイトマップ仕様と上限: サイトマップの作成と送信
• クロール最適化: クロールバジェットの考え方
• APIの適用範囲: Indexing APIの概要

関連リソース（戦略面の読み物）

• 検索戦略の設計を俯瞰したい方へ: AIを活用したSEO戦略の立て方ガイド（QuickCreatorブログ）