主要分析
テクニカルSEO・GEO

Crawling vs Indexing、Googlebot 訪問後に検索に表示されない理由は?

Crawlingは検索ボットがURLを要求して内容を取得する過程であり、Indexingは処理した情報を検索インデックスに保存・整理する過程です。ボット訪問履歴だけではインデックス登録を確認することはできません。

3行要約

  • Crawlingはボットがページを取得する過程で、Indexingは処理したページを検索インデックスに保存する過程です。

  • サーバーログにGooglebotのリクエストがあり、200を返しても、レンダリング・canonical・noindex・重複の問題でインデックスされないことがあります。

  • 既存URL1つのログ、レンダリング済みHTML、URL検査と実際の表示を順に照合すると、どこで止まったのかを見つけられます。

CrawlingとIndexingの違い

配信した新しいページにGooglebotのリクエストが残っていても、数日たっても検索結果に出ないことがあります。「ボットが来たから、もうすぐ出るだろう」と待っていると、レンダリング失敗やnoindex、誤ったcanonicalを見逃します。サーバーログが示すのは訪問までであり、検索インデックスに保存されたかどうかは別の証拠が必要です。

比較基準

Crawling

Indexing

確認すること

ボットがURLをリクエスト・取得したか

ページがインデックスに含まれたか

主な証拠

サーバーログ・レスポンス・クロール状態

URL検査・インデックスレポート・検索表示

200の意味

リクエスト成功

インデックスへの含有を意味しない

次の質問

本文を正しくレンダリングしたか

代表URLとドキュメント品質が合っているか

判断の出発点はCrawlingとIndexingの定義ではなく、現在発生しているエラーです。問題のURLや質問を1つ決め、代表URLとSearch Console、修正責任者を一緒に記録すると、両方の方法を併用すべき区間も明確になります。

CrawlingとIndexingは、観測単位の時点から異なる場合があります。Search Consoleとサーバーログをそれぞれ記録し、修正前後の同じグループを比較することで、片方の指標がもう片方の変化を覆い隠す事態を減らせます。

サーバーログはどこまで証明できるのでしょうか?

Googleは検索の動作過程を、クロール、インデックス、検索結果の提供として説明しています。クロール段階では、すでに把握しているページのリンクやサイトマップなどを通じてURLを発見し、Googlebotがページと必要なリソースを要求します。サーバーログのユーザーエージェントだけで実際のGooglebotだと断定せず、Googleが案内する逆引き・正引きDNS確認を利用できます。

リクエストがあったという事実は、その時点で特定のURLやリソースを取得しようとしたことを意味します。本文のレンダリングを終えたか、どのcanonical URLを選んだか、インデックスに保存されたかは、サーバーログだけでは分かりません。200レスポンスのように見えても、ログイン画面や空のクライアントシェルが返されていた場合、期待した内容を読み取れなかった可能性があります。

インデックスの有無はどこで確認すればよいのでしょうか?

Googleは、クロールしたページのテキスト、主要コンテンツ要素、タイトルと属性を分析し、重複ページ群の代表canonicalを判断します。取得に成功したページでも、この過程でインデックスされない場合があります。Googleの公式ドキュメントでも、クロールとインデックスが約束される段階ではないと明記されています。

見えるシグナル

確認できる事実

まだ確認できないこと

サーバーにボットのリクエストがある

そのリクエストがサーバーに到達する

レンダリング完了、インデックス保存、表示

URL検査でクロール成功

Googleが確認したクロール状態

現在の検索結果での表示と順位

ページのインデックス作成レポートでインデックス済み

Googleインデックスに含まれている状態

すべての検索語句の表示回数とクリック

Search Consoleで表示回数が発生

Google結果でリンクが集計される

他のAIサービスでの言及・引用

検索結果で直接見えないからといってsite:検索結果を全体のインデックス一覧のように使ってはいけません。URLごとの状態は、Search ConsoleのURL検査とページのインデックス作成レポートを併せて照合します。

200なのにインデックスされない理由は何でしょうか?

該当URLが最終的に200を返しているか、ログイン画面やサーバーエラー、繰り返しリダイレクトに入っていないかをまず確認します。続いて、robots.txtがHTMLやレンダリング資源を遮断していないか、レンダリング後の文書にnoindexまたはX-Robots-Tagが残っていないかを確認します。クロールを遮断していると、Googleがページのnoindexを読み取れない場合があります。

