クロール需要

要点 — クロールバジェットには、検索エンジンがページを取得できる速さ（クロール速度）と、どれだけ取得したいか（クロール需要）という2つの側面があります。クロール需要は後者です。Googleは、リンクが多い人気ページ、頻繁に変わるページ、時間を使う価値があると判断したサイトをより積極的にクロールします。需要を上げるボタンはありません。リンクを獲得し、実質的な更新を行い、重要なページを大量の不要URLに埋もれさせないことで需要を得ます。

クロール需要とは

「クロールバジェット」は、実際には2つの別の要素をまとめた言葉です。1つは、サーバーがクロールを処理できる速度と同時ページ数、つまりクロール速度です。もう1つは、検索エンジンがそもそもサイトをどれだけクロールしたいかです。これが、このページで扱うクロール需要です。

需要と供給にたとえると、クロール速度はサイトが受け入れられる供給量、クロール需要はGoogleが実行したい量です。 Evidence for this claim Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Scope: Google Search crawling. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Googleがページをクロールしたくなる要因

Googleは完全なチェックリストではなく、複数の重要要因を示しています。特に詳しく説明されているのは次の3つです。

• 人気度。 多くのリンクを受けるページほど頻繁にクロールされ、Google側のコピーが新しく保たれます。
• 古さ／鮮度。 頻繁に変わるページは確認頻度が上がり、変わらないページは次第に確認頻度が下がります。
• Googleが認識するURL数。 不要、重複、低価値のURLが多いと、本当に重要なページではなく、それらにクロールが費やされます。これは最も管理しやすい要因です。 Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Googleは、サイト規模、更新頻度、ページ品質、類似テーマを扱う他サイトとの比較も需要に影響すると説明しています。「人気度、古さ、認識されたURL数」は、特に重要で対処しやすい要因であり、完全な公式ではありません。

一時的な要因もあります。サイトを新しいドメインへ移転すると、新URLで処理するためにGoogleが全体を再クロールし、しばらく需要が増えます。

「クロール需要を増やす」ことが直接できない理由

需要を操作するつまみも、Googleのクロールを速めるボタンもありません。リンクも実用性もない記事を1日10本公開しても効果はありません。有効なのは時間のかかる本質的な対策です。リンクを獲得し、内容を本当に新しく保ち、不要URLを整理して重要なページへクロールを向けます。

意外ですが、クロール量を増やすこと自体は目標ではありません。 頻繁にクロールされても順位は上がりません。必要なのは需要の増加ではなく、既にある需要を適切なページへ向けることです。

需要とサーバー処理能力の関係、サイト品質がスケジューラへ戻す信号、需要問題と処理能力問題の見分け方を詳しく知りたい場合は、上級者向けタブへ進んでください。

要点 — クロール需要はクロールバジェットの「したい」側、クロール速度・処理能力は「できる」側です。Googleは、人気度（リンク／PageRank）、古さ（変更頻度）、認識されたURL数（不要URLを含めGoogleが存在すると考えるURL数）を重要な一般要因として挙げますが、閉じた公式ではなく、サイト規模、更新頻度、ページ品質、比較上の関連性も影響します。サイト移転では需要が一時的に増えます。私の整理では、需要がURLの優先順を決め、ホストの処理能力がキューのどこまでGooglebotが進めるかを決めます。これはGoogleが公表した文字どおりのアルゴリズムではなく、根拠を結び付けるためのモデルです。健全なサーバーが需要を作るわけではなく、高い需要も処理能力で制限されます。需要は直接設定できません。インデックス側から品質向上の信号が返るとスケジューラが需要を高めます。一方、Googleは総クロール量を減らしつつ配分を精密化しようとしているため、目標は量ではなく正しい優先順位です。ほとんどのサイトでは管理不要です。

クロール需要は「したい」、クロール速度は「できる」

Googleは、サイトのクロールに使う時間とリソース、つまりクロールバジェットが「クロール処理能力の上限とクロール需要」という2要素で決まると明示しています。私のAhrefsのクロールバジェットガイド では、クロールバジェットを「検索エンジンがサイトでクロールしたいページ数であるクロール需要と、クロール可能な速さであるクロール速度から成る」と説明しています。需要は「したい」、速度は「できる」です。 Evidence for this claim Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Scope: Google Search crawling. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

