スパムによるクロールバジェット浪費を防ぐ410ステータスとネガティブSEO対応

事業用のホームページ（ウェブサイト）を運営する上で、検索エンジン最適化（SEO）の成果を左右する重要な要素のひとつに、検索エンジンのクローラーがホームページを巡回する上限枠であるクロールバジェットの管理があります。どれほど専門性が高く有益なページを作成して公開しても、クローラーがそのページへ到達してデータを読み取らなければ、検索結果に反映されることはありません。クロールバジェットの基本的な仕組みやホームページ運用における全体像については、「クロールバジェット SEO・ホームページ運用における全体像」で解説している通りですが、実務の現場においてこの限りある巡回枠を最も急激かつ深刻に食い潰してしまう原因となるのが、外部からの悪質なスパム行為やネガティブSEOによる異常なURLの大量発生です。

ある日突然、Googleサーチコンソールのレポート上に、自社では作成した覚えのない見知らぬURLが数千件から数万件規模で出現し、クローラーがそれらの存在しないページばかりを昼夜問わず巡回し始めるという事態は、規模の大小を問わず多くのホームページで実際に発生しています。たとえば、WordPressの画像保存用ディレクトリであるuploadディレクトリ配下に動画のプレイリストを装った「.m3u8」という拡張子の架空URLが大量に生成されたり、サイト内検索の仕組みを悪用して無意味な文字列や違法な宣伝文句を含んだパラメータ付きURLが外部から大量に送り込まれたりするケースがその代表例です。

このようなスパム攻撃を受けた際、多くのホームページ運営者や制作担当者は「実際にサーバー上にファイルは存在せず、アクセスしても404（Not Found）エラーが返っているからそのまま放置していても問題ないだろう」と判断しがちです。しかし、検索エンジンのクローラーの仕様を深く理解していれば、この「404のまま放置する」という判断こそがクロールバジェットの枯渇を招き、ホームページ全体のSEO評価を長期にわたって停滞させる大きな落とし穴であることに気づきます。

クローラーは404ステータスコードを受け取っても、それが一時的な設定ミスや通信エラーである可能性を考慮し、その後も何度も同じURLへ再確認の巡回を繰り返します。さらに、WordPressなどの動的CMSを利用している環境では、存在しないURLへアクセスが来るたびにプログラムとデータベースが起動して404ページを生成するため、サーバーの応答速度が著しく低下し、ホームページ全体に割り当てられるクロールバジェットの総枠そのものが削減されてしまうという二重の被害を引き起こします。

こうした事態を素早く収束させ、正規の重要なページへクローラーの巡回リソースを取り戻すためには、単なる不在を示す404ではなく、ページが恒久的に存在しないことを明示する「410（Gone）」のHTTPステータスコードをサーバー層で返し、クローラーの巡回リストから強制的に除外させる技術的な対処が必要です。

今回は、スパムやネガティブSEOがクロールバジェットを浪費させる具体的なメカニズムから、ハッキング被害との切り分け、そして410ステータスコードを用いてクローラーの無駄な巡回を最短で停止させる実践的な手法までを専門的な視点から掘り下げて解説します。

悪質なスパムがホームページのSEO評価に与える悪影響

外部からのスパム攻撃や不正なURL生成は、単にサーチコンソールの管理画面上のエラー件数を増やして見栄えを悪くするだけの問題ではありません。検索エンジンのクローラーの巡回経路を歪め、サーバーの処理能力を奪い、結果として事業に直結する正規ページの検索順位やインデックス速度に深刻な打撃を与えます。

まずは、現場で頻発している代表的なスパムの手口と、それがどのような経路でホームページ（ウェブサイト）の評価を蝕んでいくのかを正確に把握しておく必要があります。

自動生成ディレクトリやm3u8スパムの手口と被害

近年、WordPressをはじめとするCMSで構築されたホームページにおいて特に被害が相次いでいるのが、実在する特定のディレクトリ配下に、本来は存在するはずのない架空のサブディレクトリや特殊な拡張子を持ったファイルへのURLを外部から勝手に捏造してリンクを張り、クローラーを大量に送り込む手口です。その象徴的な事例が、メディアファイルを格納するuploadディレクトリ配下を標的とした「m3u8スパム」と呼ばれる現象です。

uploadディレクトリ配下を狙う偽装リクエストの仕組み

「.m3u8」という拡張子は、本来であればHLS（HTTP Live Streaming）という動画配信技術において、分割された動画データの再生順序などを記述するプレイリストファイルに使われる形式です。攻撃者は、標的としたホームページの「/wp-content/uploads/」などのディレクトリ構造に目をつけ、その配下にランダムな英数字のフォルダ名や「index.m3u8」「video.m3u8」といった実際にはサーバー上に存在しない架空のURLを何万通りも機械的に作成します。そして、外部の粗悪なスクレイピングサイトや海賊版動画サイト、あるいは自動生成されたスパムブログ群から、それらの架空URLへ向けて大量のリンクを発信します。

