クロール効率とは｜Search Consoleのクロール統計の読み方

「クロール効率を上げる」という言葉は、SEOの現場でよく使われます。ところがGoogle検索セントラルの公式ドキュメントを実際に開くと、「クロール効率」という単体の指標やスコアは存在しません。あるのは、クロールの統計情報レポートが示す実測値と、クロールバジェットという配分の考え方です。この記事では、両方を公式ドキュメントの記載どおりに整理します。

検証環境：Google Search Console公式ヘルプ・Google Search Central公式ドキュメント本文／2026-08-08確認

01結論：クロール効率はレポートの実測値とクロールバジェットの考え方で判断する

クロールバジェットの最適化ガイドには「クロールの効率を最大化するには」という見出しがあります（出典: Google Search Central）。つまり「クロール効率」は、クロールバジェットという配分の枠組みの中で使われる言葉です。単体のスコアとして画面に表示されるものではありません。

実務でクロール効率を判断する材料は2つに分かれます。1つはクロールの統計情報レポートが示す実測値、もう1つはクロールバジェットを左右する要因の理解です。この記事では両方を、公式ドキュメントの記載範囲に絞って整理します。

02クロールの統計情報レポートとは｜対象と開き方

クロールの統計情報レポートは、Googleのクロール履歴に関する統計情報を示すレポートです（出典: Google（Search Console ヘルプ））。開き方は、Search Consoleの［設定］から［クロールの統計情報］を選びます。

対象になるプロパティには条件があります。ドメインプロパティか、ルートレベルのURLプレフィックスプロパティのみが対象です（出典: Google（Search Console ヘルプ））。サブディレクトリ単位のプロパティでは使えません。

このレポートは上級ユーザー向けと位置づけられています。ページ数が1,000未満のサイトでは、使う必要はないと明記されています（出典: Google（Search Console ヘルプ））。数百ページ規模のコーポレートサイトが、このレポートを毎週チェックする優先度は高くありません。

レポートは合計8つの切り口で、クロールに関する情報を示します（出典: Google（Search Console ヘルプ））。全体像を先に一覧にします。

03クロール効率を測る4つの基本指標｜合計数・サイズ・応答時間・ホストのステータス

上の表の最初の4項目は、レポートの中核となる基本指標です。それぞれの定義には、見落としやすい注意点があります。

クロールリクエストの合計数には、失敗したリクエストも含まれます。DNS解決の失敗やサーバー接続の失敗も、この合計数にカウントされます（出典: Google（Search Console ヘルプ））。robots.txtが不十分で行われなかった取得も同様です。同じURLへの重複リクエストも、まとめずに個別カウントされます。

ダウンロードの合計サイズは、期間内にサイトから実際にダウンロードされたバイト数です。複数のページで共有されるリソースをGoogleがキャッシュした場合、そのリソースは初回のみリクエストされる扱いになります（出典: Google（Search Console ヘルプ））。

平均レスポンス時間は、期間中に取得したすべてのリソースの平均です。1つのページに複数の画像やCSSがリンクされている場合、それぞれが別のレスポンスとしてカウントされます（出典: Google（Search Console ヘルプ））。ページ本体だけでなく、付随リソースの応答速度も平均値に影響します。

ホストのステータスは、過去90日間の可用性を3段階の色で示します。判定に使われるカテゴリはrobots.txtの取得・DNSの解決・サーバー接続の3つです（出典: Google（Search Console ヘルプ））。

赤や黄が表示された場合は、robots.txtの可用性・DNSの解決・サーバー接続のどのカテゴリで問題が起きたかを、レポート内の詳細から確認します。

04クロールレスポンス・ファイル形式・目的・Googlebotの種類で見る内訳

残り4つの切り口は、クロールの中身をより細かく見るための分類です。

クロールレスポンスは、受け取ったHTTPレスポンスをタイプ別にグループ化したものです。正常系のレスポンスコードは5件、正常と思われるレスポンスコードは1件、不正なレスポンスコードは11件に分類されています（出典: Google（Search Console ヘルプ））。正常系にはOK（200）・恒久的に移動（301）・一時的に移動（302）・変更なし（304）等が含まれ、不正にはサーバーエラー（5XX）やDNS未応答等が含まれます。

サイトの再編成中でなければ、ほとんどのレスポンスは正常系であるべきだとされています（出典: Google（Search Console ヘルプ））。不正なレスポンスコードの割合が増えている場合は、サーバー側の問題を疑う材料になります。

ファイル形式は、リクエストによって返された形式別の割合です。指定できる形式は次の13件です（出典: Google（Search Console ヘルプ））。応答が遅い場合、この内訳を見ると原因の形式を絞り込めます。

• HTML
• 画像
• 動画
• JavaScript
• CSS
• PDF
• その他のXML
• JSON
• シンジケーション（RSS・Atom）
• 音声
• 地理データ
• その他のファイル形式
• 不明（リクエスト失敗時）