このページは「したい」側だけを扱います。「できる」側、つまりクロール処理能力の上限、2024年1月に廃止されたGSCの速度調整、5xx／429がGooglebotを遅くする仕組み、BingのCrawl Controlは、クロール速度のページで扱います。両者が関係する箇所では相互に参照します。

需要を左右する3つの入力

Googleの現行ガイダンスは、認識されたURL数、人気度、古さを需要に影響する重要な一般要因としていますが、完全な公式とはしていません。サイト規模、更新頻度、ページ品質、類似サイトとの比較も考慮されます。以下の3つはGoogleが特に詳しく説明し、直接対処しやすい要因です。 Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

人気度

“URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” (翻訳) 「インターネット上で人気の高いURLほど、Googleのシステム内で鮮度を保つため頻繁にクロールされる傾向があります。」 URLへのリンクとPageRankが多いほど需要の信号は強くなります。ホームページが頻繁にクロールされ、深い階層の孤立ページがほとんどクロールされない理由です。私のガイドでも、“Popular pages, or those with more links and PageRank, will generally receive priority over other pages.” (翻訳) 「人気のあるページ、またはリンクとPageRankが多いページは、通常ほかのページより優先されます。」 内部リンクも含まれます。どこからもリンクされない孤立ページには需要がほぼ働きません。

古さ

“Our systems want to recrawl documents frequently enough to pick up any changes.” (翻訳) 「Googleのシステムは、変更を検出できるだけの頻度で文書を再クロールしようとします。」 Googleはページごとの変化の周期を学習します。頻繁に変わるページは再クロールが増え、変わらないページは確認間隔が延びます。私のガイドでは、静的ページへの後退処理を “if they crawl a page and see no changes after a day, they may wait three days before crawling again, ten days the next time, 30 days, 100 days, etc.” (翻訳) 「ページをクロールして1日後も変化がなければ、次は3日、その次は10日、30日、100日というように待つことがあります。」 と説明しています。このURL単位の周期はクロール頻度の問題ですが、その根底にある力は需要、とりわけ古さです。

認識されたURL数（最も管理しやすい要因）

