追記1:クロール上限は全クローラーで共有される
Googleが追加した文章は次のとおりです。「While each crawler has a different crawl demand, the crawl capacity limit is shared across all crawlers. This means that high demand from one crawler can reduce the capacity available for others.(各クローラーはそれぞれ異なるクロール需要を持つが、クロール処理能力の上限は全クローラーで共有される。つまり、あるクローラーの高い需要が、他のクローラーに使える処理能力を減らしうる)」
Search Engine Journalはこれを、たとえばサイトがGooglebot-ImageとGooglebotの両方にクロールされている場合、2つのクローラーはそのサイトのクロールバジェットを共有していることを意味すると説明しています。影響として挙げられているのは、あるボットによる高頻度のクロールが、他のGoogleクローラーに使える処理能力を減らしうるという点です。
公式ドキュメントは、クローラーごとの需要の違いにも触れています。AdsBotは動的な広告ターゲットを運用しているサイトで需要が高くなりやすく、Google Shoppingはマーチャントフィードに入っている商品への需要が高い、という例です。Googlebotについては、サイトの規模、更新頻度、ページ品質、他サイトと比較した関連性で需要が変わると書かれています。
追記2:304 Not Modified を返してキャッシュを使わせる
もうひとつの追記は、304 Not Modifiedというステータスコードの利用を推奨するものです。Googleの更新後のドキュメントには次の記述が入りました。「Use HTTP caching: Support 304 (Not Modified) HTTP status codes. If a page hasn’t changed since Google last crawled it, returning a 304 code tells Google to reuse the cached version, saving your server bandwidth and resources.(HTTPキャッシュを使う:304 (Not Modified)のHTTPステータスコードをサポートする。Googleが最後にクロールしてからページが変わっていない場合、304を返すとGoogleにキャッシュ済みのバージョンを再利用するよう伝えられ、サーバーの帯域と資源を節約できる)」
Search Engine Journalは、Mozilla Developer Network(MDN)のウェブドキュメントから「The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.(HTTP 304 Not Modifiedのリダイレクション応答ステータスコードは、要求されたリソースを再送する必要がないことを示す)」を引き、304についてひとつ注意点を挟んでいます。技術的には3xx系のステータスコードはすべてリダイレクトのコードに分類されるものの、304ではリダイレクトは何も起きていない、という点です。
原文の整理では、304 Not Modifiedの応答は、前回のクロール以降そのページが変わっていないことをGoogleのクローラーに伝えるものです。結果として、サーバーはGooglebotにページ本体を渡さずに済み、Googlebotは他のページのインデックス処理に向かえます。なお原文は、ここで説明した2点がドキュメントへの新規追加のすべてであり、それ以外はより正確な記述にするための細かな修正だとも述べています。
前提のおさらい:クロールバジェットは「処理能力」と「需要」で決まる
公式ドキュメントでは、クロールバジェットは2つの要素で決まると定義されています。クロール処理能力の上限(crawl capacity limit)と、クロール需要(crawl demand)です。前者はhostloadとも呼ばれ、Googleのために自社サーバーが接続を開いたまま保持する総時間を、並行接続の数とその持続時間の両面から制限するものだと説明されています。
この上限は固定ではありません。ドキュメントによれば、すべてのサイトは同じ保守的な既定値から始まり、もっとクロールする需要があってサイトが健全であれば、Googleのシステムが時間をかけて自動的に調整します。上下する条件として挙げられているのは次の点です。サイトが安定して応答し、レイテンシやTime-to-First Byteを含む応答時間が安定もしくは改善していれば上限は上がる。サイトが遅くなる(レイテンシが増える、応答時間が長くなる)、あるいは5xx系のHTTPステータスコードやHTTP 429のようなレート制限のシグナルを返すと上限は下がり、Googleのクロールは減る。
クロール需要の側でサイト運営者が最も大きく制御できるのは、ドキュメントが「perceived inventory(認識されている在庫)」と呼ぶ要素です。運営者側から何の案内もなければ、Googleは把握しているURLのすべて、あるいはほとんどをクロールしようとします。その多くが重複していたり、削除済み・重要でないなどの理由でクロールされたくないURLであれば、サイト上でGoogleのクロール時間を大きく浪費することになる、という説明です。あわせて、Google検索についてはクロールされたページが必ずインデックスされるわけではなく、クロール後に評価・正規化・判定の工程を経るとも明記されています。
ドキュメントが挙げるベストプラクティス
更新後のドキュメントには、クロール効率を高めるための実践項目が並んでいます。要点を原文の範囲で整理します。
- URLの在庫管理:クロールしてほしいページとしてほしくないページを、適切なツールでGoogleに伝える。クロールすべきでないURLにGoogleが時間を使いすぎると、クローラーはサイトの残りを探索しないか、クロールバジェットを増やさない可能性がある。
- 重複コンテンツの統合:URLの重複ではなく固有のコンテンツにクロールを集中させる。
- robots.txtでのクロールブロック:無限スクロールや並び替え違いのページなど、統合できない重要度の低いページはrobots.txtでブロックする。noindexは使わない――Googleはリクエスト自体は行い、noindexを見てからページを破棄するため、クロール時間を無駄にする。
- 恒久的に削除したページには404または410を返す。404は「そのURLを再びクロールしない」という強いシグナルになる。一方でブロックされたURLはクロールキューに長く残り、ブロックが外れると再クロールされる。
- ソフト404を解消する。ソフト404のページはクロールされ続け、バジェットを浪費する。ページのインデックス作成レポートで確認できる。
- サイトマップを最新に保つ。更新されたコンテンツがある場合は<lastmod>タグを含めることが推奨されている。
- 長いリダイレクトチェーンを避ける。クロールに悪影響がある。
- ページを効率よく読み込めるようにする。サーバー応答時間とリソースを最適化して表示を速くする。今回追記されたHTTPキャッシュ(304のサポート)も、この文脈に置かれている。
また「クロールバジェットを増やす方法」としては2つが挙げられています。URL検査ツールで「Hostload exceeded」が出ているようにサーバー容量が原因でクロールできていない場合はサーバー資源を追加すること、そして狙っているGoogleのプロダクトに向けてコンテンツの品質を最適化することです。後者について、Google検索であれば人気度、全体的なユーザー価値、コンテンツの独自性、配信能力といった要素が考慮されると書かれています。
実務への影響と、今日からできる確認手順
今回の追記で実務が変わるのは、主に大規模サイトとクローラー由来の負荷が読めていないサイトです。原文と公式ドキュメントの範囲で、手を動かせる順に整理します。
- サーバーログでGoogleのどのクローラーがどれだけ来ているかを分ける。クロール上限が全クローラー共有だと明記されたため、画像や広告関連のクローラーの負荷がGooglebotの取り分を圧迫していないかを見る価値があります。
- 5xxとHTTP 429の発生状況を確認する。ドキュメントはこの2つを、クロール上限が下がる条件として名指ししています。
- 応答時間の推移を見る。レイテンシとTime-to-First Byteが安定または改善しているかが、上限の上下に効くと書かれています。
- 304を返せているかを確認する。今回の追記でGoogleが推奨した項目です。
- 不要URLの扱いを見直す。クロールさせたくないページにnoindexを使っているなら、ドキュメントの推奨はrobots.txtでのブロックです。
※以下はScale Basics編集部による一般的な実務上の補足です。304はサーバーが単独で自由に返すコードではなく、クライアント側の条件付きリクエスト(If-Modified-SinceやIf-None-Match)に対して「変わっていない」と答えるための応答です。したがって実装の確認は、Last-ModifiedやETagといった検証用ヘッダーを返せているかから入るのが手順として自然です。CDNやリバースプロキシを挟んでいる場合は、その層でヘッダーが落ちていないかも見どころになります。ここは公式ドキュメントが踏み込んでいない部分ですので、自社環境での検証をおすすめします。
所感
ここからは記事本文にはない、Scale Basics編集部の見解です。2点の追記のうち、影響が広いのは「クロール上限は全クローラーで共有」の明文化だと考えます。これまでもログを見ていた運営者は経験的に気づいていた話ですが、公式に書かれたことで、社内で説明する根拠が持てるようになりました。画像や動的広告のクローラーの負荷が高いサイトでは、Googlebotのクロールが伸びない理由の候補として最初に挙げられる説明になります。
304の推奨は、SEOの施策というよりサーバー運用の作法に近い話です。ただ、更新のないページが大量にあるサイトほど効果が出やすい構造なので、ページ数が多いメディアやEC、そして生成されるURLが多いサイトでは検討に値します。逆に数百ページ規模のサイトが優先して取り組むべき項目とは言いにくく、そこは対象読者を「100万ページ超・1万ページ超で頻繁に更新」と明示しているドキュメントの立場どおりだと見ています。
もうひとつ、今回の更新でGoogleが「クロールされても必ずインデックスされるわけではない」という一文を文書内に置いていることは、クロールバジェットの議論が独り歩きしないための歯止めとして機能します。クロール効率の改善はインデックス登録の保証ではありません。この順序を混同しないことが、施策の優先順位を誤らないための前提になります。
まとめ
・Search Engine Journalが2026年8月3日付で、Googleのクロールバジェット最適化ドキュメントに2点の追記があったと報告した(報告者はRoger Montti氏)
・1点目は「各クローラーのクロール需要は異なるが、クロール処理能力の上限は全クローラーで共有される」という説明で、あるクローラーの高需要が他のクローラーの取り分を減らしうると明記された
・2点目は304 (Not Modified)のサポート推奨で、前回クロール時からページが変わっていなければ304を返すことでGoogleにキャッシュ版を再利用させ、サーバーの帯域と資源を節約できるとされた
・原文はこの2点が新規追加のすべてであり、残りはより正確な記述にするための修正だとしている。公式ドキュメント側の最終更新は2026年7月22日(UTC)
・対象は100万ページ超のエンタープライズサイトと1万ページ超で頻繁に更新される中規模サイトだが、クロールの仕組みを理解する情報としてはそれ以外のサイトにも有用だと原文は述べている
よくある質問
Q1: 304 Not Modified はリダイレクトの一種なのですか?
Search Engine Journalは、技術的には3xx系のステータスコードがすべてリダイレクトのコードに分類される一方で、304では実際には何もリダイレクトされていないと説明しています。MDNの記述として引用されているのは「要求されたリソースを再送する必要がないことを示す」という定義です。Googleのドキュメントでの位置づけも、リダイレクトではなくHTTPキャッシュの活用として整理されています。
Q2: クロール上限が全クローラーで共有されると、具体的に何が起きますか?
公式ドキュメントの記述では、あるクローラーからの高い需要が、他のクローラーに使える処理能力を減らしうるとされています。Search Engine Journalが挙げている例は、サイトがGooglebot-ImageとGooglebotの両方にクロールされている場合、両者が同じサイトのクロールバジェットを共有しているという形です。片方の高頻度クロールが、もう片方の取り分を圧迫しうるという理解になります。
Q3: このドキュメントは小規模サイトにも関係しますか?
ドキュメント自体は、100万ページを超えるエンタープライズサイトと、1万ページを超えて頻繁に内容が変わる中規模サイトに向けたものです。ただしSearch Engine Journalは、すべてのサイトを対象にした文書ではないとしつつ、クロールがどう機能するかを理解するうえでこのページの情報は有用だと述べています。小規模サイトでは、304の実装よりも5xxや429の発生、応答時間の安定といった基礎的な部分の確認が先に来ると読むのが妥当です。
出典:Google Recommends Using 304 Status Code To Conserve Crawl Budget(Search Engine Journal、Roger Montti氏、2026年8月3日)https://www.searchenginejournal.com/google-recommends-using-304-status-code-to-conserve-crawl-budget/584543/／Large site owner’s guide to managing your crawl budget(Google Search Central、最終更新2026年7月22日UTC)https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget
