WordPressに知らないページが大量生成された時の対処法【SEOスパム改ざん復旧ガイド】

Google Search Console で「ハッキングされたコンテンツ」や「日本語によるサイトのハッキング」といった通知を見つけ、慌てて検索している方も多いはずです。あるいは site:あなたのドメイン で検索したときに、自社と無関係な薬、通販、賭博系のページが大量に出てきて、何が起きているのか分からない状態かもしれません。

この症状は、いわゆる Japanese Keyword Hack（日本語キーワードハック）や Pharma Hack（ファーマハック）と呼ばれる SEO スパム改ざんの典型例です。放置すると、検索結果からの流入減少だけでなく、Google の手動ペナルティ、インデックス除外、指名検索時の信用低下、取引先からの指摘につながります。

本記事のゴールは次の3点です。

• 何が起きているのかを落ち着いて把握する
• 自力で確認できる範囲と順番を明確にする
• 復旧を急ぐべき条件と、専門家へ切り替える基準を持つ

何が起きているのか（仕組み解説）

この被害は、Google でも Japanese Keywords Hack として案内されている代表的な hacked content（ハッキングされたコンテンツ）です。攻撃者は脆弱性（セキュリティ上の弱点）や漏えいした認証情報を使って WordPress に侵入し、被害サイトのドメイン評価を悪用してスパム商材ページを検索結果に出そうとします。

目的は単純で、あなたのサイトのSEO評価を踏み台にして、攻撃者の売りたいページをGoogle検索で上位表示させることです。実際には、偽ブランド通販、医薬品、賭博、成人向けなど、運営者に身に覚えのないページが大量に追加されます。

さらに厄介なのが、cloaking（クローキング: 相手によって見せる内容を変える手法）です。Google の #NoHacked 解説でも、この種のハックは Googlebot にだけ大量ページを見せたり、管理者には 404 エラーや通常ページに見せかけたりすることがあると説明されています。そのため、通常閲覧では気づきにくく、Search Console や site: 検索で初めて発覚しがちです。

この段階で重要なのは、「見えるページだけを消せば終わり」と考えないことです。SEO スパム改ざんは、ページ削除より先に、侵入経路と再生成の仕組みを止める必要があります。

緊急時の最初の3分で「症状を固定」する

最初にやるべきことは修正ではなく、現象の固定です。WordPress 公式の hacked site FAQ でも、侵害発覚直後は時刻や症状を記録するよう案内されています。ここを飛ばすと、後で「どこまで直ったか」「再発したか」が判断しにくくなります。

1. site:あなたのドメイン を実行する

Google は、想定外のページ発見に site: 検索を使うことを推奨しています。検索結果のタイトルや説明文に、次のような違和感がないか確認してください。

• 日本語以外のタイトル
• 薬、通販、賭博、成人向けなど異業種キーワード
• ランダム文字列のディレクトリ
• 存在しないはずの URL

2. Search Console の「セキュリティと手動による対策」を確認する

Search Console では、セキュリティの問題 と 手動による対策 を必ず分けて確認します。Google 公式ヘルプでも、Security Issues report と Manual Actions report は別物として説明されています。

• セキュリティの問題: ハッキング、マルウェア、フィッシングなどの検知
• 手動による対策: Google の担当者が手動で検索品質上の問題を判定した状態

「警告が消えていないのに見た目だけ直った」は、復旧完了ではありません。

3. Search Console のインデックス系レポートで急増URLを見る

Search Console のページ一覧やインデックス関連レポートで、不審 URL が急増していないか確認します。件数そのものより、「昨日まで無かったURL群が急に増えていないか」を見るのが実務的です。

4. サーバー側でファイル数・容量増加を確認する

SEO スパム改ざんでは、画像フォルダやテーマ配下に大量の不正ファイルが置かれることがあります。レンタルサーバーのファイルマネージャーや使用量表示で、ファイル数や容量が不自然に増えていないか確認してください。

5. 時刻・症状・例URLを記録する

最低限、以下をメモしておくと後の調査が速くなります。

• 発見時刻
• Search Console の警告文
• site: 検索で見つかった例 URL
• 社内で直前に行った更新や設定変更

改ざんされやすい場所と確認の優先順位

