Astroの静的サイトに来るボットやAIクローラーを確認する

Astroでブログやドキュメントを公開していると、ブラウザーのアクセス解析には出てこないリクエストがあります。HTMLを取得してもJavaScriptを実行しないクローラーは、その一例です。

この記事では、Cloudflareでプロキシしている独自ドメインの静的AstroサイトにWebDecoyのEdge Sensorを設置し、テストリクエストが検知画面に届くところまで確認します。AstroをSSRに変更する必要はありません。

WebDecoyの開発元による解説です。執筆・翻訳にはAIを使用しています。手順は公開ドキュメントと実装資料に基づいており、この記事用に新しい本番環境へ設置した結果や、実際のAIクローラーの検知結果を示すものではありません。

静的サイトでは、どこでリクエストを観測するか

Astroは標準ではページをビルド時に生成します。生成済みHTMLへのアクセスごとに、Astroコンポーネントのサーバー側コードが動くわけではありません。Astroのレンダリングの説明も参考になります。

そこで、今回はAstroの外側で観測します。

クライアント → CloudflareのWorkerルート → Edge Sensor → キャッシュまたはオリジン

対象は、センサーのWorkerルートに到達したリクエストです。ページ内のJavaScriptを実行しないクライアントも観測できます。

この手順には次の条件があります。

• 独自ドメインをCloudflareでプロキシしていること
• 対象ゾーンにWorkerを設置できる権限があること
• 設置先のルートを別のWorkerが使用していないこと

ホスティング事業者の標準ドメインへのアクセスは、この独自ドメイン用の設定では対象になりません。すでにWorkerでアプリを配信している場合も、そのWorkerを上書きせず、既存構成に合う方法を検討してください。

1. サイトとCloudflareを接続する

WebDecoyで無料アカウントを作成し、観測したいサイトを選びます。

1. Integrations → Cloudflareを開きます。
2. Connect with Cloudflareから接続し、要求される権限を確認します。
3. Edge Sensorを開き、対象のゾーンとルートを選びます。
4. 検知の保存先として表示されるWebDecoyのサイトが正しいか確認します。

無料プランはクレジットカードなしで開始できます。Cloudflare側のWorker使用量には、Cloudflareの契約プランに応じた制限や料金が適用されます。

現在、管理画面から設置するEdge Sensorは1組織につき1サイトが対象です。権限や設置方法の詳細はEdge Sensorのドキュメントを参照してください。

2. DNSとルートを確認する

CloudflareのDNS → Recordsで、対象ホスト名がオレンジ色の雲のProxiedになっていることを確認します。DNS-onlyのままでは、ルートを作成できても想定するリクエストがWorkerに届きません。

ホスト名も合わせます。

example.com/*      → example.comへのリクエスト
www.example.com/*  → www.example.comへのリクエスト

この2つは同じルートではありません。普段のURLがどちらなのかを確認してください。Cloudflareのルート仕様にマッチングの説明があります。

管理インストーラーは、Workerの呼び出しを減らすために/_astro/*などのアセットパスを除外できます。ただし、Workerを割り当てない除外ルートは、既存Workerの動作にも影響します。アセットを別のWorkerで処理している場合は、除外設定を確認してください。

3. 設置してテストリクエストを送る

Deploy edge sensorで設置し、WebDecoyのSensors画面にEdge Workerが表示され、Reportingが有効になっていることを確認します。

センサーの観測処理は検知を報告します。ただし、同じWorkerが既存の拒否ポリシーを適用することもあります。観測から始める場合は、すでに設定されている拒否ルールも確認してください。

次に、自分のドメインへ以下のリクエストを送ります。URLは実際のサイトに置き換えてください。

curl -i -A 'WebDecoy-Test/1.0' https://your-site.example/

curlはページのJavaScriptを実行しません。WebDecoy-Test/1.0は検知経路を確認するための予約済みUser-Agentです。

同じサイトのDetectionsを開き、Testと表示された記録を探します。この記録が、リクエストの観測からダッシュボードへの報告まで通ったことの確認になります。

HTTP 200が返ることや、設置完了と表示されることだけでは、報告の到達までは確認できません。また、Testの記録は実際のAIクローラーの訪問を示すものではありません。

記録が出ないとき

Astroのコードを変更する前に、次を確認します。

• リクエストしたホスト名がCloudflareでプロキシされているか
• ホスト名とパスがWorkerのルートに一致しているか
• Reportingが有効で、センサーが最新になっているか
• 設置時に選んだWebDecoyのサイトを見ているか

example.comからwww.example.comへリダイレクトされる構成にも注意が必要です。curlのレスポンスヘッダーを確認し、転送先のホスト名へ直接テストすると切り分けやすくなります。センサーより前のセキュリティルールがリクエストを止める場合もあります。

実際のアクセスを読む

テストが通ったら、通常のアクセスが到着するのを待ちます。まず確認したいのは、どのURLが要求されたかです。記事を読んでいるのか、ページ送りをたどっているのか、/.envのようなパスを探索しているのかを分けて見ます。

次に、クローラー分類と、その判断を支える情報を確認します。User-AgentにGPTBotと書かれていることはクライアントの自己申告です。記録に表示される身元の検証結果とは分けて扱ってください。

時間的な傾向も手がかりになります。1日に数回の記事取得と、数秒間に集中する探索では、調べるべき点が異なります。ただし、この記録だけでコンテンツがモデルの学習に使われたかどうかまでは判断できません。

検知一覧は全アクセスのログではありません。自動化と判断したリクエストが報告対象となり、実トラフィックの件数にはサンプリングや制限の影響もあります。総リクエスト数にはCDNやホスティングのログを使います。

まずはTestの記録を1件確認し、その後に実際の検知を見てみてください。どのボットが何を要求しているのかを把握してから、許可するものと対応が必要なものを判断できます。