クロールバジェット

TL;DR — クロールバジェットとは、検索エンジンがサイトをクロールしようとする量です。これは、サーバーが処理できる量とGoogleがクロールしたい量の組み合わせで決まります。クロール量を増やしても順位は上がらず、多くのサイトでは問題になりません。公開したページが同じ日にクロールされるなら、クロールバジェットの問題はありません。

クロールバジェットとは

検索エンジンは、サイトを無制限にクロールするわけではありません。一定の時間内にいくつかのURLをクロールすると、別の処理へ移ります。この量をSEOではクロールバジェットと呼びます。

検索エンジンは常に、次の2つを判断しています。

• どれだけクロールできるか。 サーバーが処理できる量には限界があり、負荷が高まると遅延やエラーが発生します。Googleはその状態を監視してクロールを抑えます。これがクロール容量で、以前の文書ではクロール速度の上限と呼ばれていました。
• どれだけクロールしたいか。 人気があるページや頻繁に変わるページは多くクロールされます。リンクがほとんどなく、変化もしないページの頻度は下がります。これがクロール需要です。

この2つを組み合わせたものがクロールバジェットです。大まかには、Googleがクロールでき、かつクロールしたいURLの数を意味します。 Evidence for this claim Google defines crawl budget using crawl capacity limit and crawl demand. Scope: Google Search crawling for larger sites. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

ここで重要なのは、クロールバジェットがGoogleによるURLの取得を扱う点です。取得した内容をインデックス登録するかは、その後に行われる別の判断です。ページがクロールされても登録されないことはあります。クロールは登録を保証せず、最初に通過すべき段階にすぎません。

まず理解すべきこと：多くのサイトは心配不要

多くの記事が目立たせない重要な点があります。ほとんどのサイトにクロールバジェットの問題はありません。 Googleも、ページが公開当日にクロールされる場合や、サイトが巨大で頻繁に変化するわけではない場合、この問題を考える必要はないと説明しています。 Evidence for this claim Google says sites without many rapidly changing pages, or whose pages are crawled the day they publish, generally do not need crawl-budget guidance. Scope: Google's rough applicability guidance, not a guarantee for every site. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

簡単に確認するには、いくつかのURLをGoogleで検索するか、Search ConsoleのURL検査ツールを使います。新しいページが1～2日以内に確認できるなら、クロールバジェットは十分です。代わりにコンテンツやリンクへ時間を使ってください。

クロールバジェットが問題になり始めるのは、サイトに数十万～数百万ページがあり、その多くが絶えず変化する場合です。大規模なECサイトやニュースサイトが該当します。

クロール量を増やしても順位は上がらない

よくある誤解を先に否定します。ページのクロール頻度を上げても検索順位は上がりません。クロールは検索エンジンがページを発見して取得する方法です。検索結果に表示されるための前提ではありますが、再クロールの頻度自体はランキング要因ではありません。

したがって、目標は「クロールを増やす」ことではありません。重要なページがクロールされ、不要なURLに検索エンジンの時間を浪費させないことが目標です。

クロールバジェットを浪費するもの

大規模サイトでは、次の要因がクロールバジェットを消費します。

• 絞り込み・並べ替えURL（ファセットナビゲーション）— ECサイトでは、フィルターの組み合わせごとに、ほぼ同一のURLが数千件生まれることがあります。
• 重複ページ — wwwの有無やパラメータ付きURLなど、同じ内容へ複数のURLから到達できる状態です。
• ソフトエラーページ — 「見つかりません」と表示しながら200 OKを返すため、検索エンジンがクロールを続けます。
• 壊れたリダイレクトチェーンや遅いページ — 1回のクロールに必要な処理を増やします。

ほとんどの場合、解決策はGoogleにクロール量を増やすよう求めることではなく、無駄を取り除き、実際のページへクロールを集中させることです。

クロール容量と需要の関係、具体的な規模の目安、ファセットナビゲーションへの対処、Bingとの違い、測定方法については、Advancedタブを参照してください。

要点 — クロールバジェットは、クロール容量の上限（サーバーが処理できる量）とクロール需要（人気度、更新からの経過時間、認識されているURL在庫）の組み合わせです。ランキングシグナルではなく効率の問題であり、内部ではサイトごとの固定枠ではなく、ホスト負荷を上限とする重要度順のスケジューリングとして動きます。ほとんどのサイトは無視できます。Muellerによれば十万URLでは通常問題にならず、Googleも公開当日にクロールされるサイトはガイドを読む必要がないとしています。問題になりやすいのは、週単位で変わる約百万ページ以上、毎日変わる一万ページ以上、または「検出 - インデックス未登録」が増えている場合です。最も効果が大きい対策は、ファセットURL、重複、ソフトエラーページ、無限空間を減らし、重要なURLにクロールを集中させることです。

2要因モデル

