【ITニュース解説】I gave my site an access log. Within a minute it showed Bing crawling a hacker''s URLs.

ウェブサイトの運営において、サイトがどのようにアクセスされているかを把握することは非常に重要だ。特に、検索エンジンの「クローラー」と呼ばれるプログラムが、どのようなページを巡回し、どのような情報を収集しているかを知ることは、サイトの健全性を保ち、検索結果での表示を最適化する上で欠かせない。しかし、その情報をリアルタイムで正確に知ることは、意外と難しい場合がある。

この記事の著者は以前、自身のウェブサイトが不正な攻撃を受け、ハッカーによって生成された見慣れないURLがサイト内に埋め込まれるという被害に遭った。この時、サイトをクリーンアップした後も、検索エンジンのクローラーがこれらの不正なURLを再び訪れているかどうか、そしてそのURLに対してサーバーがどのような応答を返しているか、すぐに知る手段がなかった。ホスティングサービスが提供するアクセスログは、管理画面から手動で確認するしかなく、プログラムで自動的に分析することはできなかったため、状況の把握が遅れがちだったという。

そこで著者は、自分自身のサイトに独自のアクセスログシステムを導入することにした。これは約120行のPHPコードで構成されたシンプルな仕組みだ。具体的には、サイトにアクセスしてきたのが既知の検索エンジンのクローラー（GooglebotやBingbotなど）であると判断された場合にのみ、アクセスされた時間、クローラーの種類、サーバーが返した「ステータスコード」（処理結果を示す番号）、リクエストされたページのパス（URLのドメインより後の部分）、そしてクローラーのIPアドレスを記録するというものだ。人間のユーザーからのアクセスはログに残さない設定になっている。

この独自のログシステムを導入してわずか1分後、驚くべき事実が判明した。ログには、Bingのクローラー（Bingbot）が、以前のハッキングで作成されたと思われる、見たことのないURLを大量に巡回している様子が記録されていたのだ。これらのURLは、例えば「/stimulated/a0d3o2b2o25378994」のように、辞書に載っている単語と数字が混じった別の単語を組み合わせたような特徴的なパターンを持っていた。不正なコンテンツはサイトから削除されていたにも関わらず、Bingbotは依然としてこれらの存在しないページを巡回し続けていたのだ。これは、ハッキングが解決した後も、検索エンジンのデータベースには古い情報が残り続けていることを意味していた。

なぜ、サイトから消え去ったはずのURLをクローラーは何度も巡回し続けるのだろうか。その原因は、サーバーが返していた「ステータスコード」にあった。これらの不正なURLにアクセスがあった際、サーバーは「404 Not Found」というステータスコードを返していた。404は「要求されたページが見つかりません」という意味だが、同時に「一時的に見つからないだけで、後でまた利用可能になるかもしれない」というニュアンスも含む。そのため、クローラーは404を受け取ると、「また後で確認しに戻ってこよう」と判断してしまう傾向がある。これが、ハッカーが作成した存在しないURLに、Bingbotが数週間経っても繰り返しアクセスしていた理由だった。

この問題を解決するため、著者は「410 Gone」という別のステータスコードを使うことにした。410は「要求されたページはサーバーから恒久的に削除され、今後利用できません」という意味を持つ。404と異なり、410を返されたクローラーは、そのURLが二度と存在しないことを理解し、以降そのURLを巡回リストから除外するようになる。GoogleやBingのクローラーは、404よりも410の方が早くURLをインデックスから削除する傾向があるため、これがまさに著者が望む挙動だった。

しかし、410を実装する際には慎重な対応が必要となる。もし、410を返す対象となるURLのパターン（ハッカーが作ったURLの形状）の定義が広すぎると、サイト内の正規の、存在するページまで誤って「削除された」と判断し、検索エンジンから削除されてしまうリスクがあるからだ。著者はこのリスクを回避するため、正規表現を使ってハッカーが作ったURLのパターンを厳密に定義し、自身のサイトにある約6,240個の正規URLとは重複しないことを徹底的に検証した。その結果、既知の不正URLは全てマッチし、正規URLは一つもマッチしないという完璧なパターンを特定できた。

さらに重要なのが、この410を返すルールの実行順序だ。著者はこのルールを、通常のルーティング処理（サイト内の正規のURLに対して、どのプログラムを実行するかを判断する仕組み）が全て完了した後、つまり「404 Not Found」と判断される直前の、「404ハンドラ」と呼ばれる部分で実行されるように設定した。もしこのルールをルーティングの初期段階で実行してしまうと、例えば「/s/{code}」のような、数字と文字を含む短縮URLなど、たまたまハッカーのURLパターンと似ている正規のURLまで、誤って「410 Gone」として扱われてしまう可能性がある。しかし、404ハンドラ内で実行することで、正規のURLであればすでにルーティングによって適切な処理がされているため、この410ルールに引っかかることはなく、存在しない不正なURLのみが410として処理される。

この独自のログシステムは、運用開始直後にもう一つの重要な課題を浮き彫りにした。ある時、ログに「googlebot 200 /」という記録があった。一見するとGooglebotがサイトを訪れたように見えるが、IPアドレスを確認すると、それは著者自身のネットワークからのアクセスだった。これは、著者がテストのために「ユーザーエージェント」（アクセス元が「自分はGooglebotである」とサーバーに伝える情報）を偽装していたことによるものだ。ユーザーエージェントは簡単に偽装できるため、ログに記録された情報だけを鵜呑みにするのは危険だということを示している。

そこで著者は、ログの信頼性をさらに高めるため、クローラーのIPアドレスを検証する仕組みを追加した。GoogleやBingが公開している公式のIPアドレスリストと照合することで、本当に正規のクローラーからのアクセスなのか、それとも偽装されたアクセスなのかを区別できるようにしたのだ。これにより、ログに記録されたクローラーアクセスが「検証済み」か「未検証」かが分かるようになり、より正確なサイトの監視が可能になった。

このような対策を講じることは、ウェブサイト運営において非常に大きな意味を持つ。検索エンジンは、サイトのクロール（巡回）に使えるリソースや時間に限りがある。これを「クロールバジェット」と呼ぶ。もし、大量の存在しない不正なURLにクローラーが貴重なクロールバジェットを費やしてしまえば、サイト内の重要で新しいページがなかなか発見されず、検索結果に表示されないといった問題が発生する可能性がある。独自のログシステムと適切なステータスコードの利用、そしてログ情報の検証は、このようなクロールバジェットの無駄をなくし、サイトのSEO（検索エンジン最適化）を改善するために不可欠な取り組みと言える。不要になったURLを恒久的に削除したい場合は、アプリケーションコードだけでなく、ウェブサーバーの設定ファイル（.htaccessなど）で410リダイレクトを行う方法も、パフォーマンス面で有利な場合がある。いずれにせよ、パターンをしっかり検証した上で行うことが重要だ。