なぜ攻撃者がわざわざ他社のホームページのuploadディレクトリ配下に存在しないm3u8ファイルのURLを捏造するのかというと、検索エンジンのクローラーや動画収集ボットに対して「このドメインのサーバー上に動画ストリームが存在する」と誤認させ、リファラ（参照元）の履歴や検索エンジンのキャッシュ、あるいは外部のインデックス登録を悪用して自らのスパムサイトへ誘導する踏み台にするため、あるいは標的としたホームページのクロールバジェットを意図的に枯渇させるネガティブSEOを目的としているためと考えられます。

このuploadディレクトリ配下を狙ったm3u8スパムの特徴や具体的な対処の全体像については、uploadディレクトリ .m3u8スパム攻撃の目的と「410 Gone」による対処法 の記事でも詳しく取り上げていますが、検索エンジンのクローラーは外部サイトに張られたリンクを発見すると、そのリンク先が実在するかどうかを確かめるために、捏造された何万件ものm3u8ファイルのURLへ次々とアクセスしてきます。ホームページの運営者が自社のサーバー内をFTPなどでいくら探しても該当するファイルは存在しないにもかかわらず、サーチコンソール上では「/wp-content/uploads/」配下の見知らぬURLに対する404エラーが毎日数千件ずつ増え続けるという不気味な現象が引き起こされます。

動的処理の負荷増大によるクロールレート制限の低下

このm3u8スパムをはじめとする架空URLへの大量アクセスがもたらす最大の脅威は、Webサーバーの裏側で発生する「動的404生成処理」による急激な負荷増大です。通常の静的なHTMLサイトであれば、存在しないURLへのリクエストが来た場合、ApacheやNginxといったWebサーバーのソフトウェアが瞬時に「ファイルが存在しない」と判断し、極めて軽い処理で標準の404エラー画面を返します。

しかし、WordPressのような動的CMSを導入している環境では、標準のルーティング設定（.htaccess内のRewriteRuleなど）によって、「サーバー上に実在するファイルやディレクトリが見つからないリクエストは、すべてWordPressの本体プログラムであるindex.phpへ引き渡す」という仕組みになっています。

つまり、クローラーがスパムによって捏造された存在しないm3u8のURLへアクセスしてくるたびに、Webサーバーは裏側でPHPのプログラムを起動し、WordPressのコアファイルや有効化されているすべてのプラグインを読み込み、さらにMySQLなどのデータベースへ接続して「該当するURLの投稿や固定ページが存在するか」を検索するクエリを実行します。

そして、データベースの検索結果として「該当なし」と判明した段階で初めて、テーマの404.phpテンプレートを読み込み、ヘッダーやフッター、サイドバーの新着記事一覧などを動的に組み立てて、装飾されたリッチな404エラーページをクローラーに返却します。1回のアクセスであればコンマ数秒で終わる処理であっても、スパムによって誘き寄せられたクローラーが1日に何万回もこのリクエストを繰り返せば、サーバーのCPU使用率とメモリ消費量は跳ね上がり、データベースの接続上限に達してホームページ全体の応答速度が極端に遅くなります。

ピラー記事でも解説した通り、検索エンジンのクローラーは巡回先サーバーの応答速度を常に監視しており、応答が遅くなると「サーバーに負荷をかけすぎている」と判断してクロールレート制限（巡回速度の上限）を厳しく引き下げます。結果として、スパムURLがWordPressの動的404処理を酷使することでサーバーが重くなり、検索エンジン側からホームページ全体への巡回枠を大幅に減らされてしまうという深刻な二次被害が発生します。

サーチコンソールに現れる謎のURLとネガティブSEOの実態

m3u8スパムのように特定の拡張子を狙うもの以外にも、Googleサーチコンソールのレポートを確認していると、全く身に覚えのない文字列や外国語のパラメータを含んだ「謎のURL」が大量に検出されることがあります。こうした現象に直面した際、運営者が最も優先して行わなければならないのは、その謎のURLが「自社のサーバー内部がハッキングされて生成されたものなのか」、それとも「外部からのネガティブSEOやスパムリンクによって外側から送り込まれたものなのか」という原因の正確な切り分けです。

サーチコンソールに謎のURLが出現した際の調査手順や、ハッキングとネガティブSEOを見極める具体的な方法については、Google Search Consoleに現れる謎のURL 高度なハッキングとネガティブSEOへの対応 にて詳細に解説していますが、両者はクロールバジェットの浪費という共通の被害をもたらす一方で、ステータスコードの挙動やホームページの信頼性に与える影響の性質が大きく異なります。

サーバー内部の改ざんによるスパムページ生成（マルウェア感染型）

まず最も警戒すべきなのが、WordPressの古いプラグインの脆弱性や推測されやすいパスワードなどを突かれ、サーバー内部に不正なプログラム（バックドアやマルウェア）を植え付けられてしまうハッキング被害です。このケースでは、攻撃者がサーバー内の.htaccessやindex.phpを改ざんしたり、見知らぬPHPファイルを設置したりすることで、同じドメイン配下に偽のブランド品通販ページやオンラインカジノ、アダルトサイトなどへ誘導する大量のスパムページを実際に生成します。