Googleは明確に定義しています。“The amount of time and resources that Google devotes to crawling a site is commonly called the site’s crawl budget and it’s determined by two main elements: crawl capacity limit and crawl demand.” (翻訳) 「Googleがサイトのクロールに充てる時間とリソースの量は一般にサイトのクロールバジェットと呼ばれ、クロール容量の上限とクロール需要という2つの主要要素で決まります。」 Gary Illyesが2017年に示した、今でも使いやすい一文は、クロールバジェットとは*“the number of URLs Googlebot can and wants to crawl.”* (翻訳) 「Googlebotがクロールでき、かつクロールしたいURLの数」です。 Evidence for this claim Google defines crawl budget using crawl capacity limit and crawl demand. Scope: Google Search crawling for larger sites. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide 範囲を混同しないでください。クロールバジェットが左右するのは取得であり、インデックス登録ではありません。クロール済みURLも別の登録判断を受けるため、両者を一緒にするとクロールバジェットの影響を誇張します。

クロール容量の上限（供給側）。 Googleの定義では、“the maximum number of simultaneous parallel connections that Google can use to crawl a site, as well as the time delay between fetches.” (翻訳) 「Googleがサイトのクロールに使用できる同時並列接続の最大数と、取得間隔」です。 この上限はサーバーの健全性で変わります。高速で正常な応答が続けば上がり、遅い応答、5xxエラー、429が発生すればGooglebotは速度を落とします。私のHow Search Works資料 でも、サーバーの安定性、遅い応答、5xxサーバーエラー、429（リクエスト過多）を速度制限の要因として挙げています。これが「できる量」です。

クロール需要（需要側）。 主な要因は、URLへのリンクや重要度を表す人気度と、最後のクロールからの経過時間や変更頻度を表す古さです。同じ資料 では、PageRank、ページの変更頻度、最終クロールからの時間、大規模なサイト変更に分けています。特にGoogleは、制御しやすい要因として認識されているURL在庫を挙げています。“Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site. If many of these URLs are duplicates, or you don’t want them crawled for some other reason… this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” (翻訳) 「指示がなければ、Googleは認識しているURLのすべて、または大部分をクロールしようとします。重複URLや、ほかの理由でクロールしてほしくないURLが多いと、サイトに対するGoogleのクロール時間が大きく浪費されます。これは最も積極的に制御できる要因です。」

見落とされやすい構造上の事実が2つあります。

• バジェットはホスト名単位です。 “https://www.example.com/ and https://code.example.com/ are two different hostnames, and therefore have separate crawl budgets.” (翻訳) 「https://www.example.com/とhttps://code.example.com/は別のホスト名なので、クロールバジェットも別です。」サブドメイン間では共有されません。
• 異なるGooglebot種別は1つの枠を共有している可能性があります。 私自身のレポートでは、画像、ニュース、動画、広告などが同じサイト単位の枠を使っているように見えます。ただし、これを厳密に裏付ける現在のGoogle一次資料はないため、公式方針ではなく実務上の観察として扱ってください。特定の種類がほかを圧迫している疑いがあれば、Crawl Statsレポートのクローラー種別内訳を確認する価値があります。

内部の実態：重要度に基づくスケジューリング

「クロールバジェット」はSEO業界が作った包括的な呼び方です。内部の仕組みは、ホスト負荷を上限とするスケジューリングに近いものです。IllyesはGoogleのスケジューラーについて、“sets a bucket of URLs in importance order and GoogleBot will crawl in that order based on the schedule the host load decided. If Google thinks your server can handle it, it will crawl the whole bucket, if not, it will stop.” (翻訳) 「URLを重要度順のバケットに入れ、ホスト負荷が決めたスケジュールに従ってGooglebotがその順でクロールする。サーバーが処理できると判断すればバケット全体をクロールし、できなければ止める」と説明しています。

この見方をすると全体像が変わります。1日Nページという一律の割り当てではなく、優先順位付きキューであり、クロールは検索需要に連動します。Illyesはさらに、“If search demand goes down, then that also correlates to the crawl limit going down,” (翻訳) 「検索需要が下がると、クロール上限の低下とも相関する」 また、“if you want to increase how much we crawl, then you somehow have to convince search that your stuff is worth fetching, which is basically what the scheduler is listening to.” (翻訳) 「クロール量を増やしたいなら、取得する価値があると検索側に納得させる必要があり、スケジューラーは基本的にそれを見ている」と述べています。Search Relationsチームも「1日当たりの固定ページ枠」という考えを誤解だと明言しています。

本当にクロールバジェットの問題があるか

ここが最も重要なので率直に言います。ほとんどのサイトはクロールバジェットを心配する必要がありません。 Googleのガイドは次の説明から始まります。“If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide. For Google Search specifically, merely keeping your sitemap up to date and checking your index coverage regularly is adequate.” (翻訳) 「急速に変化するページが大量にない場合、または公開当日にページがクロールされている場合、このガイドを読む必要はありません。Google検索では、サイトマップを最新に保ち、インデックスカバレッジを定期的に確認するだけで十分です。」 Evidence for this claim Google says sites without many rapidly changing pages, or whose pages are crawled the day they publish, generally do not need crawl-budget guidance. Scope: Google's rough applicability guidance, not a guarantee for every site. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

