Search Console クロールの統計情報レポート ── 90日分のGooglebotの動きから読める8指標を確認する14項目（2026年9月時点）

01 何が起きたか — Googleが自分のサイトをどう見に来ているか、8つの指標で分かる

「サーバーが返した記録」ではなく「Googleが実際にリクエストした記録」

Search Consoleの「クロールの統計情報レポート」は、Googleが自分のサイトに対して行ったクロール（巡回して情報を取得する行為）の履歴を、サーバー側のアクセスログとは別の経路で確認できる仕組みである。公式ヘルプは、このレポートで分かることを次のように説明している。

"The Crawl Stats report shows you statistics about Google's crawling history on your website. For instance, how many requests were made and when, what your server response was, and any availability issues encountered."

（訳: クロールの統計情報レポートは、あなたのWEBサイトに対するGoogleのクロール履歴に関する統計情報を表示する。たとえば、何件のリクエストがいつ行われたか、サーバーの応答がどうだったか、遭遇した可用性の問題などである。）

(Crawl Stats report)　レポートが表示する指標は8種類あり、総クロールリクエスト数・合計ダウンロードサイズ・平均応答時間・ホストの状態・クロールの応答・ファイルタイプ・クロールの目的・Googlebotのタイプ、で構成される。

「1,000ページ未満なら使わなくていい」と公式が線を引いている

このレポートは誰にとっても必須というわけではない。公式ヘルプは対象読者を明確に絞っている。

"This report is aimed at advanced users. If you have a site with fewer than a thousand pages, you should not need to use this report or worry about this level of crawling detail."

（訳: このレポートは上級ユーザー向けである。サイトのページ数が1,000ページ未満の場合、このレポートやこのレベルのクロールの詳細を気にする必要はないはずである。）

(前掲のCrawl Stats report)　また、このレポートはドメインプロパティまたはルートレベルのURLプレフィックスプロパティでしか利用できない。サブディレクトリ単位のプロパティでは表示されない。

02 なぜ・背景 — カウントの仕方に、いくつかの前提がある

URLは正規化されず、実際にリクエストされた形のまま数えられる

公式ヘルプは「表示・集計されるすべてのURLは、Googleが実際にリクエストしたURLそのものであり、他の一部のレポートのように正規URLに割り当てられるわけではない」と明記している。canonicalタグで正規URLを指定していても、クロールの統計情報レポートでは、実際にリクエストされたバリエーションのURLごとに別々に集計される。同じコンテンツへの複数のURLバリエーション（パラメータ違い等）を持つサイトでは、この違いがリクエスト数の見え方に影響する。

リダイレクトは、1回の遷移につき1件として数えられる

URLがサーバー側リダイレクトを経由している場合、リダイレクトチェーンの各段階が個別のリクエストとしてカウントされる。公式の例では、page1がpage2にリダイレクトし、page2がpage3にリダイレクトする場合、Googleがpage1をリクエストすると、page1（301/302を返す）・page2（301/302を返す）・page3（うまくいけば200を返す）の3件の別々のリクエストとして表示される。クライアントサイドリダイレクト（JavaScriptによるリダイレクト等）はこのカウントに含まれない。

自分のドメイン以外へのリクエストは、このレポートに出ない

ページが読み込む画像やスクリプトなどのリソースが、別ドメインでホストされている場合、そのリソースへのリクエストはこのレポートに表示されない。公式の例では、example.com/mypageがgoogle.com/img.pngという画像を読み込んでいても、google.com/img.pngへのリクエストはexample.comのクロールの統計情報レポートには表示されない、と説明されている。兄弟ドメイン（en.example.comとde.example.com等）の間でも、互いのリクエストは表示されないが、親ドメインの視点からは、子ドメインすべてへのリクエストをまとめて確認できる。

Googlebotにも種類があり、レンダリング用の取得は別枠になる

