WordPressのクローキング・SEOスパム対策｜不正URLの確認と復旧方法

WordPressサイトを運営していると、ある日突然、Googleの検索結果に見覚えのないページが大量に表示されることがあります。

実際に運営しているWordPressサイトでも、作成した覚えのない海外向けの商品ページがGoogleにインデックスされ、大量の不正URLが検索結果に登録される問題が発生しました。サイトを直接開いても不正な商品ページは表示されず、WordPressの管理画面にも該当する投稿は見当たりません。

こうした現象は、WordPressを狙ったSEOスパムや、検索エンジンと一般ユーザーに異なるコンテンツを表示する「クローキング（Cloaking）」と呼ばれる手法で発生することがあります。

今回は、実際に経験した不正URLの大量登録と復旧調査をもとに、WordPressのSEOスパム・クローキングの仕組み、確認方法、復旧手順、再発防止策について詳しく紹介します。また、レンタルサーバーのXserver（エックスサーバー）には、表示不具合や不正アクセスによって改ざんされたWordPressを修復できる「WordPressリカバリー」という便利な機能も用意されていますので、こちらについても解説します。

WordPressのクローキングとは？

クローキング（Cloaking）とは、Webサイトにアクセスしてきた相手に応じて、異なるWebページやコンテンツを表示する仕組みです。例えば、一般ユーザーがアクセスすると通常のページや404エラーを表示する一方、Googlebotなどの検索エンジンには、別の商品ページや検索キーワードを大量に含むコンテンツを表示することがあります。特に、検索エンジンにだけSEOスパム用のページを表示し、一般ユーザーにはその存在を隠すような動作は、悪質なクローキングの典型例です。

Googlebotにだけ異なるコンテンツを返す仕組み

Webサーバーは、アクセス時に送信されるUser-Agentなどの情報を参照できます。User-Agentにはブラウザやクローラーの種類を示す文字列が含まれており、Googlebotなどのアクセスを判別する処理に利用されることがあります。

不正なPHPコードが設置された場合、アクセス元の情報を判定して、検索エンジンには偽の商品ページを返し、一般ユーザーには正常なページや404エラーを返すといった処理が可能になります。さらに高度な手法では、User-Agentだけでなく、アクセス元IPアドレス、参照元、Cookieなどを組み合わせて表示内容を切り替えることもあります。そのため、通常のブラウザで問題のURLを開いて404エラーが表示されたとしても、それだけでクローキングが行われていないと断定することはできません。

一般ユーザーには404、Googlebotには200を返すケース

クローキングを理解するうえで分かりやすいのが、アクセス元によってHTTPステータスコードが異なるケースです。例えば、同じURLに対して以下のような応答が発生する場合があります。

• 一般ユーザー：HTTP 404を返し、ページが存在しないように表示する。
• Googlebot：HTTP 200を返し、不正な商品ページを表示する。

このような動作は、検索エンジンにだけ偽の商品ページを認識させ、一般ユーザーやサイト管理者から不正コンテンツの存在を隠すために利用されることがあります。検索エンジンが不正な商品ページを取得してインデックスした後も、管理者が通常のブラウザで同じURLを確認すると404が表示されるため、問題の発見が遅れる可能性があります。

ただし、HTTPステータスコードが異なることだけで悪質なクローキングと断定することはできません。サーバーの一時的な不具合やアクセス制限、キャッシュなどが原因で応答が異なることもあります。

両方ともHTTP 200でもクローキングになる

クローキングでは、必ずしもHTTPステータスコードが異なるとは限りません。例えば、一般ユーザーとGooglebotの両方にHTTP 200を返していても、実際に表示されるHTMLが異なる場合があります。

• 一般ユーザー：HTTP 200で通常のWebページを表示する。
• Googlebot：HTTP 200で検索キーワードを大量に含む不正な商品ページを表示する。

このように、検索エンジンを欺く目的で異なるコンテンツを配信している場合、HTTPステータスコードが同じでもクローキングに該当する可能性があります。そのため、クローキングの調査ではHTTPステータスコードだけでなく、実際にどのようなHTMLやコンテンツが返されているかを確認することも重要です。

なお、モバイル端末に合わせたレイアウト変更や、利用者の言語設定に応じた正常なコンテンツの切り替えまで、すべてクローキングと呼ぶわけではありません。問題となるのは、検索エンジンを欺く目的で、検索エンジンと一般ユーザーに実質的に異なるコンテンツを表示する行為です。

Googlebotへの応答が404ならクローキングは解消している？

不正URLに対してGooglebotにもHTTP 404が返されていれば、少なくともそのアクセスでは不正ページが正常に配信されていないことを示しています。今回の調査でも、過去に不正商品ページとして検索結果に登録されたURLに対して、Googlebotを名乗るアクセスがHTTP 404を受け取っていることを確認できました。

これは復旧状況を判断するうえで重要な結果ですが、調査時点で404を返しているからといって、過去にクローキングが行われていなかったことの証明にはなりません。不正コードが削除される前は検索エンジンに偽ページを返していて、現在は404に変わっている可能性もあります。

