クロールバジェットは気にしなくていい？中小サイトの正しい対処

「クロールバジェットを増やせば、もっとインデックス（検索エンジンのデータベースへのページ登録）が進むはず」——そう考えて robots.txt をいじったり、巡回頻度を上げる方法を探したりしていないでしょうか。この記事は、自社サイトを自分で直すエンジニアやサイト担当者に向けて、クロールバジェットとの正しい向き合い方を整理するものです。

先に結論を書きます。多くの中小規模サイトにとって、クロールバジェットは基本的に気にしなくてよいものです。あとで公式ドキュメントの言葉で確かめますが、Google 自身が、クロールバジェットの管理を考えるべきサイトの目安を公式に示していて、多くの中小サイトはその手前にいます。それより、Search Console の「クロールの統計情報」レポートでサーバーの応答状態を確認するほうが、実務ではずっと役に立ちます。この記事では、クロールバジェットが何で決まるのか、なぜ中小サイトでは気にしなくてよいのか、そして代わりに何を見ればいいのかを、Google の公式ドキュメントに沿って順に確かめます。

そもそもクロールバジェットとは何か

「クロール（Googlebot＝検索ロボットによるサイトの巡回・データ収集）」に Google が割く時間とリソースの量を、通称クロールバジェットと呼びます。公式ドキュメントは、これが2つの主な要素で決まると説明しています。「クロール能力の上限（crawl capacity limit）」と「クロールの必要性（crawl demand）」の2つです。

かみ砕くと、前者は「サーバーに負担をかけずにどれだけ巡回できるか」という物理的な余裕、後者は「そのサイトをどれだけ巡回する必要があるか」という需要です。クロールの必要性のほうは、公式ドキュメントによれば、サイトの規模・更新の頻度・ページの品質・関連性などから判断されます。裏を返すと、更新が少なく規模も小さいサイトでは、そもそも頻繁に巡回する「必要性」が高くない、ということでもあります。

ここで押さえておきたいのは、クロールされたページがすべてインデックスされるわけではない、という点です。公式ドキュメントは「クロールされたすべてのページが必ずインデックスされるわけではなく、クロール後に各ページは評価・統合・査定される」と述べています。つまり、巡回されること自体はゴールではなく、その先に品質評価という関門があるということです。

中小サイトが「気にしなくていい」理由

では、どのくらいの規模から対策を考えるべきなのでしょうか。公式ドキュメントは、クロールバジェットを気にすべきサイトの目安として次のように挙げています。「1万ページ以上のユニークなページを持ち、コンテンツが日次で非常に速く更新される中〜大規模サイト」、そして**「URL の大部分が Search Console で『検出 - 現在インデックス未登録』に分類されているサイト」**です。

そして同じ公式ドキュメントは、この数字について重要な但し書きを添えています。「ここで示した数値は、サイトを分類するのに役立てるためのおおまかな見積もりであって、正確なしきい値ではありません」。つまり「1万ページ」は絶対的な境界線ではなく、目安です。とはいえ、数百〜数千ページ規模で毎日大量の更新をしているわけでもないサイトなら、この目安のはるか手前にいることになります。

この事実が、日々の不安をかなり軽くしてくれます。「新しいページがなかなか登録されない」「更新がすぐ反映されない」といった悩みを、反射的に『クロールバジェットが足りないせいだ』と結びつける必要はありません。規模の目安から外れているサイトでは、その原因は別のところにある可能性が高いからです。

未登録＝バジェット不足、とは限らない

ここはよくある誤解なので、独立させて扱います。巡回の頻度が少なく見えることと、クロールバジェットが不足していることは、イコールではありません。

たとえば「検出 - 現在インデックス未登録」が並んでいると、つい「巡回の予算が足りていない」と考えたくなります。しかし前の節で見たとおり、公式ドキュメントが目安として挙げているのは、あくまで「URL の大部分がこの状態に分類されるようなサイト」です。中小サイトで一部のページが未登録という程度なら、その目安には当てはまりません。この場合の未登録は、クロールの予算そのものよりも、コンテンツの品質やサイト構造、重複といった別の要因によることが少なくありません。公式ドキュメントも、クロールの効率を上げる打ち手として「重複コンテンツを統合し、ユニークな URL ではなくユニークなコンテンツにクロールを集中させる」ことを挙げています。

そのため、未登録が気になるときにまず疑うべきは、巡回頻度そのものではなく「そのページに登録される価値があるか」「重複や薄い内容になっていないか」です。インデックスされない原因の切り分けは インデックスされない原因の診断 でも扱っています。

代わりに見るべき「クロールの統計情報」レポート

クロールバジェットの数字を追う代わりに、実際にサーバーとクロールの健康状態を見られるのが、Search Console の「クロールの統計情報」レポートです。このレポートは、ルートレベルのプロパティ（https://example.com のようにサイト全体を対象にしたプロパティ）で利用できます。開き方は次のとおりです。

