AIクローラーでサーバーが重いときの対策｜止めずに負荷だけ下げる設定例

ここ数日サーバーが重く、ログを見るとGPTBotやClaudeBotが何度も来ている。そう気づいて、この記事にたどり着いた方もいるでしょう。

レンタルサーバーの会社から「負荷が高い」と連絡が来て、急いで対応が必要になった方もいるかもしれません。

すぐに思いつくのは、クローラーを止めることです。ただし、検索用のクローラーまで止めると、ChatGPTやPerplexityの回答でサイトが参照されにくくなります。

この記事は、AIクローラー（AIサービスがWebページを読み取る自動プログラム）のアクセスで負荷が高いときに、締め出さずに負荷だけを下げる方法をまとめたものです。原因の確かめ方から、robots.txt、HTTPの応答、キャッシュ、nginxの設定例までを順に説明します。

各社の仕様は、2026年10月17日に公式の文書を開いて確かめました。設定例と数値の目安は、筆者の提案です。

先に結論 止めずに遅くして、同じページは写しを返す

結論を、公式に言えることと、筆者の判断に分けて並べます。

論点	確認できたこと	筆者の判断
原因	Googleは、急な増加の原因に絞り込みURLやカレンダーを挙げている	AIクローラーのアクセスも、同じ型のURLに偏っていないかを見る
robots.txtのCrawl-delay	AnthropicとCommon Crawlは対応を明記。GoogleとAppleは非対応	効く相手は一部。保険として書く
429と503	Googleは数時間から1〜2日の短期なら使ってよいと案内	急ぎの止血に限り、元に戻す日を決める
キャッシュ	Cloudflareは標準ではHTMLを保存しない	最も根本的な対策。先に整える
回数制限	nginxのlimit_reqで、超えた分だけ拒否できる	自社でサーバーを触れる場合の最後の手段

進める順番は、不要なURLを減らし、写しを返す仕組みを整え、それでも足りなければ回数制限をかける形です。

ブロックは最後に回す

OpenAIは、検索用のOAI-SearchBotを許可すると、ChatGPTの検索結果にサイトが表示されると説明しています。負荷を理由に検索用まで止めると、露出を自分で減らすことになります。

負荷の問題と方針の問題は別に考える

AIに使わせるかどうかは、事業の方針の話です。サーバーが重いのは、運用の話です。

この2つを混ぜると、負荷を下げたかっただけなのに、AI検索から消える結果になりかねません。方針の決め方は、別の記事「AIクローラーは許可か拒否か」で説明しています。

AIクローラーは許可か拒否か

まず原因を確かめる 本当にAIクローラーなのか

対策の前に、重くなった原因を確かめます。AIクローラーが原因とは限りません。

Googleも、クロールが急に増えたときは、ホスティング会社に相談し、サーバーの最近のアクセスログを見て、トラフィックの出どころを確かめるよう勧めています。

ログで見る4つのこと

アクセスログは、レンタルサーバーの管理画面からダウンロードできる場合が多くあります。見る点は次の4つです。

1. 時間あたりの件数。重くなった時間帯に、どのユーザーエージェント（アクセス元が名乗るプログラム名）が多いかを見ます。
2. アクセス先のURL。同じ型のURLに偏っていないかを見ます。
3. ステータスコード。200が並んでいるのか、500番台が出ているのかを見ます。
4. 応答時間。記録していれば、集中した時間に遅くなっているかを見ます。

1日の合計より、1分や1時間あたりの山を見るほうが、原因をつかみやすくなります。

読まれすぎるURLには型がある

Googleの公式文書は、クロールが急に増える原因として、次の3つを挙げています。

原因の型	公式文書の説明	見分けるログの手がかり
絞り込み・並べ替え	絞り込みや並べ替えの機能が、URLを大量に作る	URLの末尾に条件の文字列が並ぶ
カレンダー	日付ごとのURLが大量にできる	日付だけが違うURLが連続する
動的検索広告の対象	広告の対象に指定したページが読まれる	広告の運用担当に確認する

WordPressの場合は、サイト内検索の結果ページ（?s=の付いたURL）も同じ型になります。条件の組み合わせでURLが際限なく増えるため、キャッシュも効きにくくなります。

ログでこうしたURLが目立つなら、クローラーの数を抑える前に、そのURLを読ませない対策が先です。

