クロールの統計情報レポート

クロールの統計情報レポートには、ウェブサイトの Google のクロール履歴に関する統計情報が表示されます。たとえば、リクエストの数、サーバーからのレスポンスのタイミングや内容、可用性に関する問題の有無などです。このレポートを使用すると、Google がサイトをクロールした際に配信に関する問題が検出されたかどうかを確認できます。

このレポートは上級ユーザー向けです。サイトのページ数が 1,000 未満の場合、このレポートを使用する必要はありません。また、このレベルのクロールに関する詳細情報についてご心配いただく必要もありません。

クロールの統計情報レポートを開く

 

Search Console のクロールの統計情報レポートにアクセスするには、設定([プロパティ設定]) > [クロールの統計情報] をクリックします。

はじめに

このレポートを使用する前に、以下の情報を理解しておく必要があります。

データについて

  • 表示、カウントされている URL はすべて、Google がリクエストした実際の URL です。Google による正規化の判断は、これらの URL をリクエストする前または後に行われます。
  • このサイト外でホストされているリソースは、取得されたリクエスト数、バイト数のいずれについても、このレポートではカウントされません。このため、サイトのすべての画像が別のホスティング サービスに保存されている場合、それらの画像に対するリクエストはこのレポートでは反映されません。

レポートの操作

表の項目をクリックすると、その項目の詳細ビュー(URL の例のリストを含む)が表示されます。URL をクリックすると、その特定のクロール リクエストの詳細が表示されます。たとえば、レスポンスをタイプ別にグループ化して表示している表では、[HTML] 行をクリックすると、サイトのクロールされた HTML ページすべてに関するクロール集計情報と、選択された URL の例に関するクロール時間、レスポンス コード、レスポンスのサイズなどの詳細情報を確認できます。

マルチホスト サイト

2 つ以上の子ドメインを含むドメイン プロパティを閲覧している場合(例: example.com、m.example.com、www.example.com)、1 つの子ドメインを対象としたデータ、またはすべてのドメインについてまとめられたデータのどちらも確認できます。過去 90 日間にトラフィックを獲得した上位 20 個の子ドメインのみが表示されます。

プロパティに複数の子ドメインがある場合は、[ホスト] リストが表示され、子ドメインごとに最上位の統計情報が表示されます。最上位のレポートを閲覧すると、すべての子ドメインについてまとめられた統計情報を確認できます。また、リスト内の子ドメインをクリックすると、選択された子を対象としたクロール統計情報レポートを確認できます。

クロール リクエストの合計数

サイトの URL に対して発行されたクロール リクエストの合計数(成功したかどうかは問わず)。リソースがサイト上にある場合は、ページで使用されるリソースへのリクエストが含まれます。サイト外でホストされているリソースへのリクエストはカウントされません。同じ URL に対する重複するリクエストは個別にカウントされます。

ダウンロードの合計サイズ

指定した期間内のクロール中にサイトからダウンロードされた合計バイト数。Google が別のクロールでページリソースをキャッシュに保存し、キャッシュに保存されたリソースを再度リクエストしなかった場合は、同じリソースが再度読み込まれてもカウントされません。

平均レスポンス時間

指定した期間中にサイトから取得されたすべてのリソースの平均レスポンス時間。1 つのページからリンクされている各リソースは、別々のレスポンスとしてカウントされます。

ホストのステータス

[ホストのステータス] には、Google がサイトをクロールしようとした際に可用性に関する問題が発生したかどうかが表示されます。ステータスは次のいずれかの値になります。

  • No significant availability issues icon
    過去 90 日間にサイトでクロールの可用性に関する重大な問題は発生しませんでした。必要な作業はありません。
  • Some availability issues, but not recently
    過去 90 日間にサイトでクロールの可用性に関する問題が 1 件以上発生しましたが、発生したのは 1 週間以上前です。一時的な問題だったか、問題が解決された可能性があります。[レスポンス] の表を調べて、問題の内容を確認し、対応が必要かどうかを判断する必要があります。
  • Recent availability issue
    過去 1 週間以内に、サイトでクロールの可用性に関する重大な問題が 1 件以上発生しました。エラーは最近発生したものであるため、繰り返し発生している問題かどうか調べてみてください。[レスポンス] の表を調べて、問題の内容を確認し、対応が必要かどうかを判断してください。
