/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テキストか
トラブルシューティングの順序
- 本番ホストの
/robots.txtを外部から取得 - 最終URLとHTTPステータスを記録
- リダイレクト、CDN、WAFを確認
- UTF-8のテキストか確認
- 構文を検証
- 代表URLを対象クローラーでテスト
- サーバーログで取得失敗を確認
- 古いrobots.txtのキャッシュを考慮
- 修正後も継続監視
robots.txtの正しさにはHTTP配信も含まれます。 同じ本文でも200、403、404、5xxではクロールへの影響がまったく違うため、ルールだけでなくライブ応答を必ず確認してください。