クロールの統計情報レポートには、ウェブサイトの Google のクロール履歴に関する統計情報が表示されます。たとえば、リクエストの数、サーバーからのレスポンスのタイミングや内容、可用性に関する問題の有無などです。このレポートを使用すると、Google がサイトをクロールした際に配信に関する問題が検出されたかどうかを確認できます。
このレポートは上級ユーザー向けです。サイトのページ数が 1,000 未満の場合、このレポートを使用する必要はありません。また、このレベルのクロールに関する詳細情報についてご心配いただく必要もありません。
C<span/>rawl Budget and the Crawl Stats report - Google Search Console Training
はじめに
このレポートを使用する前に、以下の情報を理解しておく必要があります。
- Google 検索の仕組み
- 上級ユーザー向けトピック、特にクロールとインデックス登録に関するトピックと、サイトマップに関するトピック。
- サイトへのアクセスの管理に関するさまざまなトピック（robots.txt によるブロックを含む）
- 大規模なサイト（数十万ページ）の場合は、クロールの割り当ての管理とトラブルシューティングに関するガイドをご覧ください。
データについて
- 表示、カウントされている URL はすべて、Google がリクエストする実際の URL です。他の一部のレポートと同様、データが正規 URL に割り当てられることはありません。
- URL にサーバーサイドのリダイレクトが設定されている場合、リダイレクト チェーン内の各リクエストは個別のリクエストとしてカウントされます。そのため、page1 が page2 に、page2 が page3 にリダイレクトされる場合、Google が page1 をリクエストすると page1（301 / 302 を返す）、page2（301 / 302 を返す）、page3（可能であれば 200 を返す）の各リクエストが表示されることになります。なお、表示されるのは現在のドメインのページのみです。リダイレクト レスポンスのファイル形式は「その他のファイル形式」です。クライアントサイドのリダイレクトはカウントされません。
- robots.txt ファイルが使用できなかったために認識されても行われなかったクロールは、クロールの合計数にカウントされますが、レポートではそうしたクロールに関する詳細の表示が制限される場合があります。詳細情報
- リソースとスコープ
- すべてのデータは、現在選択されているドメインに限定されます。他のドメインへのリクエストは表示されません。これには、このプロパティの外側でホストされているページリソース（画像など）のリクエストが含まれます。たとえば、ページ example.com/mypage に画像 google.com/img.png が含まれている場合、google.com/img.png へのリクエストは、プロパティ example.com のクロールの統計情報レポートには表示されません。
- 同様に、兄弟ドメイン（en.example と de.example）に対するリクエストは表示されません。そのため、en.example のクロールの統計情報レポートには、de.example 上の画像に対するリクエストは表示されません。
- ただし、サブドメイン間のリクエストは親ドメインから表示できます。たとえば example.com のデータを表示すると、example.com より下のレベルのすべての子ドメイン（example.com、en.example、de.example.com など）に対するリクエストをすべて確認できます。
- 逆に、プロパティ リソースが他のドメインのページで使用されている場合、ホストページに関連するクロール リクエストが表示されることはあっても、そのリソースがクロール中であることを示すコンテキストが表示されることはありません。これは、このリソースが他のドメインのページで使用されているためです（つまり、anotherexample.com/mypage というページに表示される example.com/imageX.png という画像がクロールされたかどうかはわかりません）。
- クロールデータには、URL プレフィックス プロパティの場合でも、http プロトコルと https プロトコルの両方が含まれています。つまり、http://example.com のクロールの統計情報レポートには、http://example.com と https://example.com の両方に対するリクエストが含まれます。ただし、URL プレフィックス プロパティのサンプル URL は、プロパティ（http または https）に定義されたプロトコルに限定されています。
レポートの操作
レポートには、サイトに関する次のクロール情報が表示されます。
表の項目をクリックすると、その項目の詳細ビュー（サンプル URL のリストを含む）が表示されます。任意の URL をクリックすると、その特定のクロール リクエストの詳細が表示されます。たとえば、レスポンスをタイプ別にグループ化して表示している表では、[HTML] 行をクリックすると、サイトのクロールされた HTML ページすべてに関するクロール集計情報と、選択されたサンプル URL に関するクロール時間、レスポンス コード、レスポンスのサイズなどの詳細情報を確認できます。
ホストと子ドメイン
プロパティがドメインレベル（example.com、http://example.com、https://m.example.com）にあり、2 つ以上の子ドメイン（fr.example.com と de.example.com など）を含む場合は、親ドメインのデータを表示できます。このデータは、すべての子ドメインのデータ、または単一の子ドメインを対象としたデータを含みます。
特定の子ドメインを対象としてレポートを確認するには、親ドメインのランディング ページの [ホスト] リストで任意の子ドメインをクリックすると、過去 90 日間にトラフィックを獲得した上位 20 個の子ドメインのみが表示されます。
URL の例
グループ化されたデータ型のエントリ（レスポンス、ファイル形式、目的、Googlebot タイプ）をクリックすると、そのデータ型のサンプル URL が一覧で表示されます。
サンプル URL は包括的なものではなく、代表例にすぎません。URL がリストに含まれていなくても、Google がリクエストしなかったわけではありません。サンプル数は日別で重み付けできるため、特定のタイプのリクエストに対するサンプル数が、他のタイプよりも多くなる場合があります。この不均衡は、時間の経過とともに解消します。
クロール リクエストの合計数
サイトの URL に対して発行されたクロール リクエストの合計数（成功したかどうかは問わず）。リソースがサイト上にある場合は、ページで使用されるリソースへのリクエストが含まれます。サイト外でホストされているリソースへのリクエストはカウントされません。同じ URL に対する重複リクエストは個別にカウントされます。robots.txt ファイルを十分に利用できない場合、取得はカウントされます。
失敗したリクエストのうち、カウントされるリクエストには次のものがあります。
- robots.txt ファイルが不十分だったために行われなかった取得
- DNS 解決の問題によって失敗した取得
- サーバー接続の問題によって失敗した取得
- リダイレクト ループのために放棄された取得
ダウンロードの合計サイズ
指定した期間内のクロール中にサイトからダウンロードされた合計バイト数。複数のページで使用されているページリソースを Google がキャッシュに保存した場合、そのリソースは初回のみリクエストされます（キャッシュへの保存が行われた時点）。
平均レスポンス時間
指定した期間中にサイトから取得されたすべてのリソースの平均レスポンス時間。1 つのページからリンクされている各リソースは、別々のレスポンスとしてカウントされます。
ホストのステータス
[ホストのステータス] には、Google がサイトをクロールしようとした際に可用性に関する問題が発生したかどうかが表示されます。ステータスは次のいずれかの値になります。
過去 90 日間にサイトでクロールの可用性に関する重大な問題は発生しませんでした。必要な作業はありません。
過去 90 日間にサイトでクロールの可用性に関する問題が 1 件以上発生しましたが、発生したのは 1 週間以上前です。一時的な問題だったか、問題が解決された可能性があります。[レスポンス] の表を調べて、問題の内容を確認し、対応が必要かどうかを判断する必要があります。
過去 1 週間以内に、サイトでクロールの可用性に関する重大な問題が 1 件以上発生しました。エラーは最近発生したものであるため、繰り返し発生している問題かどうか調べてみてください。[レスポンス] の表を調べて、問題の内容を確認し、対応が必要かどうかを判断してください。
ホストのステータスは緑色になっているのが理想的です。可用性のステータスが赤色の場合は、クリックして可用性の詳細を表示し、robots.txt の可用性、DNS の解決、ホスト接続をご確認ください。
ホストのステータスの詳細
ホストの可用性のステータスは次のカテゴリで評価されます。いずれかのカテゴリに重大なエラーがあると、可用性のステータスが低くなる場合があります。レポート内のカテゴリをクリックすると、詳細が表示されます。
カテゴリごとに、その期間のクロールデータのグラフが表示されます。グラフには赤色の点線があります。指標がこのカテゴリの点線より上にある場合（たとえば、DNS の解決で特定の日に失敗したリクエストが 5% を超える場合）は、そのカテゴリの問題と見なされ、ステータスには最後の問題が直近で発生した時期が反映されます。
- robots.txt の取得
グラフには、クロール中の robots.txt リクエストの失敗率が表示されます。Google はこのファイルを頻繁にリクエストし、リクエストが有効なファイル（入力されているか空の状態）または 404（ファイルが存在しない）レスポンスを返さない場合は、有効な robots.txt レスポンスが取得できるまで、Google によるサイトのクロールが遅くなるか停止されます。（詳しくは以下をご覧ください） - DNS の解決
グラフには、DNS サーバーでホスト名が認識されなかったのはいつか、またはクロール中に応答しなかったのはいつかが表示されます。エラーが表示された場合は、レジストラをチェックして、サイトが正しく設定されているかどうか、また、サーバーがインターネットに接続されているかどうかを確認してください。 - サーバー接続
グラフには、クロール中にサーバーが応答しなかったのはいつか、URL のレスポンス全体が提供されなかったのはいつかが表示されます。このようなエラーの修正について詳しくは、サーバーエラーをご覧ください。
こちらでは、Google がサイトをクロールする際に robots.txt ファイルをどのように確認するか（そしてそれに依存しているか）についてさらに詳しく説明します。
サイトに robots.txt ファイルを含める必要はありませんが、このファイルを求められたら、正常なレスポンス（以下で定義）を返す必要があります。返さなければ、Google によるサイトのクロールが停止されることがあります。
- 正常な robots.txt レスポンス
- 次のいずれかのレスポンスが正常なレスポンスと見なされます。
- HTTP 200 と robots.txt ファイル（ファイルは有効、無効、または空でもよい）。ファイルに構文エラーがある場合も、リクエストは成功と見なされますが、構文エラーのあるルールは Google によって無視される場合があります。
- HTTP 403 / 404 / 410（ファイルが存在しない）。サイトに robots.txt ファイルを含める必要はありません。
- 不成功の robots.txt レスポンス
- HTTP 429 / 5XX（接続に関する問題）
Google がサイトをクロールする際に robots.txt ファイルをリクエストして使用する仕組みは次のとおりです。
- Google はサイトをクロールする前に、まず、最近成功した robots.txt リクエスト（24 時間以内）があるかどうかを確認します。
- 取得してから 24 時間以上経過していない正常な robots.txt レスポンスがある場合、Google はサイトのクロール時にその robots.txt ファイルを使用します（エラー 404（ページが見つかりません）は成功です。robots.txt ファイルがないため、Google がサイト上のどの URL もクロールできることを意味します）。
- 最後のレスポンスが不成功であるか、24 時間以上経過している場合、Google は robots.txt file をリクエストします。
- 成功した場合、クロールを開始できます。
- 不成功の場合:
- Google は最初の 12 時間、サイトのクロールを停止しますが、robots.txt ファイルのリクエストは続行します。
- 12 時間経過後から 30 日後までは、取得が成功した最後の robots.txt ファイルを使用しながら、robots.txt ファイルのリクエストを続行します。
- 30 日後:
- サイトのホームページにアクセスできる場合、Google は robots.txt ファイルがないものとして制約なくクロールを実施します。
- サイトのホームページにアクセスできない場合、Google はサイトのクロールを停止します。
- いずれの場合も、Google は引き続き robots.txt ファイルを定期的にリクエストします。
クロール レスポンス
この表では、Google がサイトをクロールした際に受け取ったレスポンスを、レスポンスのタイプ別にグループ化し、全クロール レスポンスに対する割合で示しています。データは URL ごとではなく合計リクエスト数に基づいています。そのため、Google が URL を 2 回リクエストし、初回はサーバーエラー（500）を受け取り、2 回目は OK（200）だった場合、レスポンスはサーバーエラー 50%、OK 50% になります。
一般的なレスポンス コードとその処理方法は次のとおりです。
正常系のレスポンス コード
これらのページは問題がなく、問題が生じていません。
- OK（200）: 通常は、レスポンスの大部分が 200 レスポンスである必要があります。
- 恒久的に移動（301）: ページから HTTP 301 または 308（恒久的に移動）レスポンスが返されます。これはおそらく期待どおりのレスポンスです。
- 一時的に移動（302）: ページから HTTP 302 または 307（一時的に移動）レスポンスが返されます。これはおそらく期待どおりのレスポンスです。このページが恒久的に移動される場合は、301 に変更してください。
- 移動（その他）: メタ更新です。
- 変更なし（304）: 前回のクロールのリクエストからページが変更されていません。
正常と思われるレスポンス コード
これらのレスポンスは正常である可能性がありますが、意図したものであるかどうかを確認することをおすすめします。
- 見つかりませんでした（404）エラーは、サイト内またはサイト外の無効なリンクが原因となっている可能性があります。サイト上のすべての 404 エラーを解決できる可能性は低く、また意味がなく望ましくもありません。404 を返すのが適切である場合がほとんどです（たとえば、ページが置き換えられずに削除された場合）。404 エラーの修正方法、または修正するかどうかについては、こちらをご覧ください。
不正なレスポンス コード
これらのエラーを返すページを修正して、クロールを改善する必要があります。
- robots.txt なし: robots.txt ファイルが 1 日使用できないと、robots.txt へのリクエストに対する有効なレスポンスが得られるまで、しばらくの間 Google はクロールを停止します。Google に対して robots.txt ファイルをクローキングしないでください。また、ユーザー エージェントごとに異なる robots.txt ページを使用しないでください。
このレスポンスは、有効なレスポンスであると見なされる robots.txt ファイルの「見つかりませんでした（404）」とは異なります。詳しくは robots.txt についての説明をご覧ください。 - 未認証（401 / 407）: これらのページがクロールされないように robots.txt を使用してブロックするか、ブロックを解除すべきかどうか判断する必要があります。データが保護されていないページをクロールさせたい場合は、情報自体を保護されていないページに移動するか、ログインせずに Googlebot がエントリすることを許可します（ただし、なりすましの可能性があるため、Googlebot によるエントリを許可することで、ページのセキュリティが事実上失われることにご注意ください）。
- サーバーエラー（5XX）: このようなエラーは可用性に関する警告の原因となるため、できる限り修正する必要があります。サムネイルのグラフには、このようなエラーがおおよそいつ発生したかが表示されます。クリックすると、詳細と正確な時間を確認できます。エラーが一時的な問題だったか、サイトにおける深刻な可用性に関するエラーを表しているのかを判断します。Google がサイトをクロールする頻度が過大な場合は、クロール頻度の引き下げをリクエストできます。エラーが深刻な可用性に関する問題を示している場合は、クロールの上昇についてご覧ください。このようなエラーの修正について詳しくは、サーバーエラーをご覧ください。
- その他のクライアント エラー（4XX）: ここに記載されていないその他の 4XX（クライアント側）エラー。これらの問題を修正することをおすすめします。
- DNS 未応答: サイトの URL のリクエストに DNS サーバーが応答していませんでした。
- DNS エラー: 他の不明な DNS エラー。
- 取得エラー: 不正なポート番号、IP アドレス、または解析不能なレスポンスが原因でページを取得できませんでした。
- ページアクセス エラー: ページを取得する際のその他のエラー。リクエストがサーバーに送信されませんでした。これらのリクエストはサーバーに送信されなかったため、ログに表示されません。
- ページ タイムアウト: ページ リクエストがタイムアウトしました。
- リダイレクト エラー: 多すぎるリダイレクト、空のリダイレクト、または循環するリダイレクトなど、リクエストのリダイレクト エラー。
- その他のエラー: 上記カテゴリのいずれにも当てはまらないその他のエラー。
クロールされるファイル形式
リクエストによって返されるファイル形式。各形式のパーセント値は、その形式の取得されたバイトの割合ではなく、その形式のレスポンスの割合です。
指定できるファイル形式は次のとおりです。
- HTML
- 画像
- 動画 - サポートされている動画形式のいずれか。
- JavaScript
- CSS
- その他の XML - XML をベースとした RSS、KML などの形式を含まない XML ファイル。
- JSON
- シンジケーション - RSS フィードまたは Atom フィード
- 音声
- 地理データ - KML または他の地理データ。
- その他のファイル形式 - ここに記載されていないその他のファイル形式。リダイレクトはこのグループに含まれます。
- 不明（失敗）- リクエストが失敗した場合、ファイル形式は不明となります。
クロールの目的
- 検出: リクエストされた URL は以前 Google によってクロールされたことがありません。
- 更新: 既知のページの再クロール。
再クロールの頻度が十分でないことが多いページを急速に変更する場合は、そのページがサイトマップに含まれているようにします。あまり急速に更新されないページの場合は、特に再クロールをリクエストすることが必要な場合があります。最近新しいコンテンツを多数追加した場合や、サイトマップを送信した場合は、サイトの検出クロールが増加するのが理想的です。
Googlebot の種類
クロール リクエストに使用されるユーザー エージェントのタイプ。Google には、さまざまな理由でクロールを行い、さまざまな動作をする数多くのユーザー エージェントが存在します。
Googlebot の有効なタイプ:
- スマートフォン: スマートフォン用 Googlebot
- パソコン: パソコン用 Googlebot
- 画像: 画像用 Googlebot。画像がページリソースとして読み込まれる場合、Googlebot の種類は [画像] ではなく [ページリソースの読み込み] としてカウントされます。
- 動画: 動画用 Googlebot。動画がページリソースとして読み込まれる場合、Googlebot の種類は [動画] ではなく [ページリソースの読み込み] としてカウントされます。
- ページリソースの読み込み: ページで使用されるリソースの補助的な取得。Google はページをクロールする際、ページをインデックスに登録する前にページをレンダリングするために、画像や CSS ファイルなどのリンクされた重要なリソースを取得します。このようなリソース リクエストを行うのが、このユーザー エージェントです。
- AdsBot: AdsBot クローラの 1 つ。このようなリクエストが急増している場合は、最近サイトに動的検索広告の新しいターゲットが数多く作成されている可能性があります。クロール頻度が上昇した理由をご覧ください。AdsBot は 2 週間ごとに URL をクロールします。
- StoreBot: 商品のショッピング クローラ。
- その他のエージェント タイプ: ここに記載されていないその他の Google クローラー。
クロールが急増している場合は、ユーザー エージェントのタイプをご確認ください。AdsBot クローラーが原因で急増していると思われる場合は、クロール頻度が上昇した理由をご覧ください。
トラブルシューティング
クロール頻度が高すぎる
Googlebot には、クロール中にサイトが過負荷にならないようにするアルゴリズムがあります。ただし、なんらかの理由でクロール頻度を制限する必要がある場合は、クロール頻度を制限する方法をご覧ください。
クロール頻度が上昇した理由
新しい情報を大量に追加した場合や、サイトに非常に有用な情報が掲載されている場合は、想定を上回ってクロールされてしまう可能性があります。たとえば次のような場合です。
- サイトの大部分でクロールのブロックを解除した場合
- サイトに新しい大きなセクションを追加した場合
- 新しいページフィードまたは URL_Equals ルールを追加して、動的検索広告に新しいターゲットを多数追加した場合
サイトが頻繁にクロールされることで、サイトへのアクセスに影響が発生している場合は、次のように回避できます。
- サイトに対するクロール頻度が過大な Google クローラを特定します。ウェブサイトのログを確認するか、クロールの統計情報レポートを使用します。
- 簡単な解決策:
- 簡単な解決策としては、robots.txt を使用して、過負荷になっているエージェント（Googlebot、AdsBot など）に対するクロールをブロックします。ただし、有効になるまで最大 1 日程度かかることがあります。クロールに長期的な影響を及ぼす可能性があるため、あまり長くはブロックしないでください。
- 負荷の増大を動的に検出して対応できる場合は、配信制限に近づいた時点で HTTP 503 / 429 を返します。ただし、503 や 429 を返すのは 2～3 日程度までにすべきです。それを超えてしまうと、Google がサイトをクロールする頻度がいずれ少なくなってきます。
- 2～3 日後に Google のクロール頻度が適応すると、robots.txt ブロックを削除するか、503 または 429 エラーコードを返すことを中止できます。
- AdsBot のクロールが多すぎる場合は、
URL_Equalsまたはページフィードを使用してサイトに作成した動的検索広告のターゲットが多すぎる可能性があります。これらのクロールを処理できるだけのサーバー容量がない場合は、広告ターゲットの制限、小さなバッチでの URL 追加、広告配信容量の増加のいずれかが必要です。AdsBot は 2 週間ごとにページをクロールするため、問題を修正しなければ、同じ現象が繰り返されます。
クロール頻度が低すぎる
Google にクロール頻度を上げるよう伝えることはできません。ただし、非常に大規模なウェブサイトや更新頻度の高いウェブサイトについては、クロールの管理方法の詳細をご覧ください。
小規模または中規模のウェブサイトについては、Google がサイトの全部をクロールしていないことがわかった場合、ウェブサイトのサイトマップを更新し、どのページもブロックしていないことを確認してください。
クロール頻度が低下した理由
一般に、Google のクロール頻度は 1～2 週間は比較的安定しているはずです。急激に低下した場合は、いくつかの理由が考えられます。
- 新しい（または非常に大まかな）robots.txt ルールを追加した場合。ブロックする必要があるリソースのみをブロックしていることを確認します。Google がコンテンツを認識するために、CSS や JavaScript などの特定のリソースが必要な場合は、こうしたリソースが Googlebot からブロックされないようにしてください。
- リクエストへのサイトの反応が遅い場合、Googlebot はリクエストを抑制してサーバーの過負荷を防ぎます。クロールの統計情報レポートで、サイトの反応が遅くなっていないか確認してください。
- サーバーのエラー率が上昇すると、Googlebot はリクエストを抑制してサーバーの過負荷を防ぎます。
- サイトに変更頻度が低い情報がある場合や、サイトの品質があまり高くない場合は、サイトのクロール頻度が落ちる可能性があります。サイトを率直に見て、またサイトに関係がないユーザーに偏りのない意見を聞いて、全体的にサイトのどこをどのように改善すればよいかを検討してください。
レポートのクロールの合計数がサイトのサーバーログの合計数よりも大幅に多い
レポートのクロールの合計数が、サーバーログの Google のクロール リクエスト数よりも大幅に多くなるのは、robots.txt ファイルが長期間使用できないことで Google がサイトをクロールできないためです。このような場合には、Google では、robots.txt ファイルが使用できたと見なしてクロールをカウントしますが、実際にはクロールが行われていません。robots.txt の取得ステータスを見て、これが原因であるかどうか確認してください。
