サイトマップの「robots.txt にアクセスできません」はサーバー側の問題です

サイトマップを送ったら、ステータスが「取得できませんでした」になった。原因を調べようとURL検査でライブテストをしたら、[ページの取得]に「失敗しました: robots.txt にアクセスできません」と出ている。

robots.txtなんて置いた覚えが無い。あるいは置いてあるし、ブラウザで開けば普通に表示される。どちらにしても、話が噛み合いません。

結論を先に書きます。これはrobots.txtの中身についての指摘ではありません。robots.txtを取りに行ったのに、返事が返ってこなかったという意味です。「無い」ことは問題になりません。公式ドキュメントは404を正常なレスポンスの側に分類しています。

つまりrobots.txtを書き換えても消えません。直す対象はサーバーとDNSです。

先に安心材料を1つ。多くの場合、一時的なものです。公式が想定している時間の単位は12時間・24時間・30日です(あとで構造ごと書きます)。

この文言は、どこに出ている何なのか

「robots.txt にアクセスできません」は、URL検査ツールの[ページの取得]という欄に出る値の1つです。[ページの取得]はURL検査ツールの公式ヘルプいわく「Google がページをサーバーから実際に取得できたかどうかを示します」という欄で、主な値は「成功」「失敗」で、どちらにも当てはまらないときの「内部エラー」「なし」もあります。「失敗」のときに、その理由が並記されます。

そして重要なのは、この文言が置かれている場所です。公式ヘルプで「robots.txt にアクセスできません」が載っているのは「サイト全体の可用性に関する問題」という節です。

robots.txt にアクセスできません: robots.txt ファイルが存在してもアクセスできない場合、Google はウェブサイトをクロールしません。robots.txt がアクセス可能かどうかは、クロールの統計情報レポートで確認できます。
— Google公式ヘルプ(URL検査ツール)

同じ節に並んでいるのは、次のような項目です。「DNS サーバーが応答しません」「DNS エラー: 不明なホストです」「サーバー接続エラー」「サーバーが無効な応答を返しました」「サーバーの SSL 証明書が無効です」「ホスト負荷が制限を超えています」。全部、サイト全体が届かない系の問題です。robots.txtのエラーは、この仲間として扱われています。

ページ1枚の問題ではありません。だから、送信したサイトマップだけを疑っても原因に届きません。

なぜrobots.txtを置いていないのに、robots.txtのエラーが出るのか

Googleが問題にしているのは「ファイルがあるか」ではなく「リクエストに返事が返るか」だからです。クロールの統計情報レポートの公式ヘルプが、この区別をはっきり書いています。

サイトに robots.txt ファイルを含める必要はありませんが、このファイルを求められたら、正常なレスポンス（以下で定義）を返す必要があります。返さなければ、Google によるサイトのクロールが停止されることがあります。
— Google公式ヘルプ(クロールの統計情報レポート)

「含める必要はないが、求められたら返事はしろ」——これがこのエラーの全部です。同じページに、何が正常で何が不成功かの定義が載っています。

不成功に分類されているのは429と5xxだけです。そして404は正常な側に入っています。公式ヘルプはご丁寧に、404について「ファイルが存在しない」「サイトに robots.txt ファイルを含める必要はありません」と付記しています。

なお5xxは、robots.txtに限らずページそのものの取得でも起きます。その場合は「ページのインデックス登録」にサーバーエラー(5xx)として並びます。記事を直しても消えない種類の行で、確認する画面と直す場所は 「サーバーエラー(5xx)」はサーバーが応答を返せなかった記録、記事を直しても消えないに書きました。

だから「robots.txtを置いていないから怒られている」ではありません。置いていないサイトでも、この文言は出ます。

公式ヘルプ自身が、この取り違えを名指しで否定しています。クロールの統計情報レポートの「robots.txt なし」の項に「このレスポンスは、有効なレスポンスであると見なされる robots.txt ファイルの「見つかりませんでした（404）」とは異なります」とあります。404で返っている状態と、返事そのものが無い状態は、公式にとって別物です。

404でも200でもないなら、何が返っているのか

実際に多いのは、HTTPのステータスコードが返る手前で終わっているケースです。robots.txtの仕様書には、ステータスコードの表とは別に「その他のエラー」という項があります。

DNS またはネットワークの問題（タイムアウト、無効な応答、接続のリセットや遮断、HTTP チャンクのエラーなど）が原因で robots.txt ファイルを取得できない場合は、サーバーエラーとして扱われます。
— Google公式ドキュメント(robots.txtの書き方)