「Googlebotのタイプ」という指標には、スマートフォン・デスクトップ・画像・動画のほかに、Page resource load（ページリソースの取得）という区分がある。公式ヘルプは「Googleがページをクロールする際、そのページをレンダリングしてからインデックスしようとする前に、画像やCSSファイルなど、そのページが利用する重要なリンク先リソースを取得する。これらのリソース取得を行うユーザーエージェントがこの区分にあたる」と説明している。画像が単体のページとしてクロールされた場合はImage区分に、別のページの表示に使われるリソースとして取得された場合はPage resource load区分になるという切り分けがある。

広告関連のクロールを行うAdsBotは、通常およそ2週間おきにURLをクロールする、と公式に明記されている。AdsBotによるリクエストが急増している場合、その原因の多くは、Dynamic Search Ads向けに新しいターゲットURLを大量に追加したことにある。

「クロールされた」と「クロールされたことになっている」は、違うことがある

総クロールリクエスト数には、実際にはリクエストが行われなかったにもかかわらず、カウントに含まれるケースがある。robots.txtファイルの取得が不十分にしか成功していない状態が続くと、Googleは「もしrobots.txtが取得できていたら行っていたはずのフェッチ」を、実際には実行しないまま集計に含める。公式ヘルプはこの現象について「レポートの合計クロール数が、あなたのサーバーログの合計よりもはるかに多い場合、これはrobots.txtファイルが長期間利用できない場合に起こりうる」と説明している。

03 この記事で出てくる用語

ホスト状態が「緑」でも、個別の応答コードの問題は別に見る必要がある

ホスト状態は、あくまでサーバーの可用性（robots.txtが取れるか・DNSが引けるか・接続できるか）を判定する指標であり、個々のページが404や5xxを返しているかどうかは、別の指標である「クロールの応答」で確認する必要がある。ホスト状態が緑であっても、特定のページ群だけが継続的にエラーを返している、という状況はありうる。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どのプロパティで、どんな場面で使うか

このレポートは、サーバーの可用性に問題が疑われるとき（応答が遅い・断続的にエラーが出る）、クロールされてほしいページがクロールされていないとき（Discoveryが増えない）、意図しないファイルタイプが大量にクロールされているとき（不要な小さい画像等）、クロール頻度が急に変化したときの4つの場面で活用できる。サイト移転や大規模なリニューアルの直後は、応答コードの分布が普段と変わっていないかを確認する材料にもなる。

🅱 この記事が測っていないこと・分からないこと

公式ヘルプを確認しても、いくつかの点は明確に書かれていない。第一に、クロール頻度を意図的に増やしてもらう方法は、公式には存在しない。ヘルプ本文にも「クロール頻度を上げるようGoogleに指示することはできない」と明記されている。第二に、例示されるURLは「代表的な例」であり網羅的な一覧ではないため、特定の1つのURLがいつクロールされたかを、このレポートだけで確実に追跡することはできない。第三に、レポートの精度そのものについて「現状、ほとんどのクロールリクエストを報告しているが、一部のリクエストは何らかの理由でカウントされないことがある」という留保が明記されている。サーバーログの数字と完全に一致するとは限らない。

🅲 手順 — robots.txtが取れないとき、Googleはどう動くか

ホスト状態の「robots.txt fetching」の項目を理解するために、公式ヘルプが説明する時間経過を確認しておく。Googleは、クロールを始める前に直近24時間以内の成功したrobots.txt応答があるかを確認し、無ければ新たに取得を試みる。取得に失敗した場合の挙動は、経過時間によって段階的に変化する。

取得の成功・失敗の判定基準も明確に定義されている。HTTP 200（ファイルの中身が有効でも無効でも空でも成功扱い）と、HTTP 403/404/410（ファイルが存在しない、として成功扱い）は、いずれも「成功」に分類される。一方、HTTP 429や5xx系のレスポンスは「失敗」として扱われる。404が「robots.txtが無い」という成功の合図になる点は、直感に反するため見落とされやすい。

05 明日、自分のサイトで確認できることチェックリスト

まず何を数えるか

