robots.txtガイド

robots.txtのCrawl-delay：Googlebotは対応している？

Crawl-delayの意味、Googlebotが対応していない理由、クローラー負荷が高いときに確認すべき安全な対処方法を解説します。

Robots.txt Tools Editorial Team による最終確認 2026-09-13約7分で読めます
robots.txtのCrawl-delay：Googlebotは対応している？

Crawl-delayはrobots.txtでよく見かけますが、最も誤解されやすいディレクティブの一つです。Google SEOで重要な事実は明確で、Googlebotはrobots.txtのCrawl-delayをサポートしていません。 そのため、秒数を書いてもGooglebotのリクエスト間隔を固定する指示にはなりません。

一方、すべてのクローラーが無視するわけではありません。クローラー提供元が独自拡張として対応している場合があります。対象User-agentの公式資料を確認し、全クローラーに共通する仕様だと思い込まないことが重要です。

Crawl-delayの例

User-agent: ExampleBot
Crawl-delay: 10

一般には「リクエスト間隔を約10秒空けてほしい」という意味で使われます。しかしRFC 9309が標準化する中心はUser-agentグループとAllow/Disallowの一致処理であり、歴史的に使われてきたすべてのフィールドを共通仕様にしているわけではありません。

Googleがrobots.txtで扱うフィールドにはuser-agent、allow、disallow、sitemapなどがあり、crawl-delayは非対応として案内されています。

設定しただけで安心しない

アクセス急増時にCrawl-delayを追加して解決したと思うと、原因調査が遅れます。対象クローラーが無視すれば何も変わりません。

実際の原因は次のようなことがあります。

  • フィルターやファセットURLが急増している
  • カレンダーや検索URLが無限に生成されている
  • 5xxが続き再試行が増えている
  • robots.txtを守らないボットが来ている
  • 想定と別のUser-agentが負荷を作っている
  • アプリの応答が遅く通常のクロール量でも負荷が高い

まずアクセスログでUser-agent、リクエスト数、パス、HTTPステータスを確認してください。

401や403でGooglebotを遅くしない

/robots.txt自体を401や403にするのは危険です。Googleは429を除く多くの4xxを「有効なrobots.txtが存在しない」場合と同様に扱い、クロール制限がないものとして処理します。

HTTP/1.1 403 Forbidden

これは「Googlebotを遅くする」設定ではありません。むしろ、読み取ってほしかったDisallowルールをGoogleが利用できなくなる可能性があります。

429と5xxは別のシグナル

429 Too Many Requestsや5xxはサーバー過負荷・障害として扱われ、クロールが減る場合があります。ただし、意図的にエラーを返し続けることはクロール制御の代替策ではありません。

優先順位は、不要URLの発生源を修正し、本当に不要なパスをrobots.txtで制御し、キャッシュやサーバー容量を改善し、必要ならクローラー提供元が用意する正規の制御方法を使うことです。

不要パスならDisallowを検討する

User-agent: *
Disallow: /internal-search/
Disallow: /cart/
Disallow: /session/

Sitemap: https://example.com/sitemap.xml

これはアクセスを「遅らせる」のではなく、そのパスへのクロールを減らす考え方です。ただしDisallowはnoindexではありません。検索結果から除外したいページには別のインデックス制御が必要です。

大規模サイトではクロール効率を見る

EC、マーケットプレイス、メディアなどでは、固定の待ち時間よりクロール効率が重要です。並び替えパラメータ、内部検索、セッションID、プレビューURL、重複ページネーションなどが重要なcanonical URLより大量に発見されていないか確認します。

安全な調査手順

  • ログから負荷を作っているUser-agentを特定
  • 提供元がCrawl-delayをサポートするか確認
  • リクエスト量と上位パスを集計
  • URL爆発や重複パターンを確認
  • /robots.txtのHTTPステータス・サイズ・エンコードを確認
  • 重要ページやレンダリング資源がブロックされていないか確認
  • 429や5xxが増えていないか確認
  • 変更後は実URLとログで効果を検証

Googlebotに対しては結論が明確です。robots.txtのCrawl-delayに依存せず、対応しているDisallow/Allow、URL設計、サーバー性能、Googleの公式クロール管理情報を使ってください。

Crawl-delayだけで負荷問題を解決しません

server負荷が問題の場合、まずaccess log、response time、429、503、cache hit率を確認します。crawler requestが本当に負荷の主因か、applicationやdatabaseの別問題なのかを切り分けます。robots.txtの Crawl-delay は標準化された共通挙動ではなく、Googlebotは対応しません。対応を明示するcrawlerに対しても、値を大きくしすぎると更新発見が遅れるため、必要性と影響を記録します。

Google Search向けのcrawl問題では、Search Consoleやserver logを使い、不要なURL空間が増えていないか、5xxが発生していないか、重要pageのresponseが遅くないかを確認します。filterやinternal searchが大量URLを生成している場合は、delayよりURL設計を直す方が効果的です。

変更前後を比較します

設定を変えたら、対象crawlerのrequest頻度、server error、重要URLの発見速度をbefore/afterで比較します。単にrequest数が減ったことだけを成功条件にせず、検索に必要なpageまで更新されにくくなっていないかも確認します。

関連ガイド