クロール速度

要点 — クロール速度とは、検索エンジンがサイトのページを取得する速さです。Googleはサーバーの健全性に応じて自動設定するため、現在は手動で上下させるボタンがありません。サーバーが過負荷なら、まず高速化し、緊急時だけ1〜2日ほど「減速」を示すエラーを返します。クロールが速くなっても順位は上がりません。

クロール速度とは

検索エンジンはサイト内の全ページを一度に取得せず、負荷を調整しながら巡回します。クロール速度は、クローラーが一定時間に取得するページ数と取得間隔で表されるペースです。GoogleではGooglebot、BingではBingbotが巡回します。 Evidence for this claim Google defines crawl capacity using simultaneous connections and the delay between fetches, adjusted according to site responses. Scope: Google crawler capacity, not a ranking factor. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

この調整の目的は、サイトに過大な負荷をかけないことです。クローラーは応答状態を監視し、サーバーが苦しくなると速度を落とします。応答が速く安定していれば少し速く取得し、遅延やエラーが増えれば取得を減らします。

大きく変わった点

以前はSearch Consoleのスライダーでクロール速度を下げる方法が案内されていましたが、この機能は廃止済みです。Googleは2024年1月8日に削除しました。調整手順を紹介する古い解説は現在使えません。 Evidence for this claim Google deprecated the Search Console crawl-rate limiter and removed it on January 8, 2024. Scope: Google Search Console's legacy crawl-rate limiter. Confidence: high · Verified: 2026-07-14 Google: Crawl rate limiter deprecation

現在の速度は自動です。Googleがサーバーの応答を読み取り、適切な値を決めます。

Googlebotを減速させる方法

サーバーが実際に過負荷なら、次の順で対応します。

1. サーバーを高速化するか、リソースを増やす。 これが根本的な解決です。健全で高速なサーバーなら、Googlebotの巡回にも余裕を持って対応できます。
2. 本当の緊急時だけ： 通常ページの代わりに500、503、429を返します。Googleはこれを減速シグナルとしてすぐに読み取ります。ただし使うのは最長でも1〜2日です。長引くと検索結果からページが外れるおそれがあります。

避けるべき方法もあります。403や404でGooglebotを遮断しても巡回速度は下がらず、ページを失う危険があります。また、robots.txtのcrawl-delayはGoogleには無視されます。Bingはこの指定に対応しています。

Googleのクロールを速くできるか

直接はできません。「もっとクロールする」ボタンも、増速申請もありません。ただし、サーバーの高速化、整理されたサイトマップ、適切な内部リンク、重複・不要URLの削減によって間接的に促せます。クロール量そのものを目標にしてはいけません。増えても順位は上がりません。

ステータスコードの詳細、機能廃止の経緯、Bingとの違いはAdvancedタブで確認できます。

要点 — クロール速度はクロールバジェットの供給側で、同時接続数と取得間隔からなるクロール容量上限です。サーバー状態に応じて自動調整され、GSCの手動スライダーは2024年1月8日に廃止されました。Googlebotを減速させる緊急手段は500・503・429を最長1〜2日返すことです。401・403・404は使わず、Googleが無視するcrawl-delayにも頼りません。増速は直接申請できず、Bingには手動のCrawl Controlがあります。クロール速度はランキング要因ではありません。

クロール速度の正確な意味

クロール速度は、クローラーがサーバーからページを取得する速さ、つまり同時リクエスト数と取得間隔です。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がサイトのクロールに利用できる同時並列接続の最大数と、取得間の待機時間」と定義しています。 Evidence for this claim Google defines crawl capacity using simultaneous connections and the delay between fetches, adjusted according to site responses. Scope: Google crawler capacity, not a ranking factor. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

これはクロールバジェットの一方を構成します。Ahrefsのクロールバジェット解説 では、“crawl demand which is how many pages a search engine wants to crawl on your site and crawl rate which is how fast they can crawl.” (翻訳)「検索エンジンがサイトで何ページ巡回したいかを示すクロール需要と、どれだけ速く巡回できるかを示すクロール速度」に分けています。クロール速度は供給、クロール需要は需要であり、両者が交わる部分がクロールバジェットです。ランキングはこの循環の外にあります。