John Muellerは具体的な目安として、“100k URLs is usually not enough to affect crawl budget (it’s <1/minute over 3 months).” (翻訳) 「十万URLでは通常クロールバジェットに影響するほどではありません（3か月で1分当たり1URL未満です）」と述べています。URLが十万件未満でページが速やかにクロールされているなら、ほかの課題を優先してください。

問題になる場合について、Googleはおおよそ次の目安を示しています。

• 大規模サイト — 約週1回の頻度で変化する固有ページが百万件以上。
• 中規模以上のサイト — 毎日変化する固有ページが一万件以上。
• Search Consoleで「検出 - インデックス未登録」に分類されるURLが多いサイト — GoogleがURLを認識しているのに取得へ進めていない警告です。

Googleは*“the numbers given here are a rough estimate… not exact thresholds.”* (翻訳) 「ここで示した数値は概算であり、厳密なしきい値ではない」と付記しています。大規模サイトでも、遅れやすいのは人気ページではなく、新規、内部リンクが弱い、または静的なページであることが多いというのが私の実務上の見方です。

クロールバジェットは順位に影響するか：しない

順位を得るにはクロールが必要ですが、クロール自体はランキングシグナルではありません。Googleは2017年に、“An increased crawl rate will not necessarily lead to better positions in Search results. Google uses hundreds of signals to rank the results, and while crawling is necessary for being in the results, it’s not a ranking signal.” (翻訳) 「クロール速度を上げても検索結果の順位向上に直結するとは限りません。Googleは数百のシグナルで順位を決めます。検索結果に含まれるにはクロールが必要ですが、ランキングシグナルではありません」と説明しました。私もAhrefsの記事で、“More crawling doesn’t mean you’ll rank better, but if your pages aren’t crawled and indexed they aren’t going to rank at all.” (翻訳) 「クロールが増えても順位は上がりませんが、ページがクロールもインデックス登録もされなければ、そもそも順位は付きません」と書いています。クロールバジェットは効率の問題として扱ってください。

クロールバジェットを浪費するもの

Illyesは価値の低いURLの代表例を*“in order of significance”* (翻訳) 「重要度順」に公開しました。

1. ファセットナビゲーションとセッションID — 最大の原因です。特にECサイトの絞り込みや並べ替えの組み合わせはURLを急増させます。
2. サイト内の重複コンテンツ — HTTPとHTTPS、wwwの有無、末尾スラッシュ、大文字小文字、default/indexページ、URLパラメータなどの技術的な違いです。Googleの内部推定では、ウェブのおよそ60%が重複コンテンツです。
3. ソフトエラーページ — 見つからない内容なのに200を返すページはクロールされ続けます。
4. ハッキングされたページ。
5. 無限空間とプロキシ — カレンダー、重複を生む無限スクロール、ファセットの組み合わせなど、典型的なスパイダートラップです。
6. 低品質コンテンツとスパム。

具体的な損失について、“Wasting server resources on pages like these will drain crawl activity from pages that do actually have value, which may cause a significant delay in discovering great content on a site.” (翻訳) 「このようなページにサーバー資源を浪費すると、本当に価値のあるページからクロール活動が奪われ、優れたコンテンツの発見が大幅に遅れる可能性がある」と説明されています。さらに、長いリダイレクトチェーンは*“have a negative effect on crawling,”* (翻訳) 「クロールに悪影響を与え」、遅く重いページは取得コストを増やします。

最適化する方法

要点は、重要なURLへクロールバジェットを集中させることです。

• 重複を統合する。 Googleは*“Consolidate duplicate content to focus crawling on unique content rather than unique URLs.”* (翻訳) 「重複コンテンツを統合し、固有URLではなく固有コンテンツにクロールを集中させる」と案内しています。ホスト、プロトコル、末尾スラッシュの規則を1つに決め、canonicalとパラメータを適切に処理します。
• 本当に価値のないパスをrobots.txtでブロックする。 対象は今後もクロールさせないパスだけです。ファセットナビゲーションでは、パラメータ付きパスをrobots.txtで止めるか、?ではなく#を使って最初からクロール可能なURLにしない方法があります。
• バジェット節約のためにnoindexを使わない。 Googleは*“Don’t use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time.”* (翻訳) 「noindexを使ってもGoogleはページをリクエストし、レスポンス内のnoindexを見てから破棄するため、クロール時間を浪費する」と説明しています。取得させたくない場合はrobots.txtで止めます。
• robots.txtで空いた枠が自動的に再配分されると期待しない。 “Google won’t shift this newly available crawl budget to other pages unless Google is already hitting your site’s serving limit.” (翻訳) 「サイトの配信上限にすでに達していない限り、Googleは新たに空いたクロールバジェットをほかのページへ移さない」とされています。不要URLのブロックは有益ですが、容量上限に達していなければ、空いたクロールが良いページへ渡るわけではありません。
• ソフトエラーページを直し、削除済みページには本当の404/410を返す。 “A 404 status code is a strong signal not to crawl that URL again.” (翻訳) 「404ステータスコードは、そのURLを再びクロールしないよう伝える強いシグナル」です。
• リダイレクトチェーンを短くし、サイトマップを最新に保ち（正確なlastmodを使い）、サーバーを高速化する。
• 重要な新規ページへの内部リンクを強化する。 自分で完全に制御できるため、実行しやすい対策です。