ここからはファイル調査です。WordPress 公式 FAQ では、index.php header.php footer.php functions.php .htaccess などの主要ファイル確認が推奨されています。実務では、それに wp-config.php mu-plugins uploads も加えて確認します。

編集前には、必ず現在状態のバックアップを取得してください。感染済みでも構いません。復旧前スナップショットは、再発時の比較や侵入経路調査の基準になります。

確認場所	なぜ優先度が高いか	典型的な不審点
wp-content/uploads/	本来は画像やPDF中心で、PHPがあると不自然	見覚えのない .php、日付フォルダ直下の実行ファイル
テーマ・プラグイン配下	全ページ読み込みやすく、改ざんの影響が広い	不審な .php、難読化コード、最近更新していないのに更新日時が新しい
wp-content/mu-plugins/	自動読み込みで管理画面から見落としやすい	覚えのない単体PHP、偽装ファイル名
wp-config.php	認証キー、DB設定、追加読み込みなど中枢設定がある	不審な include、外部URL参照、余計な実行コード
index.php	ルートで必ず読み込まれるため影響が大きい	数行だけ追記された難読化コード
.htaccess	リダイレクトや条件分岐に使われやすい	覚えのない RewriteRule、User-Agent 条件分岐
データベース	投稿・ユーザー・設定の汚染が起きやすい	不審投稿、不審管理者、home siteurl 改ざん

特に uploads 配下は要注意です。画像中心の場所に PHP 実行ファイルがある場合は強い違和感です。ただし、削除は調査後に行ってください。

データベース内の確認（投稿テーブルの汚染）

ファイル側だけでなく、データベースも高頻度で汚染されます。不審ユーザーや設定改ざんが残っていると、見えるファイルを掃除しても再発します。

phpMyAdmin にログインできるか確認する

phpMyAdmin（ピーエイチピーマイアドミン: データベースをブラウザから操作するツール）に入れるか確認します。入れない場合は、WordPress だけでなくサーバーや認証情報側も問題を抱えている可能性があります。

wp_posts に不審な公開投稿が大量追加されていないか

まずは投稿テーブルを確認します。典型的には post_status='publish' の公開状態で、薬・通販・賭博など異業種キーワードを含む投稿が大量に追加されています。いきなり削除せず、まずは抽出して件数と内容を把握してください。

例として、phpMyAdmin で状況確認に使いやすいのは次のような SELECT です。

SELECT ID, post_date, post_status, post_type, post_title
FROM wp_posts
WHERE post_status = 'publish'
AND (
  post_title LIKE '%viagra%'
  OR post_title LIKE '%casino%'
  OR post_title LIKE '%薬%'
  OR post_title LIKE '%通販%'
)
ORDER BY post_date DESC;

テーブル接頭辞が wp_ でない場合は、実際の接頭辞に読み替えてください。削除は、必ずバックアップ取得後に対象件数を確認してから行います。

wp_posts.post_content に不審コードやリンクが混入していないか

post_title だけでなく、post_content に script、iframe、不審な外部リンク、CSS で隠されたリンクが挿入されていないか確認します。

wp_users に不審な管理者ユーザーがないか

WordPress 公式 FAQ でも、身に覚えのないユーザー追加は侵害の兆候とされています。wp_users と権限テーブルを確認し、覚えのない管理者がいないか見てください。削除しても再作成される場合は、別のバックドア（侵入用の裏口）が残っています。

Search Console のプロパティ所有者に身に覚えのないユーザーがいないか

Japanese Keyword Hack で特に重要な兆候として、Google 公式が強調しているのが「攻撃者が Search Console のプロパティ所有者として自分自身を追加している」ケースです。Google 公式の解説では、攻撃者は Search Console の所有者として自分自身を登録することで、geotargeting（地域ターゲティング）や sitemaps などの設定を操作し、スパムを有利に展開すると説明されています。

Search Console の 設定 → ユーザーと権限 を開き、知らないアカウント（特に googlewebmaster@gmail.com のような紛らわしい名前や、無関係なドメインのメールアドレス）が所有者として登録されていないか必ず確認してください。発見した場合は、Search Console 上でそのユーザーを削除します。

