robots.txtがエラーを返し続けると、最後は「制限なし」に行き着く ── HTTPステータス別の扱いを確認する13項目（2026年9月時点）

01 何が起きたか — robots.txtというファイル自体が、エラーを返すことがある

「ページの404」と「robots.txtファイルの404」は、まったく別の話

「robots.txtを確認する」と言うとき、多くの現場では中に書かれたDisallowやAllowの行が正しいかどうかを見ている。ここで扱うのはそれとは別の話だ。robots.txtという1つのファイルそのものが、リクエストに対してどんなHTTPステータスコードを返しているかという話である。サーバーの一時的な不調・証明書の期限切れ・CDNの設定変更など、記事の内容とは無関係な理由で、robots.txtというファイル自体が403・404・500・503を返したり、応答せずタイムアウトしたりすることがある。このとき検索エンジン側で何が起きるのかを、公式ドキュメントの記載に沿って確認する。

結論：4xxは「制限なし」、5xxは「様子見のあと同じ結論」

Googleの公式ドキュメント「How Google Interprets the robots.txt Specification」は、この挙動を明確に定義している。まず押さえておきたいのは4xxエラー（429を除く）の扱いだ。

"Google's crawlers treat all 4xx errors, except 429, as if a valid robots.txt file didn't exist."

（訳: Googleのクローラーは、429を除くすべての4xxエラーを、有効なrobots.txtファイルが存在しないものとして扱う。）

これは直感に反しやすい。「robots.txtが404を返している＝何かの拒否設定が働いている」と考えたくなるが、公式の結論は逆だ。robots.txtが403や404を返すと、Googleは「クロール制限は一切ない」とみなす。ファイルが見つからないという事実が、そのまま「全部読んでよい」という判断に変換される。02章で見る5xxエラーも、最終的にはこの「制限なし」と同じ結論に行き着く経路を持っている。

02 なぜ・背景 — 「止めて、様子を見て、それでも直らなければ」という設計

5xxは3段階に分かれている

サーバーエラー（5xx）の扱いは、4xxのような単純な二択ではない。公式ドキュメントは3段階の時間軸を示している。最初の12時間は、クロールを停止しながらrobots.txtの再取得を試み続ける。それでも新しい版が取得できない場合、続く30日間は最後に取得できた正常な版をキャッシュとして使用しながら、並行して再取得を試みる。そして30日を過ぎても直っていない場合、サイト全体がGoogleから到達可能であれば、robots.txtが存在しないのと同じ「制限なし」の扱いに切り替わる。逆にサイト自体が到達不能な状態であれば、クロール停止は継続される。5xxが長期化した末に行き着く先も、4xxと同じ「制限なし」になることがある、という設計になっている。

DNSエラー・タイムアウト・接続リセットも、5xxと同じ列に並ぶ

この段階的な扱いが適用されるのは、サーバーが明示的に5xxを返した場合だけではない。公式ドキュメントは、DNSの解決に失敗した場合やネットワークのタイムアウト、無効な応答、接続のリセットや中断、HTTPチャンク転送のエラーについても、まとめて「サーバーエラーとして扱う」と明記している。robots.txtへ到達できない原因がサーバー側のプログラムなのか、ネットワークやDNSなのかを、Googleは区別していない。到達できなかったという事実だけが判断材料になる。

キャッシュは「直したのに反映されない時間」を生む

Googleは通常、robots.txtの内容を最大24時間キャッシュする。Cache-Controlヘッダーのmax-ageを指定していれば、キャッシュ期間はそれに応じて延びたり縮んだりする。ここで見落とされやすいのは、一度5xxやタイムアウトの状態に入ってしまうと、24時間という通常のキャッシュ期間の話ではなくなるという点だ。02章の3段階が示すとおり、障害が起きている間は「最後に成功した正常な版」が最大30日間そのまま使われ続ける。目の前の障害を直しても、Googleが次にそのファイルを取りに来るタイミングまでは、古い判断が生き続けることになる。

03 この記事で出てくる用語

「クライアントエラー」なのに「サーバー側の設定不備」が原因になることが多い

robots.txtが404を返す原因の多くは、実際にはクライアント（訪問者）側の問題ではなく、サーバーやCDN側の設定に起因する。ドメイン移転時のパス設定漏れ、CDNのキャッシュルール、WAF（Webアプリケーションファイアウォール）の誤検知など、原因は運営側にあるのに、HTTPの分類上は「クライアントエラー」という名前がついている。この名前の付き方が、原因を人為的な設定ミスだと結びつけにくくしている面がある。

「429」はHTTPの分類上は4xxだが、Googleは明確に「サーバーエラー」と呼んでいる