私のHow Search Works資料 では、クロール速度上限をサイトが支えられる範囲と説明しています。サーバーの安定性、応答速度、5xx、429が影響し、Googleはサイトを停止させないよう負荷時に後退します。見落とされがちですが、すべてのGooglebotは1つのクロール枠を共有します。検索、画像、広告など、ある種類の過剰な巡回は他の取得枠も消費します。

クロール速度を決める要因

容量上限は自動で、サーバーの状態にリアルタイムで反応します。Googleは、“If the site responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (翻訳)「サイトがしばらく高速に応答すれば上限が上がり、より多くの接続で巡回できます。サイトが遅くなるかサーバーエラーを返すと上限が下がり、Googleの巡回量は減ります」と説明しています。

もう一つ、サイト側で制御できない要因がGoogle自身のリソースです。“Google has a lot of machines, but not infinite machines. We still need to make choices with the resources that we have.” (翻訳)「Googleには多数のマシンがありますが、無限ではありません。利用できるリソースの中で選択する必要があります」。サーバー状態はGoogleが利用可能な上限を決めますが、実際の使用量はGoogleの処理能力とサイトのクロール需要で決まります。

クロールに関する誤解の文書も双方向の関係を示しています。“A speedy site is a sign of healthy servers, so it can get more content over the same number of connections,” (翻訳)「高速なサイトは健全なサーバーの印なので、同じ接続数でもより多くのコンテンツを取得できます」。一方、“a significant number of 5xx HTTP response status codes (server errors) or connection timeouts signal the opposite, and crawling slows down.” (翻訳)「多数の5xx応答や接続タイムアウトは反対の状態を示し、クロールは遅くなります」。

クロール速度は順位に影響するか？ しない

誤った施策の原因になるため、最初に切り分けます。検索に掲載されるには巡回が必要ですが、クロール速度はランキングシグナルではありません。Googleは、“Improving your crawl rate won’t necessarily lead to better positions in Google Search results.” (翻訳)「クロール速度を改善しても、Google検索で順位が上がるとは限りません」と明言しています。高速化で得られるのは発見とインデックス更新の迅速化であり、順位上昇ではありません。 Evidence for this claim Improving crawl rate does not itself improve ranking positions; crawling is necessary for eligibility but is not a ranking signal. Scope: websites Confidence: high · Verified: 2026-07-15 Myths and facts about crawling

Googlebotのクロール速度を下げる方法

根本対策から緊急手段まで、次の順で進めます。

1. サーバーを直す（根本対策）。 高速化するかリソースを増やします。容量上限は応答時間とエラーを追うため、健全なサーバーにすることが、インデックスを危険にさらさず巡回を安定させる恒久策です。

2. 緊急手段 — 500・503・429。 Googleは、“return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (翻訳)「クロールリクエストには200の代わりに500、503、429を返す」と案内しています。クローラーは*“treat the 429 status code as a signal that the server is overloaded,”* (翻訳)「429をサーバー過負荷のシグナルとして扱い」、“5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling.” (翻訳)「5xxと429により一時的に巡回を遅くします」。Gary Illyesも、“if the server persistently returns HTTP 500 status codes for a range of URLs, Googlebot will automatically, and almost immediately slow down crawling.” (翻訳)「一定範囲のURLが継続的にHTTP 500を返すと、Googlebotは自動的かつほぼ即座に減速する」と述べています。可能なら「リクエスト過多」を明示しRetry-Afterを付けられる**429**を優先します。

ただし、これは厳密に一時的な手段です。Googleは、“We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days).” (翻訳)「長期間、つまり1〜2日を超えて行うことは推奨しません」としています。同じURLで数日続くと、“the URL may be dropped from Google’s index” (翻訳)「URLがGoogleのインデックスから削除される可能性」があり、Google広告では*“your campaigns may be cancelled or paused, and your ads may not serve.”* (翻訳)「キャンペーンが中止または一時停止され、広告が配信されない可能性」があります。