ここで終わらせてはいけません。相手が Verified owner（確認済み所有者）の場合、ユーザーを削除しても所有権の確認トークン（サイトに設置された HTML ファイル、HTML タグ、DNS レコード、Google Analytics、Google タグマネージャーなど）が残っていると、再び所有者として確認・登録され得ます。確認の詳細 を開いて確認方法を特定し、残っているトークンも必ず削除してください。設置型トークンの場合、たとえば www.example.com/google○○○○.html のような確認用URLが 404 を返すようになったかで削除を検証できます。

wp_options の siteurl と home

wp_options の siteurl と home は、サイトの正規URLを持つ重要項目です。ここが改ざんされると、表示先や内部リンクの挙動が崩れます。不審な外部ドメインや見覚えのないサブディレクトリになっていないか確認してください。

やってはいけない対応

SEO スパム改ざんは、初動を誤ると長引きます。次の対応は避けてください。

不審ページの URL を一つずつ手動削除して終わらせる

見えている投稿やファイルだけを削除しても、生成元が残っていれば再び作られます。再生成の仕組みを止めずに「見えるものだけ消す」のは、掃除ではなく先送りです。

バックドアを残したまま見える範囲だけ消す

SEO スパム改ざんでは、不正ページ本体とは別に、再侵入用・再生成用の PHP ファイルが残っていることがあります。

Search Console から URL 削除して「解決済み」と判断する

Search Console の削除ツールは、検索結果から一時的に見えにくくする用途であり、改ざん実体の除去そのものではありません。実体が残っていれば再クロール後に戻る可能性があります。

Nulled プラグイン・テーマを残す

Nulled（不正配布された有料製品）を使い続けると、清掃しても再侵入しやすくなります。侵入経路候補が残るため、復旧後の安全性が担保できません。

復旧の基本手順（プロが実施する流れ）

ここからは、実務で復旧を進める基本順です。ポイントは、削除より先に保全し、「クリーンな構成へ戻す」ことです。

1. 全ファイルを保全する

感染済みのままでも、まず全ファイルを別領域へコピーします。WordPress 公式 FAQ でも、清掃前にバックアップを作成するよう推奨されています。これは復元用というより、証跡保全と比較用です。

2. WordPress 本体・テーマ・プラグインをクリーンな配布元で上書きする

WordPress 公式 FAQ では、/wp-admin と /wp-includes ディレクトリは安全に置換可能と案内されています。あわせて、いま動いているのと同一バージョンの正規配布ファイルで上書きすることが重要とされています（バージョンが違うと挙動が壊れる可能性）。実務では、信頼できるテーマ・プラグイン一式へ入れ替え、不審ファイルを持ち込まない構成に寄せます。

3. データベースの不審投稿を一括で整理する

対象を特定した上で、不要な公開投稿や埋め込まれた不審リンクを除去します。post_status='publish' のうち、外国語や異業種キーワードの投稿を抽出して確認し、誤削除がないことを確認してから削除します。

4. すべての認証情報を変更する

WordPress 公式 FAQ や Hardening ガイドでも、侵害後はアクセス経路全体の認証情報変更が推奨されています。対象は以下です。

• WordPress 管理者アカウント
• FTP / SFTP
• データベース
• レンタルサーバー管理画面
• 関連メールアカウント

5. wp-config.php のシークレットキーを再発行する

WordPress 公式 FAQ では、AUTH_KEY などの secret keys（秘密鍵）を更新して既存ログインセッションを無効化する方法が案内されています。これにより、侵害時に盗まれたセッションの継続利用を防ぎやすくなります。

6. Search Console で再審査リクエストを行う

Security Issues report や Manual Actions report に警告が出ていた場合は、修正後に review request（再審査リクエスト）を行います。Google 公式ヘルプでは、何を修正し、どの原因を塞いだかを説明することが重要とされています。

自力対応の限界を判断する基準

次のどれかに当てはまるなら、自力継続より専門対応を優先したほうが安全です。

• 不審ファイル削除後、数時間から数日で再生成される
• バックアップがない、または改ざん前世代が残っていない
• cloaking のため、どのURLが本当に汚染されているか掴みきれない
• Search Console で「ハッキングされたコンテンツ」「マルウェア」などの警告を受けている
• 不審な管理者ユーザーが削除後に再生成される