HTTPの規格上429は4xx（クライアントエラー）に分類されるコードだが、robots.txt仕様のページは429だけを4xxの一般則（制限なし扱い）から明示的に除外している。この除外の理由は、別の公式ドキュメント「HTTP status codes and network errors」を見るとはっきりする。そちらのページは429を5xxのセクションで扱い、「5xxおよび429のサーバーエラーは、Googleのクローラーに一時的なクロール速度の低下を促す」と明記している。robots.txt仕様のページ単体では「4xxの例外」としか書かれていないが、Googleのクロール基盤全体としては、429は最初から5xxと同じ列に置かれている。

ステータスコードが200でも、中身が壊れていることがある

もう1つ見落とされがちな分類がある。robots.txtへのリクエストに対してHTTPステータス自体は200が返っていても、返ってきた中身がrobots.txtの構文ではなくHTMLだったというケースだ。認証エラーのページやメンテナンス通知のページが、200のステータスのまま返される設定になっているサイトでは、これが起こりうる。公式ドキュメントはこの場合について、「解析できる部分があればルールとして抽出し、それ以外は無視する」という趣旨の扱いを示している。ステータスコードだけを見て安心してはいけない理由が、ここにもある。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どんな場面でこの記事が関係してくるか

この記事の内容が直接関係してくるのは、サーバー移行やCDN切り替えの作業中のサイト・SSL証明書の更新作業を控えているサイト・メンテナンスでサイト全体を一時的に停止する予定があるサイト・共有ホスティングで他サイトの負荷の影響を受けやすいサイトである。逆に、専用のインフラで安定稼働しており、直近でインフラ側の変更予定が無いサイトでは、07章のチェックを一度通しておけば当面は優先度が低い。

🅱 この記事が測っていないこと・分からないこと

公式ドキュメントを確認しても、明確にされていない点がいくつかある。第一に、429が「サーバーエラー」に分類されクロール速度が下がることは別ページで確認できるが、robots.txt仕様のページの5xxセクションに429が直接列挙されているわけではないため、5xxとまったく同じ12時間・30日のスケジュールが429にも数字どおり適用されると断定できる一文までは見当たらない。第二に、「30日」のカウントがいつから始まるのか（最初の障害発生時からか、直近の成功取得からか）の厳密な起点も、このページには書かれていない。第三に、この記事はGoogleの挙動のみを扱っており、Bing・Yahoo!など他の検索エンジンが同じ猶予期間を採用しているかどうかは確認していない。第四に、実際にどのくらいの頻度でこうした障害が発生しているかという統計値も公開されていない。分からないことを、分かるふりで埋めていない。

🅲 手順 — 自分のサイトで確認する3段階

実際の確認は、次の3段階で進める。まずrobots.txtというファイル自体が今どんなステータスコードを返しているかを数字で確認し、次にSearch Console側の記録と突き合わせ、原因が見つかったら直して再クロールを依頼する。感覚で「たぶん大丈夫」と判断せず、まず数字を出すところから始める。

05 明日、自分のサイトで確認できることチェックリスト

以下は、今日からブラウザとSearch Consoleだけで確認できる項目である。チェックの状態はブラウザに保存され、サーバーには送信されない。

• 自社のrobots.txtをブラウザで開き、返ってきたHTTPステータスコードを確認する
• ステータスコードが200以外だった場合、4xx（429を除く）か5xxかを区別する
• 403や404が返っている場合、それが意図した設定によるものか確認する
• Search Consoleの「robots.txt」レポートを開き、直近の取得ステータスと取得日時を確認する
• robots.txtレポートに表示されているエラーと警告の件数を、それぞれ数える
• robots.txtのレスポンスヘッダーで、Cache-ControlのMax-Age値が指定されているか確認する
• サーバー証明書の有効期限が、直近30日以内に切れる予定が無いか確認する
• 直近30日間に、サーバー移行やメンテナンスでサイト全体が一時的に停止した日が無いか確認する
• robots.txtがリダイレクトされている場合、リダイレクトの回数を数える
• robots.txtへのリダイレクトが、JavaScriptやmeta refreshによるものになっていないか確認する
• robots.txtの中身を開き、HTMLのエラーページに差し替わっていないか目視で確認する
• robots.txtを修正した後、Search ConsoleのURL検査ツールで再クロールをリクエストする
• Search Consoleの「クロールの統計情報」レポートを開き、直近のクロールリクエスト数に落ち込みが無いか確認する

すべてに目を通す時間の目安は1サイトあたり45分程度である。サーバー証明書の有効期限は、契約しているホスティング会社の管理画面から確認できることが多い。原因の切り分けに時間がかかりそうな場合は、直近の変更履歴（デプロイ・証明書更新・CDN設定変更）を先に洗い出しておくと早い。

06 代替・他の選択肢（表で）

サイト全体のクロールを止めたいなら、エラーコードに頼らない

