WordPressに知らないサイトマップが増えた時の対処｜検索スパムを止める復旧手順

WordPressのSearch Consoleやサーバー上に、見覚えのないサイトマップが増えて困っていませんか？
知らないファイル名や大量のURLを見つけると、すぐ削除したくなるものです。

しかし、サイトマップを一覧から消すだけでは、検索スパムを作っている仕組みは止まりません。
正規プラグインが生成したサイトマップを誤って消すと、正常なページまで検索エンジンへ伝わりにくくなるおそれもあります。

大切なのは、正常なサイトマップと不正なサイトマップを分け、証拠を残してから生成元を止めることです。
検索結果にスパムURLが出ている場合は、WordPress本体の復旧とGoogle側の整理も並行して進めます。

よこやま良平

WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、知らないサイトマップを安全に判定し、検索スパムの生成元を止める順番を解説します。

結論からいうと、知らないサイトマップを見つけた時は、URL、内容、生成元、登録経路を記録し、WordPress内の不正処理を除去してからGoogle側を整理するのが安全です。

作業の順番を間違えると、証拠を失ったり、不正サイトマップが再生成されたりします。
まずは「なぜ複数あるのか」を確認するところから始めましょう。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressに知らないサイトマップが増えた時は削除だけで済ませない

WordPressに見覚えのないサイトマップがあっても、名前だけでマルウェアと断定せず、正規機能か不正生成かを先に切り分けるべきです。

WordPressは5.5以降、標準機能としてサイトマップインデックスを生成します。
さらにSEOプラグイン、EC機能、多言語機能、画像・動画向けプラグインが別のサイトマップを作ることもあるため、複数あること自体は異常ではありません。

WordPress標準とSEOプラグインのサイトマップを確認する

標準のWordPressでは、一般にルート直下の「wp-sitemap.xml」が入口になります。
SEOプラグインでは「sitemap_index.xml」など別の名前を使うことがあり、設定変更やプラグイン移行の後に新旧2系統が見える場合もあります。

まずプラグイン一覧、SEO設定、テーマや独自機能の仕様書を見て、現在使うサイトマップの生成担当を特定します。
担当者が不明なら、導入日、更新履歴、過去のSearch Console画面も照合してください。

不正なサイトマップを疑うサインを重ねて判断する

危険なのは、管理者が作っていないという事実に加え、サイトの事業と無関係なURLや不自然な生成挙動が重なるケースです。
一つのサインではなく、サイトマップの中身、公開URL、ファイル、ログの整合性で判断します。

検索結果、管理画面、ファイル、データベースを横断して改ざんの有無を判断する方法は、次の記事で詳しく整理しています。

サイトマップが複数あることだけでは感染の証拠になりません。正規機能を確認せず一括削除しないでください。

WordPressの知らないサイトマップを削除前に記録して判定する

不審なサイトマップを見つけたら、最初に表示内容と登録状況を記録し、Search Console上の登録とサーバー上の実体を分けて確認します。

この二つを混同すると、Search Consoleから送信履歴を消しただけで直ったと考えたり、サーバー上のファイルだけ消して侵入経路を見失ったりします。
復旧前の記録は、影響範囲と再発を比較する基準にもなります。

Search Consoleで送信元と最終読み込みを保存する

Search Consoleの「サイトマップ」画面で、対象URL、種類、ステータス、検出されたページ数、最終読み込み日時をスクリーンショットまたは作業メモへ残します。
「送信されたサイトマップ」なのか、別のサイトマップやrobots.txtから発見されたのかも重要です。

Search Consoleの所有者・ユーザー一覧、設定変更の履歴、通知メールも確認してください。
知らない所有者や委任ユーザーがいれば、サイト内だけでなくGoogleアカウント側の権限侵害も疑う必要があります。

サイトマップURLの応答と中身を安全に比較する

不審URLを確認する時は、ブラウザーで中のスパムリンクを次々クリックしないでください。
まずヘッダーとXML本文を保存し、正規サイトマップとドメイン、パス、件数、更新傾向を比較します。

curl -I --max-time 10 "https://example.com/unknown-sitemap.xml"
curl --max-time 20 -o unknown-sitemap.xml "https://example.com/unknown-sitemap.xml"

上の例は応答ヘッダーを確認し、調査用コピーを保存する基本形です。
実行環境のドメインへ置き換え、顧客情報や不審URLをチャット・公開リポジトリ・検索欄へ貼り付けないようにします。

XMLが動的に生成されている場合、サーバー上に同名ファイルが存在しないこともあります。
WordPressのリライトルール、プラグイン、テーマ、mu-plugins、独自PHPのどこが応答を作っているかを調べてください。

登録を消す操作と生成元を消す作業を区別する

Search Consoleからサイトマップを削除する操作は、管理画面上の送信情報を整理する作業です。
サーバー上のXML、スパムページ、データベースの不正投稿、再生成するバックドアまで自動で消えるわけではありません。