3. 避けるべきこと。 4xxを速度制限に使いません。“The 4xx status codes, except 429, have no effect on crawl rate,” (翻訳)「429以外の4xxはクロール速度に影響せず」、Googleは*“Don’t use 401 and 403 status codes for limiting the crawl rate.”* (翻訳)「クロール速度の制限に401と403を使用しないでください」と明記しています。2023年の記事では、“Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate. The short version of this blog post is: please don’t do that…” (翻訳)「ここ数か月、429以外の404などの4xxでGooglebotを減速しようとするサイト所有者やCDNが増えました。要点は、そうしないでください」と説明しています。また、“The non-standard ‘crawl-delay’ robots.txt rule is not processed by Google’s crawlers.” (翻訳)「非標準のcrawl-delayルールはGoogleのクローラーでは処理されません」。 Evidence for this claim Google's crawlers do not process the non-standard crawl-delay robots.txt rule. Scope: websites Confidence: high · Verified: 2026-07-15 Myths and facts about crawling

4. 緊急ではない申請。 継続的な問題なら、“file a special request to report a problem with unusually high crawl rate, mentioning the optimal rate for your site.” (翻訳)「異常に高いクロール速度の問題とサイトの最適速度を特別フォームで報告」できます。処理には時間がかかり、下げる方向にしか使えません。

クロール速度を上げられるか？ 直接はできない

手動の増速機能はありません。Googleは、“You cannot request an increase in crawl rate, and it may take several days for the request to be evaluated and fulfilled.” (翻訳)「クロール速度の引き上げは申請できず、申請の評価と実施には数日かかる場合があります」としています。間接的な改善策はあります。クロールバジェット解説 で挙げるのは、サーバー高速化・増強、重要ページを載せた整理済みサイトマップ、重複削除、外部・内部リンクの強化、リダイレクトリンク修正、可能な場面でのGET利用（POSTの代替）、対象サイトでのIndexing APIです。“a speedy site… can get more content over the same number of connections” (翻訳)「高速なサイトなら同じ接続数でより多くのコンテンツを取得できる」ため、サーバー状態は減速と増速の両面に効きます。

Bingbotのクロール速度を制御する方法

Googleが手動制御を廃止した一方、Bingは維持しています。 Bing Webmaster ToolsのCrawl Controlには、時間帯ごとの速度をブロック数で設定するグリッドがあります。繁忙時間向けプリセットのほか、Customで一日のパターンを描けます。Bingはrobots.txtの**crawl-delayにも対応**します。つまり、Googleにはサーバー応答で伝え、Bingには実際の調整ダイヤルを使えます。

Search Consoleのクロール速度ツールに何が起きたか

すでに存在しない機能を参照する情報が多いため、時系列で整理します。

• 2008年12月 — GoogleがWebmaster Toolsにクロール速度制御を導入。
• 2023年2月 — 速度制限に403や404を使わないようGoogleが案内。
• 2023年11月24日 — Crawl Rate Limiter Toolの廃止を発表。Illyesは、“with the improvements we’ve made to our crawling logic and other tools available to publishers, its usefulness has dissipated.” (翻訳)「クロールロジックの改善と公開者向けの他ツールにより、有用性が薄れた」と説明しました。旧機能は*“a much slower effect”* (翻訳)「効果がかなり遅く」、“would have taken over a day for the new limits to be applied on crawling,” (翻訳)「新しい上限の反映に1日以上かかり」、利用も*“rarely,”* (翻訳)「まれ」で、利用者は*“in many cases set the crawling speed to the bare minimum.”* (翻訳)「多くの場合、速度を最低に設定していた」とされます。
• 2024年1月8日 — 機能を削除。 Evidence for this claim Google deprecated the Search Console crawl-rate limiter and removed it on January 8, 2024. Scope: Google Search Console's legacy crawl-rate limiter. Confidence: high · Verified: 2026-07-14 Google: Crawl rate limiter deprecation Googleは下限も引き下げ、“With the deprecation of the crawl limiter tool, we’re also setting the minimum crawling speed to a lower rate, comparable to the old crawl rate limits.” (翻訳)「ツール廃止に伴い、最低クロール速度を旧上限と同等の低い値に設定する」としました。

実務上、旧スライダーは反映に24時間以上かかりました。現在のサーバーシグナル方式（5xx・429）はGooglebotをほぼ即座に減速させるため、本当の緊急時にはより適しています。

クロール速度を監視する方法

GSCのクロール統計レポートでは、総クロールリクエスト、総ダウンロード量、平均応答時間、過去約90日のホストステータス、応答コード・ファイル形式・目的・Googlebot種類別の内訳を確認できます。平均応答時間の上昇や5xxの増加はGooglebotが減速する直接の要因です。BingではCrawl ControlとBing Webmaster Tools内のクロール情報が相当します。

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