Googleが実際にバジェットを増やす方法として挙げるのは、次の2つだけです。“Add more server resources… [and] optimize your content’s quality.” (翻訳) 「サーバー資源を増やし、コンテンツの品質を最適化する」です。高速なサーバーは容量の上限を引き上げますが、需要が低ければGoogleのクロール量は少ないままです。両方が必要です。

測定方法

• GSC > 設定 > クロールの統計情報レポート — 時系列の総クロールリクエスト数、平均応答時間、ホストの状態、応答コード・ファイル形式・Googlebot種別ごとの内訳を確認できます。Google自身から見たクロール状況です。
• サーバーログ分析 — 実際の状況を示す一次データです。URLパターン別の本物のGooglebotアクセスから、クロールの無駄と未クロールの重要ページを把握できます。ユーザーエージェントを偽装するbotも多いため、逆引き・正引きDNSまたはGoogle公開のIP範囲でGooglebotを検証してください。
• GSCの「検出 - インデックス未登録」 — 増加している場合、GoogleはURLを認識しているものの取得へ進めていないため、クロールバジェットの警告として扱います。

Bingなどの検索エンジン：「クロール効率」

Bingはバジェットではなくクロール効率として捉えます。Fabrice Canelの定義は、“The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” (翻訳) 「クロールした1ページ当たり、どの程度の頻度で新しく新鮮なコンテンツをクロールし発見できるか」です。目標は*“crawl an URL only when the content has been added (URL not crawled before), updated (fresh on-page context or useful outbound links).”* (翻訳) 「コンテンツが追加されたとき（未クロールのURL）、または更新されたとき（新鮮なページ内容や有用な外部リンク）だけURLをクロールする」ことです。Bingの端的な考え方は、“Less is more for SEO. Never forget that. Less URLs to crawl, better for SEO.” (翻訳) 「SEOでは少ないほどよい。忘れないでください。クロールするURLが少ないほどSEOにはよい」です。

Bingが推奨する対策はIndexNowです。変更したURLを通知すれば、bingbotが探索目的でクロールする必要を減らせます。また、Bing Webmaster ToolsのCrawl Controlでは、サーバー負荷を守るためにbingbotがクロールする時間帯を1時間単位で設定できます。ここはGoogleとBingの実質的な違いです。GoogleはSearch Consoleの旧クロール速度制限機能を廃止しましたが、Bingでは現在もクロール予定を能動的に調整できます。

クロールバジェットに関する誤解

• 「すべてのサイトがクロールバジェットを最適化すべき」 — いいえ。公開当日にクロールされ、URLが十万件未満なら通常は問題ありません。
• 「クロールが増えると順位が上がる」 — いいえ。クロールは必要ですが、ランキングシグナルではありません。
• 「1日当たりの固定ページ枠である」 — いいえ。ホスト負荷を上限とした重要度順のスケジューリングです。
• 「noindexでバジェットを節約できる」 — いいえ。Googleは先にページをリクエストします。
• 「robots.txtでページを止めれば、ほかのページに枠が回る」 — 通常は違います。配信上限に達している場合に限られます。
• 「サーバーを速くするだけでバジェットが増える」 — 容量の上限は上がりますが、需要が低ければクロールは増えません。

この仕組みを含む広い流れ、つまり発見、クロールスケジューラー、レンダリング、クロールとインデックス登録の違いについては、クローリングのハブを参照してください。関連トピックのクロール速度、クロール頻度、スパイダートラップ、ログファイル分析では、それぞれの要素を詳しく扱っています。

AIによる要約

Advanced版の要点です。

• クロールバジェット = クロール容量の上限 × クロール需要。 容量はサーバーが処理できる量で、高速かつ正常な応答で上がり、5xxや429で下がります。需要は人気度、更新からの経過時間、認識されているURL在庫です。Googleの一文では「Googlebotがクロールでき、かつクロールしたいURLの数」です。
• ランキング要因ではありません。 順位を得るにはクロールが必要ですが、クロール量を増やしても順位は上がりません。効率の問題です。
• 内部ではホスト負荷を上限とする重要度順のスケジューリングです。 1日当たりの固定枠ではなく、検索需要に連動する優先順位付きキューです。
• ほとんどのサイトは管理不要です。 Muellerによると十万URLでは通常問題にならず、Googleも公開当日にクロールされるならガイドを読む必要はないとしています。週単位で変わる約百万ページ以上、毎日変わる一万ページ以上、または「検出 - インデックス未登録」が大量にある場合に問題になります。
• 主な浪費要因： ファセットナビゲーションやセッションID、重複コンテンツ、ソフトエラーページ、ハッキングされたページ、無限空間、低品質コンテンツに加え、リダイレクトチェーンや遅いページです。
• 無駄を減らして最適化します。 重複を統合し、価値のないパスをrobots.txtで止め、ソフトエラーページと長いリダイレクトを修正し、サイトマップと内部リンクを整えます。noindexでは取得を防げません。バジェットを本当に増やす方法は、サーバー容量とコンテンツ品質を上げることです。
• 測定には GSCのクロール統計、サーバーログ、「検出 - インデックス未登録」レポートを使います。
• Bingはクロール効率と呼び、 Googleより能動的なIndexNowとCrawl Controlを推奨します。