ここが、この記事でいちばん伝えたい構造です。DNSが引けない・接続がタイムアウトする・接続が切られる——これらはまとめてサーバーエラー扱いになり、結果として「robots.txt にアクセスできません」という顔をして出てきます。ドメインの設定を触った直後、サーバーを移した直後、WAFやセキュリティ系プラグインを入れた直後にこの文言が出るのは、これが理由です。

つまり、この文言はrobots.txtの名前を借りた「サーバーに届かなかった」の通知です。ファイルを開いて中身を直しても、何も変わりません。

「ブロックされている」と「アクセスできません」は別のエラー

この2つを混同すると、直らない作業を延々やることになります。並べて書きます。

公式ヘルプの中でも、この2つは別の欄に置かれています。[クロールを許可？]は、URL検査ツールの公式ヘルプの説明ではページへのクロールをGoogleに許可するか、robots.txtルールを使ってブロックするかを示す欄で、robots.txtが読めていることが前提です。今回の文言はそちらではなく、[ページの取得]の側に出ています。

robots.txtを置くべきか、置くなら何と書くかはサイトマップは必要か・robots.txtの書き方、個人ブログはほぼ不要に書きました。この記事では中身の書き方には踏み込みません。

サイトマップ送信でこの文言に行き着く理由

公式のデバッグ手順が、サイトマップからURL検査へ誘導しているからです。サイトマップレポートの公式ヘルプは、ステータスが「取得できませんでした」のときの調べ方をこう案内しています。

サイトマップ レポートの詳細ページからサイトマップの URL をコピーします。コピーした URL を URL 検査ツールに貼り付け、Enter キーを押します。URL 検査ツールで [ライブテスト] をクリックします。[ページの可用性] セクションを開いて、Google がサイトマップを取得できない理由を確認します。…基本的には、[クロールを許可？] が [はい]、[ページの取得] が [成功] となっているかを確認します。
— Google公式ヘルプ(サイトマップレポート)

この手順どおりに進むと、[ページの取得]の欄に到達します。そこで出るのが今回の文言です。サイトマップのエラー名ではなく、その先の診断結果です。

ひとつ補足しておきます。サイトマップレポートのヘルプに載っている取得エラーの原因一覧を最後まで読みましたが、そこに「robots.txt にアクセスできません」という項目名はありません。robots.txtの名前が出てくる項目は「サイトマップが robots.txt ファイルによってブロックされている」だけで、今回の状況に当たるのは「その他の一般的なエラー」のほうです。その説明は「その他のエラー（サーバーを利用できないなど）により、サイトからサイトマップを取得できないことがあります。これらのエラーのいくつかは一時的なものである可能性があります」です。今回の文言は、この「その他の一般的なエラー」の中身をURL検査が言い換えたものと読むのが素直です。

※ ここで「無い」と書いているのはサイトマップレポートのヘルプ(support.google.com/webmasters/answer/7451001)のエラー一覧に限った話です。文言そのものはURL検査ツールのヘルプ(answer/9012289)に載っています。

だから、サイトマップのXMLを作り直しても直りません。サイトマップは、たまたま最初にエラーが見えた場所です。

直す順番

原因がサーバー側にあると分かったので、確認は外側から内側へ進めます。順番を守ると、直っているのに気づかないという事故を避けられます。

① ブラウザでrobots.txtのURLを開く(1分)

まず自分でhttps://（あなたのドメイン）/robots.txtを開きます。URL検査ツールのヘルプも、robots.txtのルールを調べる前提として「robots.txt ファイルをブラウザで開けることが必要です」と書いています。

ここで表示された(200)か、404が出たなら、その瞬間のサーバーは正常です。404も公式の分類では正常なレスポンスなので、慌てて空のファイルを置く必要はありません。表示されるのに文言が出ている場合は、②へ進んでください。一時的だった可能性が高いです。

開けない・延々と待たされる・500系が出るなら、そこが原因です。サーバーの管理画面かレンタルサーバー会社の障害情報を先に見てください。

② クロールの統計情報レポートで、いつ・何が失敗したかを見る

公式が名指しで案内している確認場所がここです。「robots.txt がアクセス可能かどうかは、クロールの統計情報レポートで確認できます」と書かれています。設定 > クロールの統計情報から開き、ホストのステータスを見ます。評価は3カテゴリに分かれています。