この内部改ざん型スパムの非常に厄介な点は、生成された謎のURLがエラー（404）ではなく、正常なページを意味する「ステータスコード200」を返し、実際に検索エンジンのデータベースにインデックス登録されてしまうことです。さらに近年の巧妙なマルウェアは「クローキング」と呼ばれる技術を用いており、ホームページの運営者や一般ユーザーが通常のブラウザからそのURLにアクセスした際には「404エラー」や「トップページ」を表示して異常を隠蔽し、アクセス元がGoogleのクローラー（Googlebot）であった場合や、検索結果を経由したアクセスであった場合にのみ、偽の通販ページなどのスパムコンテンツを表示するようにプログラムされています。

もしサーチコンソールの「ページ」レポートで、謎のURLが「未登録（404）」ではなく「インデックス登録済み」の項目に大量に分類されている場合や、URL検査ツールでライブテストを実行した際に身に覚えのないHTMLコードが取得される場合は、内部改ざんによるスパム生成が確実視されます。この場合、クローラーは数万ページにおよぶ偽通販ページを「このホームページの正規コンテンツ」としてクロール・レンダリングし続けるため、クロールバジェットが完全に奪われるだけでなく、ホームページ全体が「悪質なスパムサイト」として検索エンジンからペナルティや評価の大幅な格下げを受けることになります。

外部からの悪意あるリンク送信とクエリパラメータ攻撃（外部誘導型）

一方、サーバー内部には一切の不正侵入やファイル改ざんが行われていないにもかかわらず、サーチコンソールに謎のURLが大量発生するケースがあります。これが外部誘導型のスパム、いわゆるネガティブSEOや自動ボットによるクエリパラメータ攻撃です。

代表的な手口としては、ホームページが備えている「サイト内検索機能」のURL構造を悪用するものが挙げられます。たとえばWordPressでは、ドメインの末尾に「?s=検索ワード」というクエリパラメータを付与してアクセスすると、その検索ワードに対するサイト内検索結果ページが動的に生成されます。攻撃者はこの仕組みを利用し、「?s=違法カジノの宣伝文句やURL」「?s=偽ブランド品の名称」といったパラメータを付与したURLを何万通りも作り出し、外部のスパムサイトからリンクを張ったり、直接ボットでアクセスしたりして、検索エンジンのクローラーにそのURLを巡回させます。

このとき、ホームページ側のサイト内検索結果ページが「該当する記事はありませんでした」という画面を表示しつつも、HTTPステータスコードとして「200（正常）」を返し、さらにnoindex設定が行われていなかった場合、スパム業者が送り込んだ違法な文字列を含む検索結果ページがそのまま自社のホームページのページとしてインデックスされてしまいます。

また、たとえnoindexが設定されていたり、無関係なクエリパラメータ（たとえば「?id=12345abc」など）で404を返していたりしても、外部から次々と新しい文字列の組み合わせでリンクが作られ続ける限り、クローラーは未知のURLを発見するたびに巡回を試みるため、クロールバジェットの激しい浪費が止まらなくなります。

スパム放置が招く正規ページのインデックス遅延と機会損失

こうしたスパムURLによるクロールバジェットの浸食を「実害がないから」と見過ごしていると、やがて本業の集客を担う正規のページ群に明確な悪影響が及び始めます。その影響は、検索エンジンのクローラーが内部で管理している巡回タスクの優先順位（クロールキュー）の崩壊というかたちで表面化します。

ディスカバリークロールとリフレッシュクロールの優先順位の崩壊

検索エンジンのクローラーの巡回活動は、大きく分けて「ディスカバリー（発見）クロール」と「リフレッシュ（更新確認）クロール」の2種類に分類されます。ディスカバリークロールとは、これまで検索エンジンが一度も見たことのない未知のURLを新しく巡回する処理であり、リフレッシュクロールとは、すでにインデックスされている既存ページに内容の変更や更新がないかを定期的に再確認する処理です。

外部から何万件ものスパムURLや不正パラメータ付きURLが生成されると、クローラーの待機列（キュー）は、それらの未知のURLを調査するためのディスカバリークロールによって埋め尽くされます。その結果、ホームページの運営者が事業の売上を伸ばすために新しく執筆して公開した本来の「新規記事」に対するディスカバリークロールが、膨大なスパムURLの後ろに並ばされることになり、公開してから何週間経ってもサーチコンソール上で「検出 – インデックス未登録」のまま放置されるという現象が起きます。

同時に、ディスカバリークロールにバジェットの大部分が割かれることで、既存の重要なサービスページや過去記事を見回るリフレッシュクロールの頻度も大幅に減少します。SEO対策を実施してから実際に検索順位の上昇などの効果が現れるまでには、クローラーによる再巡回とホームページ全体の再評価のプロセスが必要となるため一定の期間を要しますが（この期間の仕組みについては SEOの効果が出るまでの期間は？「4ヶ月〜1年」の定説とサイト規模ごとの本当の目安 で詳しく解説しています）、スパムによってリフレッシュクロールが滞ると、せっかく既存ページをリライトして品質を高めても検索エンジンがその改善に気づくまでに数ヶ月以上の遅れが生じ、SEO効果が出るまでの期間が際限なく後ろ倒しになってしまいます。