公式ドキュメント

検索エンジンが公開している一次資料です。

Google

• クロールバジェットの最適化 — 旧「大規模サイト所有者向けガイド」から移動した現行の標準文書です。クロール容量と需要、対象サイト、浪費要因、最適化方法を説明しています。最初に読む資料です。
• Googlebotにとってのクロールバジェットの意味（Gary Illyes、2017） — クロール速度の上限、クロール需要、価値の低いURL分類を示した原典です。
• クロールとインデックス登録 — robots、サイトマップ、canonicalization、クロール制御のハブです。
• Crawling Decemberシリーズ（2024） — Googlebot、HTTPキャッシュ、ファセットナビゲーション、CDNを扱うシリーズです。

Bing / Microsoft

• bingbotシリーズ：クロール効率の最大化 — Bingによる「クロール効率」の捉え方と目標です。
• bingbotシリーズ：クロール頻度の最適化 — Bingが再クロール頻度を決める仕組みです。
• Bing Webmaster Tools — クロール制御 — bingbotがクロールする時間帯を設定できます。
• IndexNow / indexnow.org — 変更URLを通知し、探索クロールを減らします。

出典からの引用

GoogleとBingによる記録済みの発言です。各リンクは、引用箇所へ移動するディープリンクです。

Google — 定義

• “The amount of time and resources that Google devotes to crawling a site is commonly called the site’s crawl budget and it’s determined by two main elements: crawl capacity limit and crawl demand.” (翻訳) 「Googleがサイトのクロールに充てる時間とリソースの量は一般にサイトのクロールバジェットと呼ばれ、クロール容量の上限とクロール需要という2つの主要要素で決まります。」 — Google Search Central docs. 引用箇所へ
• “Google’s crawlers calculate a crawl capacity limit, which is the maximum number of simultaneous parallel connections that Google can use to crawl a site, as well as the time delay between fetches.” (翻訳) 「Googleのクローラーは、サイトのクロールに使用できる同時並列接続の最大数と取得間隔から、クロール容量の上限を計算します。」 引用箇所へ
• “Taking crawl rate and crawl demand together we define crawl budget as the number of URLs Googlebot can and wants to crawl.” (翻訳) 「クロール速度とクロール需要を合わせ、クロールバジェットをGooglebotがクロールでき、かつクロールしたいURLの数と定義します。」 — Gary Illyes, Google (2017). 引用箇所へ

Google — 対策が不要な場合

• “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (翻訳) 「急速に変化するページが大量にない場合、または公開当日にページがクロールされている場合、このガイドを読む必要はありません。」 引用箇所へ
• “100k URLs is usually not enough to affect crawl budget (it’s <1/minute over 3 months).” (翻訳) 「十万URLでは通常クロールバジェットに影響するほどではありません（3か月で1分当たり1URL未満です）。」 — John Mueller, Google (2021). 関連記事

Google — 制御できる要因と、クロールと順位の違い

• “If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” (翻訳) 「重複URLや、削除済み・重要でないなどの理由でクロールしてほしくないURLが多いと、サイトに対するGoogleのクロール時間が大きく浪費されます。これは最も積極的に制御できる要因です。」 引用箇所へ
• “An increased crawl rate will not necessarily lead to better positions in Search results. Google uses hundreds of signals to rank the results, and while crawling is necessary for being in the results, it’s not a ranking signal.” (翻訳) 「クロール速度を上げても検索結果の順位向上に直結するとは限りません。Googleは数百のシグナルで順位を決めます。検索結果に含まれるにはクロールが必要ですが、ランキングシグナルではありません。」 — Gary Illyes, Google (2017). 引用箇所へ

Google — 浪費要因と避けるべきこと

• “Faceted navigation and session identifiers / On-site duplicate content / Soft error pages / Hacked pages / Infinite spaces and proxies / Low quality and spam content” (翻訳) 「ファセットナビゲーションとセッションID／サイト内の重複コンテンツ／ソフトエラーページ／ハッキングされたページ／無限空間とプロキシ／低品質コンテンツとスパム」— 重要度順の低価値カテゴリです。 — Gary Illyes, Google (2017). 引用箇所へ
• “Consolidate duplicate content to focus crawling on unique content rather than unique URLs.” (翻訳) 「重複コンテンツを統合し、固有URLではなく固有コンテンツにクロールを集中させます。」 引用箇所へ
• “Don’t use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time.” (翻訳) 「noindexを使ってもGoogleはページをリクエストし、HTTPレスポンス内のnoindexメタタグまたはヘッダーを見てから破棄するため、クロール時間を浪費します。」 引用箇所へ
• “Google won’t shift this newly available crawl budget to other pages unless Google is already hitting your site’s serving limit.” (翻訳) 「サイトの配信上限にすでに達していない限り、Googleは新たに空いたクロールバジェットをほかのページへ移しません。」 引用箇所へ

