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の公式クロール管理情報を使ってください。