ホームページ全体の品質スコアに対する間接的な悪影響

さらに見逃せないのが、クローラーがスパムURLを巡回し続けることによって生じるホームページ全体の評価の希釈です。もしスパムURLの一部がサイト内検索の仕様やテーマの不備によってステータスコード200を返してしまっていたり、内容の薄いエラーページが大量に「ソフト404」として検出されたりしている場合、検索エンジンのアルゴリズムは「このドメインには、ユーザーの役に立たない無意味なページや管理されていないエラーページが大量に含まれている」と認識します。

現在の検索エンジンは、ページ単体の評価だけでなく、ドメイン全体やディレクトリ単位での「情報の純度」や「管理の健全性」を重視しています。正規の記事が500ページあるホームページに対して、スパムによって生成されたゴミのようなURLが5万件もクロールされている状態を放置することは、ホームページ全体の信頼性を大きく損なう要因となります。クロールバジェットを守るためのスパム排除は、正規ページのインデックス速度を保つためだけでなく、ホームページ全体の専門性と信頼性を防衛するためにも極めて重要な取り組みです。

スパムURLによるクロールバジェットの浪費を止める方法

スパム攻撃やネガティブSEOによって発生した大量の不要URLからクロールバジェットを取り戻すためには、検索エンジンのクローラーの行動原則に基づいた技術的な遮断措置を講じる必要があります。その中心となるのが、Webサーバーがクローラーに返却するHTTPステータスコードの厳密な制御、とりわけ「404」と「410」の戦略的な使い分けです。

404エラーと410エラーのクロールに対する挙動の違い

ホームページ上のページが存在しない場合、サーバーが返すステータスコードとして最も一般的なのは「404（Not Found）」です。通常のホームページ運用において、不要になった少数の記事を削除した際などに404を返すことは何ら問題ありません。しかし、スパムによって数千件から数万件規模の架空URLに対するクロールが発生している緊急事態においては、404ステータスコードではクロールバジェットの浪費を素早く食い止めることができません。そこには、検索エンジンが404と410をどのように区別して処理しているかという明確な仕様の違いが存在します。

404（Not Found）が再クロールを誘発し続ける理由

HTTPプロトコルの定義において、404（Not Found）は「リクエストされたリソースが現在サーバー上で見つからない」ことを意味しますが、その不在が「一時的なものなのか、恒久的なものなのか」については言及していません。実際のインターネット上では、ホームページ運営者が誤ってファイルを別フォルダへ移動させてしまったり、CMSのパーマリンク設定を一時的に壊してしまったりして、本来存在するはずの重要なページが数日間だけ404になってしまうという人為的なミスが日常茶飯事のように起きています。

そのため、Googleをはじめとする検索エンジンのクローラーは、あるURLにアクセスして404ステータスコードを受け取ったとしても、即座にそのURLをデータベースや巡回リストから完全に抹消するような乱暴な処理は行いません。「運営者の手違いで一時的に消えているだけで、数日後には元通りに復旧するかもしれない」と配慮し、一定の猶予期間を設けて再確認のクロール（リトライ）をスケジュールに組み込みます。

具体的には、最初に404を確認した後も、数日後、1週間後、数週間後、1ヶ月後といった具合に、徐々に巡回間隔を広げながらも、長期間にわたって何度も同じURLへアクセスして「本当にまだ404のままだろうか」と確認し続けます。もしスパムによって5万件の架空URLが作られ、それらすべてに対してサーバーが通常の404を返していた場合、クローラーはその5万件に対して何回も再確認のクロールを繰り返すことになり、数十万回におよぶクロールバジェットが何ヶ月もの間、完全に無意味な確認作業のために浪費され続けることになります。

410（Gone）がクローラーに伝える恒久的な消滅のシグナル

これに対して、HTTPステータスコード「410（Gone）」は、「リクエストされたリソースはサーバー上から恒久的に取り除かれており、転送先のアドレスも存在せず、今後も二度と復活することはない」という確定的な事実を伝えるためのコードです。この状態は運営者のうっかりミスではなく、明確な意図をもってそのURLを完全消滅させたという強いシグナルとして機能します。

検索エンジンのクローラーは、アクセスしたURLから410ステータスコードを受け取ると、「このURLは今後も復活する可能性がゼロであるため、これ以上再確認のクロールを行う必要はない」と即座に判断します。すでにインデックスされていた不正ページであれば404よりもはるかに速いスピードでインデックスから削除され、未登録のスパムURLであれば、1回目に410を確認した時点でクローラーの巡回スケジュール（クロールキュー）から優先的に除外されます。

URL変更や記事統廃合の際に、過去の評価を引き継ぐために用いる「301リダイレクト」（詳細は ホームページ内部のURL変更とリダイレクト設定 SEOへの影響と記事統廃合の実践 を参照）がクローラーを「新しい場所へ誘導する標識」だとすれば、410ステータスコードはクローラーに対して「この道は完全に閉鎖されたため二度と立ち入らないでほしい」と伝える遮断機のような役割を果たします。大量のスパムURLによるクロールバジェットの流出を一刻も早く止血したい場面においては、404ではなく410を選択することが最も合理的かつ効果的な対策となります。

