クロール統計情報の見方｜ホストステータス異常と急増・急減の切り分け
設定画面のクロール統計情報を開いたら、ホストステータスに警告が出ている。グラフを見るとリクエストが急に減っている。順位にはまだ何も起きていない。放っておいていいのか、すぐ動くべきか。
判断の材料は2つです。ホストステータスの詳細（robots.txt の取得・DNS の解決・サーバー接続）のどれが、いつ赤かったか。そして応答の内訳にどんな失敗が混ざっているか。この2つを見れば、危険度はほぼ決まります。グラフの山や谷そのものを眺めても、答えは出ません。
まず、このレポートを見るべきサイトか
最初に確かめることがあります。Search Console ヘルプは、このレポートを上級者向けと位置づけています。1,000 ページ未満のサイトなら、このレポートを使ったり、この細かさのクロールを気にしたりする必要はないはずだ、とも書いています。
ただ、編集部はこれを「平常時に眺める必要はない」という意味に読んでいます。小さなサイトでも、ホストステータスの警告に気づいたなら中身は確かめておくほうが安全です。
開き方にも注意があります。レポートはルートレベルのプロパティでしか使えません。ドメインプロパティか、https://example.com のようなルートの URL プレフィックスプロパティです。場所は「設定」→「クロールの統計情報」です。https://example.com/blog/ のようなプロパティでは見当たりません。
ホストステータスは「いつ」問題があったかを示す
ホストステータスは、Google がサイトをクロールしようとして、つながりにくさ（可用性の問題）にぶつかったかどうかを表します。値は3通りです。
- 過去90日間、大きな問題はなかった
- 過去90日間に1回以上あったが、1週間より前のこと
- 直近1週間のうちに1回以上あった
2つめについて、ヘルプは「一時的な問題だったか、すでに解決している可能性がある」と書いています。3つめは「最近起きたので、繰り返す問題かどうかを見極めるべき」です。どちらでも、応答の表を見て対応の要否を決めるよう求めています。
つまり、警告が出ていても「今も壊れている」とは限りません。最初に見るのはいつ起きたかです。
赤い表示が出ていたら、クリックすると3つの項目の詳細が開きます。
| 項目 | グラフが示すもの | 公式が示す対処の方向 |
|---|---|---|
| robots.txt の取得 | クロール中の robots.txt リクエストの失敗率 | 有効なファイル（空でも可）か 404 を返せるようにする。返せないあいだ、Google はクロールを遅らせるか止める |
| DNS の解決 | DNS サーバーがホスト名を認識しなかった・応答しなかったとき | 登録事業者（レジストラ）に、設定とサーバーのインターネット接続を確認する |
| サーバー接続 | サーバーが応答しなかった・URL の応答を最後まで返さなかったとき | サーバーエラーの直し方に沿って直す |
各グラフには赤い点線があります。値がその線を上回ると、その項目は問題ありと見なされます。ヘルプは例として「ある日の DNS 解決の失敗が 5% を超えた場合」を挙げています。どの項目でも、大きなエラーがあればステータスが下がることがあります。
3項目のうち、robots.txt がいちばん重い
3つが同じ重さに見えるかもしれません。ですが、影響の広さが違います。robots.txt の取得に失敗すると、サイト全体のクロールが止まりうるからです。
ヘルプによると、Google はクロールの前に、24時間以内に成功した robots.txt の取得があるかを確かめ、あればそれを使います。最後の応答が失敗だったか24時間より古ければ取り直し、取れなかった場合はこう動きます。
- 最初の12時間は、サイトのクロールを止める（robots.txt の取得は続ける）
- 12時間から30日までは、最後に取得に成功した robots.txt を使う
- 30日を過ぎたら、トップページが表示できれば robots.txt が無いものとしてクロールする。表示できなければクロールを止める
ここで誤解しやすい点があります。robots.txt が無いこと自体は失敗ではありません。成功と扱われるのは、200 でファイルを返す場合（中身が無効でも空でも可）と、403・404・410 を返す場合です。失敗になるのは 429 と 5xx です。
ですから「robots.txt を置いていないから警告が出た」は、原因として外してかまいません。疑うのは、robots.txt の URL がエラーを返す状態です。ヘルプは、robots.txt が1日取得できないままだと、取得できるまでしばらくクロールを止めると書いています。あわせて、robots.txt を Google 向けにクローキングしたり、ユーザーエージェントで出し分けたりしないよう注意しています。
急増・急減は「誰が」「なぜ」で分ける
リクエスト数のグラフが跳ねたときは、山か谷かで見る場所が変わります。
急増したとき。ヘルプは、よくある理由として次を挙げています。
- サイトの大きな範囲のクロール制限を外した
- 大きな新しいセクションを追加した
- 動的検索広告のターゲットを大量に追加した
検索セントラルのクロール頻度の低減ガイドは、さらにサイト構造の非効率を挙げます。絞り込み・並べ替えの機能や、日付ごとの URL が大量にできるカレンダーなどです。まずホスティング会社に確認し、直近のアクセスログでトラフィックの出どころを確かめるよう、強く勧めています。
急減したとき。クロール頻度は1〜2週間の幅ではおおむね安定するのが普通だ、とヘルプは書いています。急に落ちたときの候補は次のとおりです。
- 新しい（または範囲の広い）robots.txt のルールを足した
- サイトの応答が遅くなった（Googlebot はサーバーへの負荷を避けるためリクエストを控える）
- サーバーエラーの割合が増えた（同じく控える）
- 内容があまり変わらない、または質がそれほど高くない
谷が出たら、同じ期間の平均応答時間と、応答の内訳のサーバーエラーを並べて見ます。応答時間が伸びた日と谷が重なっていれば、サーバー側を疑う根拠になります。重ならない場合は、直前に robots.txt を変えていないかを確かめます。
危険度の判定表
ここまでを、画面で見たもの別にまとめます。危険度は公式の記述をもとにした編集部の目安です。
| 画面で見たもの | 危険度 | 次の一手 |
|---|---|---|
| 問題が1週間より前だけ。応答の内訳もほぼ 200 | 低 | 起きた日を控える。翌週もう一度開いて再発がないか見る |
| 直近1週間にサーバー接続の問題。応答の内訳に 5xx | 中〜高 | エラーの時刻を確認し、同時刻のサーバーのエラーログを見る |
| 直近1週間に DNS の問題 | 高 | レジストラと DNS の設定を確認する。DNS 起因の失敗はサーバーのログに残らないことがある |
| robots.txt の取得失敗が続いている | 最高 | robots.txt の URL に直接アクセスし、200 か 404 が返るかを確かめる |
| リクエストの急増でサイトが重い | 中 | どのクローラーが増えたかを特定し、必要なら一時的に抑える（後述） |
| リクエストが急減。応答時間も悪化 | 中 | 遅くなった原因（負荷・プラン・重い処理）をサーバー側で探す |
DNS の行には根拠があります。応答の種類のうち「ページに到達できなかった」は、リクエストがサーバーに届いていない失敗です。ヘルプは、こうしたリクエストはログに現れないと明記しています。DNS が応答しなければ、リクエストはサーバーまで届きません。ですから、サーバーのログがきれいでも、DNS やネットワークの問題は否定できないことがあります。
点検の手順（ワークスルー）
架空の例で一度通します。月曜の朝、ホストステータスが「直近1週間に問題あり」になっていた。リクエスト数は土曜から半分ほどに減っている、という状況です。
- どの項目が赤いかを開く。この例ではサーバー接続のグラフが土曜に点線を超えていた。robots.txt と DNS は問題なし。
- 応答の内訳で失敗の種類と時刻を見る。「サーバーエラー（5XX）」の小さなグラフで、おおよその発生時刻がわかる。表の行をクリックすれば、URL の例を含む詳細も開く。この例では土曜の深夜に集中していた。
- 同じ時刻のサーバーログを見る。エラーログでその時間帯の 5xx と原因（メモリ不足・プロセスの再起動など）を探す。この例では、深夜のバックアップ処理と重なっていた。
- ログの Googlebot が本物かを確かめる。手順は次の節。
- 原因を潰したら、翌週に同じ画面を開く。問題の日付が「1週間より前」に移り、リクエスト数が戻りはじめていれば、再発していないと判断する。
手順 3 で一つ補足します。レポートの数字とサーバーログが少しずれても、慌てなくて大丈夫です。ヘルプは既知の問題として、一部のリクエストが数えられない場合があり、ログとの小さな差が出うると書いています。リダイレクトは転送の各段が別々の1リクエストとして数えられる点も、ずれの元になります。
逆に、レポートの合計がログよりずっと多いときは要注意です。robots.txt が長く取得できず、実際には行われなかったクロールが合計に数えられている可能性があります。ヘルプは、その場合は robots.txt の取得状況を確かめるよう案内しています。
ログの「Googlebot」は本物か
サーバーログで Googlebot を名乗るアクセスが急に増えていても、Google からとは限りません。名前は偽装できます。検索セントラルは、Google を装ったアクセスが気になる場合のために確認方法を示しています。手作業なら次の2段です。
# 1. ログの IP アドレスを逆引きし、googlebot.com / google.com / googleusercontent.com かを確認
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
# 2. 得たホスト名を正引きし、元の IP と一致するかを確認
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1
ここから実務の手がかりが1つ出ます。クロール統計情報のグラフは平らなのに、ログでは「Googlebot」が急増している。それなら、偽物が混ざっていることを先に疑ってよいでしょう。このレポートが数えるのは Google が実際にリクエストした URL だからです。この場合、Google 向けの対処（クロール頻度を下げる）をしても、負荷は減らないかもしれません。
本物の Googlebot で重いときの一時しのぎ
本物のクロールでサイトが落ちそうなときの選択肢は、公式に2つあります。
- robots.txt で、負荷をかけているクローラーをブロックする。簡単ですが、効くまで最大1日かかります。長く続けると、クロールに長期の影響が出ることがあります。
- 限界が近いときだけ 503 か 429 を返す。負荷を検知して動的に返せる場合の方法です。2〜3日を超えて返し続けないこと。長く続けると、長期的にクロール頻度を下げる合図になりうるからです。
クロール頻度の低減ガイドは、500・503・429 が大量に返ると、エラーの URL だけでなくホスト名全体のクロール頻度が下がると書いています。エラーが減れば、頻度は自動で戻ります。同じ URL が何日もこれらを返し続けると、インデックスから外れることがある、とも警告しています。
抑える前に、代償も知っておきましょう。新しいページが見つかりにくくなり、既存ページの更新の反映も遅くなります。削除したページが長く残ることもあります。2〜3日たってクロール頻度が落ち着いたら、robots.txt のブロックや 503・429 をやめます。
週1回の点検チェックリスト
- ホストステータスが「直近1週間に問題あり」になっていない
- 問題があった場合、robots.txt・DNS・サーバー接続のどれかを特定した
- robots.txt の URL が 200 か 404 を返す（429・5xx を返さない）
- 応答の内訳で、200 以外の失敗が急に増えていない
- リクエスト数の急変があれば、同じ期間の平均応答時間と並べて見た
- ログの Googlebot の急増は、逆引き・正引きで本物か確かめた
クロールの量そのものを増やしたい、という悩みは別の話です。小さなサイトで量を気にすべきかは小規模サイトにクロールバジェットは関係あるかで扱っています。ページのインデックス登録レポートに「サーバーエラー（5xx）」が出ている場合は、Search Consoleのサーバーエラー5xxを切り分けて直す手順もあわせて確認してください。
出典