なりすましの可能性も考える

ユーザーエージェントは自由に名乗れます。「GPTBot」と書かれていても、本物とは限りません。

なりすましは、Crawl-delayも守りません。

本物かどうかは、公開されているIPアドレスの一覧と、DNSの逆引きで確かめます。手順は、別の記事で説明しています。

AIクローラーのなりすましを見分ける方法

なりすましと分かったアクセスは、遮断して構いません。

対策の全体像 4つの手順を順番に進める

負荷を下げる方法は、効く相手と副作用が違います。まず全体を表にします。

方法	効く相手	手間	主な副作用や注意
不要なURLを読ませない	対応する全クローラー	小	読ませたいページを誤って除かない
robots.txtのCrawl-delay	対応を明記したクローラーだけ	小	GoogleとAppleには効かない
429や503とRetry-After	多くのクローラー（守るかは相手次第）	中	長く続けると検索から外れる
キャッシュとCDN	人を含むすべてのアクセス	中	個人ごとの内容を含むページは除く
nginxなどの回数制限	指定したクローラー	中から大	上限が厳しすぎると読まれる量が減る
ブロック	指定したクローラー	小	AI検索に出にくくなる場合がある

筆者がおすすめする順番

上から順に進めます。不要なURLを減らし、Crawl-delayを書き、写しを返す仕組みを整えます。

それでも足りないときに、回数制限をかけます。急ぎの止血だけは、429や503を一時的に使います。

共用のレンタルサーバーの場合

共用サーバーでは、nginxの設定を直接変えられないことが多くあります。その場合は、前半の3つと、サーバー会社が用意するアクセス制限の機能で対応します。

回数制限の設定は、サーバー会社や使っているCDNに、提供の有無を確かめてください。

対策1 不要なURLを読ませない

効果が大きいのに手間が小さいのが、読ませる必要のないURLの除外です。クローラーの数は変えずに、1回の訪問で無駄に読まれる量を減らします。

サイト内検索の結果ページを除く

WordPressのサイト内検索は、?s=の後ろにキーワードが付くURLです。キーワードの数だけURLが増え、キャッシュも効きにくくなります。

robots.txtには、次のように書きます。

User-agent: *
Disallow: /?s=
Disallow: /search/

robots.txtは、サイトの一番上の階層に置くファイルです。書き方の基本は、Google検索セントラルのrobots.txtの作成方法のページにあります。

名前を指定したグループがあるときの注意

robots.txtには、クローラーの名前ごとにグループを作れます。

RFC 9309は、自分の名前に合うグループがないときだけ、User-agent: *のグループに従うと定めています。名前に合うグループがあれば、そちらを使います。

つまり、GPTBotなどの名前を指定したグループを作っている場合は、除外したいURLをその中にも書き足す必要があります。

User-agent: ClaudeBot
Crawl-delay: 1
Disallow: /?s=
Disallow: /search/

除外してよいかを確かめる

除外するURLは、人も検索エンジンも使わないものに限ります。サイト内検索のページを、検索結果から入ってほしいページとして育てている場合は、除外の前にSearch Consoleで流入を確かめてください。

robots.txtに書いた直後は、まだ読まれることがあります。反映には時間がかかるため、数日後にログで確かめます。

対策2 robots.txtのCrawl-delayは対応する相手にだけ効く

Crawl-delayは、アクセスの間隔を何秒あけてほしいかを伝える指定です。標準仕様のRFC 9309には書かれていない独自の拡張で、対応はクローラーごとに違います。

公式に確かめられた対応状況

2026年10月17日に、各社の公式文書で確かめた状況は次のとおりです。

運営元	クローラー	Crawl-delay	公式文書の説明
Anthropic	ClaudeBot	対応	非標準のCrawl-delayに対応すると明記し、記述例を載せている
Common Crawl	CCBot	対応	FAQに、Crawl-delayに従うと明記している
Microsoft	Bingbot	対応と読める	robots.txtのCrawl-delayが、Crawl Controlの設定より優先されると説明している
Google	Googlebot	非対応	crawl-delayは処理されないと明記している
Apple	Applebot	非対応	Crawl-delayには従わないと明記している
OpenAI	GPTBotなど	記載なし	開発者向け文書のクローラーのページに、Crawl-delayの記載は見当たらない
Perplexity	PerplexityBot	記載なし	クローラーのページに、Crawl-delayの記載は見当たらない