また、GooglebotのUser-Agentは偽装できるため、実際のGooglebotによるアクセスか判断するには、アクセス元IPアドレスの検証も必要になります。クローキングの調査では、一般ユーザーとGooglebotの両方に対するHTTP応答に加え、実際に返されるコンテンツを比較することが重要です。

Google検索に大量の不正URLが登録されるSEOスパム

今回経験した問題では、WordPressで作成した覚えのない海外向けの商品ページがGoogleの検索結果に現れました。URLには商品名を連想させる外国語の文字列が含まれ、通常のサイト運営では生成されない形式のページが大量に登録されていました。しかし、WordPressの投稿一覧や固定ページには該当するコンテンツが存在せず、実際にアクセスしても404エラーになる状態でした。

WordPressに投稿が存在しなくても不正ページは生成できる

WordPressでページを表示する際は、必ずしもデータベースに投稿が保存されている必要はありません。PHPの処理やリライトルールを悪用すると、実際には存在しないURLに対して、外部から取得した内容や動的に生成したHTMLを返すことができます。そのため、管理画面の投稿一覧に不正な商品ページが存在しなくても、検索エンジンに不正コンテンツが配信されていた可能性はあります。

また、不正URLが大量にインデックスされたという事実だけでは、クローキングの使用までは確定できません。検索エンジンが過去に不正コンテンツを取得した後、問題のコードが削除され、現在は404を返しているというケースも考えられます。

不正URLが削除後も検索結果に残る理由

不正なファイルやコードを削除しても、Googleの検索結果から該当URLが即座に消えるわけではありません。検索エンジンが過去に取得した情報を保持しているため、すでに存在しなくなったページがしばらく検索結果に表示されることがあります。

Google Search Consoleにも大量の404エラーが記録される場合がありますが、これは必ずしも現在も不正ページが生成されていることを意味しません。重要なのは、現在そのURLにアクセスした際、サーバーがどのような応答を返しているかという点です。

不正な商品ページから詐欺通販サイトへ誘導される危険性

SEOスパムやクローキングは、Webサイトの運営者だけでなく、Googleなどの検索エンジンを利用している一般ユーザーにも被害が及ぶ可能性があります。特に注意したいのが、検索結果には正規のWebサイトのURLが表示されているにもかかわらず、アクセスすると別の通販サイトの商品ページへ転送されるケースです。

実際に、Google検索の結果からアクセスすると、検索結果に表示されていたドメインとは異なる通販サイトへ転送される現象を確認したことがあります。一方で、検索結果に表示されているURLをブラウザに直接入力すると、404エラーになってしまう場合もありました。これは、検索結果からのアクセスと通常のアクセスで処理を切り替える、不正なリダイレクトなどによって発生する可能性があります。

正規サイトのURLが詐欺通販サイトへの誘導に悪用される

例えば、Googleで商品名を検索した際に、ホテルや企業などの正規のWebサイトのURLが表示されている場合があります。しかし、その検索結果をクリックすると、まったく関係のない通販サイトの商品ページへ転送されることがあります。これは、正規のWebサイトが不正アクセスによって改ざんされ、外部の不審な通販サイトへ誘導するために悪用されている可能性がある現象です。

そのため、検索結果に表示されているドメインが実在する企業や正規のWebサイトだからといって、必ずしも安全な商品ページへ移動できるとは限りません。また、転送元となった正規サイトの運営者自身が、詐欺行為に関与しているという意味でもありません。第三者による不正アクセスなどによって、Webサイトの所有者が知らないうちに不正な誘導に利用されている可能性もあります。

実際に確認した詐欺が疑われる通販サイトの商品ページ

以前、Google検索に表示された不審な通販サイトについて調査した際にも、検索結果のURLと実際に表示される商品ページのURLが異なる事例を確認しました。転送先の通販サイトでは、ほかのWebサイトから取得したと思われる商品画像が使用されていたり、販売事業者の情報や支払い方法に不自然な点が見られたりしました。また、正規のWebサイトで公開されている画像や記事タイトルが、無関係な通販サイトの検索結果に表示されているケースも確認しています。

こうした事例については、実際の検索結果や不審な商品ページの画像を交えながら、別の記事で詳しく紹介しています。

注意喚起！騙されないで！詐欺通販サイトや偽ECサイトを簡単に見分ける方法！

こちらの記事では、検索結果から不審な通販サイトへ転送される仕組みのほか、商品画像の無断使用が疑われる事例、会社概要や販売事業者情報の確認方法、銀行振込先の不自然な点などについて紹介しています。なお、こうした特徴が一つ見つかっただけで詐欺サイトと断定できるわけではありません。複数の不自然な点を確認し、販売事業者や購入先の信頼性を総合的に判断することが大切です。

Google検索の上位に表示されていても安全とは限らない