robots.txtによるブロックと410ステータスの使い分け

クロールバジェットの浪費を防ぐ方法として、「robots.txtファイルにDisallow（巡回拒否）を記述してクローラーのアクセス自体をブロックすればよいのではないか」と考える方もいるかもしれません。確かに、まだ一度もインデックスされておらず、外部からのスパムリンクも張られていない純粋な内部パラメータ等であれば、robots.txtによるブロックはクロールバジェットの節約に有効です。しかし、すでにハッキングやスパムによって検索結果にインデックスされてしまったURLや、外部のスパムサイトから大量に被リンクを受けているURLに対して、いきなりrobots.txtでブロックを行うことには大きな落とし穴があります。

なぜなら、robots.txtでクローラーのアクセスを禁止してしまうと、クローラーはそのURLへアクセスすること自体をやめてしまうため、サーバー側で設定した「410（消滅）」や「noindex」といったレスポンスを確認することすらできなくなるためです。その結果、すでにインデックスされてしまっているスパムページが検索結果からいつまでも消えずに残り続けたり、外部リンクの存在だけを根拠にして「robots.txtによりブロックされましたがインデックスに登録しました」という状態で検索結果に不気味なURLだけが表示され続けたりする事態を招きます。

したがって、スパムURLに対する正しい対処の順序としては、まずrobots.txtでのブロックは行わずにクローラーを一度アクセスさせ、サーバーから明確に「410（Gone）」を返却して「このURLは完全に消滅した」とクローラーに直接認識させることが先決です。410を返してインデックスからの完全な消去とクロール頻度の鎮静化を確認した上で、それでもなお外部からの新規パラメータ生成が止まらないような場合に限り、補助的な手段としてrobots.txtの制御を検討するという手順を踏むことが重要です。

410ステータスを活用して素早くクロール対象から外す手順

スパムURLに対して410ステータスコードを返す際、絶対に守らなければならない技術的な鉄則があります。それは「WordPressのプラグインやPHPのプログラム（functions.phpなど）を使って410を返すのではなく、必ず前段のWebサーバー層（Apacheであれば.htaccess、Nginxであれば設定ファイル）でリクエストを捕捉し、即座に410を返す」という点です。

.htaccessを用いた特定ディレクトリや拡張子への410応答設定

前述の通り、WordPressのプログラムが起動してから410ステータスを返すような作りにしてしまうと、クローラーがスパムURLへアクセスするたびにPHPとデータベースが稼働してしまい、サーバー負荷の軽減（クロールレート制限の維持）という目的が達成できません。.htaccessの先頭（WordPressの標準記述である「# BEGIN WordPress」よりも上の行）に条件を記述することで、PHPを一切起動させず、Webサーバーのメモリ上だけで瞬時に410を返却することができます。

たとえば、uploadディレクトリ配下に存在しない「.m3u8」ファイルや「.ts」ファイルなどの動画関連スパムURLが大量発生している場合、.htaccessの上部に以下のようなRewriteRule（書き換えルール）を記述して410を返します。

RewriteEngine On
RewriteRule ^wp-content/uploads/.*.(m3u8|ts)$ - [G,L,NC]

この記述において重要な意味を持つのが、行末の角括弧内に指定している「G」というフラグです。Apacheのmod_rewriteモジュールにおいて、「G」は「Gone（410ステータスコードを返す）」を意味し、「L」は「Last（このルールが適用されたら、それ以降のWordPress本体へのルーティング処理を一切行わずにここで処理を終了する）」を意味します。「NC」は大文字と小文字を区別しない指定です。

このわずか数行の記述を「# BEGIN WordPress」よりも前に配置しておくだけで、クローラーが「/wp-content/uploads/」配下のいかなる階層の「.m3u8」ファイルへアクセスしてきても、サーバーはWordPressやデータベースに一切触れることなく、わずか数ミリ秒という超高速で410（Gone）を突き返すことができます。同様に、ハッキングの残骸やスパムによって特定の存在しないディレクトリ（たとえば「/shop-spam/」や「/casino-page/」など）へのアクセスが集中している場合も、正規表現を用いて以下のように一括で410処理を行うことが可能です。

RewriteEngine On
RewriteRule ^(shop-spam|casino-page)/ - [G,L]

このように、スパム特有のディレクトリ名やファイル名の規則性（パターン）を見つけ出し、正規表現を使って網羅的に「G」フラグで遮断することが、数万件のスパムURLを最も効率よく処理する手法です。

不正なクエリパラメータやサイト内検索スパムへの410制御

URLのパス部分ではなく、末尾に「?s=スパム文字列」や「?p=9999999」といった不正なクエリパラメータが付与されるタイプのネガティブSEOに対しても、.htaccessの「RewriteCond（条件分岐）」を組み合わせることで、Webサーバー層での410遮断が可能です。