記載がないことは、非対応の証明にはなりません。ただし、書けば効くと考える根拠もありません。

書き方と値の決め方

クローラーの名前ごとに、秒数を書きます。

User-agent: ClaudeBot
Crawl-delay: 1

User-agent: CCBot
Crawl-delay: 2

Anthropicの文書の例は、ClaudeBotに1秒の指定です。Common Crawlの文書の例は、CCBotに2秒の指定です。

値を大きくしすぎると、読まれる量が極端に減ります。10秒にすると、1日に読めるのは最大でも8,640ページです。

まず1秒から2秒で試します。

Applebotは自動で調整する

Appleの文書は、サイトが遅くなったりエラーを返したりすると、Applebotのクロール頻度が自動で調整されると説明しています。Crawl-delayを書いても、Applebotには効きません。

Bingは管理画面でも調整できる

Bing Webmaster Toolsには、時間帯ごとにBingbotのクロール速度を変えられるCrawl Controlがあります。robots.txtにCrawl-delayがあるときは、そちらが優先されると、Microsoftの文書に書かれています。

対策3 429や503とRetry-Afterで「今は待って」と伝える

急いで負荷を下げたいときの手段が、HTTPの応答で待ってほしいと伝える方法です。HTTPのステータスコードは、サーバーが返す3桁の結果番号です。

429と503の意味

「今は応じられない」を伝える代表的なコードは2つあります。

コード	意味	定めている文書
429 Too Many Requests	一定時間に送られたリクエストが多すぎる（回数制限）	RFC 6585
503 Service Unavailable	一時的に応じられない	RFC 9110

RFC 6585は、429の応答にRetry-Afterを付けてよいと定めています。あわせて、429の応答はキャッシュに保存してはならないとも定めています。

回数制限には429が合い、サーバー全体の不調やメンテナンスには503が合います。

Retry-Afterの書き方

Retry-Afterは、いつ以降にもう一度来てほしいかを伝える応答ヘッダーです。RFC 9110は、値を秒数か日時のどちらかで書くと定めています。

書式	例	意味
秒数	Retry-After: 120	120秒後以降に再試行してほしい
日時	Retry-After: Wed, 21 Oct 2026 03:00:00 GMT	日本時間の21日12時以降に再試行してほしい

日時はGMTで書きます。日本時間から9時間引いた時刻です。

Googleの公式案内の要点

Googleの「クロール頻度を下げる」の文書（2026年10月6日更新）には、次の内容があります。

• 急いで短い期間（数時間、または1〜2日）だけ減らすなら、200の代わりに500、503、429を返す
• 503と429にはRetry-Afterを付けられる。秒数か、UTCの日時で書く
• 効果はホスト名（たとえばサブドメインごと）の全体に及ぶ
• 数が減れば、Googleは自動でクロールの頻度を戻す

同じ文書は、副作用も明記しています。新しいページの発見が減り、既存のページの更新も遅れます。

2日を超えて返し続けない

Googleは、長期間の使用を勧めていません。目安は1〜2日までです。

トラブルシューティングの文書には、503や429を2日を超えて返すと、そのURLがインデックスから外れるとあります。数日以上続くと、クロールが恒久的に減ったり止まったりするおそれもあると、同じ文書は説明しています。

止血に使うときは、元に戻す日を先に決めておきます。

特別な依頼という手段もある

エラーを返せない環境では、Googleに特別な依頼を送る方法があります。頻度が異常に高いことを報告し、サイトに合う頻度を書いて送ります。

ただし、頻度を上げてほしいという依頼はできません。評価と対応には、数日かかることがあります。

Googleの案内を押さえておく理由

この記事の主題はAIクローラーです。それでもGoogleの文書を詳しく見るのは、止血の方法がGooglebotにも同じように効いてしまうからです。

AIクローラーだけに返したつもりが、Googlebotにも返っていないか

User-Agentの判定が広すぎると、Googlebotにまで429や503が返ります。止血のつもりが、検索の登録に影響する事故になりかねません。

AIクローラー向けの設定を入れたら、Search Consoleの「クロールの統計情報」レポートで、サーバーの応答に変化がないかを確かめます。

403や404で代用しない