ここまでの内容を、実際に手を動かせる作業に翻訳した。観点は、レポートへのアクセス（対象プロパティかどうか）、ホスト状態の確認、応答コードの確認、ファイルタイプ・目的別の確認、の4つに分かれる。

• 自分のサイトのプロパティが、ドメインプロパティまたはルートレベルのURLプレフィックスプロパティかを確認する
• Search Consoleの「設定」から「クロールの統計情報」レポートを開き、ホストの状態が緑・黄・赤のどれか確認する
• 黄または赤の場合、robots.txt取得・DNS解決・サーバー接続のどのカテゴリで問題が出ているか確認する
• 「クロールの応答」の表で、200以外のレスポンスが占める割合を確認する
• 404の内訳を3件クリックし、現在サイト内・サイト外からリンクされているURLかどうかを確認する
• 5xx（サーバーエラー）が含まれている場合、その発生日時をエラーログの日時と突き合わせる
• 「ファイルタイプ」の表を開き、意図しない小さい画像やリソースが大量にクロールされていないか確認する
• 「クロールの目的」でDiscoveryとRefreshの比率を確認し、新しく公開したページがDiscoveryされているか探す
• 直近1ヶ月で更新頻度の高いページを3件選び、Refreshの対象に含まれているか確認する
• 「Googlebotのタイプ」でスマートフォン向けとデスクトップ向けの比率を確認する
• 総クロールリクエスト数が普段と比べて急増・急減していないか、直近90日のグラフで確認する
• 自分のサーバーのアクセスログを1日分開き、このレポートの総リクエスト数と桁が大きく違わないか突き合わせる
• 子ドメインを持つ場合、「Hosts」の一覧に主要な子ドメインが表示されているか確認する
• 今日確認した内容を1ヶ月後に同じ手順で再確認する予定を、カレンダーに入れる

14項目の内訳と、かかる時間の目安

14項目は4つの観点に対応している。それぞれの観点にどの項目が入り、目安としてどれくらいの時間がかかるかを、以下の表にまとめた。

すべてに目を通す時間の目安は1サイトあたり40〜50分程度である。データは日次で更新されるため、確認した直後に手を打っても、その効果がレポートに反映されるまでには数日かかる。

06 代替・他の選択肢（表で）

応答コードは3段階で判断する

公式ヘルプは、応答コードを「良い」「要確認」「悪い」の3段階に分類して案内している。すべてのコードを均等に見るのではなく、まずこの3段階のうち「悪い」に該当するものから優先して対応するのが効率的である。

クロール頻度が落ちた理由の候補

クロール頻度は通常、数週間の単位で比較的安定して推移する。急な低下が見られた場合、公式ヘルプは4つの候補を挙げている。新しい、または範囲の広いrobots.txtルールを追加したこと、サイトの応答が遅くなったこと（Googlebotは負荷をかけすぎないよう自動的に速度を落とす）、サーバーエラー率が上昇したこと、そしてコンテンツの更新頻度や品質が下がったと判断されたこと、の4つである。意図的にクロール頻度を下げる方法は公式に用意されているが、逆に上げる方法は用意されていない。

クロール頻度を増やしてほしい、への公式の答え

「クロールされる頻度を上げたい」という要望に対して、公式ヘルプの答えは明確である。Googleに対してクロール頻度を上げるよう直接指示する手段は存在しない。中規模以下のサイトに対する案内は、sitemapを最新の状態に保つことと、重要なページをブロックしていないかを確認することの2点に限られている。robots.txtで意図せず重要なCSS・JavaScriptをブロックしていないかは、公式が特に注意を促している点である。

07 自社サイトで確認したこと — UAが「Googlebot」を含むアクセスを14日分数えてみた

383件のうち、98.4%が200だった

当サイトのサーバーログから、直近14日分（2026年8月25日〜9月8日）のうち、User-Agentに「Googlebot」の文字列を含むリクエストを数えたところ、383件あった。応答コードの内訳は200が377件（98.4%）、404が4件、403が2件である。この集計は、公式のクロールの統計情報レポートそのものではなく、当サイトのサーバーログをUser-Agent文字列だけで数えた簡易な集計であり、正規化・重複排除の扱いも公式レポートとは異なる可能性がある点をあらかじめ断っておく。

User-Agentの内訳では、スマートフォン向けを示す文字列を含むものが274件、デスクトップ向けが106件、Googlebot-Imageが3件だった。スマートフォン向けのアクセスがデスクトップ向けの2.6倍という比率は、モバイルファーストインデックスのもとでスマートフォン向けクローラーが優先的に使われているという一般的な説明と整合する。

404だった4件は、参照元（Referer）が空だった

404を返した4件を確認したところ、いずれも当サイトの現在のページやsitemap.xmlのどこからもリンクされていない、実在しないツールのURLへのリクエストだった。4件とも参照元ヘッダーは空で、送信元IPはすべて66.249.x.x帯という、Googleが公開しているクローラーのIPアドレス範囲に含まれていた。「クロールの目的」の観点で見れば、これはRefresh（過去に知っていたURLの再確認）に近い挙動であり、公式ヘルプが「404のすべてを修正する必要はなく、ページが本当に無くなっている場合は404を返すことが正しい」と案内している状況にそのまま当てはまる。

383件は、231種類のURLに分散していた

383件のリクエスト先を集計すると、重複を除いたURLの種類は231であり、1URLあたり平均で1.7回リクエストされていた計算になる。もっとも多かった/（トップページ）が39回、/robots.txtが25回で、この2つで全体の17%弱を占めていた。robots.txtへのリクエストが14日で25回という頻度は、本記事02章で触れた「直近24時間以内に成功応答があるかを確認する」という挙動と、おおむね整合する回数である。残りの229種類のURLは、いずれも14日間で1〜4回程度のリクエストにとどまっており、特定の少数ページに集中するのではなく、記事ページ全体に薄く分散してクロールされている形だった。

公式のレポートと、この簡易集計は「別のもの」である

本記事02章で触れたとおり、公式のクロールの統計情報レポートには、robots.txt取得の失敗が続いた場合に「実際には行われなかったリクエストがカウントに含まれる」という性質がある。今回のサーバーログの集計にはこの性質がなく、実際にサーバーへ到達したリクエストだけを数えている。両者の数字が一致しない場合、その差は「公式レポートが多めに見積もっている」可能性と「サーバーログの記録漏れ」の両方が候補になり、どちらか一方だけを原因と決めつけることはできない。

08 このテーマの、これまで

「再クロール待ち行列547件」との付き合い方

クロールの目的（Discovery・Refresh）を扱った回として、再クロールの待ち行列が547件溜まっていた状態から、公式が示す「最長2週間」という基準の意味を確認し、"待つ"を能動的な行動に変える方法を扱った回がある(archives/108)。本記事05章のチェックリストにある「更新頻度の高いページがRefreshされているか」という項目は、この回で扱った待ち行列の考え方と直接つながっている。

「同じ条件で測っていなかった」という失敗

robots.txtの「24時間キャッシュ」という仕様を前提に3サイトの数字を比較しようとしたところ、実際には測定条件がサイトごとに揃っていなかったことに気づいた回がある(archives/117)。本記事07章の集計も、公式のクロールの統計情報レポートとは条件が異なる簡易集計であることを明記したのは、この回で得た教訓を踏まえている。2つの数字を並べるときは、同じ条件で測っているかを先に確認する必要がある。

Search Console自体が11ヶ月にわたってバグを抱えていた事例を扱った回もあり(archives/54)、公式ツールが出す数字であっても無条件に正しいとは限らないという前提は、クロールの統計情報レポートを読むときにも変わらず当てはまる。noindexやrobots.txtの設定がクロールにどう影響するかという、本記事の前提部分をさらに詳しく確認したい場合はnoindex・nofollow・robots.txtは、それぞれ何を止めているのかを、robots metaタグ側のルールを詳しく確認したい場合はrobots meta タグ・X-Robots-Tagのディレクティブを、それぞれ参照してほしい。