ホーム › 記事 › クロールが12日間止まり、再発防止を作った8日後に、デプロイが「完了」と出たまま動いていなかった

クロールが12日間止まり、再発防止を作った8日後に、デプロイが「完了」と出たまま動いていなかった

著者：SecBilly　公開 2026-09-29

このサイトで起きた2件の故障の記録です。どちらも画面には成功と出ていました。

1件目はGoogleのクロールが12日間止まっていたこと。2件目は、その再発防止を作った8日後に、デプロイスクリプトが「✓ デプロイと確認まで完了」と表示しながら1件もデプロイしていなかったことです。

この記事の要点

• Googleがこのサイトを 12日間クロールしなかった
• 原因は robots.txt が HTTP 200 を返しながら中身が認証ページだったこと
• 同じ200を、自分は「漏えい」、Googleは「ブロック」と誤読
• 再発防止を作った8日後、デプロイが0件のまま「完了」と表示された
• 2件に共通していたのは、失敗が成功の顔をして出てくること

使った記録

自分のサイトのログと管理画面の実測値だけです。

• Search Console の URL 検査（2026-09-21 実施）
• Vercel の CLI 出力（vercel deploy --prod、2026-09-29 実行）
• scripts/deploy.sh と ga4/fetch.py のソース
• 参照日：2026年9月29日

推測の部分には「分からない」と書きます。

1件目：12日間クロールされなかった

GA4のセッションが1しかない原因を追ったときに見つけました。記事の質でも本数でもありませんでした。

Search Console の URL 検査の結果はこうです。

Googleはこのサイトの本文を一度も読めていませんでした。URLだけ知っている状態です。

原因は200を返す認証ページだった

2026-09-09 に Googlebot が来たとき、Vercel のデプロイが保護された状態でした。/robots.txt は HTTP 200 を返しましたが、中身は Vercel の認証ページのHTMLでした。

Googleは robots.txt を読めない場合、サイト全体を不許可として扱います。そのため以後12日間まったくクロールされませんでした。

同じ200を、2者が逆に誤読した

この事故の少し前、自分は別件で「公開してはいけないファイルが本番に出ていないか」を調べていました。20件のURLに curl を投げ、ステータスコードだけを見て「全部漏れている」と判断しました。実際の200は同じ認証ページで、中身は漏れていませんでした。

• 自分：200を見て「漏えいしている」と読んだ
• Google：200を見て「ブロックされている」と読んだ

どちらもステータスコードだけを見ていました。200は「取得できた」としか言っていません。

直した結果

サイト側が正常であることを Googlebot の User-Agent で実測し、Search Console でインデックス登録をリクエストしました。

デプロイを直した時点では回復していません。Googleが次に来るまで、壊れていた期間の影響は残りました。

再発防止として作ったもの

同じ日に2つ作りました。

角度を2つに分けたのが要点でした。サイトを直しても、Googleが来るまでは直っていません。

2件目：デプロイが0件のまま「完了」と出た

8日後の 2026-09-29、トップページの表記を直して deploy.sh を走らせました。画面にはこう出ました。

✓ 公開ゲート通過
✓ 正常
✓ デプロイと確認まで完了

本番は変わっていませんでした。ローカルのファイルは直っていて、公開されているHTMLだけが古いままでした。

原因は2つ重なっていた

1つ目。NODE_OPTIONS が実体の消えたファイルを読み込み先に指していて、node 自体が起動に失敗していました。vercel は node で動くので、コマンドは何もせずに終わります。

2つ目。スクリプトの書き方がこうでした。

vercel deploy --prod 2>&1 | tail -20

パイプでつなぐと、終了コードは最後のコマンド（tail）のものになります。vercel が落ちても、シェルから見た結果は成功です。

後段のチェックも通ってしまった

deploy.sh はデプロイのあとに健全性チェックを走らせます。これも通りました。古い版のサイトが正常に動いていたからです。

前段が何もしなくても、対象が以前から正常なら後段は通ります。「後段が通った」は「前段が走った」の証拠になりません。

裏の取り方

vercel deploy --prod を単体で走らせたら、node の起動失敗がそのまま出ました。デプロイのURLは1つも返りませんでした。原因を直してから同じスクリプトを走らせると、今度はURLが返り、3秒でデプロイが1件できました。本番の表記もそこで変わりました。

何回「完了」と出していたかは分かりません。スクリプトがその記録を残していなかったためです。

2件に共通していたこと

どちらも、成功を報告する仕組みが失敗を隠していました。そしてどちらも、作ってあった監視では捕まりませんでした。

仕事で統制の有効性を確かめるときも同じ問いを使います。「動いていますか」ではなく「動かなかったとき、それが分かりますか」です。この2件は、自分のサイトでその問いに答えられていなかった記録です。

直したこと

deploy.sh を2か所変えました。

1. パイプをやめて変数で受け、終了コードを捨てないようにした

2. 出力にデプロイURLが含まれることを検査し、無ければ落とすようにした

2つ目が効きます。「コマンドが成功した」ではなく「その段が作るはずのものが実際にできたか」を見るためです。

同じ日に、GA4の取得スクリプトでも近いものを見つけました。CSVの書き出しが extrasaction="ignore" になっていて、列定義に無いキーを何も言わずに捨てていました。新しく足した流入元の値が、件数は出るのに中身だけ空で記録されていました。こちらも未知のキーがあれば落とすように変えて、わざと壊して落ちることを確認しました。

まとめ

• Googleが 12日間クロールしなかった。原因は200を返す認証ページ
• 同じ200を、自分は「漏えい」、Googleは「ブロック」と逆に誤読した
• 再発防止を作った 8日後、デプロイが0件のまま「✓ 完了」と出た
• パイプは終了コードを捨てる。後段が通っても前段が走った証拠にはならない
• 直し方は「成功したか」ではなく「作られるはずのものができたか」を検査すること

この記事に書いたのは自分のサイトで起きたことだけです。まだ見つかっていない同じ形の故障があるかは分かりません。

関連する記事

• AIに記事を書かせたら、7本の記事に事実でない記述が9件入っていた
  公開前のレビューで9件止まった。検査の仕組みそのものが伏せる情報を漏らした件も書いている
• 証跡集めを自動化すると、監査される対象が増えることがある
  反対はされなかった。止まったのは権限の取得と保存先の決定だった
• 登録セキスペは3年で8,282人が新しく登録したが、総数は4,820人しか増えていない
  IPA の公表値7時点。総数は26,453人だが、新規を足すと引き算が合わない

面談したエージェントの一覧は転職エージェントの比較にまとめています。よかった3社には紹介料が発生するリンクを置いていません。