回数制限のつもりで403や404を返す人がいます。Googleは、401と403をクロール頻度の制限に使わないよう案内しています。

429以外の4xxは、クロール頻度に影響しないと、HTTPステータスコードの文書に書かれています。しかも4xxを返したURLは、検索のインデックスから外れていきます。

返すコード	クロール頻度への効果	検索への副作用
429	下がる（過負荷の合図として扱われる）	短期なら小さい。2日を超えると外れる
503や500	下がる	短期なら小さい。2日を超えると外れる
403や404	影響しない	インデックスから外れる

robots.txtには5xxを返さない

robots.txtが5xxを返すと、Googleは最初の12時間、サイトのクロールを止めます。その後は、30日間、最後に取得できた版を使いながら、取り直しを続けます。

回数制限や503の対象から、robots.txtを必ず外してください。後で示すnginxの設定例でも、そうしています。

Search Consoleの頻度設定ツールは終了している

Search Consoleには、かつてクロール頻度を設定するツールがありました。Googleの公式ブログによると、2024年1月8日に廃止されました。

現在、頻度を下げる方法は、サーバーの応答で伝える方法と、先ほどの特別な依頼です。

AIクローラーは429を守るのか

Googleの案内は、Googlebotの動きです。AIクローラーも同じように動くとは限りません。

公式文書で確かめられたのは、次の範囲です。

クローラー	429や5xxへの反応	根拠
CCBot	429か5xxを受けると、間隔を自動で広げる	Common CrawlのFAQ
Applebot	サイトが遅いときやエラーのときに、頻度を自動で調整する	Appleのサポート文書
GPTBot、OAI-SearchBot	記載を確認できなかった	OpenAIの開発者向け文書
ClaudeBot	記載を確認できなかった。Crawl-delayには対応	Anthropicのヘルプ
PerplexityBot	記載を確認できなかった	Perplexityの開発者文書

守るかどうかはクローラー次第です。429を返すことは、相手に伝える試みであり、強制する手段ではありません。

だからこそ、サーバー側で負荷を受け止める対策も、あわせて進めます。

対策4 キャッシュとCDNで同じページを何度も作らない

CMS（サイトの管理システム）は、アクセスのたびにデータベースから記事を読み出し、HTMLを組み立てる作りが多くあります。クローラーに何千回も読まれると、この処理が追いつかなくなります。

ページキャッシュの考え方

ページキャッシュは、一度組み立てたHTMLを保存し、次からはそのまま返す仕組みです。2回目以降はファイルを返すだけで済むため、サーバーの負担が下がります。

人のアクセスにも効くので、AIクローラー対策としては最も根本的な方法です。

CDNを使うときの注意

CDNは、各地のサーバーにページの写しを置いて配る仕組みです。アクセスの多くを、自社のサーバーに届く前に返せます。

Cloudflareの文書によると、CloudflareのCDNは、HTMLとJSONを標準では保存しません。標準で保存するのは、画像やCSSなど決まった拡張子のファイルで、robots.txtも含まれます。

HTMLを保存したいときは、Cache Rulesで対象を指定します。

保存してはいけないページ

人ごとに内容が変わるページを保存すると、別の人に見えてしまう危険があります。管理画面、ログイン後のページ、会員向けのページは、保存の対象から外します。

Cloudflareには、特定のCookieがあるときは保存しない設定（Bypass Cache on Cookie）の例が、公式文書にあります。

効いているかを確かめる

Cloudflareの応答ヘッダーCF-Cache-Statusで、保存された写しから返したかを確かめられます。

値	意味
HIT	Cloudflareの保存から返した
MISS	保存の対象だが、その時点では未保存で、サーバーから取った
DYNAMIC	保存の対象外と判断し、サーバーに取りに行った
BYPASS	対象だったが、サーバーの応答が保存を許さなかった

確かめるコマンドは次のとおりです。URLは自社のものに置き換えます。

curl -sI https://www.example.com/blog/sample/ | grep -i -E "cf-cache-status|cache-control|age"

2回続けて実行して、2回目にHITが出れば保存されています。

対策5 nginxのlimit_reqでクローラーごとに回数を制限する

自社でnginxを管理している場合は、limit_req（一定時間あたりのリクエスト数に上限を設ける機能）で、AIクローラーにだけ上限を設けられます。超えた分だけを拒否し、止めずに速度を落とす設定です。