反対に、サーバー上のファイルだけ消しても、WordPressのフックやCronが残っていれば再び作られます。
先に記録し、生成経路を見つけ、侵入口を止めてから削除するという順番が必要です。

WordPressの検索スパムを止める初動は保全と公開被害の制限から行う

検索スパムが確認できた時は、証拠と正常データを保全したうえで公開被害を抑え、サイトマップを再生成する不正処理を特定します。

最初からWordPressを全削除したり、古いバックアップを上書き復元したりすると、最新の注文・問い合わせ・投稿を失い、侵入経路も分からなくなることがあります。
利用者への危険が大きい場合は、サーバー会社や専門家と一時制限の方法を決めます。

ファイルとデータベースを保全して作業範囲を固定する

ファイル一式とデータベースを、感染状態の調査用コピーとして保存します。
これはそのまま公開へ戻すためのバックアップではなく、変更前後を比較し、何が不正だったかを確認するための証拠です。

不正サイトマップの生成元をWordPress全体から探す

調査対象はXMLファイルだけではありません。
テーマのfunctions.php、プラグイン、mu-plugins、uploads内の実行ファイル、wp-config.php、データベースの投稿・options、WP-Cron、サーバー側Cronを確認します。

更新日時が新しいファイルだけに絞るのも危険です。
攻撃者が日時を偽装したり、古いバックドアが後からスパム生成処理を呼び出したりするため、正規配布物との差分、コードの役割、実行ログを合わせて判断します。

感染ファイルを探す優先順位と、削除前に正規ファイルと比較する方法はこちらを参考にしてください。

クイックレスキュー

WordPressマルウェア駆除を自分で行う方法｜感染ファイルを見つける基本手順 WordPressマルウェア駆除を自分で進めたい方へ。感染ファイルが見つかりやすい場所、候補の絞り込み方、削除前の判断基準、再発防止の入口対策まで初心者向けに解説します…

決まった間隔でXMLや投稿が復活する場合は、WP-Cronのフック名、次回実行時刻、登録元を記録します。
イベントをいきなり削除すると手掛かりが消えるため、次の記事の確認順で停止範囲を判断してください。

不正アクセスの入口を閉じて再生成を止める

不正コードを消す前後で、WordPress管理者、ホスティング、SFTP、データベース、メール、CDN、Search Consoleの権限を棚卸しします。
安全な端末からパスワードを変更し、不要なセッションやAPI連携を失効してください。

知らない管理者を見つけても、証拠を残さず即削除するのは避けます。
作成日時、メールアドレス、権限、所有コンテンツ、ログを記録し、正規ユーザーの保護とセッション遮断を先に行います。

クイックレスキュー

WordPressの管理者ユーザーが勝手に増えた時の危険性と初動対応 WordPressに見知らぬ管理者ユーザーが増えて困っていませんか？削除前の証拠保全、権限停止、セッション遮断、認証情報変更、侵入口調査、投稿を失わない削除判断を初心者…

わたしの実務では、サイトマップを消して再発を待つより、誰が何を生成しているかを先に追うほうが復旧後の再感染を防ぎやすいです。

WordPressの不正サイトマップとスパムURLを根本から復旧する

生成元と侵入口を特定したら、不正コード、スパムコンテンツ、権限侵害をまとめて修正し、URLごとに正しいHTTP応答へ戻します。

サイトマップだけ正常に見せても、不正ページが200で残っていれば検索汚染は続きます。
逆に、正常な記事まで削除やnoindexにすると、本来の検索流入を失うため、対象URLを一覧化して処理を分けます。

不正コードとスパムコンテンツを同じ復旧単位で除去する

改ざんされた正規ファイルは、信頼できる同一バージョンのWordPress本体・テーマ・プラグインと比較し、正規版へ置き換えます。
見覚えのないプラグインやPHPは、業務機能との関係を確認してから公開領域外へ隔離します。

データベースでは、不正な投稿、固定ページ、メタデータ、リダイレクト設定、options内の生成条件を確認します。
文字列を一括置換するとシリアライズデータや正規設定を壊すため、項目単位でバックアップと修正結果を残してください。

消したスパムURLは404または410で応答させる

存在しないスパムURLは、内容のある404ページを表示しつつHTTPステータスを404にするか、恒久削除を明確にするなら410を返します。
すべてトップページへ301転送すると、無関係なURLが残り、ソフト404として扱われる可能性があります。

本来の正規記事が改ざんされていた場合は、その記事を復元して200を維持します。
URLごとに「正規ページを復元」「不正ページを削除」「一時的に公開制限」を分類し、機械的な一括処理を避けることが重要です。

正常なサイトマップを一系統に整理してキャッシュを消す