ApacheのRewriteRule自体はURLのパス部分のみを判定対象とするため、クエリパラメータ（「?」以降の文字列）を判定したい場合は、直前に「RewriteCond %{QUERY_STRING}」という条件行を追加します。たとえば、事業用のコーポレートサイトや専門ブログにおいて、一般ユーザー向けのサイト内検索機能自体をそもそも使用していない（検索窓を設置していない）にもかかわらず、外部から「?s=」を使ったサイト内検索スパム攻撃を受けている場合は、以下のように記述することでサイト内検索パラメータへのアクセスをすべて410で遮断できます。

RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)s= [NC]
RewriteRule ^ - [G,L]

もしホームページ内で正規のサイト内検索機能を使用している場合は、検索機能そのものを410にするのではなく、検索結果ページ（search.php）のHTMLヘッダーに確実に「noindex, follow（またはnoindex, nofollow）」を出力させてインデックス登録を防ぐとともに、スパム業者が送り込んでくる特有の文字列パターン（たとえば特定の外国語コードや、URL形式の文字列「http」を含む検索クエリなど）だけをRewriteCondの正規表現で指定して410を返すように設計します。その際、Google広告の計測パラメータ（gclidなど）や、管理画面で使用する正規のパラメータを誤って巻き込んで410にしてしまわないよう、事前にアクセスログやサーチコンソールのURL一覧を精査して条件式を絞り込む注意深さが求められます。

WordPressに処理を渡さずWebサーバー層で完結させる負荷軽減効果

ここまでの手順で特に強調しておきたいのは、Webサーバー層（.htaccess）で410を返す際には、さらに「ErrorDocument 410」の設定を極力シンプルにしておくことで、クロールバジェットの保護効果が最大化するという点です。

サーバーの設定によっては、410エラーが発生した際にもデザインされたHTMLファイルやスクリプトを読み込んで表示しようとする場合がありますが、スパムURLにアクセスしてきたクローラーに対して丁寧なデザインのエラー画面を見せる必要は全くありません。.htaccess内に「ErrorDocument 410 “Gone”」といった最小限のテキスト応答を設定しておくか、Apacheの標準の簡素な410レスポンスをそのまま返すようにしておけば、1回のリクエストあたりのデータ転送量はわずか数百バイト以下に抑えられます。

これまで1リクエストあたり数メガバイトのメモリとデータベース通信を消費し、0.5秒から1秒かけて動的404ページを返していた処理が、わずか数百バイト・数ミリ秒の410レスポンスに置き換わることで、サーバーの負荷は劇的に低下します。すると、Googleのクローラーは「このサーバーは非常に高速かつ軽快に応答を返している」と評価を改め、クロールレート制限の上限を引き上げます。そして、410を受け取ったスパムURL群が次々と巡回リストから消えていくため、拡大したクロールバジェットの枠がすべて正規の重要な記事やサービスページへと一気に振り向けられるようになります。

スパム対応の遅れが引き起こすインデックス評価の希釈

スパムによる異常なURL生成に気づきながら、適切な410対応を行わずに放置したり、誤った対処を行ったりした場合、ホームページのSEO評価は時間の経過とともに深刻なダメージを蓄積していきます。なぜ迅速な対応が必要なのか、その裏返しとなるリスクについても整理しておきます。

ソフト404判定の増加と正規ページのクロール後回し現象

スパム対応において最もやってはいけない誤った処置が、大量に発生した見知らぬURLやエラーページを、301リダイレクトを使ってすべてトップページへ強制転送してしまうことです。エラーを減らしたいという心理からこのような設定を行ってしまうケースが散見されますが、検索エンジンのクローラーは、元のURLと全く関連性のないトップページへ一律にリダイレクトされる挙動を検知すると、それらすべてを「ソフト404（実質的なエラーページであるにもかかわらず、不適切な転送や200ステータスを返している状態）」として判定します。

ソフト404と判定されたURLは、通常の404ページ以上にクローラーの解析リソースを無駄に消費するだけでなく、トップページ自体の評価シグナルに大量のノイズを混入させる結果となります。また、先述した通り、動的CMSが重い404ページを返し続けている状態も、時にはページの構造によってクローラーのレンダリング処理を長引かせ、正規ページのクロールをどんどん後回しにする原因となります。存在しないスパムURLには、リダイレクトでも曖昧な404でもなく、即座に410を返して関係を断ち切ることが鉄則です。

異常発生から対処完了までの期間とSEO評価回復のタイムラグ

もうひとつ理解しておくべき現実として、サーバー側で.htaccessを設定してスパムURLが410を返すように修正したとしても、その瞬間に検索エンジンのクロールバジェットが100パーセント元通りになるわけではないという点があります。

なぜなら、クローラーがそのスパムURLが「410（消滅）になった」という事実を知るためには、すでにクロールキュー（巡回待ちリスト）に溜まっている何万件ものスパムURLに対して、最低でもあと1回ずつは実際にアクセスして410のレスポンスを受け取る必要があるためです。つまり、スパムを放置していた期間が長ければ長いほど、検索エンジン側が抱え込んでいる未確認のスパムURLの母数が膨れ上がっており、410を設定した後にそれらを一巡して消化し切る（お掃除を完了する）までにも数週間から1ヶ月以上の期間を要することになります。