1. ルートレベルのプロパティを開く：Search Console で、https://example.com のようにサイト全体を対象にしたルートレベルのプロパティを開きます。公式ヘルプでも、このレポートはルートレベルのプロパティで確認できると案内されています。
2. 設定からレポートを開く：（プロパティ設定）を開き、そこから「クロールの統計情報」を選びます。公式ヘルプでも、Property settings（プロパティ設定）＞ Crawl stats（クロールの統計情報）の順にたどると案内されています。
3. サーバーが健全に応答できているかに注目する：ここで確かめたいのは、Googlebot の巡回に対してサーバーが安定して応答できているか、という点です。応答が重くなっている兆候があれば、巡回の予算より先にサーバー側を疑うサインになります。
4. 問題が特定の範囲に偏っていないかを見る：うまく処理できていないリクエストが特定のディレクトリに偏っていないかにも注意すると、原因の当たりをつけやすくなります。
5. robots.txt の取得状況を確認する：公式ヘルプによれば、robots.txt の取得が成功していればクロールを開始でき、取得が最初の12時間失敗するとクロールを停止し、12時間〜30日は最後に取得できた内容を使い続ける、といった挙動になります。取得が恒常的に失敗していないかを見ておきます。

この5ステップで、「巡回の予算が足りない」という漠然とした不安を、「応答が遅いページはどこか」「エラーを返しているディレクトリはどこか」という具体的な調査対象に置き換えられます。これがクロールバジェットを直接いじるより実効性のある独自の打ち手です。

クロール頻度は「増やす」ものではなく「守る」もの

「巡回頻度を上げたい」という発想も、公式の仕組みを知ると位置づけが変わります。Search Console のヘルプは、クロール頻度についてはっきりこう述べています。「クロール頻度の増加をリクエストすることはできません」。用意されているのは、巡回が異常に多くサーバーに負担がかかっているときに、頻度を下げるようリクエストする機能のほうです（しかも、リクエストが審査・処理されるまで数日かかることがあるとされています）。

さらに、短時間で急いで巡回を抑えたい場合の挙動も公式に説明されています。クロールのリクエストに対して 200 の代わりに 500・503・429 のいずれかの HTTP ステータスコードを返すと、Google のクローラー基盤が巡回の速度を落とす、というものです。つまり、サイト側から巡回頻度を一律に「増やす」ためのレバーは用意されておらず、増やそうとする操作はできない前提に立つ必要があります。

逆に、頻度が下がったときの影響も知っておく価値があります。公式ヘルプは、巡回が減ると「検出できる新規ページが少なくなる」「既存ページの更新頻度が下がり、価格や在庫状況が検索に反映されるまで時間がかかる」「削除済みページがインデックスに残る時間が長くなる」といった影響が起こり得るとしています。だからこそ、頻度を増やそうとするより、サーバーを安定して速く保ち、Google が巡回したくなる状態を「守る」ほうが理にかなっています。

なお、Google が巡回したくなる状態を保つという意味では、サイトマップを正しく送信し、内部リンクをたどりやすく整えておくことも助けになる場合があります。巡回のしやすさそのものを底上げする打ち手として、内部リンクの最適化 もあわせて検討する価値があります。

robots.txt でクロールを絞るときの注意

クロールを制御しようとして、まっさきに robots.txt に手を伸ばす人は多いです。ただ、robots.txt の役割を取り違えると逆効果になります。公式ドキュメントは、robots.txt について「サイト上の URL への検索エンジンのクローラーのアクセスを管理するもので、主な目的はサーバーの過負荷を避けることだ」と説明しています。そして、こう釘を刺しています。「ページを Google から隠すためのものではない。そのためには noindex を使うか、パスワード保護を使うこと」。

つまり robots.txt は「クロールさせない」指示であって、「検索結果に出さない」指示ではありません。検索結果から確実に消したいページには、robots.txt でのブロックではなく、noindex かパスワード保護を使うよう公式は案内しています。クロールバジェットの節約目的で不要な URL のクロールをブロックすること自体は、公式も打ち手として挙げていますが、その対象は「ユーザーには必要でも Google の各サービスに出す必要がないページ」であって、検索から消したいページとは別の話だと切り分けてください。

自己点検チェックリスト

自分のサイトがクロールバジェットを気にすべき側にいるのか、それとも別の対処に進むべきかを、次の観点で見分けます。

左から順に見て、上2行が「気にしなくてよい」側なら、クロールバジェットそのものは論点から外して構いません。そのうえで、下3行で見つかった具体的な問題（未登録・遅い応答・エラー）を、一つずつ対処していくのが実務的な順番です。

まとめ

クロールバジェットの管理を公式が勧めているのは、1万ページ以上かつ日次で更新が非常に速いサイトや、URL の大部分が未登録に分類されるようなサイトです。多くの中小サイトはこの目安の手前にいるため、基本的に気にしなくてよいものです。数字を上げようとして robots.txt を触るより先に、Search Console の「クロールの統計情報」でサーバーの応答時間とエラーの内訳を確認するほうが、はるかに具体的で効果のある一手になります。

クロール頻度をサイト側から一律に「増やす」ことはできません。できるのは、サーバーを安定して速く保ち、サイトマップと内部リンクで巡回しやすい道筋を整え、robots.txt と noindex の役割を取り違えないこと——つまり巡回したくなる状態を守ることです。未登録が気になるときは インデックスされない原因の診断 を、巡回のしやすさを底上げしたいときは 内部リンクの最適化 をあわせてご覧ください。