クロールの統計情報を最近よく見るようになりましたが、どんな見方をすればいいのか悩んでました。
ですがクロールの統計情報を見てるうちに覚えた見方から、意外とたくさんのヒントが分かるようになるかもしれないと思えるようになってきたのでクロール統計情報の見方をまとめておきます。
クロールの統計情報で見る3つのデータ
クロールの統計情報を見たいときはGoogleの旧SearchConsoleで見ることができます。
旧SearchConsoleのクロールの統計情報はSearchConsoleに私たちが登録してるWebサイトのURLにGooglebotがクロールしたときのデータが表示されてます。
このときのGooglebotがクロールするデータはCSS、JavaScript、Flash、PDFファイル、画像などをクロールします。
そしてクロールの統計情報ではクロールする上記のデータをGooglebotが情報収集(クロール)した状態を3つのデータに分けて見ることができます。
以下は3つのクロールの統計情報の詳細です。
1日あたりのクロールされたページ数
クロールの統計情報の1日あたりにクロールされたページ数の確認ができます。
1日あたりにクロールされたページ数のグラフは青のグラフ。
グラフの青い線にマウスを置いて、マウスをグラフの線に沿って移動させると何日に何回クロールしたか、1日のクロール数の詳細を追いかける見方ができます。
そしてもう1つ1日のクロール数で分かることは、期間中の3つのクロール数
- 平均クロール数
- 一番高かったクロール数
- 一番低かったクロール数
上記の3つのクロール数がグラフ右横で見ることができます。このときのグラフでクロール数の高低差が激しかったりする部分を探すのに分かりやすいです。
1日にダウンロードされたキロバイト数
次に分かるのは1日にダウンロードされたキロバイト(KB)数です。
GooglebotがWebサイトをクロールしたときに、レンダリングでダウンロードしたHTMLやCSS、JavaScript、画像などダウンロードのキロバイト(KB)数です。
1日にダウンロードされるキロバイト数のグラフは赤いグラフです。
そしてグラフの右横には
- 平均ダウンロード数
- 一番高かったダウンロード数
- 一番低かったダウンロード数
をみることができます。
ページのダウンロード数
ページのダウンロード時間(ミリ秒)
Googlebotがクロールするときのレンダリングでページのファイルをダウンロードするのにかかった時間です。
単位はミリ秒
例として 100ミリ秒＝0.1秒
グラフは緑で表示されてグラフ右横は定番の
- 平均ダウンロード時間
- 一番高かったダウンロード時間
- 一番低かったダウンロード時間
ちょっと個人的なクロールの統計情報の見方を紹介
3つのクロール統計情報の高低はグラフでもすぐ分かるのですが、平均数がグラフで分かりづらいので私はグラフをスクショして平均数に近い日を元に横線を引いてみたりしてます。
そして平均数の線を基準にして、低いを隠したり高いを隠したりして高低差数を比較してるっぷりをするような見方もたまにします。
かなり個人的な見方なので参考にはならないと思いますが紹介です。
3つのクロールの統計情報で分かること
SearchConsoleでは、過去16か月のデータが保持されてるのですが、クロールの統計情報には、その内の90日間のデータを見ることができます。
そしてSearchConsoleのデータは、SearchConsoleに収集されてから48時間後に反映されます。(Google本社があるタイムゾーンのため、さらに反映は遅れる)
反映された3ヶ月期間のクロールの統計情報のデータを見るとWebサイトによって、それぞれのGooglebotのクロール頻度が分かります。
Googlebotのクロール頻度
Googlebotのクロールには決まったクロール頻度はありません。ですがクロールの統計情報を見て、毎日のクロールされてるページ数がインデックスさせてるページ数クロールされてるのが理想な頻度と思えます。
クロール頻度を1日単位で見る場合にはクロールの統計情報を確認するのが手っ取り早いのですね。
インデックス登録させてるURL(ページ)は新SearchConsoleのインデックスカバレッジで確認ができます。
そしてGooglebotは平均して秒数に1回を超える頻度でサイトにアクセスすることはありません。ただし、遅延などにより短時間にアクセス頻度が若干増えたように思える場合があるようです。
またサーバーの帯域幅に多く負荷をかけないように、1回のアクセスでサイトの多くのページをクロールすることを目標にして頑張ってるようです。
そんなGooglebotでもクロールし過ぎてしまったり、クロール数を減らしたりな状況が出てしまう場合があります。
クロールの統計情報のデータが急増した
クロールの統計情報を確認するとWebサイトによっては、データが急増してる日があります。
新しい情報を大量に追加した場合や、サイトに非常に有用な情報が掲載されている場合は、想定を上回ってクロールされてしまう可能性があります。サーバー負荷がかかりすぎてると思われる場合に、サイトのGooglebotのクロール頻度を管理する
引用元 クロールの統計情報レポート
とSearchConsoleヘルプに説明があります。
- 新しい情報を大量に追加した場合
- サイトに非常に有用な情報は掲載されてる場合
- サーバーに負荷がかかり過ぎてると思われる場合
上記3つの「場合のパターン」に分かれます。
Webサイトの質はそれぞれに異なるものなので、それぞれのWebサイトに「場合のパターン」を一致させて見ると分かることが見えてきます。
もしクロールの急増後にアクセスが増加すれば有益な情報を発信できた要因の1つとして、そのサイトには考えることができるかもしれません。
ですが新しい情報を更新してもクロールが急増後にアクセスが伸び悩むとしたらGooglebotがクロールすることに対して、リンク経路やサーバー負荷の改善策を検討する先回りしておくことに絞ることが必要と分かってきます。
クロールされたページ数が激減した
robots.txtルールでWebサイトのページをブロックする追加をしたらGooglebotがクロール中に迷子になるからクロール数を減らしてしまう。
ページのHTMLが壊れている、コンテンツがサポートされてない場合だとGooglebotがページのコンテンツをレンダリングできない。
リクエストへのサイトの反応が遅いのでGooglebotがリクエストを抑制してサーバーの過負荷を防ぐためクロールが激減する。
Webサイトの変更頻度が低かったり、ページの情報が少ないと、サイトの質があまり高くないと判断してしまいクロールが激減。
上記の可能性をそれぞれに当てはめて考えていくことができます。
そしてこのようなクロールの統計情報の急増と激減を確認して実際にどんな改善のヒントにすることができるか考えてみました。
クロールの統計情報のデータをヒントに改善できること
Googlebotがページをクロールしやすいダウンロード時間は100～500ミリ秒とMueller氏はコメントしてました。
100ミリ秒＝0.1秒
一般的にダウンロード時間が100～500ミリくらいであればGooglebotはクロールしやすい。1000ミリ秒(1秒)を超えるとサーバーが本当に遅いということになってしまいクロールに制限をかけるかもしれない。
このようなことから何を改善していけるかというと
- クロール頻度の抑制
- 使用するサーバーの見直し
- 更新頻度
- Googlebotがクロールしやすいリンク経路作り
- 余計にクロールしてるコンテンツの整理。
さらに重要と思うのはWebサイトで使用するコンテンツ(画像やHTML、CSS、JavaScriptなど)がレンダリングの妨げにならないように改善。
それぞれのWebサイトで当てはまることを絞って改善していきます。
ページ表示速度が順位付けの要因に入ってますが、膨大な数のインデックス登録がある中でページ表示速度を要因にできるのはGooglebotがクロールするときのクロールにかかる時間を表示速度として順位付けに使ってると思ってます。
そのGooglebotがクロールする統計情報をたまに確認して見るのも必要なのだと思っています。