Google検索に表示されているからといって、その通販サイトが安全であるとは限りません。検索結果の上位に表示されている場合でも、不正なSEO対策によって検索順位が操作されていたり、第三者のWebサイトが不正な誘導に悪用されていたりする可能性があります。

特に注意したいのは、検索結果に表示されていたURLと、実際に商品ページを開いた後のアドレスバーに表示されているURLが異なる場合です。もちろん、正規の通販サイトでも決済サービスや別ドメインの商品ページへ移動することはありますので、URLが変わったという理由だけで詐欺と判断することはできません。

しかし、商品を販売している事業者と転送元のWebサイトに関連性が確認できない場合や、相場と比較して極端に安い価格で販売されている場合、運営会社や連絡先に不自然な点がある場合などは、購入前に詳しく確認することをおすすめします。また、HTTPSに対応していることや、ドメインが.comや.jpであることも、安全性を保証するものではありません。

偽商品ページにアクセスしただけでウイルスに感染する？

Google検索などから不審な商品ページにアクセスしてしまった場合、ウイルス感染や個人情報の流出を心配する方もいると思います。基本的には、偽商品ページや詐欺が疑われる通販サイトを閲覧しただけで、直ちに端末がウイルスに感染したり、保存されている個人情報が盗まれたりするわけではありません。現在のブラウザやOSにはさまざまなセキュリティ対策が組み込まれており、最新の状態に更新されていれば、一般的なWebページの閲覧だけで端末が侵害される危険性は比較的低いと考えられます。

ただし、ブラウザやOSの脆弱性を悪用して、Webページを開いただけで不正なプログラムを実行させる攻撃も存在するため、絶対に安全とは言い切れません。また、ページを閲覧した際には、IPアドレスやブラウザ情報などがアクセス先に記録される場合があります。

特に注意したいのは、偽通販サイトで氏名や住所、電話番号、クレジットカード情報などを入力してしまうことや、不審なファイルをダウンロードして実行してしまうことです。このほか、偽のセキュリティ警告を表示してアプリのインストールを促したり、ブラウザの通知を許可させたりする手法にも注意が必要です。

もし不審な商品ページを開いてしまった場合でも、個人情報を入力したり、不審なファイルを実行したりしていなければ、過度に心配する必要はありません。不審な通知の許可やアプリのインストールを求められても応じず、ページを閉じるようにしましょう。また、不安が残る場合は、ブラウザやOSを最新の状態に更新し、端末のセキュリティ機能でスキャンを実施することも有効です。

一方、クレジットカード情報やログイン情報を入力してしまった場合は、カード会社や利用しているサービスに速やかに連絡し、必要な手続きを行うことが重要です。偽商品ページを開いてしまったこと自体よりも、その後に個人情報を入力したり、不審な操作を行ったりしないことが大切です。

SEOスパムは消費者の詐欺被害にもつながる可能性がある

WordPressのSEOスパムというと、検索順位の低下や不正URLの大量登録など、Webサイトの運営者側の問題として考えがちです。しかし、不正な商品ページが検索結果に表示され、それをクリックした利用者が詐欺通販サイトへ誘導されれば、金銭的な被害につながる可能性もあります。

さらに、正規サイトのURLが不正な誘導に悪用されることで、そのWebサイトを運営している企業や個人の信用にも影響を与える恐れがあります。このため、WordPressの不正アクセス対策は、サイト運営者自身を守るだけでなく、検索エンジンを通じてアクセスする一般ユーザーを保護するうえでも重要だと考えています。

WordPressの不正アクセスを発見した際の確認方法

今回の調査では、Google Search Console、Webサーバーのアクセスログ、WordPressのセキュリティスキャン、データベースの内容を確認しました。それぞれ調べられる範囲が異なるため、一つの結果だけで安全性を判断するのではなく、複数の情報を照合することが重要です。

Google Search Consoleで不正URLを確認する

まず確認したいのが、Google Search Consoleの「ページのインデックス登録」です。見覚えのないURLや、通常のサイト構成では生成されないページが大量に検出されていないか確認します。特に、外国語の商品名、意味のない文字列、サイトで使用していないディレクトリなどが大量に現れた場合は注意が必要です。

ただし、404エラーの件数が多いだけで、不正アクセスを受けているとは限りません。外部サイトからの誤ったリンクや、クローラーによる存在しないURLへのアクセスでも404は発生します。

アクセスログでHTTPステータスコードを確認する

Webサーバーのアクセスログには、アクセス日時、要求されたURL、HTTPステータスコード、User-Agentなどが記録されています。不正URLへのアクセスを抽出することで、現在どのような応答を返しているかを確認できます。主なHTTPステータスコードは以下の通りです。

• 200：リクエストが正常に処理された
• 301：別のURLへの恒久的なリダイレクト
• 403：アクセスが拒否された
• 404：要求されたリソースが見つからない
• 429：短時間のアクセス集中などにより制限された
• 500：サーバー内部でエラーが発生した