Gary Illyes, Google — スケジューリングとホスト負荷（Search Engine RoundtableによるStone Temple Q&Aの報道）

• “Host load kind of sets a bucket of URLs in importance order and GoogleBot will crawl in that order based on the schedule the host load decided. If Google thinks your server can handle it, it will crawl the whole bucket, if not, it will stop.” (翻訳) 「ホスト負荷がURLを重要度順のバケットにまとめ、Googlebotはホスト負荷が決めたスケジュールに従ってその順でクロールします。サーバーが処理できるとGoogleが判断すればバケット全体をクロールし、できなければ止めます。」 引用箇所へ

Fabrice Canel, Microsoft Bing

• “The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” (翻訳) 「クロールした1ページ当たり、どの程度の頻度で新しく新鮮なコンテンツをクロールし発見できるかがクロール効率です。」 引用箇所へ
• “Less is more for SEO. Never forget that. Less URLs to crawl, better for SEO.” (翻訳) 「SEOでは少ないほどよい。忘れないでください。クロールするURLが少ないほどSEOにはよいのです。」 引用箇所へ

クロールバジェット最適化チェックリスト

実際にクロールバジェットの問題があると確認できた場合だけ実施してください。対象は、大規模サイト、公開当日のクロールが遅いサイト、または「検出 - インデックス未登録」が増えているサイトです。確認後は次へ進みます。

• 問題が実在することを確認した — 最適化前にGSCのクロール統計と「検出 - インデックス未登録」を確認した。
• canonicalの規則（ホスト、プロトコル、末尾スラッシュ、大文字小文字）を1つに決め、重複を統合した。
• URLパラメータを処理した — canonicalを指定するか、重複・低価値な派生だけを生むものをブロックした。
• ファセットナビゲーションを制御した — 価値のない絞り込み・並べ替えの組み合わせをrobots.txtでブロックするか、#の背後に置いてクロール可能にしなかった。
• ソフトエラーページを修正し、恒久的に削除したページへ本当の404/410を返した。
• リダイレクトチェーンを削除または短縮した。
• サイトマップにはcanonicalかつインデックス登録可能なURLだけを載せ、lastmodを正確にした。
• バジェット節約にnoindexを使わず（Googleはどのみち取得する）、robots.txtのブロックでほかのページへ枠が再配分されるとも期待しなかった。
• 重要なページと新規公開ページへの内部リンクを強化した。
• サーバーの応答時間とページ読み込み効率を改善した。
• （Bing）変更通知にIndexNowを導入し、サーバー負荷が制約ならCrawl Controlを使った。

考え方の枠組み

1. バジェット = 容量 × 需要。 クロール容量はサーバーが処理できる量、クロール需要は人気度、更新からの経過時間、認識されているURL在庫です。両方が必要です。高速なサーバーでも需要が低ければクロールは少なく、需要が高くても不調なサーバーでは制限されます。実効的なバジェットを増やすには、クロール増加を求めるより、ほとんどの場合は無駄を減らします。

2. 「そもそも問題があるか」の判定。 何かを変更する前に確認します。

• 公開当日にページがクロールされる → 問題なし。ここで終了。
• 約十万URL未満（Muellerの目安）→ ほぼ確実に問題なし。
• 週単位で変わる百万ページ以上、毎日変わる一万ページ以上、または「検出 - インデックス未登録」が大量にある → 対応を検討する価値があります。

3. Googleにクロール増加を求める前に無駄を除く。 この記事で最も効果が大きい考え方です。Googleは認識しているものをすべてクロールしようとします。その半分が重複、ファセット、ソフトエラーページなら、不要なURLにバジェットを使っています。不要URLを減らせば重要なページへ集中します。これが「最も積極的に制御できる要因」です。

4. クロール ≠ 順位。 クロールは入口であり、スコアボードではありません。クロールが増えても順位は上がりません。目標は生のクロール量ではなく、適切なURLを必要なときに網羅することです。

5. 固定枠ではなく優先順位付きキュー。 内部ではホスト負荷を上限として重要度順にスケジュールされます。1日Nページの一律枠ではありません。リンクや需要によって重要度を高め、不要な取得を減らすことでキュー内の優先順位を上げます。

クロールバジェット早見表

浪費要因（Googleが示した重要度順）

加えて、長いリダイレクトチェーンや遅く重いページは、1回の取得コストを増やします。

対策が必要か

• 公開当日にクロールされる → 不要。
• 約十万URL未満（Mueller）→ ほぼ確実に不要。
• 週単位で変わる百万ページ以上、毎日変わる一万ページ以上、または「検出 - インデックス未登録」が大量にある → 必要。

有効な対策