公式文書で確かめた仕様

nginxの公式文書には、次の仕様が書かれています。

項目	仕様
burst	平均を超えても、この数までは処理する。標準は0
nodelay	超えた分を待たせず、すぐに処理する
拒否のコード	標準は503。limit_req_statusで変えられる
空のキー	キーが空のアクセスは、数えない
limit_req_dry_run	制限をかけず、超えた数だけを数える（1.17.1以降）
記録の水準	拒否は標準でerrorの水準で記録する

この仕様を使うと、クローラーの名前を鍵にして数える設計ができます。大手のクローラーは多数のIPアドレスから来るため、IPごとに数えても全体は減りません。

設定例

次の例は、GPTBot、ClaudeBot、PerplexityBot、CCBotのそれぞれに、平均で1秒に1回までの上限を設けます。

この設定例は、公式文書の仕様に沿って筆者が組んだものです。この記事の制作環境ではnginxを動かしていないため、実機での動作は未確認です。

反映の前に、必ず後述の文法チェックと試運転を行ってください。

# httpブロックの中
map $http_user_agent $ai_bot_ua {
    default           "";
    ~*GPTBot          gptbot;
    ~*ClaudeBot       claudebot;
    ~*PerplexityBot   perplexitybot;
    ~*CCBot           ccbot;
}

# robots.txtは制限の対象外にする
map $uri $ai_bot_key {
    /robots.txt       "";
    default           $ai_bot_ua;
}

limit_req_zone $ai_bot_key zone=ai_bots:1m rate=1r/s;

# serverブロックの中
limit_req zone=ai_bots burst=5 nodelay;
limit_req_status 429;

error_page 429 = @too_many_requests;
location @too_many_requests {
    add_header Retry-After 120 always;
    return 429 "Too Many Requests";
}

各行の意味

設定	役割
map $http_user_agent	名乗っているクローラー名を、数えるための鍵に変える。一致しなければ空
map $uri	robots.txtへのアクセスは、鍵を空にして数えない
limit_req_zone	鍵ごとに、平均で1秒に1回までの枠を作る。1MBで約8千から1万6千件の状態を持てる
burst=5 nodelay	一時的な集中は5回まで待たせずに処理し、超えた分を拒否する
limit_req_status 429	拒否のコードを、標準の503から429に変える
error_page と location	拒否の応答にRetry-Afterを付ける。alwaysは、エラーの応答にも付けるための指定

一般の訪問者のアクセスは、鍵が空になるため、数えられません。Googlebotも対象に含まれません。

試運転から始める

いきなり制限をかけると、読ませたいページまで読まれなくなるおそれがあります。nginxには、制限をかけずに、かけたらどうなるかだけを数えるlimit_req_dry_runがあります。

limit_req_dry_run on;

アクセスログの形式に$limit_req_statusを加えると、各リクエストが通ったか、制限にかかったかを記録できます。試運転の間は、REJECTED_DRY_RUNの件数を数えます。

反映の前に文法を確かめる

設定を変えたら、反映の前に文法チェックを行います。

sudo nginx -t
sudo systemctl reload nginx

nginx -tが成功したときだけ、reloadを実行してください。

WordPressの場合に確かめること

WordPressのサイトでは、次の3点を順に確かめます。

サイトヘルスでページキャッシュを見る

WordPress 6.1から、管理画面の「サイトヘルス」に、ページキャッシュの確認が加わりました。公式の開発者向けブログによると、全ページを保存する仕組みを使っているかと、サーバーの応答時間が許容範囲かを調べます。

応答時間の基準は、標準で600ミリ秒です。この確認は、本番環境として動いているサイトでだけ実行されます。

キャッシュの方法は1つに絞る

ページキャッシュを入れる方法は、いくつかあります。

• レンタルサーバーの会社が提供するキャッシュ機能を有効にする
• キャッシュ用のプラグインを導入する
• CDNでHTMLを保存する

複数を重ねると、古い内容が返る原因を切り分けにくくなります。サーバー会社の案内を確かめて、1つを選んでください。

サーバーの設定を触れないとき

共用のレンタルサーバーでは、nginxの設定を直接変えられないことが多くあります。その場合は、次の組み合わせで対応します。