復旧後は、WordPress標準または採用中のSEOプラグインのどちらを使うか決め、公開したい正規URLだけが含まれる状態へ戻します。
重複する生成機能は設定で整理し、テーマやプラグインを直接改造して場当たり的に止めないでください。

WordPress、サーバー、CDNにキャッシュがある場合は、修正後に順番を決めて削除します。
別端末や未ログイン状態からサイトマップを再取得し、不正URLが消え、正規URLが同じドメインとHTTPSで返ることを確認します。

WordPressのサイトマップをSearch Consoleで整理して検索スパムを収束させる

サーバー側の復旧が完了したら、知らないサイトマップの送信情報を整理し、正常なサイトマップを送信してインデックス状況を監視します。

Googleへの操作を先にしても、不正URLが200で再生成される状態では汚染が戻ります。
必ず「生成元停止」「不正URLの応答修正」「正常サイトマップ確認」の後に、Search Consoleの整理へ進んでください。

知らない送信情報を削除して正常なサイトマップを再送信する

Search Consoleのサイトマップレポートで、不正または不要と確認できた送信情報を削除します。
その後、正常なサイトマップURLを開いて内容とHTTP 200を確認し、正規のURLだけを含む状態で送信します。

サイトマップの送信は、Googleに存在を知らせる手段であり、すべてのURLが必ずクロール・登録される保証ではありません。
処理後は「成功しました」という表示だけでなく、検出URLの増減やページのインデックス状況まで見ます。

緊急時だけ削除ツールを使い元ページも必ず消す

検索結果に危険なスパムページが大量表示され、利用者被害を急いで抑えたい場合は、Search Consoleの削除ツールで一時的な非表示を検討します。
ただし、これはWordPress上のコンテンツ削除やマルウェア駆除の代わりではありません。

一時削除の期限が終わっても戻らないよう、元URLを404または410へ直し、不正サイトマップから外し、内部リンクやリダイレクトも除去します。
検索結果汚染の確認と削除申請の流れは、次の記事と役割を分けて進めると迷いません。

復旧後はログとサイトマップを一定期間比較する

復旧直後だけ正常でも、残ったバックドア、盗まれた認証情報、別サイトの感染から不正ファイルが戻ることがあります。
アクセスログ、ファイル変更、管理者、WP-Cron、Search Consoleの検出URLを同じ記録表で追跡してください。

駆除後に見直す管理者、更新、バックアップ、監視の全体像も確認しておくと、サイトマップ以外の再感染兆候を見逃しにくくなります。

正常なサイトマップと検索結果の両方が安定し、再生成ログがないことまで確認して復旧完了と判断します。

WordPressの知らないサイトマップと検索スパムに関するよくある質問

サイトマップを見つけた直後によく迷う点を、復旧順に合わせて回答します。

知らないサイトマップはすぐ削除してもよいですか？

すぐには削除せず、URL、中身、最終読み込み、生成元、関連ログを記録してください。正規プラグイン由来なら削除不要です。不正と確認できた場合も、再生成元と侵入口を止めてから削除します。

Search Consoleから削除すれば検索スパムは止まりますか？

止まりません。Search Console上の送信情報を消しても、WordPressの不正コード、スパムページ、サーバー上のXMLは残ります。サイト側の生成元を修復し、不正URLの応答も直す必要があります。

wp-sitemap.xmlとsitemap_index.xmlが両方あるのは感染ですか？

両方あるだけでは感染とはいえません。WordPress標準とSEOプラグインがそれぞれ生成している可能性があります。含まれるURL、プラグイン設定、robots.txt、Search Consoleの登録を比較して採用する系統を決めます。

復旧後、検索結果からスパムURLが消えるまで何を確認しますか？

元URLが404または410を返すこと、不正サイトマップが再生成されないこと、正常サイトマップだけが送信されていることを確認します。緊急時は一時削除を使い、Search Consoleとアクセスログを継続して監視します。

WordPressの知らないサイトマップは生成元を止めてから整理する

WordPressに知らないサイトマップが増えた時は、一覧から消すことより、正規機能との比較、証拠保全、生成元の特定を優先します。

不正と確認できたら、公開被害を制限し、ファイル・データベース・Cron・管理者・認証情報をまとめて調査します。
不正コードとスパムページを除去し、URLを正しいHTTP応答へ戻してから、正常なサイトマップをSearch Consoleへ送信してください。

原因が分からないまま削除を繰り返すと、検索汚染が広がり、正常なSEO設定まで壊すおそれがあります。
自力で生成元を特定できない場合は、証拠を残した段階で専門家へ切り替えるのが安全です。

知らないサイトマップと検索スパムが自分で解決できない時は

見覚えのないサイトマップ、検索スパム、再生成される不正URLでお困りなら、
クイックレスキューが生成元の調査から駆除・復旧・再感染防止まで対応します。

原因不明のまま削除を繰り返す前にご相談ください。
いまなら期間限定で3つの安心保証を用意しています。