この段階では、「掃除」ではなく「障害復旧」として扱うべきです。表面のスパムページだけでなく、侵入経路、再生成コード、認証情報漏えい、Search Console での再審査まで含めて対処しないと、検索被害が長引きます。判断に迷う場合は、早い段階で WordPress改善復旧 に切り替えたほうが安全です。

また、外部から見える範囲の公開リスクを急ぎで確認したい場合は、お問い合わせ で初期把握を進める方法もあります。

再発防止：このタイプの被害を起こさない運用設計

復旧後は「元に戻す」だけでなく、同じ被害を再発させない運用設計が必要です。WordPress の Hardening ガイドや Google の案内に沿うと、最低限見るべき点は整理できます。

自動バックアップを世代管理で複線化する

バックアップは1世代だけでは不十分です。改ざん後に気づいた場合、その1本も汚染されている可能性があります。複数世代を残し、可能なら保存先も分散してください。

WordPress 本体・プラグイン更新を定期業務にする

古い本体やプラグインは侵入経路になりやすいため、更新作業を「気づいたとき」ではなく定例運用にします。更新前バックアップ、検証、反映の順序を固定すると事故を減らせます。

ログイン保護を強化する

WordPress 公式の Two Step Authentication ガイドでは、長く一意なパスワードと 2 要素認証（2FA）が推奨されています。加えて、Brute Force Attacks ガイドでは /wp-login.php のレート制限やアクセス制限、WAF の活用などが案内されており、これらを組み合わせると不正ログインのリスクを下げやすくなります。

不要プラグインを棚卸しする

停止中のプラグインでも、古いファイルが残っていればリスクになります。使っていないプラグインやテーマは無効化だけでなく削除まで検討してください。

ファイル変更検知と uploads 配下の PHP 実行対策を行う

WordPress の Hardening ガイドでも、監視や権限設計は重要な論点です。実務では、重要ファイルの変更検知（FIM: File Integrity Monitoring）と、画像ディレクトリでの PHP 実行抑止をセットで考えると効果的です。

Search Console を継続監視する

Google は、Security Issues report や site: 検索による定期監視を推奨しています。復旧後もしばらくは、不審URLが増えていないか、警告が再発していないかを追ってください。

社内でこの監視や更新を継続しにくい場合は、復旧後の再発防止フェーズとして WordPress月額保守プラン に切り替える選択肢も現実的です。

まとめ

WordPress に知らないページが大量生成されたとき、見える範囲だけ消しても復旧は完了しません。Japanese Keyword Hack や Pharma Hack は、侵入経路の特定、再生成コードの除去、認証情報変更、Search Console での再審査まで含めて初めて収束します。

特に避けたいのは、焦って投稿削除だけで済ませることです。削除後に再生成されるなら、原因は別の場所に残っています。まず症状を固定し、ファイルとデータベースの両方を確認し、必要なら早めに復旧対応へ切り替えてください。

復旧後も Search Console 監視を続けることで、再発の早期発見につながります。見えなくなった時点ではなく、原因まで取り切って終えることが重要です。

参考情報（公式・一次情報）

• web.dev (Google): Fixing the Japanese keyword hack
  https://web.dev/fixing-the-japanese-keyword-hack/
• web.dev (Google): Request a review
  https://web.dev/request-a-review/
• Google Search Console Help: Security issues report
  https://support.google.com/webmasters/answer/9044101
• Google Search Console Help: Reconsideration requests
  https://support.google.com/webmasters/answer/35843
• WordPress 公式 FAQ: My site was hacked
  https://wordpress.org/documentation/article/faq-my-site-was-hacked/
• WordPress Developer Resources: Hardening WordPress
  https://developer.wordpress.org/advanced-administration/security/hardening/
• WordPress Developer Resources: Two Step Authentication
  https://developer.wordpress.org/advanced-administration/security/mfa/
• WordPress Developer Resources: Brute Force Attacks
  https://developer.wordpress.org/advanced-administration/security/brute-force/
• Google Search Console Help: Remove a verified owner
  https://support.google.com/webmasters/answer/7281924

※本記事は2026年6月4日時点の公開情報を基に作成しています。各サービスのUI・仕様は変更されることがあるため、最新情報は各公式ページで確認してください。