「クロール効率を上げましょう」。提案書やレポートで、この一文を見たことがある方は多いと思います。読むほうも書くほうも、なんとなく意味は分かる。ただ、では画面のどこを見ればその効率が分かるのかと聞かれると、急に答えに詰まります。
詰まって当然です。Google検索セントラルの公式ドキュメントを実際に開いても、「クロール効率」という単体の指標やスコアは出てきません。あるのは、クロールの統計情報レポートが示す実測値と、クロールバジェットという配分の考え方だけです。
この記事では、その2つを公式ドキュメントの記載どおりに並べ直します。数字を読む前に、その数字が何を数えているのかを確かめるための記事です。自社サイトがそもそもこのレポートを追うべき規模なのか、という手前の判断にも触れます。
こんなふうに調べていませんか
- 「クロール効率 Search Console」で検索して、どの画面を見ればいいのか探している
- レポートに「クロール効率の改善」と書いたが、根拠として何を出せばいいか分からない
この記事を読み終えたときに手に入るもの
- クロール効率が単体のスコアではないことを、根拠つきで説明できるようになります
- クロールの統計情報レポートの8つの切り口を、目的別に読み分けられるようになります
- 自社サイトがレポートを追うべき規模かどうかを、条件で判断できるようになります
結論30秒でわかる、この記事の結論
- 「クロール効率」という単体の指標やスコアは、Search Consoleの画面には存在しません。
- 実務で使えるのは、クロールの統計情報レポートの実測値と、クロールバジェットという配分の考え方の2つだけです。
- そのどちらも、対象になるサイトの規模に条件があります。条件に当てはまらないサイトは、先に見るべき項目があります。
検証環境：Google Search Console公式ヘルプ・Google Search Central公式ドキュメント本文／2026-08-08確認
この記事にも、社内でよく出る問いを3人に代弁してもらいます。用語からつまずく若葉さん、運用の手間を気にする高梨課長、投資の判断を求める大森部長。答える側は鈴木さんです。
01クロール効率とは、Search Consoleで見えるSEO指標のことですか？
若葉さん「クロール効率」って、Search Consoleのどこかに数字で出ているものなんですか。
鈴木さんそれが、出ていないんです。言葉としては公式にありますが、スコアとしては無い。 ここが最初のつまずきどころですね。
クロールバジェットの最適化ガイドには「クロールの効率を最大化するには」という見出しがあります（出典: Google Search Central）。つまり「クロール効率」は、クロールバジェットという配分の枠組みの中で使われる言葉です。単体のスコアとして画面に表示されるものではありません。
ここを取り違えると、社内報告の書き方が変わってしまいます。「クロール効率が◯点に改善しました」とは書けません。書けるのは、レポートに出ている実測値の変化と、その変化をどう解釈したかです。
実務でクロール効率を判断する材料は2つに分かれます。1つはクロールの統計情報レポートが示す実測値、もう1つはクロールバジェットを左右する要因の理解です。この記事では両方を、公式ドキュメントの記載範囲に絞って整理します。
この章のまとめ
単体のスコアは存在しない。実測値と配分の考え方、この2つを組み合わせて判断する。
02Search Consoleのクロール統計は、どのSEO担当が開くレポートですか？
クロールの統計情報レポートは、Googleのクロール履歴に関する統計情報を示すレポートです（出典: Google（Search Console ヘルプ））。開き方は、Search Consoleの［設定］から［クロールの統計情報］を選びます。
まず、開ける人と開けない人がいます。対象になるプロパティには条件があり、ドメインプロパティか、ルートレベルのURLプレフィックスプロパティのみが対象です（出典: Google（Search Console ヘルプ））。サブディレクトリ単位のプロパティでは使えません。
そして、開ける人が全員見るべきものでもありません。このレポートは上級ユーザー向けと位置づけられており、ページ数が1,000未満のサイトでは使う必要はないと明記されています（出典: Google（Search Console ヘルプ））。数百ページ規模のコーポレートサイトが、このレポートを毎週チェックする優先度は高くありません。
この章のまとめ
対象はドメイン単位かルート単位のプロパティ。小規模サイトでは、そもそも使う必要がないとされている。
03Search Consoleのクロール統計は、SEOで見る8つの切り口をどう並べますか？
レポートは合計8つの切り口で、クロールに関する情報を示します（出典: Google（Search Console ヘルプ））。全体像を先に一覧にします。
| 切り口 | 何を示すか |
|---|---|
| クロール リクエストの合計数 | 成功・失敗を問わない、サイトURLへの総リクエスト数 |
| ダウンロードの合計サイズ | クロール中にサイトからダウンロードされた総バイト数 |
| 平均レスポンス時間 | サイトから取得した全リソースの平均応答時間 |
| ホストのステータス | 可用性に関する問題の有無を3段階で示す指標 |
| クロール レスポンス | 受け取ったHTTPレスポンスの種類別割合 |
| ファイル形式 | クロールされたリソースの形式別割合 |
| クロールの目的 | 新規URLの発見か、既知ページの再クロールか |
| Googlebotの種類 | クロールに使われたユーザーエージェントの種類 |
並べ方にコツがあります。上の4つは「いま全体がどんな様子か」をつかむための切り口、下の4つは「その様子の中身を割る」ための切り口です。異常に気づくのが上の4つ、原因を絞るのが下の4つ、と覚えると迷いません。
この章のまとめ
8つの切り口は、様子をつかむ4つと、中身を割る4つに分かれる。上で気づき、下で絞る。
04クロール効率の基本指標は、Search ConsoleでSEO上どう読むんですか？
上の表の最初の4項目は、レポートの中核となる基本指標です。それぞれの定義には、見落としやすい注意点があります。
クロールリクエストの合計数には、失敗したリクエストも含まれます。 DNS解決の失敗やサーバー接続の失敗も、この合計数にカウントされます（出典: Google（Search Console ヘルプ））。robots.txtが不十分で行われなかった取得も同様です。同じURLへの重複リクエストも、まとめずに個別カウントされます。
つまりこの数字は「うまくいった回数」ではありません。声をかけられた回数です。増えたから良い、減ったから悪い、とは読めません。
ダウンロードの合計サイズは、期間内にサイトから実際にダウンロードされたバイト数です。複数のページで共有されるリソースをGoogleがキャッシュした場合、そのリソースは初回のみリクエストされる扱いになります（出典: Google（Search Console ヘルプ））。
平均レスポンス時間は、期間中に取得したすべてのリソースの平均です。1つのページに複数の画像やCSSがリンクされている場合、それぞれが別のレスポンスとしてカウントされます（出典: Google（Search Console ヘルプ））。ページ本体だけでなく、付随リソースの応答速度も平均値に影響します。
高梨課長平均が遅いと出たら、ページの表示速度を直せばいいということですか。
鈴木さんそこが早合点になりやすいところです。平均には画像やCSSも入っています。 本体だけを直しても数字が動かないことがあります。
この章のまとめ
合計数は成否を問わない回数。平均応答時間は付随リソースも含む平均。定義を読まずに増減を語らない。
05ホストのステータスが赤いとき、SEOでは何を疑えばいいんですか？
ホストのステータスは、過去90日間の可用性を3段階の色で示します。判定に使われるカテゴリはrobots.txtの取得・DNSの解決・サーバー接続の3つです（出典: Google（Search Console ヘルプ））。
| ステータス | 意味 |
|---|---|
| 緑 | 過去90日間、クロールの可用性に重大な問題は発生していない |
| 黄 | 過去90日間に問題が1件以上あったが、発生は1週間以上前 |
| 赤 | 過去1週間以内に、重大な可用性の問題が1件以上発生した |
色は結果であって、原因ではありません。赤や黄が表示された場合は、robots.txtの可用性・DNSの解決・サーバー接続のどのカテゴリで問題が起きたかを、レポート内の詳細から確認します。
赤と黄の違いは、深刻さではなく近さです。赤は直近に起きたこと、黄は過去に起きたこと。だから赤のほうが対応の優先度が高くなります。
この章のまとめ
色は3つのカテゴリの判定結果。赤と黄の差は深刻さではなく、いつ起きたかの近さ。
06クロールレスポンスの内訳は、SEOのどこを直すサインですか？
ここからは、中身を割る側の切り口です。
クロールレスポンスは、受け取ったHTTPレスポンスをタイプ別にグループ化したものです。正常系のレスポンスコードは5件、正常と思われるレスポンスコードは1件、不正なレスポンスコードは11件に分類されています（出典: Google（Search Console ヘルプ））。正常系にはOK（200）・恒久的に移動（301）・一時的に移動（302）・変更なし（304）等が含まれ、不正にはサーバーエラー（5XX）やDNS未応答等が含まれます。
サイトの再編成中でなければ、ほとんどのレスポンスは正常系であるべきだとされています（出典: Google（Search Console ヘルプ））。不正なレスポンスコードの割合が増えている場合は、サーバー側の問題を疑う材料になります。
読むときは、絶対数ではなく割合の推移を見てください。サイトの規模が変われば絶対数も変わりますが、割合の傾きは規模に左右されにくい指標です。
この章のまとめ
正常系が大半であるのが通常の姿。不正の割合が増えたら、サーバー側を疑う材料として扱う。
07ファイル形式とGooglebotの種類は、AI検索のクローラーとどう関わりますか？
ファイル形式は、リクエストによって返された形式別の割合です。指定できる形式は次の13件です（出典: Google（Search Console ヘルプ））。応答が遅い場合、この内訳を見ると原因の形式を絞り込めます。
- HTML
- 画像
- 動画
- JavaScript
- CSS
- その他のXML
- JSON
- シンジケーション（RSS・Atom）
- 音声
- 地理データ
- その他のファイル形式
- 不明（リクエスト失敗時）
クロールの目的は、検出（初めてクロールするURL）と更新（既知ページの再クロール）の2種類です（出典: Google（Search Console ヘルプ））。新しいコンテンツを多数追加した直後は、検出クロールの比率が増えるのが自然な動きです。
Googlebotの種類は次の8件に分かれます（出典: Google（Search Console ヘルプ））。
- スマートフォン用Googlebot
- パソコン用Googlebot
- 画像用Googlebot
- 動画用Googlebot
- ページリソースの読み込み（画像・CSS等の補助取得）
- AdsBot
- StoreBot
- その他のエージェントタイプ
このうちAdsBotは、動的検索広告のターゲット確認のため2週間ごとにURLをクロールします。AdsBot由来のリクエストが急増している場合は、広告側の設定変更が原因であることが多いとされています。
ここでAI検索の話に触れておきます。AI専用クローラーのUser-agentも、クロール能力の上限を他のクローラーと共有します。許可・拒否の設定がクロールバジェットと無関係だ、とは言えません。 AI検索向けのクローラーを増やせば、その分だけ同じ枠を分け合う相手が増えます。
大森部長AI検索のクローラーを許可すると、通常のクロールが痩せるということかね。
鈴木さん同じ枠を共有するという点はそうです。ただ、痩せる量を数字で示せる一次情報は確認できていません。心配の種としては持っておく、断定はしないという扱いにしています。
この章のまとめ
形式と種類の内訳は原因を絞る道具。AI専用クローラーも同じクロール能力の枠を共有する。
08クロールバジェットとは、SEOで言うクロール効率と何が違うんですか？
ここから、もう一方の材料である配分の考え方に移ります。
Googleは、1サイトのクロールに割けるリソースには限界があるとして、これを「クロールバジェット」と呼んでいます（出典: Google Search Central）。クロールバジェットは、クロール能力の上限とクロールの必要性という2つの要素で決まります。
| 要素 | 何で決まるか |
|---|---|
| クロール能力の上限 | サーバーの応答状態（安定していれば上がり、エラーやレート制限が出れば下がる）、Google側のリソース配分 |
| クロールの必要性 | 検出されたURL群の量、ページの人気度、コンテンツの古さ |
この2つは、片方だけを整えても効きません。サーバーを速くしても求められていなければ回ってきませんし、求められていてもサーバーが不安定なら回ってこられません。掛け算に近い関係だと考えてください。
クロール効率という言葉は、この枠組みの中で「限られた配分をどう使い切るか」を指しています。だから効率という言葉が出てきたら、まず配分の話をしているのだと読み替えると、議論がずれません。
この章のまとめ
クロールバジェットは能力の上限と必要性の掛け合わせ。効率は、その配分の使い方を指す言葉。
09うちのサイトは、クロール効率をSearch ConsoleでSEO的に追う規模ですか？
このガイドの対象読者にも条件があります（出典: Google Search Central）。次のいずれかに当てはまるサイトが主な対象です。
- 重複のないページが100万以上あり、週1回程度更新されるサイト
- 重複のないページが1万以上あり、毎日更新されるサイト
- ページのインデックス登録レポートで「検出 - インデックス未登録」に分類されるURLが多いサイト（出典: Google（Search Console ヘルプ））
この条件に当てはまらないサイトは、クロール効率よりも先に見るべき項目があるはずです。
高梨課長うちは条件に当てはまりません。それでも定例に入れておいたほうが安心ではありませんか。
鈴木さん安心のために枠を取ると、見るべき項目に使う時間がその分だけ減ります。 条件に当てはまらないうちは、見送るのも判断です。
この章のまとめ
対象は大規模・高頻度更新のサイト。条件に当てはまらないなら、追わないことも正しい判断。
10クロールバジェットのベストプラクティスは、SEOで何から手をつけますか？
ガイドが挙げるベストプラクティスは、次の8点に整理できます（出典: Google Search Central）。
- 重複コンテンツを1つにまとめる
- 重要でないページはrobots.txtでブロックする
- noindexを、クロール節約の目的では使わない
- 削除済みページには404か410のステータスコードを返す
- サイトマップを最新の状態に保つ
- 長いリダイレクトチェーンを避ける
- ページの読み込みを高速化する
- 304（Not Modified）に対応したHTTPキャッシュを使う
並べ替えると、性格が3つに分かれます。無駄な取得そのものを減らすもの、通り道を整えるもの、応答を軽くするもの。この順に手をつけると、後の施策の効きが良くなります。
この章のまとめ
8点は、無駄を減らす・通り道を整える・応答を軽くするの3種類。下から順に着手する。
11noindexを使えばクロール効率は節約できるというSEOの誤解は本当ですか？
とくに誤解されやすいのがnoindexです。
noindexを付けても、Googleは引き続きそのURLをリクエストし、レスポンスを確認した時点で対象外にします（出典: Google Search Central）。クロール自体は発生するため、他ページのためにクロールバジェットを再配分する目的でnoindexを使うのは、公式ガイドが明確に非推奨としている使い方です。
言い換えると、noindexは「見たあとで棚に載せない」指定であり、「見に来なくていい」という指定ではありません。見に来させたくないなら、robots.txtでのブロックが対象になります。
若葉さん検索結果に出したくないページには、とりあえずnoindexを付けていました。
鈴木さん目的が「出したくない」ならそれで合っています。目的が「見に来させたくない」なら、道具が違うというだけです。
この章のまとめ
noindexは棚に載せない指定。クロール自体は起きるので、節約を目的に使わない。
12内部リンクの整備は、クロール効率とSEOのどこに効くんですか？
Google Search Centralのリンクガイドラインは、リンクをクロールのシグナルとして使うと説明しています（出典: Google Search Central）。新しいページを見つける際に、Googleがリンクを手がかりにするという趣旨です。クロールバジェットの要因のうち「検出されたURL群」は、この内部リンクの構造と直接つながります。
ただし、リンクなら何でもよいわけではありません。クロールされるのは、href属性を持つ<a>要素のリンクです。<span href="...">やJavaScriptのイベントだけで機能するリンクは、信頼できる形では抽出されません（出典: Google Search Central）。新しいページを内部リンクだけに頼って発見させたい場合、このリンクの形式が条件を満たしているかが前提になります。
内部リンクの点検は、次の手順で進められます。
- 新規公開したページへ、
<a href="...">形式のリンクがどこかのページから張られているかを確認する - そのリンクのアンカーテキストが空でないか、
alt属性のない画像リンクになっていないかを確認する - クロールの統計情報レポートで「クロールの目的」を見て、検出クロールの比率に変化が出ているかを確認する
この章のまとめ
内部リンクは検出の手がかり。ただし通れる形式でなければ、手がかりとして数えられない。
13内部リンクを増やせば、クロール効率はSEO的にすぐ上がるんですか？
ここで注意したいのは、内部リンクが直接改善するのは「検出」の要因であり、「人気度」や「古さ」の要因ではないという点です（出典: Google Search Central）。
内部リンクを整備しても、クロール頻度全体が即座に底上げされるとは限りません。発見されやすくなることと、繰り返しクロールされやすくなることは、公式ドキュメント上は別の要因です。
社内で説明するときは、「見つけてもらいやすくする施策です」と範囲を限って伝えてください。頻度まで約束すると、あとで説明がつかなくなります。
この章のまとめ
内部リンクが効くのは検出の要因まで。人気度や古さの要因には直接効かない。
14クロール効率とSearch Consoleの読み方で、AI検索の時代につまずくのはどこですか？
実務でよく見かける誤解を整理します。
| よくある誤解 | 正しい理解 |
|---|---|
| クロールリクエスト数は多いほど良い | 多すぎるクロールはサーバー負荷を高める。目安を超えた場合はクロール頻度の抑制を検討する対象になる |
| noindexを使えばクロールバジェットを節約できる | Googleは引き続きそのURLをリクエストする。節約にはrobots.txtによるブロックが必要 |
| ページ数が少なくてもクロールの統計情報レポートは毎回見るべきだ | 1,000ページ未満のサイトでは、このレポートを使う必要はないと明記されている |
| 内部リンクを増やせばクロール頻度がすぐ上がる | 内部リンクが効くのは主に「検出」の要因。人気度や古さの要因は別に働く |
| AIクローラーの許可・拒否設定はクロールバジェットと無関係だ | AI専用クローラーのUser-agentも、クロール能力の上限を他のクローラーと共有する |
並べてみると、どれも同じ形をしています。数字や設定の名前だけを見て、それが何の要因に効くかを確かめていない。 つまずきの正体は、知識の不足ではなく確認の省略です。
自社サイトの規模がクロールバジェットの対象条件に当てはまらない場合は、レポートの数値を毎週追うより、テクニカルSEOの基本を優先したほうが投資対効果は高くなります。
この章のまとめ
誤解はどれも「何の要因に効くか」の確認漏れ。名前ではなく要因で読む。
15クロール効率をSEOで追う前に、Search Consoleで先に見る項目はどれですか？
最後に、手を動かす前の点検です。上から順に埋めてください。
- 対象プロパティが、ドメインプロパティかルートレベルのURLプレフィックスプロパティである
- クロールの統計情報レポートで、クロールリクエストの合計数とホストのステータスを確認した
- ホストのステータスが赤または黄の場合、robots.txtの取得・DNSの解決・サーバー接続のどこに問題があるか確認した
- クロールレスポンスの内訳で、不正なレスポンスコードの割合が増えていないか確認した
- 自社サイトが、クロールバジェットガイドの対象規模（重複無し100万ページ以上・週次更新、または1万ページ以上・日次更新）に該当するか確認した
- noindexページを、クロール節約の目的でrobots.txtブロックと混同していないか確認した
- 新規公開ページが
<a href="...">形式のクロール可能なリンクで内部リンクされているか確認した - サーバーエラー（5xx）やレート制限（429）が、クロール頻度低下の原因になっていないか確認した
この章のまとめ
点検は上から順に。プロパティの条件と規模の条件を先に確かめると、無駄な調査が減る。
16よくある質問
クロール効率という指標はSearch Consoleのどこで確認できますか
単体の指標としては存在しません。クロールの統計情報レポートの8項目（出典: Google（Search Console ヘルプ））と、クロールバジェットの考え方を組み合わせて判断します。
クロールの統計情報レポートは、どんなサイトでも毎週チェックすべきですか
いいえ。ページ数が1,000未満のサイトでは使う必要がないと明記されています（出典: Google（Search Console ヘルプ））。対象は主に大規模・高頻度更新のサイトです。
noindexタグを付ければクロールバジェットを節約できますか
できません。Googleは引き続きそのURLをリクエストし、レスポンスを確認した時点で対象外にします（出典: Google Search Central）。節約したい場合はrobots.txtでのブロックが対象になります。
内部リンクを増やせばクロール効率はすぐ改善しますか
即座の改善は保証されません。内部リンクが関係するのは主に「検出されたURL群」という要因で、ページの人気度や古さといった別の要因には直接効きません（出典: Google Search Central）。
ホストのステータスが赤色になったらどうすればよいですか
robots.txtの取得・DNSの解決・サーバー接続の各グラフを確認し、どのカテゴリで問題が発生しているかを特定します（出典: Google（Search Console ヘルプ））。直近1週間以内の問題であることを示すため、対応の優先度は高くなります。
クロールリクエストの合計数には、失敗したリクエストも含まれますか
含まれます。robots.txtが不十分で行われなかった取得、DNS解決の失敗、サーバー接続の失敗も、合計数にカウントされます（出典: Google（Search Console ヘルプ））。
17まとめ｜今日やる3つのこと
今日この順でやります
プロパティの型を確かめる
ドメインプロパティかルートレベルのURLプレフィックスプロパティかを見ます。違えばこのレポートは開けません
自社サイトが対象規模かを判定する
重複のないページの数と更新の頻度を、ガイドの条件に当てて判定します
当てはまらなければ、追わないと決める
レポートを定例から外し、テクニカルSEOの基本に時間を戻します
AI検索では、こう聞かれています
クロール効率という指標は、Search Consoleのどこで見られますか？
「クロール効率とは、Search Consoleで見えるSEO指標のことですか？」の章で、単体のスコアが無い理由を説明しています
クロールの統計情報レポートは、小さいサイトでも毎週見るべきですか？
「うちのサイトは、クロール効率をSearch ConsoleでSEO的に追う規模ですか？」の章に、対象規模の条件を挙げています
noindexを付ければクロールバジェットを節約できますか？
「noindexを使えばクロール効率は節約できるというSEOの誤解は本当ですか？」の章で、公式ガイドの記載を引いています
次に読むなら、この記事です