特に、不正URLへのアクセスに対して200が返されている場合は、実際にどのようなコンテンツが配信されているのか詳しく確認する必要があります。一方、404が返されている場合は、少なくともそのリクエストでは不正ページが正常に配信されていないことを示しています。ただし、HTTP 200が必ず不正ページの配信を意味するわけではなく、HTTP 301も最終的な転送先の応答を確認する必要があります。

Googlebotと一般ユーザーの応答を比較する

クローキングの調査では、同じ不正URLに対して、Googlebotと一般ユーザーがそれぞれどのような応答を受け取っているかを比較します。例えば、一般ユーザーへのHTTP 404とGooglebotへのHTTP 200が同じ時間帯に確認された場合は、コンテンツの出し分けが行われていないか調べる価値があります。

ただし、アクセスログには通常、レスポンス本文のHTMLそのものは保存されていません。また、リクエストの日時やキャッシュの状態によって応答が変化する場合もあるため、異なるステータスコードだけでクローキングを断定することはできません。

GooglebotのUser-Agentを指定して応答を確認する方法もありますが、User-AgentだけでなくIPアドレスなどを判定する不正コードには対応できない場合があります。検索エンジン向けの応答を詳しく調べる場合は、アクセスログの分析と実際のコンテンツ確認を組み合わせることが重要です。

WordPressにバックドアが残っていないか確認する

SEOスパムを発生させる不正コードは、WordPressの投稿データだけでなく、PHPファイルやプラグイン、テーマなどに埋め込まれている可能性があります。不正なURLが404を返すようになった後も、再侵入に利用できるバックドアが残っていないか確認することが重要です。

uploadsフォルダ内のPHPファイル

WordPressの「wp-content/uploads」は、通常、画像や動画などのメディアファイルを保存するディレクトリです。この場所に見覚えのないPHPファイルが存在する場合は、内容を確認する必要があります。ただし、プラグインが正規の用途でファイルを作成している場合もあるため、PHPファイルが存在するという理由だけで削除するのは避けます。

mu-pluginsと通常のプラグイン

「wp-content/mu-plugins」は、WordPressが自動的に読み込むMust-Useプラグインのディレクトリです。通常のプラグインとは管理方法が異なり、管理画面の一般的なプラグイン一覧から停止することはできません。そのため、見覚えのないPHPファイルが設置されていないか確認する価値があります。通常の「wp-content/plugins」についても、使用していないプラグインや不明なファイルが残っていないか確認します。

テーマとWordPress本体の改ざん

WordPressのテーマでは、functions.phpなどに不正な処理が追加されるケースがあります。また、WordPress本体のファイルが改ざんされる可能性もあるため、正規の配布ファイルと比較する整合性チェックが役立ちます。独自テーマやカスタマイズ済みファイルについては、単純な差分だけで不正と判断できないため、更新履歴や変更内容も確認します。

PHPの自動読み込み設定を確認する

PHPには「auto_prepend_file」という設定があり、指定されたPHPファイルを通常の処理より前に読み込むことができます。この機能は正規のセキュリティ対策などにも利用されますが、不正なPHPファイルの自動実行に悪用される可能性もあります。

そのため、サーバーのPHP設定や.user.ini、.htaccessなどを確認し、見覚えのないファイルが指定されていないか調べます。正規のセキュリティ機能が利用している場合もあるため、内容を確認せずに設定を削除しないことが重要です。

WordPressのデータベースに不正コードが残っていないか調べる

WordPressのデータベースには、投稿や固定ページだけでなく、プラグインの設定やウィジェット情報なども保存されています。今回の調査では、設定情報が保存されるテーブルを中心に、不審なコードや不正URLに関連する文字列が存在しないか確認しました。例えば、PHPコードの難読化や動的実行に関連する関数名、Googlebotを判別する文字列、不正URLに含まれる特徴的な文字列などが調査対象になります。

ただし、これらの文字列は正常なプラグインでも使用される場合があり、見つかっただけで不正コードとは判断できません。逆に、検索結果が0件であっても、別のテーブルやファイルに不正コードが存在する可能性は残ります。

見覚えのないデータがすべて不正とは限らない

調査中には、WordPressのデータベースに大量の海外サービス名やレビューサイト名が登録されていることもありました。一見すると不正な商品ページに関連するデータのように見えますが、構造化データやレビュー機能を持つプラグインが、対応サービスの一覧を登録している可能性があります。

このようなデータは、登録内容の規則性や分類、使用しているプラグインとの関連を確認する必要があります。見覚えがないという理由だけで削除すると、正常な機能に影響する恐れがあります。

XserverのWordPressリカバリーで表示不具合や不正アクセスから復旧する方法

WordPressが不正アクセスを受けたり、プラグインの更新によって正常に表示されなくなった場合、自力で原因を特定して復旧するのは簡単ではありません。特に、WordPressの管理画面にログインできない状態では、プラグインの無効化や設定変更も難しくなります。