グラフには赤い点線が引かれています。公式の説明では、指標がこの線より上にあるとそのカテゴリの問題と見なされ、例として「DNS の解決で特定の日に失敗したリクエストが 5% を超える場合」が挙げられています。失敗が0件であることを目指す作り方ではありません。

ここで見たいのは、日付です。失敗が特定の1日に集中しているのか、線が高いまま続いているのか。前者なら一時的な障害、後者なら設定の問題という切り分けになります。

DNSが赤い場合、公式は「レジストラをチェックして、サイトが正しく設定されているかどうか、また、サーバーがインターネットに接続されているかどうかを確認してください」と案内しています。サーチコンソール側では直せません。

③ 心当たりを、変更した日から逆算する

②で失敗した日が分かったら、その日に何をしたかを思い出します。個人ブログで起きやすいのは、次のような場面です。

• ドメインやネームサーバーを移した … DNSの反映待ちが、そのままこの文言になります
• サーバーを移転した・プランを変えた … 旧サーバーを向いている間、接続が失敗します
• セキュリティ系のプラグインやWAFを入れた・設定を強くした … Googlebotのアクセスが遮断されると、公式のいう「接続のリセットや遮断」に当たります
• アクセスが急増した・共有サーバーが重い … 5xxや429が返り、robots.txtも巻き添えになります
• SSL証明書が切れた … 同じ節に「サーバーの SSL 証明書が無効です」が別項目としてありますが、更新忘れは同時に起きがちなので一緒に見てください

robots.txtの中身を書き換えた、は原因の候補に入りません。ルールの問題なら、別の文言で出ます。

④ 直したら、サイトマップを再送信する

サーバー側が直ったら、サイトマップレポートから再送信します。公式ヘルプは「問題を解決してから、サイトマップをレポートに再送信してください」と書き、あわせて「サイトマップを取得できない場合、Google は数回再試行しますが、それでも取得できないと最終的にそのサイトマップの読み取りを停止します」とも書いています。放置したまま待つ形にはなっていません。

すぐ消えないのは、失敗ではない

直した直後に表示が変わらないのは、Google側の待ち方がそういう作りだからです。クロールの統計情報レポートのヘルプに、時間の構造がそのまま書かれています。

ここが、この文言に慌てなくていい理由と、放置してはいけない理由の両方です。サーバーが復帰していれば、12時間から30日の間はGoogleが最後に成功したrobots.txtで動き続けます。一方、30日を超えてもサイトに到達できないままだと、クロールそのものが止まります。

キャッシュの扱いは、同じヘルプではなく仕様書のほうに書かれています。robots.txtの仕様書は「Google は、通常 robots.txt ファイルの内容を最大 24 時間キャッシュに保存します」としたうえで、「（たとえば、タイムアウトや 5xx エラーが原因で）その内容を更新できないと、さらに長く保存する場合があります」と続けます。直してから表示が変わるまで、丸1日かかることは普通にあります。

ちなみに503については、仕様書に「503 (service unavailable) エラーの場合、再試行が頻繁に行われます」とあります。メンテナンス中に503を返す設定は、この文言が出ても想定内です。

この文言が出ているとき、順位はどうなるのか

公式が書いているのは「クロールが停止される・遅くなることがある」までで、順位についての記述はありません。クロールの統計情報レポートのヘルプの表現は「有効な robots.txt レスポンスが取得できるまで、Google によるサイトのクロールが遅くなるか停止されます」です。すでにインデックスされているページが消えるとは書かれていません。

なので、慌てて記事を書き直したり、URLを変えたりしないでください。止まっているのは新しい情報の取り込みであって、既存の掲載ではありません。先にサーバーを直すのが、順序として正しいです。

インデックスされない原因を系統立てて潰したい場合はインデックスされない原因は2系統に分かれる、確認できるものから潰すを、URL検査の各表示が何を意味するのかはサーチコンソールでインデックスを確認する方法、URL検査の表示ごとに次の一手が違うにまとめています。

よくある質問

「robots.txt にアクセスできません」とはどういう意味ですか

robots.txtを取りに行ったのに、正常なレスポンスが返ってこなかったという意味です。URL検査ツールの公式ヘルプは「robots.txt ファイルが存在してもアクセスできない場合、Google はウェブサイトをクロールしません」と説明し、この文言を「サイト全体の可用性に関する問題」の節に置いています。ファイルの中身についての指摘ではありません。

robots.txtを置いていないのに、このエラーが出ます