反対に、スパム攻撃が始まった直後のまだ数千件程度の段階で異常を察知し、素早く410による遮断設定を導入できれば、クローラーは数日のうちにすべてのスパムURLの消滅を確認し終え、正規ページのSEO評価やインデックス速度にほとんど悪影響を残すことなく事態を収束させることができます。日頃からのモニタリングと初動の速さが、事業用ホームページの収益と資産価値を守る上で大きな差を生みます。

サーチコンソールとサーバーログを活用した異常検知と防御体制の構築

スパムやネガティブSEOによるクロールバジェットの浪費を最小限に抑えるためには、問題が深刻化する前にいち早く兆候を捉える観測体制と、そもそも不正なページ生成を許さない堅牢なホームページ管理の仕組みを整えておくことが重要です。

最後に、実務で実践すべき異常検知の具体的な見方と防御体制について解説します。

Googleサーチコンソールによるスパム兆候の早期発見

クロールバジェットの異常を検知するための最も身近で強力なツールが、Googleサーチコンソールです。単に検索キーワードの表示回数やクリック数を見るだけでなく、クローラーの動きを映し出す管理レポートを定期的に点検する習慣を持つことで、スパム攻撃の初期段階を確実に捉えることができます。

ページレポートにおける未登録URLの急増パターンの分析

まず確認すべきは、左メニューの「インデックス作成」内にある「ページ」レポートです。ここには、インデックスに登録されているページ数と、登録されなかったページ（未登録）の数がグラフで表示されています。通常の運用であれば、未登録のページ数はホームページ内のアーカイブや意図的に除外したページの分だけ緩やかに推移しますが、スパム攻撃を受けると、ある日を境に未登録のグレーのグラフが垂直に近い角度で急増します。

その下の「ページがインデックスに登録されない理由」の一覧を確認し、「見つかりませんでした（404）」「クロール済み – インデックス未登録」「検出 – インデックス未登録」「代替ページ（適切な canonical タグあり）」などの項目の中で、急激に件数が増えているものをクリックします。そこに表示されるサンプルURLの一覧を観察し、「/wp-content/uploads/」配下の見知らぬ「.m3u8」ファイルや、「?s=」などのパラメータ付きURL、あるいは身に覚えのないディレクトリ名が含まれていないかをチェックします。ここで攻撃されているURLの規則性（共通するディレクトリ名、拡張子、パラメータ名）を正確に抜き出すことが、先ほどの.htaccessによる410設定を作成するための直接の設計図となります。

クロールの統計情報レポートで確認すべきリクエスト内訳の異常値

「ページ」レポートと合わせて必ず確認したいのが、「設定」メニューの内部にある「クロールの統計情報」レポートです。実は「ページ」レポートへの反映には数日間のタイムラグがあるほか、表示されるサンプルURLも最大1,000件までという制限がありますが、「クロールの統計情報」ではクローラーが実際にサーバーへアクセスしてきた生のリクエスト数の推移をよりリアルタイムに近い状態で確認できます。

このレポートを開いたら、まず「クロール リクエストの合計数」と「平均応答時間（ミリ秒）」の2つのグラフを見比べます。新しい記事を大量に公開したわけでもないのにリクエスト数が普段の数倍から十数倍に跳ね上がっており、同時に平均応答時間のグラフも高止まり（悪化）している場合は、スパムURLへの大量クロールによってサーバーが悲鳴を上げている典型的な症状です。

さらにその下にある「クロール リクエストの内訳」を見ることで、原因を深く特定できます。「レスポンス別」の項目で「見つかりませんでした（404）」や「サーバーエラー（5XX）」の割合が急増していないか、「ファイルの形式別」でHTMLや画像以外の「その他」や「不明なファイル形式」が不自然に増えていないか（m3u8スパムの場合はここに反応が出ることが多くあります）、そして「クロールの目的別」において、既存ページの更新確認である「更新」ではなく、未知のURLを探す「検出」の割合が全体の大部分を占めていないかを確認します。

もし「検出」のクロールが異常に膨れ上がっていれば、外部から大量のスパムリンクや架空URLが送り込まれている証拠です。そして、.htaccessで410の設定を導入した後は、この「レスポンス別」の内訳の中に新しく「除外（410）」という項目が出現し、410の件数消化とともに全体の無駄なリクエスト数と平均応答時間が正常な数値へと落ち着いていく過程をデータで明確に検証することができます。

生ログ（アクセスログ）解析によるクローラーの正確な追跡

サーチコンソールは非常に優れたツールですが、対象となっているのはあくまでGoogleのクローラー（Googlebot）によるアクセスのみであり、またURLのリストも最大1,000件のサンプルしか抽出できません。数万件規模の複雑なスパム攻撃の全容を漏れなく把握し、1つの取りこぼしもなく410設定や遮断ルールを作成するためには、レンタルサーバーのコントロールパネル等からダウンロードできるWebサーバーの「生ログ（アクセスログ）」を直接確認する手法が極めて有効です。

サーチコンソールには表示されない微細なクロール浪費の特定

サーバーのアクセスログには、人間やクローラーを問わず、ホームページに対して行われたすべての通信の記録（アクセス日時、接続元IPアドレス、リクエストされたURLとパラメータ、返却したHTTPステータスコード、データ転送量、リファラ、ユーザーエージェント）が1行ずつ克明に記録されています。