こうしたトラブルに対応するため、レンタルサーバーのXserver（エックスサーバー）では、独自の「WordPressリカバリー」機能を提供しています。WordPressリカバリーは、Xserverのサーバーパネルから実行できる復旧機能で、プラグインの更新による表示不具合だけでなく、不正アクセスによって改ざんされたファイルの除去や、WordPress本体のリセットにも対応しています。

WordPressリカバリーで対応できる5種類のトラブル

XserverのWordPressリカバリーでは、主に次の5種類の復旧・リセット機能が用意されています。

• 正しく表示されなくなったWordPressの復旧
• 不正アクセスを受けたWordPressの復旧
• ログインできなくなったWordPressの復旧
• ログインパスワードのリセット
• WordPress本体のリセット

表示不具合と不正アクセスでは問題の原因や復旧方法が異なるため、発生しているトラブルに合わせて処理を選択できます。

正しく表示されなくなったWordPressの復旧

WordPress本体やプラグインの更新後にサイトが表示されなくなったり、管理画面でエラーが発生したりした場合に利用できる機能です。例えば、プラグイン同士の競合、PHPエラー、テーマの不具合などによってサイトが正常に表示されなくなることがあります。

通常であれば、FTPソフトやファイルマネージャーを利用してプラグインを停止したり、エラーログを調べたりする必要があります。WordPressリカバリーでは、このような表示不具合に対して補正処理を実行できます。

なお、WordPressの設定ファイルに登録されたデータベース名に問題がある場合は、復旧処理の途中でデータベースの選択画面が表示されることもあります。ただし、すべての表示不具合を解消できるわけではないため、処理の完了後にはサイトが正常に動作するか確認する必要があります。

不正アクセスを受けたWordPressの復旧

SEOスパムやクローキングなどの原因となる不正ファイルの設置、WordPress本体の改ざんが疑われる場合には、「不正アクセスを受けたWordPressの復旧」を利用できます。この機能は、不正ファイルを除去し、WordPress本体を正常な状態へ戻すことを目的としています。

WordPressを完全に削除して最初から作り直す方法とは異なり、既存のサイトデータを引き継ぎながら補正処理を試みられる点が特徴です。Xserverの案内では、投稿記事などのデータベース情報やメディアファイル、インストールされているプラグインやテーマを引き継ぎ、対象のWordPressに対して補正処理を行うと説明されています。そのため、サイトを一から構築し直す負担を軽減できる便利な復旧手段です。

ただし、引き継ぐデータやカスタマイズ部分に不正な処理が残っている場合、復旧機能だけでは問題を解消できない可能性があります。また、不正アクセスによってテーマやプラグインの一部ファイルが削除されていた場合などには、復旧後に再インストールや設定の見直しが必要になることもあります。そのため、WordPressリカバリーを実行しただけで完全なマルウェア駆除やサイトの復旧が保証されるわけではありません。

WordPressの管理画面にログインできなくても復旧できる

WordPressリカバリーの大きな特徴は、WordPressの管理画面からではなく、Xserverのサーバーパネルから操作できることです。例えば、プラグインの不具合によって管理画面が開けなくなったり、PHPエラーでログイン画面すら表示されなくなったりした場合でも、サーバーパネルにアクセスできれば復旧処理を試すことができます。

また、「ログインできなくなったWordPressの復旧」と「ログインパスワードのリセット」は別々の機能として用意されています。前者はログインできなくなった原因に対する補正処理で、後者はパスワードを忘れてしまった場合などに使用する機能です。

WordPress本体をリセットする機能も利用できる

表示不具合が解消されない場合や、不正アクセスによる改ざんが深刻な場合には、WordPress本体をリセットする機能も用意されています。この機能では、データベースやメディアデータ、テーマ、プラグインなど、引き継ぎたいデータを選択してからリセット処理を実行できます。

ただし、引き継がないデータは失われる可能性があるため、リセットする前には選択内容を慎重に確認する必要があります。特に、独自のカスタマイズを加えているテーマやプラグインなどについては、復旧後に再設定が必要になる場合も考えられます。

XserverのWordPressリカバリーを実行する手順

WordPressリカバリーは、Xserverのサーバーパネルから実行します。基本的な手順は以下の通りです。

1. Xserverのサーバーパネルにログインする。
2. 「WordPressリカバリー」を開く。
3. 復旧したいWordPressを選択し、「復旧」または「復旧に進む」をクリックする。
4. 表示不具合や不正アクセスなど、発生しているトラブルに対応する項目を選択する。
5. 注意事項を確認し、内容に同意して復旧処理を開始する。
6. 処理の進行状況を確認し、完了画面が表示されたら復旧結果を確認する。

Xserverには新旧のサーバーパネルがあるため、表示されるボタン名や画面構成が異なる場合があります。不正アクセスを受けたWordPressの復旧では、処理完了後にログインIDと新しいパスワードが表示されるため、必ず確認しておきます。復旧後には、管理画面へのログイン、記事の表示、画像の読み込み、プラグインの動作などを確認しましょう。