• 重複を統合し、canonicalを指定する。
• 価値のないパス（ファセット、パラメータ）をrobots.txtでブロックする。バジェット節約にnoindexは使わない。
• ソフトエラーページを直し、本当の404/410を返す。
• リダイレクトチェーンを短くし、サーバーを高速化する。
• サイトマップを整理し、内部リンクを強化する。

バジェットを増やす方法は2つだけ（Google）： サーバー容量の増強とコンテンツ品質の向上です。片方だけでは不十分です。

Bing： 「クロール効率」と捉え、IndexNowで変更を通知し、Crawl Controlで時間帯を設定します。

クロールバジェットを測定・管理するツール

• Google Search Console — クロールの統計情報レポート（設定 → クロールの統計情報）— 時系列の総リクエスト数、平均応答時間、ホストの状態、応答コード・ファイル形式・Googlebot種別ごとの内訳を確認できます。まずここから始めます。
• GSC「検出 - インデックス未登録」（ページレポート）— Googleが認識しているもののクロールしていないURLを示す警告です。
• サーバーログ分析 — botが実際にアクセスしたURLと頻度を示す一次データです。Screaming Frog Log File Analyserを使うか、ログをBigQueryやログ基盤へ取り込みます（ログファイル分析を参照）。
• Ahrefs Site Audit / Screaming Frog SEO Spider — クロールを再現し、重複URL、リダイレクトチェーン、ソフトエラーページ、ブロックURL、スパイダートラップ状のファセット空間を検出します。
• Ahrefs Webmaster Tools — 所有確認したサイトを無料でクロール・監査できます。
• URL検査（GSC） — 単一URLが公開当日にクロールされたかを手早く確認できます。
• Bing Webmaster Tools — Crawl Control — サーバー負荷が制約の場合に、bingbotのクロール時間帯を設定します。

クロールバジェットの問題があるか

毎月のクロールバジェット健全性チェック

1. 毎月同じ集計期間について、サーバーログから検索クローラーのリクエストを出力します。
2. リクエストをステータスコード、ディレクトリ、ページ種別、インデックス登録可否で分けます。
3. リクエスト量の多いパラメータ、重複パス、リダイレクト、ソフトエラーページ、サーバーエラーを確認します。
4. 価値のあるテンプレートへのクロール比率を前期間と比較し、公開や移行の影響を注記します。
5. 新しい浪費パターンごとに担当者と対策を決めます。対策はリンク、パラメータ、リダイレクト、canonical、削除、サーバー修復のいずれかです。
6. 次のログ期間に対象パターンを再確認します。重要URLへのアクセスが維持され、サイト固有の基準値から無駄が減れば完了です。

クロールバジェットの誤った対策

• リクエスト総数を増やそうとする。 クロールが増えても順位は上がりません。代わりに重要なURLが必要なときにクロールされるかを追跡します。
• robots.txtだけで無駄を止める。 取得は止まっても、発見済みURLや、それを生むリンクは残ることがあります。適切な場合はクロール経路をなくし、URL在庫を統合します。
• ビルドのたびに全サイトマップのlastmodを更新する。 偽の鮮度はシグナルへの信頼を損ないます。意味のあるページ更新時だけ変更します。
• URLパターンを調整しながらサーバーエラーを放置する。 容量の問題は有用なクロールの上限になります。まずタイムアウトと5xx応答を修復します。
• 除外URLをすべて無駄とみなす。 インデックス未登録のリソースでも、レンダリングや発見を支える場合があります。ブロック前に目的を分類します。

プロンプト：クロールログの無駄を分類する

URL、テンプレート、ステータス、bot、ヒット数、バイト数、インデックス登録可否を含む、ログから作成したCSVを貼り付けます。先にクエリ値やユーザーデータを削除してください。

Act as a technical SEO analyst. Classify each URL pattern as valuable crawling, necessary support crawling, redirect/error waste, duplicate/parameter waste, or unclear. Do not infer intent from the URL alone: list the evidence needed for every unclear row. Rank patterns by crawler requests and bytes, propose the safest control, and state what could break if that control is wrong. Return a table plus a short validation plan.

プロンプト：クロールバジェット診断を反証する

Review the crawl-budget diagnosis below. Separate evidence of capacity, demand, discovery, and URL-inventory problems. Flag claims that confuse crawling with indexing or rankings. Then give the three smallest tests that would confirm or reject the diagnosis. Do not invent thresholds; use changes against the site's own baseline.

[PASTE DIAGNOSIS AND OBSERVATIONS]

アクセスログからクローラーのステータスコードを集計する

検証済みクローラーのトラフィックに合わせてbotのパターンを調整した後、nginx/Apache形式のログに対して実行します。

awk 'BEGIN{IGNORECASE=1} /Googlebot|bingbot/ {print $9}' access.log | sort | uniq -c | sort -nr

PowerShellの場合：

Select-String -Path .\access.log -Pattern 'Googlebot|bingbot' | ForEach-Object { if ($_.Line -match '"\s(\d{3})\s') { $Matches[1] } } | Group-Object | Sort-Object Count -Descending

クエリパラメータ群を抽出する

クローラーのエクスポートまたはテキストエディターで、最初のクエリパラメータ名を取得するには次の正規表現を使います。