手段	内容
不要なURLの除外	robots.txtで、サイト内検索の結果ページなどを除く
Crawl-delay	対応を明記したクローラーの名前ごとに書く
キャッシュ	サーバー会社の機能か、プラグインを使う
アクセス制限	サーバー会社やCDNが提供する、回数制限やWAFの機能を確かめる

プラグインで429を返す方法もあります。ただし、WordPressが動き出してから判定するため、負荷を下げる効果は限られると筆者は考えます。

できるだけ、サーバーやCDNの手前で処理してください。

負荷対策とブロックの使い分け

ここまでは、止めずに負荷を下げる方法でした。ブロックを選ぶ場面も、整理しておきます。

状況	おすすめの対応
本物の検索用クローラーが、一時的に集中している	Crawl-delay、キャッシュ、回数制限
学習に使われること自体を望まない	学習用だけをrobots.txtで拒否し、検索用は許可する
名乗りが偽物で、robots.txtを守らない	WAFやファイアウォールで遮断する
意味のないURLを大量に読まれている	そのURLだけをrobots.txtで拒否する

学習用と検索用は別のクローラー

OpenAIの文書によると、検索用のOAI-SearchBotと学習用のGPTBotは、それぞれ独立して設定できます。Anthropicも、ClaudeBot、Claude-User、Claude-SearchBotの3つを分けています。

負荷が理由で検索用まで止めると、AI検索での露出を自分で減らします。Anthropicの文書は、Claude-SearchBotを止めると、検索結果での見え方と正確さが下がるおそれがあると説明しています。

利用者の操作で動くアクセスは別に考える

OpenAIの文書によると、ChatGPT-Userは、利用者がChatGPTに質問したときに、ページを読みに来るアクセスです。自動で巡回するものとは違い、robots.txtの規則が適用されないことがあると書かれています。

Perplexityの文書も、利用者の依頼で動くPerplexity-Userは、一般にrobots.txtを無視すると説明しています。

こうしたアクセスは、回数制限の対象に入れる前に、数と時間帯を確かめます。

IPアドレスでの遮断は確実ではない

Anthropicは、IPアドレスを遮断する方法では、拒否の意思が確実に、または長く伝わらない場合があると説明しています。robots.txtを読む作業まで妨げるためです。

拒否したいときは、robots.txtで指定する方法を案内しています。

やってはいけないこと

1. 503や429を何日も返し続ける

2日を超えると、インデックスから外れるおそれがあります。止血に使ったら、元に戻す日を決めてください。

2. 403や404で回数制限をする

クロール頻度を下げる効果がなく、検索のインデックスから外れる原因になります。

3. robots.txtまで制限の対象にする

robots.txtが読めないと、Crawl-delayも拒否の指定も、クローラーに届きません。Googleは、5xxのときに最初の12時間、サイトのクロールを止めます。

4. botの3文字だけで判定する

「bot」という短い条件では、GooglebotやBingbotまで含まれます。クローラーは正式な名前で指定してください。

5. 設定したまま効果を確かめない

数日後に、ログで次の点を確認します。

• 429の件数
• クローラーごとの件数
• サーバーの応答時間
• 人のアクセスへの影響

作業のチェックリスト

作業の前後で、次の表を使って確認してください。

段階	確認すること
原因	重い時間帯に、どのクローラーが、どのURLに、何回来ているかをログで確かめた
原因	多いクローラーが本物かを、公開IPとDNSの逆引きで確かめた
原因	サイト内検索の結果など、読ませる必要のないURLが多くないか確かめた
設定	不要なURLをrobots.txtで除いた（名前を指定したグループにも書いた）
設定	Crawl-delayは、対応を明記したクローラーの名前ごとに、1秒から2秒で書いた
設定	ページキャッシュが効いているかを確かめた
設定	HTMLを保存するCDNでは、ログイン後の画面やCookieを使うページを除いた
設定	回数制限は、GooglebotとBingbotを対象に入れていない
設定	robots.txtを、回数制限と503の対象から外した
設定	拒否は403や404でなく、429か503を返し、Retry-Afterを付けた
設定	nginxの設定は、nginx -tで文法を確かめ、試運転をしてから反映した
反映後	一時的な429や503は、2日を超えないうちに元へ戻す日を決めた
反映後	数日後にログで、429の件数と応答時間を確かめた
反映後	Search Consoleのクロールの統計情報で、Googlebotの様子に異常がない
反映後	検索用のクローラーまで止めていない

