ボットアクセスは一般的にセキュリティやSEOの問題として語られますが、WordPressサイトを運用するサーバーインフラの観点では、特定のURLへのアクセス集中によるパフォーマンスの問題として現れることが少なくありません。
さらに、リクエストによってサーバーへの負荷は大きく異なります。キャッシュされた静的ページへのアクセスと動的に処理されるURLへのアクセスでは、必要となるサーバーリソースに大きな違いがあります。静的ページへのリクエストはほとんどリソースを消費しない一方で、動的URLへのリクエストではPHPスレッドが占有され、データベースクエリやセッション処理が発生します。
したがって、どのURLが特に大きな負荷を生むのかを理解することが、効果的なボット管理戦略の鍵となります。これにより、必要以上にアクセスをブロックしてしまったり、逆に十分な対策が取れなかったりする事態を防ぐことができます。
すべてのリクエストが同じではない
ユーザーがブログ記事や商品一覧ページ、会社概要ページなどの一般的なWordPressページにアクセスした際、サーバーは通常、キャッシュされたコンテンツを返します。
Kinstaのフルページキャッシュはエッジでリクエストを処理するため、PHPやデータベースが実行されることはありません。
一方、リクエストがキャッシュできないURLに送られると、サーバーは実際の処理を行う必要があります。PHPスレッドが割り当てられ、リクエストの処理が完了するまで占有されるほか、データベースへのクエリも実行されます。また、ページがカート情報やユーザーセッション、パーソナライズされたコンテンツを含む場合は、セッション処理による追加の負荷も発生します。こうしたレスポンスはユーザーやリクエストごとに内容が異なるため、キャッシュすることができません。
人間の訪問者が中心の健全なサイトであれば、これは大きな問題にはなりません。動的なURLは、商品をカートに追加したり、購入手続きを進めたり、商品を検索したりする実際の買い物客のために処理されるため、サーバー負荷も実際の利用状況に応じたものになります。
しかし、ボットによるアクセスはこの前提を覆してしまいます。クローラーは商品を購入することも、コンバージョンにつながることもありません。それにもかかわらず、実際の顧客と同じサーバー側の処理を発生させます。しかも、そのアクセス頻度は人間のユーザーでは到底実現できないほど高くなります。
この問題が発生しやすいURL
WooCommerceストアでは、以下のURLパターンやエンドポイントは設計上キャッシュできず、ボットアクセスの影響を受けやすい傾向があります。
?add-to-cart=
add-to-cart=（カートに追加）URLは、Kinstaの最新レポート「AI・ボット時代におけるトラフィックの実態」で紹介した中でも特にリソース消費の大きい例です。商品をカートに追加する処理では、PHPの実行、データベースへの書き込み、そしてセッションの作成または検証が行われるため、キャッシュ済みのレスポンスを返すことはできず、リクエストごとにサーバー側で処理を実行する必要があります。
実際に、Kinstaのインフラデータでは、わずか5種類のボットによって24時間で767万回もの「カートに追加」リクエストが発生したケースもあります。
これは24時間休みなく、平均すると約11ミリ秒ごとにPHPとデータベースの処理を発生させていた計算になります。しかし、その処理によって生成される結果はクローラーにとってほとんど価値がなく、実際の顧客にも何ら利益をもたらしません。
/cart と /checkout
WooCommerceでは、これらのページはデフォルトでページキャッシュの対象外となっています。カートの内容やユーザーごとのセッション情報、さらに決済ページでは決済処理に関するデータを扱うためです。
ボットが/checkoutに繰り返しアクセスしても、実際に購入が行われることはありません。しかしサーバー側には、そのリクエストがボットによるものか、本物の顧客によるものかを判断する手段がありません。そのため、すべてのリクエストを実際の購入手続きである可能性があるものとして処理します。
?s=（検索クエリ）
WordPressやWooCommerceの検索機能は、リクエストごとにデータベースへのクエリを実行します。検索語句は毎回異なるため、通常のページキャッシュで処理することはできません。
クローラーがパラメータ付きURLのバリエーションをたどったり、見つけた検索リンクを片っ端からクロールしたりすると、大量のユニークな検索クエリが発生します。その結果、サーバーは負荷の高いデータベース検索を繰り返し実行することになります。
ファセットナビゲーションとフィルターパラメータ
問題がさらに深刻になるのが、ファセットナビゲーションやフィルターパラメータです。一般的なWooCommerceの商品カタログでは、次のようなURLが生成されます。
/shop/?color=blue
/shop/?color=blue&size=M
/shop/?color=blue&size=M&orderby=price
/shop/?color=blue&size=M&orderby=price&paged=2人間から見れば、これらはほぼ同じページのバリエーションですが、リンクをたどるボットにとっては、それぞれがクロール対象となる別個のURLになります。そして、そのたびにサーバーはフィルタリングされたデータベースクエリを新たに実行しなければなりません。
Googleも、ファセットナビゲーションがクロール効率を低下させる要因のひとつであると指摘しています。クローラーがほぼ無限ともいえるURLの組み合わせを探索してしまうためです。しかし、問題はクロールバジェットの浪費だけではなく、こうしたURLバリエーションが生成されるたびにサーバー側で実際のリソースが消費されることにあります。
AJAXを利用した機能
ウィッシュリスト、在庫確認、価格のリアルタイム更新、カレンダー表示など、多くのWordPressプラグインはページキャッシュを経由しないAJAXリクエストを利用しています。
ボットがこうした機能を直接呼び出したり、それらのAJAXリクエストを発生させるページを読み込んだりすると、サーバー側の負荷が発生します。この負荷は、通常のアクセス解析では「ページビュー」として記録されない場合がありますが、PHPスレッドの使用量には確実に反映されます。
PHPスレッドが不足するとどうなるのか
動的URLへのアクセスでは、リクエストの処理が完了するまでPHPスレッドが占有されます。一見すると些細なことのように思えるかもしれませんが、利用できるPHPスレッドの数には限りがあります。ボットは都合よく順番待ちをしてくれるわけではありません。
Kinstaでは、WordPressサイトごとに利用できるPHPスレッド数が割り当てられています。キャッシュされないリクエストが発生するたびに、その処理が完了するまでPHPスレッドが1つ確保されます。
通常のトラフィック環境では、これが問題になることはほとんどありません。リクエストは到着後すぐに処理され、PHPスレッドも速やかに解放されます。
しかし、ボットが動的URLに継続的にアクセスすると、PHPスレッドは次々と占有されます。利用可能なPHPスレッドがすべて埋まると、新たなリクエストはキューで待機することになります。その結果、商品をカートに追加したり、購入手続きを完了したりしようとしている実際の顧客は、ページ表示の遅延やタイムアウト、HTTP 504エラーなどの影響を受ける可能性があります。
これが、動的URLへのボットアクセスが、キャッシュ可能なページへのボットアクセスとは本質的に異なる理由です。
ループ問題─ボットが巡回し続けるとどうなるのか
Kinstaのインフラチームが確認しているボットアクセスの多くは、実は意図的な攻撃によるものではありません。クローラーがページ上のあらゆるリンクをたどり続ける一方で、自分が同じような場所を何度も巡回していることを認識する仕組みを持たないことが原因になっています。
クエリパラメータは、以下のようにループするのが典型的です。
- ボットが
/shop/にアクセスする - ページ内に
/shop/?color=blue（色で絞り込んだ商品一覧）へのリンクがある - そのページには
/shop/?color=blue&size=Mへのリンクがある - さらに
/shop/?color=blue&size=M&orderby=priceへのリンクがある - そして
/shop/?add-to-cart=123のような「カートに追加」URLへのリンクがある - それぞれのページが、ボットにとって未訪問の新しいURLをさらに生成する
ボットはこれらのリンクをすべてたどります。「フィルター条件が違うだけで、実質的には同じ商品ページをすでに見ている」という認識はなく、ボットにとっては、URLが少しでも異なれば別ページになります。そのため、すべてのURLに対して新たなリクエストが送られ、サーバー側で処理が実行されます。
このように、ボットがクエリパラメータのバリエーションをたどりながら動的URLを巡回し続けるパターンは、先ほどのレポートでも特に多く確認された問題のひとつです。実際にKinstaのインフラでは、ある1つのループパターンに対するフィルタールールだけで、30日間に5億5,000万件ものリクエストを処理対象から除外しました。これは攻撃ではありませんが、非効率な自動化処理が大規模に繰り返された結果であり、早い段階で制御されなければ膨大なリソース消費につながります。
動的URLに対する効果的なボット管理
WooCommerceストアや動的な機能を持つWordPressサイトでは、特定の設定に関係なく、いくつかの原則が適用されます。
- robots.txtはシグナルであり、防御策ではない：
/cart、/checkout、?add-to-cart=などのURLは、robots.txtでクロールを禁止しておくことが推奨される。Googlebotはこうした指示を尊重はするが、robots.txtの遵守はあくまで任意。近年増加しているAI学習用クローラーの中には、robots.txtを確認しないものや、確認しても指示に従わないものがある。robots.txtでの設定は「クロールしてほしくない」という意思表示にはなるが、実際にアクセスを制御するには、WAF（ウェブアプリケーションファイアウォール）レベルでのルール設定が不可欠。 - URLパラメータの増殖を抑える：WooCommerceの標準設定では、セッショントークンや数量パラメータ、フィルター条件の組み合わせによって大量のURLバリエーションが生成される可能性がある。canonicalタグの適切な設定、パーマリンク構造の整理、パラメータ付きURLに対するrobots.txtの
Disallowルールの活用などによって不要なURLの増殖を抑えることで、クローラーがループに陥るリスクを減らすことができる。 - 総リクエスト数だけでなくURL単位で監視する：トラフィックの増加が必ずしも問題とは限らない。広告キャンペーンやSNSでの拡散によってアクセス数が増加することも。一方で、
?add-to-cart=へのリクエストが急増し、そのアクセス元がブラウザではなくボットである場合は、対策が必要な兆候。URLパターンやユーザーエージェントごとのリクエスト分布を確認できるサーバーログや分析ツールの有無によって、問題を数時間で発見できることもあれば、数日間見逃してしまうこともあります。 - PHPスレッドの使用状況を重要な指標として監視する：PHPスレッドが頻繁に上限へ達しているにもかかわらず、実際のユーザーセッション数に大きな増加が見られない場合は、動的URLへのボットアクセスが原因のひとつである可能性がある。Kinsta APMでは、エンドポイントごとの処理時間が長いPHPトランザクションを確認できる。そのため、
/cartや/checkoutが負荷の原因になっている場合も、推測ではなくデータに基づいて特定することができる。
サイトの種類によって異なる影響
動的URLに対するボットアクセスの問題は、WooCommerceストアで特に顕著ですが、サイトの種類によって異なる形で現れます。
- WooCommerceストア：カートやチェックアウト、フィルタリングされた商品一覧ページといった負荷の高いURLが、ボットによる通常のリンク巡回だけで容易に発見されるため、最も影響を受けやすいサイトのひとつ。その影響は直接的で、ボットアクセスによってPHPスレッドが枯渇すると、実際の顧客のチェックアウト処理や購入体験に悪影響を及ぼす。
- コンテンツサイトやブログ：チェックアウト機能に関するリスクは低いものの、ボットがページネーションされたアーカイブページやタグページ、検索結果ページを巡回することで大きな影響を受ける可能性がある。検索クエリは毎回新たなデータベースアクセスを発生させるため、大規模なアーカイブをクローラーが体系的に巡回すると、EC機能がなくても継続的なデータベース負荷が発生することがある。
- ビジネスやサービスのサイト：お問い合わせフォームや見積もり依頼フォーム、予約フォームなどが主なリスクポイントに。これらの機能ではセッション管理やデータベースへの書き込みが行われることが多く、ボットによるアクセスはサーバーリソースを消費する。また、ボットが送信したフォームデータは、CRMへの不要データの流入や営業担当者の工数増加といった別の問題を引き起こすこともある。
- ウェブアプリとSaaS製品：ウェブアプリケーションやSaaSは、ボットアクセスの影響を最も受けやすいケース。APIエンドポイントやダッシュボード、アプリケーションロジックは基本的にキャッシュできないため、アプリケーション層に到達したボットアクセスはキャッシュ基盤を完全に迂回する。このような環境では、認証を必要としない
/apiや/appへのアクセスを原則としてブロックし、正当な連携サービスのみを許可リストで管理する方法が有効。
AI・ボットアクセスの全体像
動的URLへのボットアクセスは、WordPressインフラにおけるボットアクセス問題の一側面にすぎません。近年、AIクローラーは急速に増加しており、その挙動も変化しています。リンクを積極的にたどるクローラーが増え、クロール制御の指示を無視するケースも見られるようになりました。また、サーバー負荷の高いURLへのアクセスも増加しています。
こうした変化の背景や実際のデータ、さらにサイトの種類や運用方針に応じたボット管理の考え方については、先にもご紹介したKinstaのレポート「AI・ボット時代におけるトラフィックの実態」で詳しく取り上げています。このレポートは、Kinstaが管理するインフラ上で観測された100億件以上のリクエストを分析して作成したものです。
今回ご紹介した内容をもとに対策を進めたい場合は、Kinstaのボット対策機能が役立ちます。この機能は、高負荷な動的URLへのアクセスを含む一般的なボットアクセスパターンに対応しており、MyKinstaで対策レベルを選択するだけで利用できます。
ボットアクセス、ボット対策機能、あるいはKinstaのサービスに関して、ご不明な点がございましたら、カスタマーサポートまでお気軽にお問い合わせください。
