[レベル: 上級]
Google は、クロール バジェットの管理を解説する技術ドキュメントを更新しました。
内容自体に大きな変更はなく専門用語の追加や説明の明確性の改善が中心です。
しかし、注目したい変更もいくつか含まれています。
この記事では、現行ドキュメントでの主な変更点をピックアップします。
⚠️この記事を書いている時点では日本語ドキュメントは未更新
「クロール能力の上限」の定義がより正確に
旧版では、クロール能力の上限 (Crawl capacity limit) は主に次のように説明されていました。
- 同時接続数の上限
- リクエスト間の待機時間
現行版では、Google との接続をサーバーが開いたまま維持する合計時間として説明されています。
また、並列接続数と接続時間の両方が考慮されると明記されています。
さらに、この概念が hostload（ホストロード）とも呼ばれることが追加されました。
この変更は単なる表現の変更ではありません。
クロール能力は、固定されたリクエスト数や同時接続数だけで決まるのではなく、各接続がどれだけ長く維持されるかも関係することが明確になりました。
初期値と自動調整の仕組みの追加
現行版では、次の説明が追加されています。
- すべてのサイトは、同じ控えめな初期クロール能力の上限から始まる。
- クロール需要があり、サイトが正常な状態を維持していれば、Google のシステムが時間の経過とともに上限を自動調整する。
旧版には、初期値や自動調整の仕組みに関する説明はありませんでした。
「クロールの状態」に関する技術的なシグナルを具体化
クロールの状態 (Crawl health) は、レスポンスが速ければ上限が上がり、遅くなったりサーバーエラーが発生したりすれば上限が下がると、旧版では一般的に説明されていました。
現行版では、次の具体的な要素が示されています。
- レイテンシ
- Time to First Byte
- レスポンス時間の長期化
5xxサーバーエラー429のレート制限レスポンス
具体例の追加により、クロール能力の問題を診断するときに確認すべき指標がより明確になりました。
クロール バジェットは各クローラーで共有される
現行版では、次の重要な説明が新たに追加されています。
The crawl capacity limit is shared across all crawlers, so high demand from one crawler can reduce the capacity available to others.
クロール能力の上限はすべてのクローラーで共有されるため、あるクローラーの需要が高まると、ほかのクローラーが利用できる容量が減る場合があります。
たとえば、AdsBot や Google Shopping のクロール需要が増えると、Googlebot が利用できるサーバー容量が減る可能性があります。
旧版でもクローラーごとに需要が異なることは説明されていましたが、同じ容量を共有しているとは明記されていませんでした。
読み込み速度と HTTP キャッシュに関する推奨事項の追加
現行版では、ページを効率的に読み込めるようにするための具体策として、次の 2 点が追加されています。
- サーバーレスポンス時間とリソース読み込みを改善する。
304 Not Modifiedをサポートし、Google がキャッシュ済みの内容を再利用できるようにする。
こうした対応により、サーバーの帯域幅やリソースを節約できると説明しています。
旧版では、ページの読み込みとレンダリングが速ければ、Google がより多くのコンテンツを読み取れる可能性がある、とだけ記載されていました。
したがって、HTTP キャッシュを明示的に推奨した点は、実務上意味のある追加です。
Google のリソースが有限であることを明確化
旧版では、Google には多くのマシンがあるものの、無限ではないと説明されていました。
現行版では、Google のリソースは有限であり、ウェブ全体で優先順位を付けて配分する必要がある、と説明されています。
これは主に表現の明確化であり、実質的な方針変更ではありません。
ここまで説明した比較的大きな変更のほかに、用語や表現の細かな更新があります。
たとえば、「serving limit（配信上限）」が、より正確な「crawl capacity limit（クロール能力の上限）」に変更されました。
「サイト」を一意のホスト名として定義する説明が、より明確に書き直されました。
実質的に変わっていない点
ドキュメント更新後も、基本的な考え方は変わっていません。
クロール バジェットは、「Crawl capacity limit（クロール能力の上限）」と「Crawl demand（クロールの必要性）」の 2 つによって決まります。
主要な推奨事項も、ほぼ従来どおりです。
- 不要な URL を管理する
- 重複コンテンツを統合する
- クロールさせたくない URL には
robots.txtを使用する - クロール バジェット節約のためだけに
noindexを使わない - 完全に削除したページには
404または410を返す - ソフト 404 を解消する
- サイトマップと
<lastmod>を適切に管理する - 長いリダイレクトチェーンを避ける
- コンテンツ品質とサーバー容量を改善する
最も重要な変更
最も重要な追加は、クロール能力の上限が Google のすべてのクローラーで共有されると明記された点でしょうか。
旧版でも、Googlebot、AdsBot、Google Shopping などでクロール需要が異なることは説明されていました。
しかし、それぞれの動作が互いにどのような影響を与えるかは説明されていませんでした。
現行版では、これらが同じホスト単位の容量を共有していることが明確になっています。
したがって、Googlebot のクロールが減少した場合、原因は Googlebot の需要やページ品質、サーバー障害だけとは限りません。
別の Google クローラーの需要増加によって、共有容量が多く使われている可能性もあります。
次に重要なのは、クロール能力の上限が単なる接続数ではなく、接続時間も含めて決まると明確化された点です。
さらに、TTFB、レイテンシ、5xx、429 といった具体的なシグナルが追加されたことで、サーバーレベルでのクロール最適化に役立つ、より実践的な内容になっています。