用語を混同しないよう整理します。

• クロール速度 = どれだけ速く取得できるか（供給・容量）。
• クロール需要 = どれだけ取得したいか（人気度・古さ）。
• クロールバジェット = 両者の相互作用。“the amount of time and resources a search engine allows for crawling a website.” (翻訳)「検索エンジンがサイトの巡回に割り当てる時間とリソースの量」です。
• クロール頻度 = 特定ページを再巡回する頻度で、主に人気度や鮮度という需要側の問題です。

安心材料として、ほとんどのサイトはクロールバジェットを気にする必要がありません。 “Most sites don’t need to worry about crawl budget, but there are few cases where you may want to take a look” (翻訳)「大半のサイトでは心配不要ですが、確認した方がよい場合もあります」。対象は、多数のページを持つ新しいサイト、非常に大規模または急速に変化するサイト、GSCで「検出 - インデックス未登録」が大量にあるサイトです。それ以外では、Googleの自動調整に任せます。

AI要約

Advanced版の要点をまとめます。

• クロール速度はクローラーがページを取得する速さで、同時接続数と取得間隔からなる「クロール容量上限」です。クロールバジェットの供給側であり、クロール需要が需要側です。
• サーバー状態に応じて自動調整されます。 高速で健全なら上限が上がり、遅延や5xx・429が増えるとGoogleは減速します。Google自身の処理能力も別の上限で、すべてのGooglebotは一つの枠を共有します。
• GSCの手動スライダーは2024年1月8日に廃止されました。
• 現在Googlebotを減速させるには、まずサーバーを直し、緊急時だけ500・503・429を最長1〜2日返します。429にはRetry-Afterを付けられます。401・403・404は使わず、Googleが無視するcrawl-delayにも頼りません。
• 増速は申請できません。 サーバー、サイトマップ、重複URL、リンク、対象サイトでのIndexing APIを改善します。
• Bingには手動制御があります。 時間帯別のCrawl Controlとcrawl-delayを利用できます。
• クロール速度はランキング要因ではありません。 ほとんどのサイトで管理は不要です。

公式ドキュメント

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

Google

• Googlebotのクロール速度を下げる — 500・503・429、1〜2日の上限、減速申請フォームを説明。
• クロールバジェット管理 — クロール容量上限とサーバー状態への反応を定義。
• HTTPステータスコードがGoogleのクローラーに与える影響 — 減速する5xx・429と、影響しない429以外の4xxを整理。
• クロールに関する誤解と事実 — crawl-delay、順位、サーバー状態との関係を説明。
• Crawl Rate Limiter Toolの廃止予定（2023年11月） — 廃止発表。
• 速度制限にアクセス拒否や不存在の応答を使わない（2023年2月） — 4xxが不適切な理由。
• 新しいクロール統計レポート（2020年11月） — レポートの読み方。
• クロールバジェットを最適化する — 容量、需要、確認が必要なサイトを解説。

Bing / Microsoft

• Bing Webmaster Tools — Crawl Control — 時間帯別の手動クロール速度グリッド。
• Bingbotガイダンス — 1〜20秒のcrawl-delay指定を説明。
• bingbotシリーズ：クロール頻度の最適化（2018年10月） — 再取得の考え方。

出典からの引用

Googleの公式発言です。各リンクは出典ページの引用箇所を直接開きます。

Google — クロール速度の意味と決定要因

• “If the site responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (翻訳)「サイトがしばらく高速に応答すれば上限が上がり、より多くの接続で巡回できます。サイトが遅くなるかサーバーエラーを返すと上限が下がり、Googleの巡回量は減ります。」 — クロールバジェット管理。 引用箇所
• “Google has a lot of machines, but not infinite machines. We still need to make choices with the resources that we have.” (翻訳)「Googleには多数のマシンがありますが無限ではなく、利用できるリソースの中で選択する必要があります。」 引用箇所

Google — クロール速度を下げる方法

• “return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (翻訳)「クロールリクエストには200ではなく500、503、429を返してください。」 — Googlebotのクロール速度を下げる。 引用箇所
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days).” (翻訳)「長期間、つまり1〜2日を超えて行うことは推奨しません。」 引用箇所
• “You cannot request an increase in crawl rate, and it may take several days for the request to be evaluated and fulfilled.” (翻訳)「クロール速度の引き上げは申請できず、申請の評価と実施には数日かかる場合があります。」 引用箇所