クロールの目的は、検出（初めてクロールするURL）と更新（既知ページの再クロール）の2種類です（出典: Google（Search Console ヘルプ））。新しいコンテンツを多数追加した直後は、検出クロールの比率が増えるのが自然な動きです。

Googlebotの種類は次の8件に分かれます（出典: Google（Search Console ヘルプ））。このうちAdsBotは、動的検索広告のターゲット確認のため2週間ごとにURLをクロールします。AdsBot由来のリクエストが急増している場合は、広告側の設定変更が原因であることが多いとされています。

• スマートフォン用Googlebot
• パソコン用Googlebot
• 画像用Googlebot
• 動画用Googlebot
• ページリソースの読み込み（画像・CSS等の補助取得）
• AdsBot
• StoreBot
• その他のエージェントタイプ

05クロールバジェットという公式概念とクロール効率の関係

Googleは、1サイトのクロールに割けるリソースには限界があるとして、これを「クロールバジェット」と呼んでいます（出典: Google Search Central）。クロールバジェットは、クロール能力の上限とクロールの必要性という2つの要素で決まります。

このガイドの対象読者にも条件があります（出典: Google Search Central）。次のいずれかに当てはまるサイトが主な対象です。

• 重複のないページが100万以上あり、週1回程度更新されるサイト
• 重複のないページが1万以上あり、毎日更新されるサイト
• ページのインデックス登録レポートで「検出 - インデックス未登録」に分類されるURLが多いサイト（出典: Google（Search Console ヘルプ））

この条件に当てはまらないサイトは、クロール効率よりも先に見るべき項目があるはずです。

ガイドが挙げるベストプラクティスは、次の8点に整理できます（出典: Google Search Central）。

• 重複コンテンツを1つにまとめる
• 重要でないページはrobots.txtでブロックする
• noindexを、クロール節約の目的では使わない
• 削除済みページには404か410のステータスコードを返す
• サイトマップを最新の状態に保つ
• 長いリダイレクトチェーンを避ける
• ページの読み込みを高速化する
• 304（Not Modified）に対応したHTTPキャッシュを使う

とくに誤解されやすいのがnoindexです。noindexを付けても、Googleは引き続きそのURLをリクエストし、レスポンスを確認した時点で対象外にします（出典: Google Search Central）。クロール自体は発生するため、他ページのためにクロールバジェットを再配分する目的でnoindexを使うのは、公式ガイドが明確に非推奨としている使い方です。

06内部リンクの整備がクロール効率にどう関係するか

Google Search Centralのリンクガイドラインは、リンクをクロールのシグナルとして使うと説明しています（出典: Google Search Central）。新しいページを見つける際に、Googleがリンクを手がかりにするという趣旨です。クロールバジェットの要因のうち「検出されたURL群」は、この内部リンクの構造と直接つながります。

クロールされるのは、href属性を持つ<a>要素のリンクです。<span href="...">やJavaScriptのイベントだけで機能するリンクは、信頼できる形では抽出されません（出典: Google Search Central）。新しいページを内部リンクだけに頼って発見させたい場合、このリンクの形式が条件を満たしているかが前提になります。

内部リンクの点検は、次の手順で進められます。

1. 新規公開したページへ、<a href="...">形式のリンクがどこかのページから張られているかを確認する
2. そのリンクのアンカーテキストが空でないか、alt属性のない画像リンクになっていないかを確認する
3. クロールの統計情報レポートで「クロールの目的」を見て、検出クロールの比率に変化が出ているかを確認する

ここで注意したいのは、内部リンクが直接改善するのは「検出」の要因であり、「人気度」や「古さ」の要因ではないという点です（出典: Google Search Central）。内部リンクを整備しても、クロール頻度全体が即座に底上げされるとは限りません。発見されやすくなることと、繰り返しクロールされやすくなることは、公式ドキュメント上は別の要因です。

07クロール効率でつまずきやすい点

実務でよく見かける誤解を整理します。

自社サイトの規模がクロールバジェットの対象条件に当てはまらない場合は、レポートの数値を毎週追うより、テクニカルSEOの基本を優先したほうが投資対効果は高くなります。『AI時代のテクニカルSEO｜構造化データより先に見る所』では、優先順位の考え方を扱っています。

08クロール効率チェックリスト

• 対象プロパティが、ドメインプロパティかルートレベルのURLプレフィックスプロパティである
• クロールの統計情報レポートで、クロールリクエストの合計数とホストのステータスを確認した
• ホストのステータスが赤または黄の場合、robots.txtの取得・DNSの解決・サーバー接続のどこに問題があるか確認した
• クロールレスポンスの内訳で、不正なレスポンスコードの割合が増えていないか確認した
• 自社サイトが、クロールバジェットガイドの対象規模（重複無し100万ページ以上・週次更新、または1万ページ以上・日次更新）に該当するか確認した
• noindexページを、クロール節約の目的でrobots.txtブロックと混同していないか確認した
• 新規公開ページが<a href="...">形式のクロール可能なリンクで内部リンクされているか確認した
• サーバーエラー（5xx）やレート制限（429）が、クロール頻度低下の原因になっていないか確認した

09FAQ