404 監視のボット除外ルールが、公開中のページを隠していた
自分のサイトの 404 を監視していると、設定ファイルや管理画面を探して回るボット（スキャナ）の 404 が大量に混ざります。読者が実際に開いて 404 になったページを見るには、ボットを除外するルールが要ります。ただ、このルールが間違えて実在のページを隠しても、そのページがレポートから消えるだけで何の知らせも出ません。
そこで私は、ルールを足すたびにサイトマップ（サイトが公開している全ページの URL の一覧）の全 URL をルールに通し、ボット扱いになる物が 0件かを確かめています。件数が減ったのを見ても、減った分がボットを除いた分なのか実在のページを隠した分なのかは区別できないからです。この確かめ方で、前からあったルールが公開中のプロフィールページを隠していたのが見つかりました。
件数が減っても、正しく除いたとは限らない
私は個人で 8サイトを運用していて、Cloudflare のアクセスの集計から 404 を拾って分類する週 1回のレポートを自作しています。ある週、読者が開いたページの不具合として扱う 404 が、6サイトで合計 465件ありました。大半は /config.js や /env.js のような、ルート直下の JS をしらみつぶしに叩くスキャナでした。レポートが .js で終わる URL を拡張子だけで画像や CSS と同じ「ページの部品」と判定していたためです。
設定ファイルを探すファイル名をボット除外のルールに足すと、同じ週の集計で 465件は 123件に減りました。ただ、減った分が全部ボットだったかは件数からは分かりません。
サイトマップの全 URL をルールに通す
ルールの変更は AI エージェント（Claude Code）に任せ、合格の条件を先に決めました。8サイトのサイトマップにある全 URL を新しいルールに通し、ボット扱いになる物が 0件であることです。結果は私も別にルールに通して確かめました。
962 URL を通すと新しいルールでは 0件でしたが、変更前のルールではこのブログ（shinobiworks.com）の運営者のプロフィールページ /profile が 1件当たっていました。管理画面を探すスキャナを除外するための単語の一覧に profile が入っていて、公開中のページを隠していました。この語を一覧から外しました。
この誤りは今回の変更より前からあった物で、件数の比較ではなくサイトマップとの照合で見つかりました。
ボットだと分かっても、ありふれたページ名はルールにしない
ルールは、実在のページを隠す害がボットを 1種類見逃す害より大きいので、迷ったらボット扱いしない原則にしています。この原則に従ってボットのアクセスだと確かめたのにルールにしなかったパスがあります。
/contactと/blog: 別のサイトでは実在するページ/service/company/work/works: ボットと名乗るアクセスだったが、どのサイトにもありうるページ名
これらのパスは「ボット扱いしてはいけないパス」としてテストに並べ、次に足したルールがこれらのパスをボット扱いするとテストが失敗するようにしました。足すルールは /stripe.config.js のような具体的なファイル名に限り、config のような一般的な語の部分一致にはしません。