robots.txtが無いことは、このエラーの原因になりません。クロールの統計情報レポートの公式ヘルプは「HTTP 403 / 404 / 410（ファイルが存在しない）」を「正常な robots.txt レスポンス」に分類しています。不成功に分類されているのは「HTTP 429 / 5XX」だけです。加えて仕様書は「DNS またはネットワークの問題…が原因で robots.txt ファイルを取得できない場合は、サーバーエラーとして扱われます」としています。疑うのはサーバーとDNSです。

robots.txtを空にすれば直りますか

直りません。公式の分類では200で空のファイルも、404も、どちらも正常なレスポンスです。問題はファイルの中身ではなく、返事が返ってこないことなので、置き換えても状態は変わりません。先にクロールの統計情報レポートのホストのステータスで、robots.txtの取得・DNSの解決・サーバー接続のどれが失敗しているかを見てください。

「robots.txt によってブロックされています」と同じですか

別のエラーです。「ブロックされている」はrobots.txtが読めていて、その中のルールが止めている状態で、直す場所はファイルの中身です。「アクセスできません」はrobots.txtそのものに到達できていない状態で、直す場所はサーバーです。公式ヘルプでも、前者は[クロールを許可？]、後者は[ページの取得]と、別の欄に出ます。

直したのに、まだ同じ表示のままです

すぐには変わりません。仕様書は「通常 robots.txt ファイルの内容を最大 24 時間キャッシュに保存します」とし、更新できない場合は「さらに長く保存する場合があります」と書いています。サーバー側が直っていることをブラウザで確認したら、サイトマップを再送信して待ってください。ライブテストは今の状態を見に行くので、そちらが成功に変われば復旧しています。

放っておいたらどうなりますか

30日が区切りです。公式ヘルプによれば、不成功が続くとGoogleは最初の12時間クロールを停止し、その後30日までは最後に成功したrobots.txtを使い続けます。30日後は、ホームページにアクセスできれば「robots.txt ファイルがないものとして制約なくクロール」、アクセスできなければ「サイトのクロールを停止します」と書かれています。サーバーが復帰していれば、自然に戻ります。

まとめ

• 「失敗しました: robots.txt にアクセスできません」は、robots.txtの中身への指摘ではなく、robots.txtへの返事が返ってこなかったという通知。URL検査の[ページの取得]欄に出る、サイト全体の可用性に関する問題
• 公式の分類では200・403・404・410は「正常なレスポンス」、不成功は429と5xxだけ。robots.txtが無いことは原因にならない
• 仕様書はDNS・タイムアウト・接続の遮断も「サーバーエラーとして扱われます」としている。DNSの問題がこの文言に化ける
• 「robots.txtによってブロックされている」とは別のエラー。あちらはファイルを直す、こちらはサーバーを直す
• 直す順番は①ブラウザでrobots.txtを開く ②クロールの統計情報レポートのホストのステータス(robots.txtの取得・DNSの解決・サーバー接続)を見る ③失敗した日から心当たりを逆算 ④直してから再送信
• すぐ消えないのは失敗ではない。robots.txtのキャッシュは最大24時間、クロール停止は最初の12時間、最後に成功したファイルを使うのが30日まで
• 順位が下がるとは公式に書かれていない。止まっているのは新しい情報の取り込みなので、記事を触る前にサーバーを直す

ここから先は、私が作ったツールの話です。

この文言はサーバーが直れば消える種類の問題で、直したあとに残るのはすでに検索結果に出ているページをどうするかのほうです。リライトレーダーは、そちら側だけを扱います。Search Console のエクスポートをZIPのまま落として貼るだけで、掲載順位4.0〜20.5位・表示回数100回以上のページを拾い、改善余地スコアの大きい順に並べます。判定と候補3記事の改善余地スコアの確認、そのうち1記事分の診断カードまでは無料で、残りの診断カードが2,980円(税込)の買い切りです。月額課金や自動更新はありません。ログインも不要です。CSVファイルそのものはブラウザの外に出ません(送るのは、診断カードを出すときは選んだ1ページのURL・数値・入力したキーワード、「ページタイトルを取得する」を押したときは判定に出たページのURL最大10件です)。

⚠️ ただし、向かない人がいます。クロールやサーバーの問題を片付けたい人には向きません。robots.txtもDNSもクロールの統計情報も扱っていません。読むのは、すでに検索結果に出ているページの4つの数字だけです。また、表示回数が2桁で止まっているサイトにも向きません。判定の条件が表示回数100回以上なので、対象になるページが1つも出ないからです。