Google — 巡回を減速させるステータスコード

• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (翻訳)「Googleのクローラーは429をサーバー過負荷のシグナルとして扱い、サーバーエラーと見なします。」 — HTTPステータスコードがGoogleのクローラーに与える影響。 引用箇所
• “The 4xx status codes, except 429, have no effect on crawl rate.” (翻訳)「429以外の4xxはクロール速度に影響しません。」 / “Don’t use 401 and 403 status codes for limiting the crawl rate.” (翻訳)「クロール速度の制限に401と403を使わないでください。」 引用箇所

Google — crawl-delayとランキング

• “The non-standard ‘crawl-delay’ robots.txt rule is not processed by Google’s crawlers.” (翻訳)「非標準のcrawl-delay robots.txtルールはGoogleのクローラーでは処理されません。」 — クロールに関する誤解と事実。 引用箇所
• “Improving your crawl rate won’t necessarily lead to better positions in Google Search results.” (翻訳)「クロール速度を改善しても、Google検索で順位が上がるとは限りません。」 引用箇所

Gary Illyes（Google）（クロール速度ツールの廃止について）

• “if the server persistently returns HTTP 500 status codes for a range of URLs, Googlebot will automatically, and almost immediately slow down crawling.” (翻訳)「一定範囲のURLが継続的にHTTP 500を返すと、Googlebotは自動的かつほぼ即座に減速します。」 記事
• “with the improvements we’ve made to our crawling logic and other tools available to publishers, its usefulness has dissipated.” (翻訳)「クロールロジックの改善と公開者向けの他ツールにより、その有用性は薄れました。」 記事

クロール速度チェックリスト

Googlebotを安全に減速させる手順

• 推測だけで決めず、GSCのクロール統計（平均応答時間・ホストステータス）とサーバーログで、クローラーが原因か確認する。
• サーバーを高速化するかリソースを増やし、根本原因を直す。これはインデックスを危険にさらさない恒久策。
• 本当の緊急時だけ、クロールリクエストに500・503・429を返す。Retry-After付きの429を優先する。
• 緊急応答は最長1〜2日に限定する。長引くとページがインデックスから外れ、広告が停止するおそれがある。
• 緊急ではない継続問題は、サイトの最適速度を添えてGoogleの専用フォームから申請する。
• BingではCrawl Controlで速度を設定し、必要ならrobots.txtにcrawl-delayを追加する。

してはいけないこと

• 401・403・404を速度制限に使わない。速度に効果がなく、ページを失う危険がある。
• Google向けにrobots.txtのcrawl-delayへ頼らない。Googleは無視し、Bingは対応する。
• 旧GSCのクロール速度スライダーを探さない。2024年1月8日に廃止済み。

より多くの巡回が必要な場合（強制ではなく間接改善）

• サーバーを高速化し、必要なリソースを追加する。
• 正規かつインデックス可能なURLを、正確なlastmod付きの整理されたサイトマップに載せる。
• クロールを浪費する重複URLや価値の低いURLを減らす。
• 内部リンクを強化し、外部リンクを獲得する。
• 可能な場面ではPOSTでなくGETを使い、対象サイトではIndexing APIを利用する。

クロール速度早見表

ステータスコードがGoogleのクロール速度に与える影響

重要事項

• クロール速度は速さ（供給）、クロール需要は取得したい量（需要）、クロールバジェットは両者の組み合わせ。
• Googleの用語はクロール容量上限。同時接続数と取得間隔からなり、サーバー状態に応じて自動調整される。
• 緊急時の5xx・429は最長1〜2日。長引くとインデックス削除や広告停止の危険がある。
• 手動増速はできない。 Googleへの申請は下げる方向だけ。
• GSCの手動スライダーは2024年1月8日に廃止（2023年11月24日発表）。
• すべてのGooglebotは一つのクロール枠を共有する。
• クロール速度はランキング要因ではない。
• BingではCrawl Controlとcrawl-delayを利用できる。

Googlebotへ一時的に減速を伝える