これは中心的なレバーです。Google: “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 (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.” (翻訳) 「サイト所有者からの指示がなければ、Googleは把握しているURLの全部または大半をクロールしようとします。その多くが重複していたり、削除済み・重要でないなどの理由でクロール不要だったりすると、サイトに対するGoogleのクロール時間が大量に無駄になります。これは、サイト所有者が最も積極的に管理できる要因です。」

重要なのは、処理能力だけでなく需要にも作用する点です。不要URLは、新規コンテンツの代わりにコピー取得へリソースを使うため「クロールバジェットを浪費する」と考えられます。それだけでなく、把握可能なURLの大半が低価値な重複やパラメータ増殖で占められるサイトは、Googleから見てクロール価値が低く映ります。認識されたURL数を減らすと処理能力が空くだけでなく、時間をかけて価値あるURLへ需要が集中します。ファセットナビゲーション、セッションID、無限カレンダーなどのスパイダートラップは典型的な膨張要因であり、需要を抑える要因でもあります。

サイト移転などによる需要の急増

URL単位ではない需要要因もあります。“Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” (翻訳) 「さらに、サイト移転のようなサイト全体のイベントでは、新しいURLでコンテンツを再処理するため、クロール需要が増えることがあります。」 ドメイン移行や大規模な再構築の後、数週間Googlebotのアクセスが大幅に増えても想定内です。新しいアドレスで全体を再取得・再処理するための一時的な増加で、新しい平常値ではありません。競合ガイドでは見落とされがちですが、Google公式文書に明記された需要イベントです。 Evidence for this claim Google says site-wide events such as site moves may temporarily increase crawl demand so content can be reprocessed under new URLs. Scope: large or rapidly changing websites Confidence: high · Verified: 2026-07-16 Optimize your crawl budget

需要とホスト負荷の関係：キュー順序と処理能力ゲート

全体を理解しやすくする考え方を示します。ただし、これはGoogleが文字どおりのアルゴリズムとして公表したものではなく、私の整理です。Search Engine Roundtableが紹介したGary IllyesのQ&Aでは、ホスト負荷が「重要度順にURLの集合を作り、Googlebotはホスト負荷が決めた予定に沿ってその順でクロールする。サーバーが処理できるとGoogleが判断すれば集合全体をクロールし、できなければ停止する」と説明されています。同じQ&Aによれば、ホスト負荷が追うのはページの重要度であり、URL総数やサイト所有者が望むクロール数ではありません。当該ページは自動取得を拒むため、今回も原文を直接再確認できませんでした。一次資料の逐語引用ではなく、十分裏付けられた言い換えとして扱ってください。

この説明から、次の関係を読み取れます。これもGoogleが端から端まで明示した機構ではなく、私が要素を結び付けたものです。

• 需要が順序を決める。 「重要度順のURL集合」はクロール需要に相当し、人気度と古さがキュー上位のURLを決めます。
• 処理能力が到達点を決める。 ホスト負荷／クロール速度は、その日のGooglebotが順序付き集合のどこまで進めるかを決めます。サーバーが処理できれば全体をクロールし、できなければ途中で止まります。

2つは単純に掛け合わせるだけでなく、役割が異なります。高速で健全なサーバーは需要を生みません。既存需要を実現できる上限を高めるだけです。また、高い需要も処理能力で制限されます。遅いサーバーやエラーの多いサーバーでは、Googlebotが望んでいてもキューの途中で止まります。「サーバーを速くしたのに新しいページがクロールされない」という結果が多いのは、制約が処理能力ではなく需要だったためです。

需要は直接設定できないが、スケジューラは信号を聞く

短く言えば、需要は直接設定できません。インデックス信号に表れる本物のリンクと品質改善を通じて、間接的に獲得します。それ以外では動きません。

速度と同様、需要にも「もっとクロールして」という要求手段はありません。ただし需要は動的です。Gary Illyes: “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.” (翻訳) 「クロール量を増やしたければ、コンテンツを取得する価値があると検索側に何らかの形で納得させる必要があります。スケジューラが聞いているのは基本的にその信号です。」 さらに、“Scheduling is very dynamic. As soon as we get the signals back from search indexing that the quality of the content has increased across this many URLs, we would just start turning up demand.” (翻訳) 「スケジューリングは非常に動的です。多数のURLでコンテンツ品質が向上したという信号が検索インデックスから返れば、需要を高め始めます。」 反対に、“If search demand goes down, then that also correlates to the crawl limit going down.” (翻訳) 「検索需要が下がれば、クロール上限の低下とも相関します。」 これら3文はSearch Engine Journalの記事と逐語的に一致することを再確認しましたが、Googleの音声・文字起こしによる一次資料は未確認です。十分裏付けられた二次資料の引用として扱ってください。

この説明により、「クロール需要を増やす方法」は小手先の施策から切り離されます。偽のlastmod、サイトマップのping、公開本数ではスケジューラを説得できません。有効なのは、本物の人気度（リンク）と、インデックス信号に反映される実質的な品質改善です。それ以外は見せかけにすぎません。

Googleは増やすのではなく、クロールを減らそうとしている

古いガイドが見落としやすい新しい視点は、Googleの目標が総クロール量を増やすことではなく減らすことだという点です。Illyesは2024年4月のLinkedIn投稿で、“My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” (翻訳) 「今年の私の使命は、クロールをさらに減らし、通信上のバイト数を少なくする方法を見つけることです。」 と述べました。Googleがクロールを大幅に減らしたとの見方には、“we’re crawling roughly as much as before, however scheduling got more intelligent” (翻訳) 「クロール量は以前とほぼ同じですが、スケジューリングがより賢くなりました。」 と反論し、“Decreasing crawling without sacrificing crawl-quality would benefit everyone.” (翻訳) 「クロール品質を犠牲にせずクロール量を減らせれば、全員に利益があります。」 と説明しています。手段はキャッシュ改善、ユーザーエージェント間のキャッシュ共有、転送量削減であり、「自分のサイトをもっとクロールさせる」ことではありません。

要点は、クロール需要を最大化すべきではないということです。Googleは、同等以上の品質を保ちながら総クロール量を減らし、価値が高そうなURLへ需要を配分しようとしています。目標は需要の増加ではなく、獲得した需要の正しい優先順位付けです。

本当に需要の問題があるか

ほとんどのサイトには問題がなく、時間を使う必要もありません。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.” (翻訳) 「急速に変化するページが大量になく、公開当日にクロールされているようなら、このガイドを読む必要はありません。」 John Muellerも規模について明確で、Search Engine Roundtableが紹介した投稿によれば、10万URLは3か月平均で1分あたり1回未満のクロールに相当し、通常はクロールバジェットへ影響する規模ではありません。

検討に値する規模なら、GSCのクロール統計情報とサーバーログで、需要と処理能力を切り分けます。ただし得られるのは診断ではなく検証すべき仮説です。ホスト状態と平均応答時間が健全なのに、一部URLがほとんどクロールされず「検出 - インデックス未登録」に留まるなら、需要を示す証拠ではありますが確証ではありません。クロール統計は需要スコアではなく、処理能力側の活動を示します。公開されたサイト別需要スコアは存在しないため、活動とインデックス状態から推定します。

需要問題と判断する前に、同じ症状を生む原因を除外します。URLがまだ発見されていない、レンダリングで内容が見えない、正規化が別URLを指す、薄い・重複・低価値などの品質問題、Google側のインデックス選択などです。これらで説明できない場合にのみ低需要を作業仮説とします。それでも確定原因ではありません。本当の需要問題は高速なハードウェアでは直らず、ページへのリンク、再クロールする実質的理由、重要URLを埋もれさせる不要URLの削減が必要です。

URL単位のクロール実態を確認するにはログ分析が最適です。実際に使ったことのある現行ツールを「ツール」タブで紹介します。

クロール需要、速度、バジェット、頻度の違い

関連用語を区別してください。

• クロール需要 — Googleがどれだけクロールしたいか（人気度＋古さ＋認識されたURL数）。このページの主題です。
• クロール速度 — どれだけ速くクロールできるか（処理能力／ホスト負荷）。別ページで扱います。
• クロールバジェット — 上記2つを合わせた「Googlebotがクロールでき、かつクロールしたいURL数」。
• クロール頻度 — 特定URLを再クロールする頻度。主に古さから生じる需要の結果です。

Bingは「クロール需要」という用語を使わず、全体をクロール効率として捉えます。Fabrice Canelは “how often we crawl and discover new and fresh content per page crawled,” (翻訳) 「クロールしたページ当たり、新しく新鮮なコンテンツをどれだけ頻繁にクロールし発見できるか」 と定義しています。Bingは認識されたURL数の削減に相当する、インベントリ削減を重視します。IndexNowは、古さを推定させる代わりに変更イベントをBingへ伝える仕組みです。ただしGoogleはIndexNowを使用しないため、Googleの需要は変わりません。

AI要約

上級者向け内容の要約です。

• クロール需要はクロールバジェットの「したい」側で、クロール速度・処理能力は「できる」側です。
• 重要な需要要因は閉じた公式ではありません。 人気度、古さ、認識されたURL数に加え、サイト規模、更新頻度、ページ品質、比較上の関連性も影響します。
• サイト移転では需要が一時的に増えます。
• 需要と処理能力のモデルは私の整理です。 需要がURLの優先順を決め、処理能力がGooglebotの到達点を決めます。
• 需要は直接設定できません。 リンク獲得と実質的な品質・鮮度改善が主なレバーです。偽のlastmod、ping、公開本数では動きません。
• Googleは増やすよりクロールを減らそうとしています。 目標は量ではなく正しい優先順位です。
• 需要と処理能力を切り分けます。 健全なホスト、少ないクロール、「検出 - インデックス未登録」は需要仮説ですが、発見、レンダリング、正規化、インデックス選択を先に除外します。公開需要スコアはありません。
• Bingではクロール効率として扱い、IndexNowはBingに変更を知らせますがGoogleには作用しません。ほとんどのサイトで管理不要です。

公式ドキュメント

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

Google

• クロールバジェットを最適化する — クロール需要、主要入力、サイト移転による増加を定義する資料。
• クロールバジェット管理 — 処理能力と需要の区分、および処理能力の仕組み。
• Googlebotにとってのクロールバジェット（2017年） — Googlebotが「クロールでき、かつしたい」範囲として定義し、低価値URLの分類を示したGary Illyesの投稿。
• クロールに関する誤解と事実 — クロール速度がランキング信号ではなく、サーバー状態が処理能力の上限を決めることを確認。
• Crawling Decemberシリーズ（2024年） — Googlebot、HTTPキャッシュ、ファセットナビゲーション、クロール削減の効率化。

Bing / Microsoft

• bingbot Series: Maximizing Crawl Efficiency — Bingの「クロール効率」という需要側の捉え方。
• bingbot Series: Optimizing Crawl Frequency — コンテンツ変更頻度に基づく再クロール周期。
• IndexNow / indexnow.org — 推定を待たず、変更URLをBingなどへ通知する仕組み（Googleは対象外）。

出典からの引用

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つの主要要素で決まります。」 — 大規模サイト所有者向けクロールバジェット管理ガイド。 引用箇所へ
• “Each crawler has its own ‘demand’ when it comes to crawling the web.” (翻訳) 「各クローラーには、ウェブをクロールする際に固有の『需要』があります。」 引用箇所へ
• “URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” (翻訳) 「インターネット上で人気の高いURLほど、Googleのシステム内で鮮度を保つため頻繁にクロールされる傾向があります。」（人気度） 引用箇所へ
• “Our systems want to recrawl documents frequently enough to pick up any changes.” (翻訳) 「Googleのシステムは、変更を検出できるだけの頻度で文書を再クロールしようとします。」（古さ） 引用箇所へ

Google — 認識されたURL数とサイト移転

• “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の多くが重複していたり、削除済み・重要でないなどの理由でクロール不要だったりすると、サイトに対するGoogleのクロール時間が大量に無駄になります。これは最も積極的に管理できる要因です。」 引用箇所へ
• “Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” (翻訳) 「さらに、サイト移転のようなサイト全体のイベントでは、新URLでコンテンツを再処理するためクロール需要が増えることがあります。」 引用箇所へ
• “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.” (翻訳) 「急速に変化するページが大量になく、公開当日にクロールされているようなら、このガイドを読む必要はありません。」 引用箇所へ

Gary Illyes（Google）— 需要が実際に変化する仕組み（ポッドキャスト出演を報じたSearch Engine Journal経由）

• “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.” (翻訳) 「クロール量を増やしたければ、コンテンツを取得する価値があると検索側に納得させる必要があります。スケジューラが聞いているのは基本的にその信号です。」 記事を読む
• “Scheduling is very dynamic. As soon as we get the signals back from search indexing that the quality of the content has increased across this many URLs, we would just start turning up demand.” (翻訳) 「スケジューリングは非常に動的です。多数のURLで品質が向上したという信号が検索インデックスから返れば、需要を高め始めます。」 記事を読む
• “If search demand goes down, then that also correlates to the crawl limit going down.” (翻訳) 「検索需要が下がれば、クロール上限の低下とも相関します。」 記事を読む

Gary Illyes（Google）— 「クロールをさらに減らす」という使命（LinkedIn、2024年4月、一次資料で逐語確認済み）

• “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” (翻訳) 「今年の私の使命は、クロールをさらに減らし、通信上のバイト数を少なくする方法を見つけることです。」 投稿を読む
• “we’re crawling roughly as much as before, however scheduling got more intelligent” (翻訳) 「クロール量は以前とほぼ同じですが、スケジューリングがより賢くなりました。」 および “Decreasing crawling without sacrificing crawl-quality would benefit everyone.” (翻訳) 「クロール品質を犠牲にせずクロール量を減らせれば、全員に利益があります。」 投稿を読む

Bing / Microsoft — クロール効率（需要側に相当）

• “The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” (翻訳) 「クロール効率とは、クロールしたページ当たり、新しく新鮮なコンテンツをどれだけ頻繁にクロールし発見できるかです。」— Fabrice Canel 引用箇所へ

クロール需要の問題か、対処が必要か

上から順に確認します。ほとんどのサイトは早い段階で「何もしない」に到達します。

クロール需要に関する誤解と失敗

異なる概念を混同すると、誤った対策へ進みます。

「クロール需要とクロールバジェットは同じ」 誤りの理由： 需要は2要素の一方で、バジェットは処理能力と需要を合わせた「Googlebotがクロールでき、かつしたいURL数」です。 代わりに： 用語を分けます。バジェットは結果で、需要と処理能力が入力です。

「高速なサーバーはクロール需要を増やす」 誤りの理由： 速度は処理能力の上限を高めるだけで、Googleがよりクロールしたいと思う理由にはなりません。 代わりに： サーバーが健全なのにクロールされないなら、リンク、鮮度、不要URL削減という需要要因に取り組みます。

「公開頻度を上げると需要が増える」 誤りの理由： 重要性も実質的な変化もない公開本数ではスケジューラを説得できません。 代わりに： リンクを得られ、本当に改善される内容を公開します。

「不要URLをrobots.txtで拒否すれば、その需要が良いページへ即座に移る」 誤りの理由： 認識URLを減らすと再評価に伴って時間をかけて需要が集中しますが、即時の再配分ではありません。 代わりに： 長期的な集中効果のため不要URLを減らし、推移を待ちます。

「Search Consoleでクロール需要スコアを確認できる」 誤りの理由： 公開されたサイト別需要スコアはありません。クロール統計は処理能力側の活動を示します。 代わりに： 活動とインデックス状態から推定し、URL単位の実態はログで確認します。

「IndexNowやサイトマップpingでGoogleの需要が上がる」 誤りの理由： GoogleはIndexNowを使わず、サイトマップのchangefreq／priorityを無視します。 代わりに： IndexNowは対応する検索エンジンに使います。Googleでは正確なlastmodが予定作成に役立ちますが、需要要因はリンク、鮮度、URL数です。

「クロールは多いほど常に良い」 誤りの理由： クロール増加は順位を上げず、Google自身が “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire” (翻訳) 「今年の使命は、クロールをさらに減らし、通信上のバイト数を少なくする方法を見つけることです。」 と述べています。 代わりに： 量ではなく、適切なURLへの優先配分を目指します。

手順書：「重要ページをGoogleがクロールせず、サーバーは健全」

需要問題を疑う大規模サイト向けの手順です。解決した時点で止めます。

1. 検討すべき規模か確認する。 通常は公開日にクロールされる、または一般的な規模なら終了します。対象は1M+ページ、1日1万ページ以上が変わるサイト、または「検出 - インデックス未登録」が大量にあるサイトです。

2. 先に処理能力を除外する。 GSCのクロール統計で過去90日のホスト状態と平均応答時間を確認します。5xx／タイムアウトの急増や応答悪化があれば処理能力問題です。サーバーを直してから再実行します。

3. ログからURL単位の実態を得る。 対象URLのサーバーログまたはボット分析を取得します。重要ページへの本物のGooglebotアクセスが少なく、不要URLがアクセスを消費しているか確認します。これは需要仮説であり、発見、レンダリング、正規化、品質・重複、インデックス選択をURL検査とレンダリング済みHTMLで先に除外します。

4. 認識URL数の膨張を確認する。 ファセットの組み合わせ、セッションID、並べ替え・絞り込みパラメータ、無限カレンダー、サイト内重複など、Googleが発見できる低価値URLを数えます。

5. 不要URLを減らす。 パラメータ処理、無限空間のrobots.txt拒否、スパイダートラップ修正、正規化による重複統合など、発生源で低価値URL空間を縮小します。即時ではなく時間をかけた集中を見込みます。

6. 人気度を改善する。 強いページからクロール不足ページへ内部リンクを追加して孤立を解消し、外部リンクも獲得します。

7. 品質と鮮度を改善する。 ページを実質的に改善・更新し、インデックスから返る品質信号でスケジューラに需要増加を伝えます。正確なlastmodは役立ちますが、偽の鮮度は無効です。

8. 待って再計測する。 Googleが再評価する時間を置き、クロール統計とログを再確認します。改善しなければ、そのページが本当にクロール価値を持つか再検討します。薄いページを無理にインデックスへ入れるべきではありません。

クロール需要チェックリスト

診断：需要か処理能力か

• 検討が必要な大規模・高頻度更新サイトであることを確認した。
• GSCクロール統計でホスト状態、平均応答時間、5xx／タイムアウトを確認した。
• サーバーログでURL単位のGooglebotアクセスを確認した。
• 健全なサーバー、良いページへの少ないクロール、「検出 - インデックス未登録」を、証明ではなく需要仮説として特定した。
• 発見、レンダリング、正規化、品質・重複、インデックス選択を除外した。

需要要因に取り組む（直接操作はできない）

• 人気度： 重要ページに内部リンクがあり、必要に応じて外部リンクを獲得している。
• 古さ／鮮度： 再クロールが必要なページを実質的に更新し、lastmodを正確にしている。
• 認識されたURL数： ファセット、パラメータ、セッションID、無限URL空間を制御し、トラップと重複を整理している。

現実的な確認事項

• 高速サーバーが需要を増やすとは考えない。
• 不要URLのrobots.txt拒否で需要が即座に移るとは考えない。
• IndexNowやサイトマップpingがGoogleの需要を動かすとは考えない（Googleはchangefreq／priorityを無視する）。
• サイト移転後の一時的増加を異常と扱わない。
• 目標は量ではなく正しい優先順位で、クロール量は順位要因ではないと理解する。

クロール需要 — チートシート

クロールバジェットの2つの側面

特に対処しやすい3つの需要要因（Googleはサイト規模、更新頻度、ページ品質、比較上の関連性も挙げており、閉じた公式ではありません）

早見表

• クロールバジェットは「Googlebotがクロールでき、かつしたいURL数」。
• 認識されたURL数は「最も積極的に管理できる要因」。
• サイト移転では一時的に需要が増える。
• 需要は優先順、処理能力はGoogleの到達点を決める。
• インデックス品質信号が改善するとスケジューラが需要を高める。
• Googleの目標は総クロール量を減らすことで、量は順位要因ではない。
• 公開されたクロール需要スコアはない。
• Bingではクロール効率と呼び、IndexNowはBingに変更を知らせるがGoogleには作用しない。

クロール需要を診断するツール

需要メーターはないため、クロール活動を読み、ページについて分かっている事実と比較します。

• Google Search Console — クロール統計情報 — リクエスト数、ホスト状態、平均応答時間、ステータスコード、ファイル種別、目的、Googlebot種別を確認します。処理能力側の情報として読みます。
• GSC — ページのインデックス登録 — 「検出 - インデックス未登録」は需要不足の典型的な痕跡です。
• URL検査 — URLの最終クロール日時と登録状態を確認します。
• サーバーログ分析 — URL単位のGooglebotアクセス、頻度、不要URLへの浪費を確認する基準データです。
• Ahrefs Bot Analytics — 私が実際に説明できるツールです。公開時に “Have y’all checked out Bot Analytics in Ahrefs yet? We released a new tool that shows how bots crawl your website. Bot Analytics collects data server-side via Cloudflare integration.” (翻訳) 「AhrefsのBot Analyticsをもう確認しましたか。ボットがサイトをどうクロールするかを示す新しいツールで、Cloudflare連携によりサーバー側でデータを収集します。」 と紹介しました。12カテゴリでボットとアクセス先を確認できます。Ahrefsは “uncontrolled bot traffic wastes crawl budget — bots crawling 404 pages or low-value URLs aren’t crawling the pages you need indexed,” (翻訳) 「制御されないボットトラフィックはクロールバジェットを浪費します。404や低価値URLをクロールする間、インデックスさせたいページはクロールされません。」 と説明し、クローラートラフィックの半分超が無駄 との推定を紹介しています。
• Ahrefs Site Audit / Screaming Frog SEO Spider — パラメータ増殖、重複、トラップを発見します。

重要度 × 変化 × URL数のフレームワーク

クロール需要の変化を3つの質問で説明します。

1. 重要度： 内部・外部信号によりURLの重要度は変わったか。
2. 変化： ページは実質的に変わり、正確なサイトマップ信号で伝えられたか。
3. URL数： クローラーが把握する重複、パラメータ、低価値URLは増えたか。

ホスト状態は上限であり、第4の需要要因ではありません。ログにエラーやタイムアウトがあれば処理能力を別に診断します。サーバーが健全なのに価値あるURLのクロール比率が下がったら、重要度、変化、URL数の順で確認します。

ディレクトリ別のクロール比率を比較する

次のシェルパイプラインは、一般的なアクセスログから検証済みクローラーのリクエストをURLパスの最初のディレクトリ別に集計します。

awk 'BEGIN{IGNORECASE=1} /Googlebot/ {split($7,p,"/"); print "/" p[2] "/"}' access.log | sort | uniq -c | sort -nr

PowerShellの場合：

Select-String .\access.log -Pattern 'Googlebot' | ForEach-Object { if ($_.Line -match '"(?:GET|HEAD)\s+https?://[^/]+/([^/?\s]*)|"(?:GET|HEAD)\s+/([^/?\s]*)') { '/' + (($Matches[1],$Matches[2] | Where-Object { $_ })[0]) + '/' } } | Group-Object | Sort-Object Count -Descending

変更前後で同じ長さの期間を比較します。ディレクトリの比率増加はスケジューラ配分の手掛かりであり、品質や順位向上の証明ではありません。

クロール需要の指標

価値あるテンプレートのクロール比率

指標： 重要テンプレートへのクローラーリクエスト数 ÷ 検証済みクローラーリクエスト数。分かること： 重要なURL群へ需要が届いているか。取得方法： ログURLをテンプレート別に分類。目安： 自サイトの価値あるURL構成と更新周期から望ましい比率を定めます。普遍的な割合はありません。頻度： 大規模で変化の多いサイトは毎週、それ以外は毎月。

実質的な変更後の再クロール遅延

指標： 実際のページ更新から次の検証済みクローラー取得までの時間。分かること： スケジューラが重要度と変化パターンを認識しているか。取得方法： デプロイまたは更新時刻とアクセスログを結合。目安： テンプレート別に基準化し、ニュースと安定した資料ページに同じ目標を使わない。頻度： 毎月。

低価値URLの比率

指標： 有用URLに対する、既知かつクロール済みのパラメータ、重複、空、soft 404 URLの比率。分かること： 認識URL数が注意を薄めているか。取得方法： クロール結果、サイトマップ、インデックス可否ルール、ログを結合。目安： 必要なリソースを遮断せず、自サイト基準から減少させる。頻度： 毎月およびファセットナビゲーションや基盤変更後。

参照する価値のある資料

関連する私の記事

• クロールバジェットを心配すべきタイミング — 需要と速度の区分、人気度、古さ、対象サイトを説明。
• Googlebotとは何か、どう動くか — 何をどれだけクロールするかの判断。
• テクニカルSEO入門 — クロールとクロールバジェットの位置付け。

講演

• How Search Works （SlideShare）— PageRank、鮮度、前回クロールからの時間、サイト全体の変更という需要要因と、別の処理能力スライドを含む説明。免責事項：「これはシステムに対する私の理解であり、100%完全または正確とは限りません。」

業界資料

• Gary Illyesが語るGoogleのクロール優先順位 — 需要が動く仕組みに関する引用。
• Gary Illyes on crawling even less — クロール削減と賢い予定作成の一次資料。
• Google Has Two Types Of Crawling: Discovery & Refresh — 発見クロールと更新クロール。
• Google’s Gary Illyes On Crawl Budget, Scheduling & Host Load — 重要度順URL集合の説明。
• Google: 100k URLs Won’t Impact Crawl Budget — 規模の目安。
• What Is Crawl Budget? How It Works + Optimization Tips — 需要3要因を含む総合ガイド。
• Ahrefs Bot Analytics — ボット分析とクロール浪費の説明。

理解度チェック：クロール需要

クロールバジェットの「したい」側について5問あります。回答を選んで確認してください。

変更履歴