「robots.txtを404にすれば全部止まるはずだ」という誤解は根強いが、01章で見たとおり結果は正反対になる。サイト全体のクロールを意図的に制御したいなら、robots.txtを200で正しく応答させ、その中に明示的なルールを書くのが唯一の確実な方法だ。ページ単位でインデックス登録だけを制御したい場合は、<span class="wd-nowrap">robots meta</span>タグやX-Robots-Tagヘッダーという、robots.txtとは別の仕組みが用意されている。目的に応じてどれを使うべきかを、以下にまとめた。

「一時的な緊急停止」という用途は、公式にも案内がある。ただし数日が限度

サーバー負荷が急上昇した際の応急処置として、Googleは公式ドキュメントの中で、クロールリクエストに対して一時的に500・503・429のいずれかを返す方法を案内している。ただしこの方法は数時間から1〜2日程度の短期間に限って使うべきだとされ、それより長く続けるとGoogle製品における表示に悪影響が出る可能性があると明記されている。さらに複数日にわたって同じURLでこれらのコードを返し続けると、そのURLがインデックスから削除される可能性があるとも述べられている。robots.txt自体の5xxが最終的に「制限なし」へ向かうのに対し、こちらは通常のページに対する応急処置であり、対象も結末も別の話だという点を混同しないようにしたい。

リダイレクトを使う場合は、5回とロジックの制約がある

robots.txtのURLを別の場所へ移したい場合、通常のHTTPリダイレクトは利用できる。ただし公式ドキュメントは「Googleは少なくとも5回のリダイレクトを追跡し、それ以降は停止してrobots.txtの404として扱う」としており、リダイレクトチェーンが長いサイトほど不利になる。加えて、フレームやJavaScript、meta refreshによる「論理的なリダイレクト」はここでの追跡の対象に含まれない、という点も見落とされやすい。

07 自社サイトで確認したこと — robots.txtは200・370バイトだった

自社のrobots.txtは200を返し、Cache-Controlは明示していなかった

当サイトのrobots.txtに対して、レスポンスヘッダーを実際に確認したところ、ステータスコードは200、ファイルサイズは370バイトだった。Cache-Controlヘッダーは付与されておらず、max-ageの指定も無い状態である。02章で確認したとおり、max-ageを指定していない場合、Googleは通常の最大24時間キャッシュのルールに従う。これは今すぐ対処が必要な不備というより、キャッシュ期間の制御をGoogle側の既定値に委ねている状態として、そのまま記録しておく。

Last-Modifiedは7月8日だった — 直近で更新した記憶と一致している

レスポンスヘッダーのLast-Modifiedは2026年7月8日を示していた。この日付は、サイトマップの記載を見直した際の更新作業と一致している（archives/39）。robots.txt自体が壊れていないかを確認する作業は、こうした関連ファイルを触ったタイミングでまとめて行うと、抜け漏れが少ない。

08 このテーマの、これまで

1994年、1人の提案として始まった

robots.txtの仕組みは、1994年にMartijn Kosterが提案した非公式な取り決めとして始まった。以来25年間、多くのサイトとクローラーがこの取り決めに従ってきたが、正式なインターネット標準になったことは一度もなかった。公式な標準が無いということは、エラー時の挙動やキャッシュの扱いといった細部を、各クローラーの実装がそれぞれ独自に解釈してよいという状態が長く続いていたことを意味する。

2019年、Googleが標準化を提案し、パーサーを公開した

2019年7月1日、Googleは自社が使っているrobots.txtの解析処理をオープンソースとして公開すると同時に、プロトコルの原著者や他の検索エンジン、サイト運営者とともに、現代のWeb上での実際の使われ方を文書化してIETF（インターネット技術タスクフォース）へ提案したことを発表した（Google公式ブログ）。25年間、慣習として機能していた仕組みを、初めて正式な標準化のプロセスに乗せた節目である。

2022年9月、RFC 9309として標準になった — エラー処理が初めて明文化された

この提案は2022年9月、RFC 9309「Robots Exclusion Protocol」としてProposed Standard（標準化過程文書）になった。著者にはGoogleの技術者3名が名を連ねている。4xx・5xx・DNSエラーの扱いやキャッシュの仕組みが公式な仕様として明文化されたのは、この標準化が初めてである。01章から06章で見てきた挙動の多くは、この標準化を土台にした公式ドキュメントの記述に基づいている。

2026年、ドキュメントの置き場所が変わった — 中身は今も更新され続けている

本記事執筆時点で確認すると、この仕様を解説する公式ページのURLは、以前の「search/docs/crawling-indexing」という体系から「crawling/docs/robots-txt」という新しい体系へ301リダイレクトで移動しており、最終更新日は2026年8月31日を示していた。数字の基準（12時間・30日・5回のリダイレクト）は長く安定している一方で、ドキュメントの置き場所や解説の細部は今も動いている。当サイトが52日間ログを開かずに「測定中」と書き続けていた記事（archives/135）と同じく、宣言したまま確認を止めないことが、この種のドキュメントとの付き合い方では欠かせない。