詳しい操作方法については、XserverのWordPressリカバリー操作マニュアルで確認できます。

復旧処理の前にはバックアップが作成される

XserverのWordPressリカバリーでは、補正処理の実行前にバックアップデータが作成される仕組みになっています。ただし、このバックアップは復旧処理直前の状態を保存するものであり、すでに改ざんされていたファイルやデータが含まれる可能性があります。

不正アクセスを受ける前の正常なバックアップが残っている場合は、そちらも保管しておくことが重要です。また、既存のデータや設定を確実に残しておきたい場合は、WordPressリカバリーの実行前に独立したバックアップを取得しておくと、復旧方法の選択肢を増やせます。

WordPressリカバリーを利用できないケース

Xserverの案内では、以下の環境はWordPressリカバリーの対象外とされています。

• WordPress 5.0より前のバージョンを使用している場合
• WordPressのマルチサイト機能を使用している場合

また、データサイズやファイル数、サーバーの負荷状況によって処理に時間がかかる場合があります。復旧機能を実行しても問題が解決しない場合は、ファイルの改ざん状況やデータベースを個別に調査する必要があります。

WordPressリカバリー実行後もセキュリティ確認は必要

XserverのWordPressリカバリーは、不正アクセスを受けたWordPressの復旧に役立つ機能ですが、実行しただけでサイト全体の安全性が保証されるわけではありません。特に、不正アクセスの原因となった脆弱性や流出したログイン情報がそのまま残っている場合、復旧後に再び被害を受ける可能性があります。そのため、復旧後にはWordPress本体やプラグインの更新、認証情報の見直し、不審なファイルの確認、セキュリティスキャンなどを実施することが重要です。

復旧後も脆弱性を探す不審なアクセスや攻撃は続いている

WordPressの不正アクセスを経験して強く感じたのは、不正なファイルを削除してサイトを復旧させても、外部からの不審なアクセスがなくなるわけではないということです。復旧後もアクセスログの調査を継続していますが、存在しないPHPファイルへのアクセス、WordPressのログイン画面に対するリクエスト、サーバーの設定ファイルを探すようなアクセスなどが繰り返し確認されています。

これらは、公開されたWebサイトの脆弱性や設定不備を調べる、自動化されたスキャンや攻撃試行の可能性があります。もちろん、存在しないファイルへのアクセスがすべて攻撃とは限りませんし、不審なリクエストが記録されたというだけで侵入に成功したことを意味するわけでもありません。しかし、サイトの復旧後も脆弱性を探すようなアクセスが継続していることは、Webサイトが常に外部からの調査や攻撃の対象になり得ることを示しています。

2026年も国内企業を狙った不正アクセスが相次いでいる

2026年には国内企業や組織に対する不正アクセスが相次いで発生しており、セキュリティ対策の重要性が改めて注目されています。JPCERT/CC（一般社団法人JPCERTコーディネーションセンター）は、2026年10月8日に「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」を公開し、10月23日にも内容を更新しています。

この注意喚起では、国内組織で個人情報などの漏えい被害が相次いでいることに加え、複数のソフトウェアに存在する既知の脆弱性を探索する攻撃や、設定ファイル・バックアップファイルの取得を試みる攻撃などについて報告しています。また、AIを利用した侵入テスト用の基盤を悪用し、公開されているWebアプリケーションの脆弱性を探索する攻撃試行も確認されています。

注目したいのは、攻撃者が一つの特定の脆弱性だけを狙っているとは限らないことです。攻撃対象のシステムに応じて、複数の既知の脆弱性や設定不備を探し、利用できるものがないか繰り返し調査する手法が確認されています。つまり、特定の脆弱性を修正したとしても、それだけですべての攻撃から守られるわけではありません。

参考：JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」

GMOインターネットグループ関連サービスでも不正アクセス被害が発生

2026年10月には、GMOインターネットグループのGMOインターネット株式会社が提供する「お名前.com デスクトップクラウド」において、不正アクセス被害が発生したことも公表されています。2026年10月21日にはサービスの停止と不正アクセスに関する第1報が公表され、その後も被害の調査と対応が続けられています。

この不正アクセスでは、利用者のサーバー環境に不正なプログラムが設置され、保存されていた取引口座のログイン情報などが第三者に取得され、不正利用されたことが報告されています。また、攻撃者からは多額の身代金を要求され、10月28日には犯人の特定や事件の解明につながる情報を募る「GMOサイバー犯罪撲滅・懸賞金」も開設されました。11月2日にはGMOインターネットグループが記者会見を開き、今回の不正アクセスによる被害やセキュリティ上の問題について説明と謝罪を行っています。

大手インターネット関連企業が提供するサービスであっても、セキュリティ上の問題が存在すれば深刻な被害につながる可能性があることを示した事例です。ただし、この事件はWordPressのクローキングやSEOスパムと同じ攻撃手法によって発生したと確認されたものではありません。被害を受けたサービスや攻撃の目的は異なりますが、企業規模に関係なく継続的なセキュリティ対策が求められるという点で参考になります。