よくある質問

Q1. Crawl-delayを書けば、GPTBotもゆっくりになりますか。

2026年10月17日に確かめた範囲では、OpenAIの文書にCrawl-delayの記載は見当たりませんでした。書いても害はありませんが、効くことを前提にはしないでください。

対応を明記しているのは、AnthropicのClaudeBotとCommon CrawlのCCBotです。Bingは、robots.txtのCrawl-delayを優先すると説明しています。

Q2. 429と503は、どちらを使えばよいですか。

特定のクローラーのアクセスが多すぎるときは、回数が多すぎるという意味の429が合います。サーバー全体が過負荷やメンテナンスで応じられないときは、503を使います。

Googleは、どちらもクロールを減らす合図として扱うと説明しています。どちらにもRetry-Afterを付けられます。

Q3. Retry-Afterは何秒にすればよいですか。

公式の文書に、決まった秒数はありません。

数値を決めるときの筆者の目安は、数十秒から数分です。

メンテナンスのように終わる時刻が分かっているときは、日時で書けます。守るかどうかはクローラー次第なので、この値だけで負荷が下がるとは考えないでください。

Q4. 回数制限をかけると、AI検索に引用されにくくなりますか。

上限が適切なら、影響は小さいと筆者は考えます。ただし、厳しい上限を長く続けると、新しいページや更新が読まれるまでの時間が延びます。

引用されやすさとの関係は、各社の公式文書に記載が見当たりません。試運転で影響を見ながら、数値を調整してください。

Q5. 自社でサーバーを管理していません。何から始めればよいですか。

サーバー会社に、負荷の原因となっているアクセスの内訳を問い合わせます。そのうえで、キャッシュ機能の有効化と、robots.txtでの不要なURLの除外から始めます。

回数制限の機能があるかも、あわせて確かめてください。

まとめ

AIクローラーでサーバーが重いときは、いきなりブロックせずに、次の順で進めます。

1. ログで、どのクローラーが、どのURLに、どれだけ来ているかと、本物かどうかを確かめる
2. 読ませる必要のないURLを、robots.txtで除く
3. 対応しているクローラーには、Crawl-delayを書く
4. ページキャッシュやCDNで、同じページを毎回作らないようにする
5. それでも足りなければ、nginxのlimit_reqなどで上限を設け、超えた分に429とRetry-Afterを返す
6. 急ぎの止血に429や503を使うときは、robots.txtを除き、2日を超えないうちに元へ戻す

負荷の問題と、AIに使わせるかどうかの方針は別です。負荷は、遅くする方法で解決し、検索用のクローラーが読む機会は残しておきます。

参照した公式文書

2026年10月17日に確認しました。

• Google検索セントラル、Googleのクロール頻度を下げる（developers.google.com/crawling/docs/crawlers-fetchers/reduce-crawl-rate）
• Google検索セントラル、クロールエラーのトラブルシューティング（developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors）
• Google検索セントラル、HTTPステータスコードの扱い（developers.google.com/crawling/docs/troubleshooting/http-status-codes）
• Google検索セントラル、robots.txtの仕様、クロールに関する誤解、クロールバジェットの管理
• Google検索セントラルのブログ、Search Consoleのクロール頻度制限ツールの廃止予告（2023年11月）
• Anthropic、ウェブのクロールとサイト所有者のブロック方法（support.claude.com/en/articles/8896518）
• Common Crawl、CCBotのページとFAQ（commoncrawl.org）
• Apple、About Applebot（support.apple.com/en-us/119829）
• Microsoft、Bing Webmaster Tools、Crawl Controlのヘルプ
• OpenAIの開発者向け文書、クローラー（developers.openai.com/api/docs/bots）
• Perplexityの開発者文書、クローラー（docs.perplexity.ai/docs/resources/perplexity-crawlers）
• nginx、ngx_http_limit_req_moduleの文書（nginx.org）
• Cloudflare、キャッシュの標準の動作と応答ヘッダーの文書
• WordPress開発者ブログ、WordPress 6.1のキャッシュ確認の追加（make.wordpress.org/core/2022/10/06/）
• RFC 9110、RFC 9309、RFC 6585

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。