robots.txtガイド

robots.txtのHTTPステータス：200・404・403・429・5xxの意味

robots.txtのHTTP応答がGooglebotに与える影響を解説。200、リダイレクト、404、403、429、5xx、DNS障害の違いをまとめます。

Robots.txt Tools Editorial Team による最終確認 2026-09-13約7分で読めます
robots.txtのHTTPステータス：200・404・403・429・5xxの意味

/robots.txtのHTTP応答はルール本文と同じくらい重要です。正しいDisallowを書いていても、エンドポイントが403、5xx、リダイレクトループ、HTMLエラーページなどを返していれば、クローラーの解釈は想定と変わります。

Googlebotの処理を早見表で確認

応答一般的なGoogleの扱い
2xx返されたrobots.txtを処理
3xx一定回数までリダイレクトを追跡
多くの4xx（429を除く）有効なrobots.txtがないものとして扱い、制限なしと判断
429通常の404とは違い、過負荷シグナルとして扱う
5xx一時的にクロールを停止・抑制し再試行。以前のルールが影響する場合あり
DNS・ネットワーク障害サーバーエラーに近い扱い

特に403を「botを拒否できた」と誤解しないことが重要です。

200：通常の状態

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8

User-agent: *
Disallow: /internal-search/
Sitemap: https://example.com/sitemap.xml

GoogleはUTF-8を期待し、robots.txtには500KiBの処理上限があります。200でもファイルが巨大なら上限以降は無視されます。

404：Googleでは通常「制限なし」

robots.txtが404だから全クロールが止まるわけではありません。Googleは429を除く通常の4xxを、有効なrobots.txtが存在しない状態として扱います。

そのため、制限が不要なサイトで404は必ずしもエラーではありません。ただし、ステージング環境を守る方法にはなりません。非公開環境は認証してください。

403・401は「クロール拒否」にならない

WAFや認証で/robots.txtに403を返す設定は危険です。

HTTP/1.1 403 Forbidden

Googleはrobots.txtに対する通常の403/401を、意図したDisallowとしては解釈しません。CDNがGooglebotだけrobots.txtを拒否すると、リポジトリに正しいルールがあっても本番では制限が読まれない可能性があります。

429は別扱い

429 Too Many Requestsは過負荷やレート制限のシグナルです。Googleは通常の4xxとは分けて扱います。これは日常的なrobots.txt設定方法ではなく、本当に負荷が高い場合の運用応答です。

5xxはクロールを一時停止させる可能性がある

robots.txt取得で500、502、503などが続くと、Googleは再試行しながらクロールを抑制します。以前取得した有効なrobots.txtを一定期間利用することもあります。

デプロイで静的ファイルが動的ルートに変わった、Edge Functionが失敗している、上流サーバーが落ちている、といった問題は早急に確認してください。

リダイレクトは短く終わらせる

robots.txtはリダイレクトできますが、ループや長いチェーンは避けます。よくある原因は次の通りです。

  • HTTP↔HTTPSのループ
  • www↔apexのループ
  • 多言語middlewareが/robots.txtを言語URLへ送る
  • 認証middlewareがログインページへ送る
  • CDNがHTMLを200で返す

最も単純なのは、各オリジンの/robots.txtで直接200を返す構成です。

ブラウザ表示だけで判断しない

確認すべき項目：

  • 最終URL
  • HTTPステータス
  • Content-Type
  • ファイルサイズ
  • 文字コード
  • キャッシュヘッダー
  • User-agentごとのWAF動作
  • 本文が本当にrobots.txtテキストか

トラブルシューティングの順序

  1. 本番ホストの/robots.txtを外部から取得
  2. 最終URLとHTTPステータスを記録
  3. リダイレクト、CDN、WAFを確認
  4. UTF-8のテキストか確認
  5. 構文を検証
  6. 代表URLを対象クローラーでテスト
  7. サーバーログで取得失敗を確認
  8. 古いrobots.txtのキャッシュを考慮
  9. 修正後も継続監視

robots.txtの正しさにはHTTP配信も含まれます。 同じ本文でも200、403、404、5xxではクロールへの影響がまったく違うため、ルールだけでなくライブ応答を必ず確認してください。

Status codeごとに対応を分けます

robots.txt取得時の 200、404、403、429、5xx は同じ意味ではありません。正常な200ではbodyのruleを評価できますが、存在しない場合や一時的なserver errorではcrawler側の扱いが変わります。障害調査では、browserで表示できるかだけでなくstatus code、redirect chain、content-type、response bodyを保存します。

特に 5xx やtimeoutが断続的に出る場合、robots ruleを編集する前にoriginやCDNの可用性を直します。crawlerが古いcached robots.txtを使い続けているように見えても、実際には新しいfileを取得できていない可能性があります。429 もrate limit policyがcrawlerへ影響していないかを確認します。

Redirectとsoft errorも確認します

/robots.txt が別hostやlogin pageへredirectされていないか、200でHTML error pageを返していないかも見ます。production monitoringではstatusだけでなくbodyの先頭やhashを記録すると、CDN rollbackや誤ったroute ownershipを検出しやすくなります。checkerの結果とserver logを組み合わせ、rule解釈の問題と配信障害を分離します。

監視ではbodyも確認します

robots.txt monitoringを行う場合、status codeだけでは不十分です。200でもlogin pageやgeneric HTMLが返るsoft errorがあるため、content-type、先頭数行、body hashなどを記録します。これによりroute設定やCDN rollbackで内容が入れ替わったときも検知しやすくなります。

関連ガイド