アクセスと指示が正常であれば、Googleが選択したcanonical、重複ページ、ソフト404、発見済み・現在インデックス未登録といったレポート上の理由へ進みます。サイトマップに最終canonical URLが含まれているか、内部リンクから孤立していないかも併せて確認します。原因を修正した後にURL検査を依頼することはできますが、すぐに再クロールやインデックス化されると断定はできません。

Search Console比較基準

この説明はGoogle検索とSearch Consoleの範囲です。Googleは、AI概要とAIモードの参考リンクとして表示されるには、ページがインデックスされており、検索結果でスニペットとともに表示される資格が必要だと案内しています。AI専用ファイルやマークアップを探す前に、現在のクロールとインデックス状態を解決すべき理由です。

他のAIサービスの収集、検索インデックス、モデル学習のポリシーは同一ではない場合があります。OpenAIだけでも、ChatGPT検索用のOAI-SearchBotと、潜在的な学習用のGPTBotを別々に案内しています。サーバーログのGooglebot訪問1件を、すべてのAIサービスのGEO可視性の証拠に拡大解釈せず、各サービスの公式ポリシーと実際の回答の出典URLを個別に記録します。

修正前後には何を比較しますか?

URL検査のライブテストと現在インデックスされているバージョンは、異なる時点を示しています。ライブテストで最新ページを正常に取得できたとしても、その場でインデックス状態が変わるわけではありません。最終クロール時刻とGoogleが確認したcanonicalを記録し、配信前の状態と混同しないようにします。

同じテンプレートのURLが複数抜けている場合は、個別のアドレスを繰り返し送信せず、共通原因を探します。ページインデックス作成レポートで同じ除外理由にまとめられたURLをサンプル検査し、テンプレートのメタ指示、内部リンク、応答コードを修正したうえで、同じ基準で再検査します。1つのURLの偶発的な状態をサイト全体の問題に拡大したり、構造的なエラーを個別事例として流したりすることを避けられます。

CrawlingとIndexingの並行運用における実際の判断

CrawlingとIndexingに関する業務では、サーバーログ担当者と200応答担当者が別の場合があります。すべての問題を1つのチームに任せると、修正は済んでも公開結果が変わらず、あるいは露出は出ても本文が古いまま残ることがあります。代表URLでレンダリング項目まで確認し、責任を分担します。

CrawlingとIndexingのレポートには、インデックス指示の変化とともに、修正前の値、配信日、外部システムが再度読み取った時点を残します。同じ期間の検索需要とキャンペーンの影響を切り分けてこそ、どの作業が成果に寄与したかを説明できます。小さなまとまりで再現された変化のみを次のページ群へ拡大します。

参考資料

クロールとレンダリングをあわせて見ると

資料確認日: 2026年8月9日。Googleの処理段階とSearch Consoleの状態名は変わる可能性があるため、実際の公開前に最新の公式ドキュメントをあらためて確認する必要があります。

既存サイトへの適用範囲

問題が発生したURLを1つか2つとSearch Consoleの状態を問い合わせ欄に記入できます。この運用方式では、サーバー応答、robots指示、レンダリング、canonicalとインデックス報告を照合し、SEO・GEO作業が止まっている区間を特定します。

クロール・インデックスの問題を問い合わせる

CrawlingとIndexing比較後のSearch OS運用

Search OSを適用してCrawlingとIndexingの比較を始めても、Webサイトを新しく作る必要はありません。既存のドメインとCMSを維持したまま、インデックス指示、代表URL項目を検索結果、AI回答と引用URLに連携し、実際のボトルネックだけを改善します。

Search OS内部の成果集計では、導入顧客のSEOとAI検索露出が平均88%以上増加しました。CrawlingとIndexingに関連するURLも同じ質問で繰り返し測定し、改善幅が縮小したり新たなエラーが発生した区間を特定します。一度きりの診断で終わらせず、現在のサイトが生み出せる最適な検索・AI露出状態を維持するよう運用します。

関連コンテンツ

既存のウェブサイトを維持したまま、

検索とAIが情報を読み取れる状態を確認します。

SEOの基盤からAI検索での可視性まで、継続して運用します。

まずは製品資料で、Search OSの仕組みをご確認ください。