確認すべき点

ホストのステータスは緑色になっているのが理想的です。可用性のステータスが赤色の場合は、クリックして可用性の詳細を表示し、robots.txt の可用性、DNS の解決、ホスト接続をご確認ください。

ホストのステータスの詳細

ホストの可用性のステータスは次のカテゴリで評価されます。いずれかのカテゴリに重大なエラーがあると、可用性のステータスが低くなる場合があります。レポート内のカテゴリをクリックすると、詳細が表示されます。

カテゴリごとに、その期間のクロールデータのグラフが表示されます。グラフには赤色の点線があります。指標がこのカテゴリの点線より上にある場合(たとえば、DNS の解決で特定の日に失敗したリクエストが 5% を超える場合)は、そのカテゴリの問題と見なされ、ステータスには最後の問題が直近で発生した時期が反映されます。

  • robots.txt の取得
    グラフには、クロール中の robots.txt リクエストの失敗率が表示されます。Google はこのファイルを頻繁にリクエストし、リクエストが有効なファイル(入力されているか空の状態)または 404(ファイルが存在しない)レスポンスを返さない場合は、有効な robots.txt レスポンスが取得できるまで、Google によるサイトのクロールが遅くなるか停止されます。(詳しくは以下をご覧ください
  • DNS の解決
    グラフには、DNS サーバーでホスト名が認識されなかったのはいつか、またはクロール中に応答しなかったのはいつかが表示されます。エラーが表示された場合は、レジストラをチェックして、サイトが正しく設定されているかどうか、また、サーバーがインターネットに接続されているかどうかを確認してください。
  • サーバー接続
    グラフには、クロール中にサーバーが応答しなかったのはいつか、URL のレスポンス全体が提供されなかったのはいつかが表示されます。このようなエラーの修正について詳しくは、サーバーエラーをご覧ください。
robots.txt の可用性の詳細

こちらでは、Google がサイトをクロールする際に robots.txt ファイルをどのように確認するか(そしてそれに依存しているか)についてさらに詳しく説明します。

サイトに robots.txt ファイルを含める必要はありませんが、このファイルを求められたら、正常なレスポンス(以下で定義)を返す必要があります。返さなければ、Google によるサイトのクロールが停止されることがあります。

  • 正常な robots.txt レスポンス
  • 次のいずれかのレスポンスが正常なレスポンスと見なされます。
    • HTTP 200 と robots.txt ファイル(ファイルは有効、無効、または空でもよい)。ファイルに構文エラーがある場合も、リクエストは成功と見なされますが、構文エラーのあるルールは Google によって無視される場合があります。
    • HTTP 403 / 404 / 410(ファイルが存在しない)。サイトに robots.txt ファイルを含める必要はありません。
  • 不成功の robots.txt レスポンス

Google がサイトをクロールする際に robots.txt ファイルをリクエストして使用する仕組みは次のとおりです。

  1. Google はサイトをクロールする前に、まず、最近成功した robots.txt リクエスト(24 時間以内)があるかどうかを確認します。
  2. 最近の正常な robots.txt レスポンスがある場合は、取得した robots.txt ルールに従ってクロールが開始されます。
  3. 最近の正常な robots.txt レスポンスがない場合、最後のレスポンスが不成功の場合は、Google は robots.txt ファイルをリクエストします。
    • 成功した場合、クロールを開始できます。
    • 失敗した場合、Google はクロールを停止しますが、robots.txt のリクエストは約 30 日間続けます。30 日が経過しても正常な robots.txt レスポンスを受け取れない場合:
      • それ以外ではサイトにアクセスできる場合、取得が成功した最後の robots.txt ルールが使用され、その情報に基づいてクロールが行われます。
      • サイトに全面的にアクセスできない場合、Google によるサイトのクロールは徐々に停止されます。

クロール レスポンス

この表では、Google がサイトをクロールした際に受け取ったレスポンスを、レスポンスのタイプ別にグループ化し、全クロール レスポンスに対する割合で示しています。データは URL ごとではなく合計リクエスト数に基づいています。そのため、Google が URL を 2 回リクエストし、初回はサーバーエラー(500)を受け取り、2 回目は OK(200)だった場合、レスポンスはサーバーエラー 50%、OK 50% になります。

確認すべき点
サイトの再編成やサイトの移動をしている場合を除き、ほとんどのレスポンスが 200 またはその他の「正常系」のレスポンスである必要があります。他のレスポンス コードを処理する方法については、以下のリストをご覧ください。

 

一般的なレスポンス コードとその処理方法は次のとおりです。

正常系のレスポンス コード

これらのページは問題がなく、問題が生じていません。

  • OK(200): 通常は、レスポンスの大部分が 200 レスポンスである必要があります。
  • 恒久的に移動(301): ページから HTTP 301(恒久的に移動)レスポンスが返されます。これはおそらく期待どおりのレスポンスです。
  • 一時的に移動(302): ページから HTTP 302(一時的に移動)レスポンスが返されます。これはおそらく期待どおりのレスポンスです。このページが恒久的に移動される場合は、301 に変更してください。
  • 移動(その他): 別の 300 リダイレクト レスポンス(301 または 302 ではありません)。

正常と思われるレスポンス コード

これらのレスポンスは正常である可能性がありますが、意図したものであるかどうかを確認することをおすすめします。

不正なレスポンス コード

これらのエラーを返すページを修正して、クロールを改善する必要があります。

  • robots.txt なし: robots.txt ファイルが 1 日使用できない場合、robots.txt へのリクエストに対する有効なレスポンスが得られるまで、しばらくの間 Google によるクロールは停止されます。これは robots.txt ファイルの「見つかりませんでした(404)」(これは有効なレスポンスです)とは異なります。詳しくは robots.txt についての説明をご覧ください。
  • 未認証(401 / 407): これらのページがクロールされないように robots.txt を使用してブロックするか、ブロックを解除すべきかどうか判断する必要があります。これらのページに安全なデータがなく、クロールさせたい場合は、情報を保護されていないページに移動するか、ログインせずに Googlebot にエントリを許可することをご検討ください(ただし、Googlebot になりすましている可能性があるため、Googlebot によるエントリを許可することで、ページのセキュリティが事実上失われることにご注意ください)。
  • サーバーエラー(5XX): このようなエラーは可用性に関する警告の原因となるため、できる限り修正する必要があります。サムネイルのグラフには、このようなエラーがおおよそいつ発生したかが表示されます。クリックすると、詳細と正確な時間を確認できます。エラーが一時的な問題だったか、サイトにおける深刻な可用性に関するエラーを表しているのかを判断します。Google がサイトをクロールする頻度が過大な場合は、クロール頻度の引き下げをリクエストできます。エラーが深刻な可用性に関する問題を示している場合は、クロールの上昇についてご覧ください。このようなエラーの修正について詳しくは、サーバーエラーをご覧ください。
  • その他のクライアント エラー(4XX): ここに記載されていないその他の 4XX(クライアント側)エラー。これらの問題を修正することをおすすめします。
  • DNS 未応答: サイトの URL のリクエストに DNS サーバーが応答していませんでした。
  • DNS エラー: 他の不明な DNS エラー。
  • 取得エラー: 不正なポート番号、IP アドレス、または解析不能なレスポンスが原因でページを取得できませんでした。
  • ページアクセス エラー: ページを取得する際のその他のエラー。リクエストがサーバーに送信されませんでした。これらのリクエストはサーバーに送信されなかったため、ログに表示されません。
  • ページ タイムアウト: ページ リクエストがタイムアウトしました。
  • リダイレクト エラー: 多すぎるリダイレクト、空のリダイレクト、または循環するリダイレクトなど、リクエストのリダイレクト エラー
  • その他のエラー: 上記カテゴリのいずれにも当てはまらないその他のエラー。

クロールされるファイル形式

リクエストによって返されるファイル形式。各形式のパーセント値は、その形式の取得されたバイトの割合ではなく、その形式のレスポンスの割合です。

考えられる値は次のとおりです。

  • HTML
  • 画像
  • 動画 - サポートされている動画形式のいずれか。
  • JavaScript
  • CSS
  • PDF
  • その他の XML - XML をベースとした RSS、KML などの形式を含まない XML ファイル。
  • JSON
  • シンジケーション - RSS フィードまたは Atom フィード
  • 音声
  • 地理データ - KML または他の地理データ。
  • その他のファイル形式 - ここに記載されていないその他のファイル形式。
  • 不明(失敗) - リクエストが失敗した場合、ファイル形式は不明となります。
確認すべき点
可用性に関する問題がある場合やレスポンス速度が遅い場合は、この表を参照して、Google がクロールしているリソースのタイプと、クロールが遅くなる理由を確認してください。ブロックする必要のある小さな画像が多数リクエストされていますか?応答性が低い別のサイトでホストされているリソースがリクエストされていますか?さまざまなファイル形式をクリックすると、日付別の平均レスポンス時間のグラフと日付別のリクエスト数が表示され、その形式の遅い項目の増加が、全体的な遅延または不可用性の増加と一致しているかどうか確認できます。

クロールの目的

  • 検出: リクエストされた URL は以前 Google によってクロールされたことがありません。
  • 更新: 既知のページの再クロール。

再クロールの頻度が十分でないことが多いページを急速に変更する場合は、そのページがサイトマップに含まれているようにします。あまり急速に更新されないページの場合は、特に再クロールをリクエストすることが必要な場合があります。最近新しいコンテンツを多数追加した場合や、サイトマップを送信した場合は、サイトの検出クロールが増加するのが理想的です。

Googlebot の種類

クロール リクエストに使用されるユーザー エージェントのタイプ。Google には、さまざまな理由でクロールを行い、さまざまな動作をする数多くのユーザー エージェントが存在します

  • スマートフォン: スマートフォン用 Googlebot
  • パソコン: パソコン用 Googlebot
  • 画像: 画像用 Googlebot。画像がページリソースとして読み込まれる場合、Googlebot の種類は [画像] ではなく [ページリソースの読み込み] としてカウントされます。
  • 動画: 動画用 Googlebot。動画がページリソースとして読み込まれる場合、Googlebot の種類は [動画] ではなく [ページリソースの読み込み] としてカウントされます。
  • ページリソースの読み込み: ページで使用されるリソースの補助的な取得。Google はページをクロールする際、ページをインデックスに登録する前にページをレンダリングするために、画像や CSS ファイルなどのリンクされた重要なリソースを取得します。このようなリソース リクエストを行うのが、このユーザー エージェントです。
  • AdsBot: AdsBot クローラの 1 つ。このようなリクエストが急増している場合は、最近サイトに動的検索広告の新しいターゲットが数多く作成されている可能性があります。クロール頻度が上昇した理由をご覧ください。AdsBot は 2 週間ごとに URL をクロールします。
  • その他のエージェント タイプ: ここに記載されていないその他の Google クローラ。

クロール リクエストの大半は、メインクローラから送信されます。クロールが急増している場合は、ユーザー エージェントのタイプをご確認ください。AdsBot クローラが原因で急増していると思われる場合は、クロール頻度が上昇した理由をご覧ください。

トラブルシューティング

クロール頻度が高すぎる

Googlebot には、クロール中にサイトが過負荷にならないようにするアルゴリズムがあります。ただし、なんらかの理由でクロール頻度を制限する必要がある場合は、クロール頻度を制限する方法をご覧ください。

クロール頻度を減らすためのヒント:

  • robots.txt ファイルを微調整し、呼び出す必要がないページをブロックします。
  • 一時的な解決策として、Search Console で最大クロール頻度を設定できます。クロールするページやリソースと、クロールしないページやリソースを具体的に指定するものではないため、この解決策を長期的に使用することはおすすめしません。
  • 無限のカレンダーや無限の検索ページなど、「無限」の結果を含むページのクロールを許可しないようにします。こうしたページは robots.txt または nofollow タグでブロックしてください。
  • URL が存在しなくなった場合や移動した場合は、正しいレスポンス コードを返すようにしてください。存在しなくなった URL、無効な URL には 404 または 410、別の URL に恒久的に置き換えられた URL には 301(一時的な置き換えの場合は 302)リダイレクト、予定された一時的なダウンタイムには 503 を使用します。サーバーが処理できない問題の場合には 500 エラーを返すようにします。
  • サイトが過負荷になっているためクロール頻度を緊急に引き下げる必要がある場合は、下記のクロール頻度が上昇した理由をご覧ください。

クロール頻度が上昇した理由

新しい情報を大量に追加した場合や、サイトに非常に有用な情報が掲載されている場合は、想定を上回ってクロールされてしまう可能性があります。たとえば次のような場合です。

  • サイトの大部分でクロールのブロックを解除した場合
  • サイトに新しい大きなセクションを追加した場合
  • 新しいページフィードまたは URL_Equals ルールを追加して、動的検索広告に新しいターゲットを多数追加した場合

サイトが頻繁にクロールされることで、サイトへのアクセスに影響が発生している場合は、次のように回避できます。

  1. サイトに対するクロール頻度が過大な Google クローラを特定します。これは中長期の計画に役立ちます。
  2. 簡単な解決策:
    • 簡単な解決策としては、robots.txt を使用して、過負荷になっているエージェント(Googlebot、AdsBot など)に対するクロールをブロックします。
    • 負荷の増大を動的に検出して対応できる場合は、配信制限に近づいた時点で HTTP 5XX/429 を返します。ただし、5XX や 429 を返すのは 2~3 日程度までにすべきです。それを超えてしまうと、Google がサイトをクロールする頻度がいずれ少なくなってきます。
  3. クロール頻度設定ページクロール頻度を変更します(選択可能な場合)。
  4. 2~3 日後に Google のクロール頻度が適応すると、robots.txt ブロックを削除するか、ステップ 1 のエラーコードを返すことを中止できます。
  5. 問題のあるクローラが AdsBot クローラである場合、Google によるクロールの対象であるサイト用に動的検索広告ターゲットを作成したことが問題になっている可能性があります。このクロールは 2 週間ごとに再実行されます。これらのクロールを処理できるだけのサーバー容量がない場合は、広告ターゲットを制限するか、配信容量を増やす必要があります。
  6. クロール設定ページでクロール頻度を制限している場合、クロール頻度は 90 日後に自動調整に戻ります。

クロール頻度が低すぎる

Google にクロール頻度を上げるよう伝えることはできません(プロパティのクロール頻度を明示的に低くしている場合を除く)。ただし、大規模なウェブサイトや更新頻度の高いウェブサイトについては、クロールの管理方法の詳細をご覧ください。

小規模または中規模のウェブサイトについては、Google がサイトの全部をクロールしていないことがわかった場合、ウェブサイトのサイトマップを更新し、どのページもブロックしていないことを確認してください。

クロール頻度が低下した理由

一般に、Google のクロール頻度は 1~2 週間は比較的安定しているはずです。急激に低下した場合は、いくつかの理由が考えられます。

  • 新しい(または非常に大まかな)robots.txt ルールを追加した場合。ブロックする必要があるリソースのみをブロックしていることを確認します。Google がコンテンツを認識するために、CSS や JavaScript などの特定のリソースが必要な場合は、こうしたリソースが Googlebot からブロックされないようにしてください。
  • ページの HTML が壊れている、コンテンツがサポートされていない場合。Googlebot がページのコンテンツを解析できない場合は、使用されているメディアのタイプがサポートされていないか、ページが画像でのみ構成されている可能性があります。こうしたコンテンツをクロールすることはできません。URL 検査ツールを使用して、ページが Googlebot からどのように認識されるかを確認してください。
  • リクエストへのサイトの反応が遅い場合、Googlebot はリクエストを抑制してサーバーの過負荷を防ぎます。クロールの統計情報レポートで、サイトの反応が遅くなっていないか確認してください。
  • サーバーのエラー率が上昇すると、Googlebot はリクエストを抑制してサーバーの過負荷を防ぎます。
  • 最大クロール頻度を下げていないことを確認してください。
  • サイトに変更頻度が低い情報がある場合や、サイトの品質があまり高くない場合は、サイトのクロール頻度が落ちる可能性があります。サイトを率直に見て、またサイトに関係がないユーザーに偏りのないフィードバックを聞いて、全体的にサイトのどこをどのように改善すればよいかを検討してください。
この情報は役に立ちましたか?
改善できる点がありましたらお聞かせください。