参考：GMOインターネット株式会社「お名前.com デスクトップクラウドへの不正アクセスに関する現在の対応について」

セキュリティアップデートを行っても攻撃は終わらない

WordPress本体やプラグイン、テーマのセキュリティアップデートは、不正アクセスを防ぐうえで非常に重要です。しかし、アップデートを実施したからといって、そのWebサイトに対する脆弱性探索や攻撃試行が止まるわけではありません。インターネット上では、既知の脆弱性を持つ古いソフトウェアや、管理の行き届いていないWebサイトを探す自動スキャンが行われています。

攻撃者は、ある脆弱性が修正されても、別のプラグインやテーマ、サーバーの設定不備、管理画面の認証など、異なる侵入経路を探すことができます。さらに、新たな脆弱性が発見された場合には、その情報を利用した攻撃試行が行われる可能性もあります。

そのため、セキュリティアップデートは「一度実施すれば安全になる対策」ではなく、継続して実施する必要がある基本的な防御策です。また、アップデートによって既知の脆弱性を修正できても、すでに不正アクセスによって設置されたバックドアが自動的に削除されるとは限りません。被害を受けたWordPressでは、アップデートと不正ファイルの調査・除去を分けて考えることも重要になります。

企業だけでなく個人のWordPressサイトも注意が必要

サイバー攻撃というと、大企業や金融機関などを狙ったものを想像するかもしれません。しかし、WordPressの脆弱性探索は、必ずしも特定の企業や個人を狙って行われるものではありません。自動化されたスキャンによって、さまざまなWebサイトの脆弱性や設定不備を調べ、攻撃できる対象を探すこともあります。そのため、アクセス数が少ない個人ブログや、趣味で運営しているWordPressサイトでも、不正アクセスの対象になる可能性があります。

SEOスパムの場合、攻撃者の目的は運営者の個人情報を盗むことだけとは限りません。Webサイトを不正な商品ページや外部サイトへの誘導に利用するなど、検索エンジンからの流入を悪用する目的で改ざんされる場合もあります。

企業サイトであれば顧客情報の漏えいや業務への影響が懸念されますし、個人サイトであっても検索結果の汚染やサイトの信用低下につながる可能性があります。企業と個人のどちらであっても、WordPressを公開している以上、不正アクセスは他人事ではありません。

WordPressのSEOスパムとクローキングへの対策

不正URLが404を返すようになったとしても、それだけで復旧作業が完全に終了したとは限りません。再発を防ぐためには、不正ファイルの除去に加え、侵入経路の対策と継続的な監視が必要です。

WordPressとプラグインを最新の状態に保つ

WordPress本体、テーマ、プラグインは、セキュリティ修正を含む更新を適用することが基本です。使用していないプラグインやテーマは、停止するだけでなく、必要性を確認したうえで削除することも検討します。ただし、更新によってサイトの表示や機能に影響する場合もあるため、事前のバックアップが重要です。

管理者アカウントと認証情報を見直す

不正アクセスが疑われる場合は、WordPress管理者だけでなく、サーバー管理、FTP・SFTP、データベースなどの認証情報も確認します。必要に応じてパスワードを変更し、不明な管理者アカウントや不要なアクセス権限がないか調べます。管理画面へのログインには、多要素認証やログイン試行の制限を利用することも有効です。

セキュリティスキャンを継続する

WordPress向けのセキュリティプラグインでは、既知のマルウェアや不審なファイル、WordPress本体の改ざんなどを検出できる場合があります。今回も、不審なファイルの削除後に継続してスキャンを実施し、再検出がないか確認しました。

ただし、セキュリティスキャンで異常が見つからないことは、すべてのバックドアが存在しないことを保証するものではありません。ファイルの整合性確認やアクセスログの調査と組み合わせることが重要です。

WAFやアクセス制限を適切に利用する

外部からの不審なアクセスを減らす方法として、Web Application Firewall（WAF）やサーバーのアクセス制限が有効です。WAFは、Webサイトへのリクエストを検査して、不正なアクセスや攻撃の疑いがある通信を遮断する仕組みです。

ただし、WAFを導入したからといって、すべての攻撃を防げるわけではありません。攻撃方法によっては検出できない場合もあり、逆に正常なアクセスを誤って遮断する可能性もあります。そのため、WAFの有効化に加え、WordPressやプラグインの更新、アクセスログの確認などを組み合わせることが重要です。

バックアップを定期的に取得する

不正アクセスによって大量のファイルが改ざんされた場合、正常なバックアップが残っているかどうかで復旧作業の負担は大きく変わります。WordPressのデータベースだけでなく、テーマ、プラグイン、アップロードした画像なども含めてバックアップを取得しておくことが大切です。

また、バックアップが作成されているだけでなく、必要な時点のデータを復元できるかも重要になります。不正アクセスに気付くまで時間が経過していた場合、直近のバックアップにも不正ファイルが含まれている可能性があるためです。