これは緊急時だけの手段です。クローラーに200ではなく、Retry-After付きの503（または429）を返します。Googleはほぼ即座に減速シグナルとして読み取ります。使用は最長1〜2日です。長引くと対象URLがインデックスから外れ、そのURLを指すGoogle広告が停止する可能性があります。恒久的な対策は、エラーを返し続けることではなく、サーバーを高速で健全にすることです。

Apache（.htaccess）— Retry-After付き503を返す

# Emergency only — remove within 1–2 days.
# Sends Googlebot a "slow down / try later" signal.
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Googlebot|bingbot) [NC]
RewriteRule ^ - [R=503,L]
Header always set Retry-After "3600"
ErrorDocument 503 "Server temporarily overloaded — please retry later."

Nginx — クローラーへRetry-After付き503を返す

# Emergency only — remove within 1–2 days.
if ($http_user_agent ~* (Googlebot|bingbot)) {
    return 503;
}
# Send a Retry-After hint with the 503 response.
add_header Retry-After 3600 always;

Express / Node.js — Retry-After付き429 Too Many Requests

// Emergency only — remove within 1–2 days.
// 429 explicitly means "too many requests" and carries a Retry-After.
app.use((req, res, next) => {
  const ua = req.get("user-agent") || "";
  if (/Googlebot|bingbot/i.test(ua)) {
    res.set("Retry-After", "3600"); // seconds
    return res.status(429).send("Too many requests — please retry later.");
  }
  next();
});

この処理はクロールを一時的に減速させるだけです。インデックス登録の停止や遮断には使えず、サーバー容量の問題を直す代わりにもなりません。

クロール速度の確認・制御ツール

• Google Search Console — クロール統計レポート — 総クロールリクエスト、総ダウンロード量、平均応答時間、過去約90日のホストステータス、応答コード・ファイル形式・目的・Googlebot種類別の内訳を確認できます。Google側の減速が見える場所です。
• Bing Webmaster Tools — Crawl Control — 時間帯ごとにBingbotの速度を設定する手動グリッドです。プリセットとカスタム設定があります。
• robots.txtのcrawl-delay — Bingなど一部のエンジンは対応し、Googleは無視します。
• サーバーログ分析 — ボットが実際にアクセスする速さと、返されたステータスコードを確認する一次資料です。
• サイト監査・クローラー — Ahrefs Site AuditやScreaming Frog SEO Spiderで、巡回を浪費する重複URL、パラメーターURL、クローラートラップを探します。

クロール速度への対応を決める

クローラー負荷でオリジンサーバーが過負荷になったときの手順

1. ボットを検証する。 送信元IPが名乗っているクローラーに属するか確認します。偽物なら通常のセキュリティ制御で遮断または速度制限します。
2. 影響を測る。 クローラーのリクエストと遅延、飽和、タイムアウト、5xxを照合します。一致しなければ本当の負荷源を調べます。
3. 可用性を守る。 必要なトラフィックだけを制限します。Googlebotの一時的な緊急対応には403・404でなく429・503を使います。
4. 集中箇所を探す。 ディレクトリ、パラメーター、応答コード、バイト数でリクエストを集計します。暴走するURL空間が主因なら、リンクや生成規則を直します。
5. 原因を修復する。 容量増強、安全な応答のキャッシュ、クローラートラップ削除、クローラー固有の公式制御を実施します。
6. 復旧を確認する。 一時制限を解除し、利用者の遅延とクローラーのエラー率が通常値へ戻ったことを確認します。

クロール速度で避けるべき誤り

• Googlebot向けにcrawl-delayを使う。 Googleは無視します。緊急時だけ一時的な429・503を使い、負荷の原因を直します。
• Googlebotを遅くするため403や404を返す。 これらはアクセス拒否や不存在を示し、一時的な過負荷を伝えません。正しい一時シグナルを使います。
• 恒久的な増速を強制する。 Search Consoleのスライダーは廃止済みで、巡回量を増やしても順位は上がりません。サーバー状態と需要シグナルを改善します。
• ユーザーエージェント文字列だけを信じる。 偽装できるため、挙動を変える前にIPを検証します。
• 緊急時の制限を残し続ける。 長期エラーはクロールとインデックス登録を損ないます。導入前に担当者と解除条件を決めます。

検証 → 保護 → 修復のフレームワーク