\?([^=&]+)(?:=[^&]*)?

グループ1がパラメータ名です。リクエスト数の多いパターンは調査対象を示すものであり、自動的にブロックすべきURLを示すものではありません。

理解度チェック：クロールバジェット

読む価値のある資料

私の関連記事

• クロールバジェットを心配すべきタイミング — このテーマを詳しく扱ったAhrefsの記事です。最適化の詳細とファセットナビゲーションの判断を説明しています。
• 「検出 - インデックス未登録」の修正方法 — クロールバジェットの警告にもなるGSCの状態を扱います。
• 技術SEO初心者ガイド — 技術SEO全体におけるクロールバジェットの位置付けです。
• エンタープライズSEO戦略 — 実際に対策が必要な少数の大規模サイト向けです。

私の講演資料

• How Search Works （SlideShare）— クロール需要とクロール速度の上限のモデルを説明しています。常設の注意書きは*“This is my understanding of systems… not going to be 100% complete or accurate.”* (翻訳) 「これは私のシステム理解であり、完全または正確であるとは限りません」です。

業界の資料

• GoogleのCrawling December シリーズ — 公式資料で、ファセットナビゲーションを含むクロール解説が集約されています。
• ウェブマスター向け：Googleが説明する「クロールバジェット」の意味 （Barry Schwartz、Search Engine Land、2017）— Googleの元記事を平易にまとめ、“most sites don’t need to worry” (翻訳) 「ほとんどのサイトは心配不要」という背景を説明します。
• Gary Illyesが解説するクロールバジェット、スケジューリング、ホスト負荷の違い （Search Engine Roundtable）— 固定枠ではなく優先順位付きキューであることを示す、重要度順バケットとホスト負荷の説明です。
• Google：十万URLでは通常クロールバジェットに影響しない （Search Engine Roundtable、2021）— Muellerによる十万URLと3か月で1分当たり1URL未満という目安です。
• Googleのクロール優先順位：Gary Illyesの解説 （Search Engine Journal）— 1日当たりの固定枠という誤解と、取得価値を検索側へ示す考え方を扱います。
• クロール、レンダリング、インデックス登録を支える5つの基盤ゲート （Search Engine Land）— Fabrice Canelの「Less is more for SEO」とBingのクロール効率の出典です。
• bingbotシリーズ：クロール頻度の最適化 （Bing Webmaster Blog、Fabrice Canel）— Bingが再クロール頻度を決める仕組みです。
• r/TechSEO — クロールとインデックス登録のデバッグを扱うコミュニティです。

引用に使える統計

• 十万URLでは通常問題になりません。 John Muellerの具体的な目安： “100k URLs is usually not enough to affect crawl budget (it’s <1/minute over 3 months).” (翻訳) 「十万URLでは通常クロールバジェットに影響するほどではありません（3か月で1分当たり1URL未満です）。」クロールバジェットへの過度な不安を抑えるうえで最も有用な数値です。 出典
• 問題になり始める目安： およそ週単位で変わる百万ページ以上、または毎日変わる一万ページ以上です。Googleの概算であり、厳密なしきい値ではありません。 出典
• ウェブのおよそ60%は重複コンテンツ — Googleの内部推定です。重複URLがクロールバジェットを浪費しやすい理由を示します。 出典

クロール効率の継続的KPI

クロールバジェットはGoogleから数値として渡されるものではありません。Googlebotが実際にリクエストをどこへ使っているかから推定します。KPIは配分、つまりインデックス登録したいページへのクロールと、純粋な無駄へのクロールの比率です。前提として、これは大規模サイトでのみ重要です。Googleは主に約百万ページ以上のサイト、または自動生成URLが多い中規模サイトの問題だとしています。小規模な静的サイトでは、この指標自体を省略できます。

クロール配分：価値のあるリクエストと無駄なリクエスト

• 指標 — 検証済みGooglebotのリクエストのうち、重要でインデックス登録可能なURLに届いた割合と、無駄なURL（重複、パラメータ・ファセットURL、非canonicalの派生、リダイレクト経由、4xx/5xx）に届いた割合。
• 分かること — 順位を得られるページにクロール容量が使われているか。無駄の割合の上昇は、順位問題として表れる前の発見・インデックス登録遅延の先行指標です。
• 取得方法 — サーバーログをLog File Analyzerで処理し、検証済みGooglebotのアクセスをURL分類別に分けます。GSCのクロールの統計情報レポート（総リクエスト、応答別、ファイル用途別、ホストの状態）でも照合します。
• 基準値／現実的な範囲 — 状況依存です。URL構造によって変わるため、正直な普遍的「無駄率」はありません。自社サイトの基準値を設定し、時間とともに無駄の割合を下げます。見るべきなのは傾向であり、作られた絶対値ではありません。
• 頻度 — 毎月、および新しいファセットや移行など構造変更の直後、Crawl Statsでリクエストや4xx/5xx応答が急増したとき。無駄なクロールは先行指標で、インデックス登録ページ数は遅行します。

変更履歴