不正URLの404エラーは放置しても大丈夫？

不正アクセスによって生成されたURLがGoogleに大量登録された場合、復旧後もしばらく404エラーが残ることがあります。しかし、存在しない不正URLに対して正しく404を返しているのであれば、すべてのURLを個別に修正する必要はありません。

むしろ、不正URLを一律にトップページへリダイレクトすると、検索エンジンがソフト404と判断する場合があります。不正なページが実際に存在しないのであれば、404または410を返すことが基本です。

404と410の違い

404は「ページが見つからない」、410は「ページが恒久的に削除された」ことを示します。不正URLが存在しない状態で404を返していれば、検索エンジンは再クロールを通じてその状態を認識していきます。

410を返す方法もありますが、大量の不正URLすべてに個別設定を追加する必要があるわけではありません。重要なのは、検索エンジンに不正なコンテンツを再配信しないことです。

Search Consoleの404件数が増えても再感染とは限らない

不正URLの削除後も、Googleが過去に発見したURLを再クロールすることで、Search Consoleに404が追加される場合があります。そのため、404の件数が増えたという理由だけで、マルウェアが再び動作しているとは判断できません。不正URLへの応答が404で維持されているか、新しい不正ページが200で配信されていないか、セキュリティスキャンで異常が検出されていないかを継続して確認することが大切です。

実際に調査して分かったこと

今回の経験で特に重要だと感じたのは、Googleの検索結果に大量の不正URLが表示されていることと、現在も不正なページが配信されていることは、必ずしも同じではないという点です。不正なファイルを削除した後も、検索エンジンには過去のURLが残り、アクセスログにもそれらのURLへのリクエストが記録され続けました。

しかし、アクセスログを詳しく調べると、不正URLに対して404が返されており、Googlebotを名乗るアクセスでも同様の応答が確認できました。特に、クローキングではGooglebotと一般ユーザーに異なるコンテンツを返すことがあるため、Googlebotへの応答を確認できたことは重要な判断材料になりました。ただし、アクセスログに記録されたHTTPステータスコードだけでは、実際に返されたHTMLの内容までは分からず、過去にクローキングが行われていたかどうかも確定できていません。

また、データベースを調査した際には、見覚えのない大量のデータが見つかりましたが、プラグインが正規の用途で登録したと考えられるものもありました。こうした調査から、単に不審な文字列や大量の404を見つけるだけではなく、それぞれが何を意味するのか判断することが重要だと分かりました。さらに、復旧後も脆弱性を探すような不審なアクセスは継続しており、サイトを正常な状態に戻すことと、外部からの攻撃がなくなることは別の問題だと実感しています。

まとめ：WordPressの不正アクセス対策は復旧後も継続することが重要

WordPressのSEOスパムやクローキングは、一般ユーザーからは問題が見えにくく、Googleの検索結果やSearch Consoleを確認して初めて異常に気付くことがあります。クローキングの代表的な手法は、Googlebotには不正な商品ページを表示し、一般ユーザーには通常のページや404エラーを返すというものです。

また、両方にHTTP 200を返していたとしても、検索エンジンにだけ異なる不正コンテンツを表示していれば、クローキングに該当する可能性があります。そのため、HTTPステータスコードだけでなく、アクセス元によって実際にどのようなコンテンツが配信されるのかを確認することが重要です。

さらに、SEOスパムによって正規サイトのURLが悪用され、Google検索から詐欺が疑われる通販サイトの商品ページへ誘導されるケースもあります。これはWebサイトの運営者だけでなく、検索結果を信頼してアクセスする一般ユーザーにも影響が及ぶ問題です。ただし、不審な商品ページを開いてしまっただけで、必ずしも端末がウイルスに感染したり、個人情報が流出したりするわけではありません。過度に不安になる必要はありませんが、個人情報の入力や不審なファイルの実行などには十分な注意が必要です。

不正ファイルの削除後も大量の404エラーが残るケースでは、Googlebotへの応答や不正URLの再配信状況を確認することが復旧状況の判断に役立ちます。また、Xserverを利用している場合は、表示不具合や不正アクセスによる改ざんに対応できるWordPressリカバリーも有力な復旧手段です。

しかし、今回の調査でも確認できたように、WordPressを復旧させた後も脆弱性を探す不審なアクセスがなくなるわけではありません。2026年には国内企業への不正アクセスも相次ぎ、GMOインターネットグループ関連サービスでも大きな被害が公表されました。こうした事例からも、企業規模やサイトの知名度に関係なく、継続的なセキュリティ対策が必要であることが分かります。

WordPressやプラグインのセキュリティアップデートは非常に重要ですが、それによって新たな脆弱性探索や攻撃試行が止まるわけではありません。不正アクセスから復旧できたとしても、そこで対策が終わるわけではありません。WordPress本体・プラグインの更新、認証情報の管理、バックアップ、セキュリティスキャン、アクセスログの監視を継続することが、企業サイトと個人サイトのどちらにも求められています。