• 検証： トラフィックが本物のクローラーで、サーバー障害と相関することを証明します。
• 保護： 利用者の可用性を維持し、正しいHTTPの意味を伝える最小範囲の一時制御を使います。
• 修復： 容量のボトルネックや暴走URL空間を除去し、一時制御を解除します。

クロール速度とクロール需要は分けて考えます。健全なサーバーは容量上限を引き上げられますが、検索エンジンにより多くのURLを欲しがらせることはできません。

クロール速度への介入が効いたことを検証する

一時的な減速応答

テスト： curl -Iで制限対象のテストURLを要求します。期待結果： 予定した429または503が障害中だけ現れ、通常URLは利用できます。失敗の意味： 規則の範囲または返すステータスが誤っています。監視期間： 即時。ロールバック条件： 利用者や無関係なボットにも制限がかかった場合。

制限解除後の復旧

テスト： ヘッダー確認を繰り返し、サーバーとアクセスログを監視します。期待結果： 通常の200が戻り、クローラーエラーが減り、利用者の遅延が基準値に保たれます。失敗の意味： 一時規則が残っているか、容量問題が続いています。監視期間： HTTP挙動は即時、さらに次の通常クロール時間帯まで。ロールバック条件： 飽和や5xxが再発し、障害対応へ戻る必要がある場合。

URL空間の修復

テスト： 過剰リクエストを生んだパラメーターやパスをクロールし、ログで確認します。期待結果： 新しいトラップURLが生成・リンクされず、価値あるURLは到達可能です。失敗の意味： 別の発見経路が残っています。監視期間： 同等期間のログを比較。ロールバック条件： 価値あるページや必要なリソースが到達不能になった場合。

クロール速度の健全性を測る指標

検証済みクローラーのリクエスト率

指標： 検証済みクローラーIPからの単位時間当たりリクエスト数。分かること： 実際の巡回ペース。取得方法： ボット検証後のアクセスログ。基準・現実的な範囲： クローラーと時間帯ごとに自サイトの基準値を作ります。普遍的な安全値はありません。頻度： 障害中は毎日、通常は毎月。

クローラーに相関するエラー率と遅延

指標： クローラー活動中の5xx・タイムアウト・オリジン遅延。分かること： 速度が容量を超えているか。取得方法： サーバーテレメトリーとクローラーログの時刻を照合。基準・現実的な範囲： 平常時の自サイト基準と容量目標を使います。頻度： 重要サイトでは継続監視。

有用リクエストの割合

指標： 価値ある200ページへの検証済みクローラーリクエストと、リダイレクト・エラー・既知のトラップURLへのリクエストの比率。分かること： 容量が有効に使われているか。取得方法： ログのURLとステータスを分類。基準・現実的な範囲： 自サイトのURL在庫に対する推移を見て、普遍的な目標値は避けます。頻度： 毎月。

理解度チェック：クロール速度

参考資料

筆者の関連記事

• クロールバジェットを気にすべきタイミング — クロール速度をクロールバジェットの一要素として説明し、減速・改善策を紹介。
• Googlebotとは何か、どのように動くか — Googlebotが速度と取得対象を決める方法、速度変更機能の廃止を説明。
• テクニカルSEO初心者ガイド — クロールとクロール速度を全体像の中で整理。

筆者の講演

• How Search Works （SlideShare）— クロール速度上限を「サイトが支えられる範囲」と捉え、全Googlebotが一つのクロール枠を共有する点を説明します。注記：これはシステムに関する筆者の理解であり、完全または100%正確とは限りません。

その他の資料

• Search Engine Land — Googlebotのクロール速度ツール廃止発表 と廃止完了 — 廃止理由を含む解説。
• GoogleのCrawling December シリーズ — 公式クロール解説をまとめて確認できます。
• Search Engine Journal — Search ConsoleからCrawl Rate Limiter Toolを削除 — 2023年11月の発表と、自動設定される新しい最低速度を解説。
• Search Engine Journal — Googlebotの速度制限に403・400系応答を使わない — 4xxで減速させないよう求めたGoogleの2023年2月記事を紹介。
• Bing Webmaster Blog — bingbotシリーズ：クロール頻度の最適化 — Bingbotが再取得を決める仕組み。
• Bing Webmaster Blog — Bing Webmaster Toolsでbingbotを活用する — Crawl ControlなどBWT設定によるBingbotの速度管理。

変更履歴