robots.txtの戻し忘れを検知する方法｜「Disallow: /」が本番に残る事故を監視で防ぐ

「Disallow: /」が本番に残ると何が起きるか

ステージング環境では検索エンジンに拾われないよう、robots.txt に User-agent: * と Disallow: / を書くのが定石です。問題は、その robots.txt をそのまま本番に持ち込んだときに起きます。

サイトは正常に表示され、HTTP監視は200を返し続けます。顧客も制作会社も何も気づきません。しかし Googlebot は robots.txt の指示に従ってクロールをやめ、数日から数週間かけてインデックスが消えていきます。発覚するのは「検索しても出てこない」と顧客が気づいたときで、その頃には順位の回復に公開前より長い時間がかかります。

この事故が厄介なのは、死活監視の観点では何も壊れていないことです。robots.txt は静的なテキストファイルで、200 OK で配信され、サイト本体も正常です。検知するには「robots.txt の内容が意図どおりか」を見る監視が別に必要になります。

robots.txt 監視が確認する3つのこと

Miterl の robots.txt 監視（type: robots_txt）は、監視対象URLのオリジン直下にある /robots.txt を定期的に取得し、以下を確認します。

ポイントは2つあります。

• URL はオリジンに正規化される — 監視対象に https://example.com/about/ を指定しても、取得先は https://example.com/robots.txt です。robots.txt はオリジン直下でしか効力を持たないため、パスやクエリは捨てられます
• グループの解釈は RFC 9309 に従う — 複数の User-agent: 行が連続する場合は1つのグループとして扱い、最初のルール行でグループが閉じます。Sitemap: はグループに属さない指示なので、どこに書かれていても拾います

なお、この監視が見るのは User-agent: * に対するルールです。「Googlebot だけを Disallow している」といった特定クローラー向けの設定は判定対象に含みません。特定クローラーの扱いも含めて公開前に一括で確認したい場合は、後述の公開前監査を使います。

Sitemap チェックを有効にする理由

Disallow: / の検知に比べると地味ですが、Sitemap: の記述漏れも制作現場では頻繁に起きます。CMSを入れ替えた、robots.txt を手で書き直した、といった作業で Sitemap: の行が消えると、検索エンジンにサイトマップの場所を伝える経路が1つ減ります。新規公開したページのクロールが遅れる原因になるので、robots_check_sitemap は有効にしておくことをおすすめします。

手元で確認する方法

監視を設定する前に、いま公開されているサイトの状態を手元で確認しておきます。

# robots.txt の取得とステータス確認
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/robots.txt

# 全面ブロックの有無（User-agent: * の直後に Disallow: / があるか）
curl -s https://example.com/robots.txt | grep -A3 -i '^User-agent: \*'

# Sitemap の記述
curl -s https://example.com/robots.txt | grep -i '^Sitemap:'

ステージングから持ち込まれた典型的な robots.txt は次のような内容です。この状態で公開されると、上の2つ目のコマンドで Disallow: / が表示されます。

User-agent: *
Disallow: /

本番で期待する形はこうです。

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/sitemap.xml

APIで監視を作成する

robots.txt 監視は他の監視タイプと同じ Monitor リソースで作成します。追加のプラン制限はなく、type に robots_txt を指定するだけです。

# robots.txt 監視（type: robots_txt）— 全面ブロックと Sitemap 記述を 10 分おきに確認
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example.com robots.txt",
    "type": "robots_txt",
    "url": "https://example.com/",
    "interval_seconds": 600,
    "robots_check_disallow_all": true,
    "robots_check_sitemap": true
  }'

制作会社が管理する全サイトに同じ監視を配る場合は、サイト一覧をループで回します。robots.txt は変更頻度が低いので、間隔は10分程度で十分です。

# sites.txt: 1行1URL
while read -r url; do
  host=$(echo "$url" | sed -E 's#https?://([^/]+).*#\1#')
  curl -s -X POST https://miterl.com/api/v1/monitors \
    -H "Authorization: Bearer $MITERL_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"name\":\"$host robots.txt\",\"type\":\"robots_txt\",\"url\":\"$url\",\"interval_seconds\":600,\"robots_check_disallow_all\":true,\"robots_check_sitemap\":true}"
done < sites.txt

公開前監査と継続監視を組み合わせる

robots.txt の事故は「公開の瞬間」に起きるものと、「公開後の作業」で起きるものの2種類があります。それぞれに対応する仕組みを分けておくと取りこぼしがなくなります。

公開前監査は API から呼べるため、デプロイパイプラインの最終ステップに組み込めば「robots.txt がブロックしたまま公開する」経路そのものを塞げます。組み込み方は「公開前テスト自動化ガイド」で、公開前に確認すべき項目の全体は「Webサイト公開前の監視設定チェックリスト」でまとめています。

継続監視の側では、robots.txt 監視と同じく「落ちていないのに壊れている」を捕まえる仲間として、noindex メタタグの混入を見る DOM改ざん検知があります。「WordPress改ざん検知を自動化する方法」で解説しているとおり、robots.txt と noindex の両方を見張ると、検索結果から消える経路をほぼ塞げます。

検知したときの対応

robots.txt 監視が Down になったときの対応は単純ですが、順序を決めておくと復旧が早まります。

1. robots.txt を正しい内容に戻す — Git 管理しているなら本番用ファイルを再デプロイ、手作業なら上の「本番で期待する形」に書き換えます
2. Search Console で再クロールを促す — Search Console の robots.txt レポートで修正後の内容が取得されたことを確認し、主要ページの URL 検査からインデックス登録をリクエストします
3. どれくらいの期間ブロックされていたかを記録する — 監視の検知時刻と復旧時刻から期間を出し、顧客への報告に含めます。報告書の書き方は「障害報告書テンプレート」を参照してください

ブロックされていた期間が短ければ（数時間〜1日）、インデックスへの影響はほぼありません。robots.txt 監視を10分間隔で入れておく最大の価値は、この「短ければ影響がない」の範囲に収めることです。

まとめ

• ステージングの Disallow: / を本番に持ち込む事故は、HTTP監視では検知できない（200 を返し続ける）
• robots.txt 監視は、ファイルの存在・User-agent: * への全面ブロック・Sitemap: の記述の3点を確認する
• 監視対象 URL はオリジンに正規化され、グループの解釈は RFC 9309 に従う
• 公開の瞬間は公開前監査、公開後は robots.txt 監視、と役割を分けて取りこぼしを無くす
• 検知後は「戻す → 再クロール → 期間を記録」の順で対応する

監視タイプの詳細はドキュメントを参照してください。robots.txt 監視は無料プランで登録してすぐに使えるので、管理しているサイトのうち公開直後のものから設定することをおすすめします。