このアクセスログをテキストエディタや表計算ソフト、あるいはコマンドラインツール等で開き、ユーザーエージェントに「Googlebot」を含む行だけを抽出して、ステータスコードが「404」になっているURLの一覧を集計します。すると、サーチコンソールの画面上では隠れて見えなかったスパムURLのすべてのバリエーションや、どのURLに対して1日に何回アクセスが来ているのかという正確な頻度、さらには外部のどのスパムサイト（リファラ）からクローラーが誘導されてきているのかまでが手に取るように判明します。

この生ログのデータをもとに正規表現を組み立てて.htaccessの410ルールに反映させ、翌日のアクセスログで該当URLへのリクエストが確実にステータスコード「410」として処理され、データ転送量が最小化されていることを確認する作業こそが、技術的に最も確実で抜け漏れのないクロールバジェット防衛策です。

正規のGooglebotと偽装ボットの見極めとアクセス遮断

また、アクセスログを解析すると、ユーザーエージェント名には「Googlebot」と名乗っているにもかかわらず、接続元のIPアドレスを調べるとGoogleの公式サーバーではなく、海外のデータセンターや踏み台にされた一般サーバーからアクセスしてきている「偽装ボット（なりすましクローラー）」が大量に紛れ込んでいることがよくあります。あるいは、検索エンジンとは無関係な悪質スクレイピングボットや脆弱性探索ボットが、1秒間に何十回もの猛烈なスピードで架空URLへアクセスし、サーバーのCPUとメモリを食い潰しているケースも少なくありません。

これらの悪質な偽装ボットや攻撃ボットは、検索エンジンのインデックスとは無関係ですが、サーバーの応答速度を低下させることで結果的に本物のGooglebotの「クロールレート制限」を悪化させ、間接的にクロールバジェットを奪う原因となります。正規のGooglebotであるかどうかは、IPアドレスの逆引き（ホスト名が「googlebot.com」または「google.com」で終わるか）によって判別できます。本物の検索エンジンクローラーではない悪質なボット群による大量アクセスに対しては、410を返すまでもなく、サーバーのWAF（Webアプリケーションファイアウォール）機能や.htaccessのIP制限・ユーザーエージェント制限を用いて「403（Forbidden：アクセス禁止）」で通信自体を入り口で遮断し、サーバーの計算資源を守ることが大切です。

事業用ホームページの資産価値を守る継続的なセキュリティとSEO管理

クロールバジェットを脅かすスパム問題への対処は、一度.htaccessを設定して410を返せば永遠に安心という性質のものではありません。攻撃者の手口や狙われるディレクトリ構造は時代とともに変化するため、ホームページを長期的な事業資産として運用していく上では、予防と早期発見の両輪を仕組み化しておく必要があります。

CMSおよびプラグインの脆弱性管理とディレクトリ権限の最適化

まず大前提として、自社サーバーの内部が改ざんされてスパムページを物理的に生成されてしまう「マルウェア感染型」の被害を絶対に起こさないためのセキュリティ管理が必要です。WordPress本体やテーマ、プラグインを常に最新の状態に保つことはもちろん、使用していない不要なプラグインやテーマは停止するだけでなくサーバーから完全に削除しておくことが求められます。

さらに、先述したuploadディレクトリ（/wp-content/uploads/）などは、本来であれば画像やPDFなどの静的ファイルだけを保存する場所であり、そのディレクトリ内でPHPなどのプログラムが実行される必要は一切ありません。万が一、脆弱性を突かれてuploadディレクトリ内に不正なPHPファイルをアップロードされたとしても、それが起動してスパムページを生成することができないよう、uploadディレクトリ配下に設置した個別の.htaccess等でPHPファイルの実行自体を拒否（403エラーまたは410エラー）する設定を施しておくことが、ホームページ制作および管理における高度な防御策となります。

クロールバジェットの健全性を維持する定期監査の仕組み化

その上で、外部から勝手にリンクを張られたりパラメータを付与されたりする「外部誘導型」のスパムやネガティブSEOに対しては、これまで解説してきた通り、サーチコンソールの「ページ」レポートおよび「クロールの統計情報」の定期的な監査によって対抗します。月に一度、あるいは数週間に一度は必ずクローラーの統計情報を確認し、不自然な404エラーの急増や、未知のURLへの「検出」クロールの偏りが発生していないかを点検します。

もし異常なスパムURL群を発見した際には、「実在しないから404のままでいい」と放置するのではなく、クローラーが何度も再確認に訪れてバジェットを浪費する404の特性を理解し、Webサーバー層（.htaccessなど）で即座に「410（Gone）」を返してクロール対象から素早く切り離すこと。この一連の迅速な対処を徹底することで、外部からのいかなるノイズにも揺らぐことなく、自社のホームページが持つ本来の専門性と情報純度を検索エンジンへ正確に伝え続け、安定したSEOの成果を維持していくことができます。

クロールバジェット SEO・ホームページ運用における全体像

SEO（検索エンジン最適化）対策と費用・料金

ホームページの更新・修正料金 価格表