自社のWordPressサイトを開いたはずなのに、見知らぬ通販サイトや広告ページ、フィッシング（偽ログインページ）に飛ばされる。この現象は単なる表示崩れではなく、サイト改ざんによる重大な障害である可能性が高いです。

とくに厄介なのは、社内から見ると普通なのに、検索結果から来た一般訪問者だけが別サイトへ飛ばされるケースです。気づくのが遅れると、問い合わせや購入の機会損失だけでなく、Google検索での警告表示、指名検索からの離脱、取引先からの信用低下にもつながります。

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

  • 症状を落ち着いて見極める
  • 自力で進めてよい範囲を順番で把握する
  • 専門家へ切り替える基準を明確にする

リダイレクトハックとは何か（仕組み解説）

リダイレクトハックとは、攻撃者がWordPress本体・テーマ・プラグインの脆弱性（セキュリティ上の弱点）や、漏えいした管理者認証情報を使ってサイト内部に侵入し、訪問者を別サイトへ転送するコードを埋め込む改ざん被害です。

WordPress公式のハッキングFAQでも、改ざん時の典型症状として「見慣れない挙動」「身に覚えのないユーザー作成」「Google等でのブラックリスト登録」が挙げられています。つまり、勝手な転送は「よくある困りごと」ではなく、侵害の兆候（IoC: Indicator of Compromise）として扱うべき事象です。

攻撃者の主な目的は次のとおりです。

  • スパムSEO（検索順位を悪用して別サイトへ送客する行為）
  • 広告詐欺
  • フィッシング
  • マルウェア（悪意あるプログラム）の配布

さらに厄介なのが、cloaking（クローキング: 相手によって見せる内容を変える手法）です。Google Search Centralでも、ハッキング被害ではコード注入や不正ページ追加が起こりうると説明されています。実際の現場では、管理者や検索エンジンbotには正常表示し、一般訪問者だけを飛ばす動きが珍しくありません。

「自分のPCでは普通に見えるから大丈夫」と判断すると、被害の把握が遅れます。

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

最初にやるべきことは修正ではなく、現象の記録です。ここを飛ばして先にファイルを書き換えると、後から再現条件が分からなくなります。

1. 別環境でも再現するか確認する

  • 別ブラウザ
  • シークレットウィンドウ
  • スマホ
  • 別IP（アイピー: 接続元識別情報。可能ならテザリング）

この確認は、ブラウザ拡張や社内ネットワーク固有の問題を切り分けるためです。Google Search Centralでも、セキュリティ問題確認時は環境差分や見え方の違いに注意するよう案内されています。

2. リダイレクト先のドメインを記録する

飛ばされた先のURLやドメイン名は、画面キャプチャとテキストの両方で残します。ただし、そのリンクを新規タブで開いたり、何度もクリックしたりしないでください。悪性サイト側で追加の不正動作が走る可能性があるためです。

3. site:あなたのドメイン でGoogle検索する

Google Search Centralは、site: 検索で意図しないページや身に覚えのない内容が出ていないか定期確認することを推奨しています。検索結果のタイトルやスニペット（検索結果の説明文）に、次のような不審要素がないか見ます。

  • 海外言語のタイトル
  • カジノ、成人向け、医薬品、偽通販など無関係な文言
  • 存在しないURL

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

GoogleのSecurity Issues reportでは、ハッキング、マルウェア、ソーシャルエンジニアリング（だまして個人情報や操作を引き出す手口）が検出されると警告が表示されます。検索結果に「このサイトは危険な可能性があります」といった表示が出る前後で、ここに痕跡が残ることがあります。

5. 状況ログを残す

最低限、次をメモしてください。

  • 発見時刻
  • どのURLで起きたか
  • どの環境で再現したか
  • 直前に何を変更したか

この記録は、そのままインシデントメモ（障害記録）になります。WordPress公式FAQでも、ハック後は時刻や直前変更を文書化することが推奨されています。

改ざんされやすい場所・調査優先順位

調査は「影響範囲が大きく、書き換えられやすい場所」から見ます。作業前には、必ず現在状態のバックアップを取得してください。改ざん済みであっても、証跡として残す価値があります。

場所 まず見る理由 不審な兆候
.htaccess リダイレクト設定を書きやすく、被害時の定番 覚えのない RewriteRule、外部ドメインへの転送、難読化された記述
wp-config.php サイト全体設定を持ち、侵入後の追記先になりやすい 覚えのない include、外部ファイル読込、WP_HOME WP_SITEURL の不自然な固定
テーマの functions.php 全ページ実行されやすい base64_decode など読みにくいコード、外部JS読込、条件分岐つき転送
テーマの header.php head内に不正scriptを埋め込みやすい 不審な <script> <iframe>、見慣れない外部ドメイン
ルートや各階層の index.php WordPress公式FAQでも確認対象として挙がる 数行の不審コード追記、別PHPファイルの呼び出し
wp-content/mu-plugins 自動読み込みされ、管理画面で見落としやすい 覚えのない単機能PHP、名前を偽装したファイル
wp_options URLや有効プラグインなど重要設定を保持 siteurl home の改ざん、不審オプション、見慣れない自動読込設定

WordPress公式FAQでも、.htaccess、index.php、header.php、footer.php、functions.php は重点確認対象です。そこに加えて実務上は、wp-config.php、mu-plugins、wp_options まで見ないと再発要因を取り逃しやすくなります。

焦って .htaccess だけ直して終わりにしないことが重要です。そこだけ元に戻しても、別の不正コードが再生成していると数分から数時間で再発します。

プラグイン・テーマ起因の確認

侵入経路の特定では、「最近何を入れたか」「更新が止まっていたものは何か」を洗い出します。

最近インストール・更新したものを確認する

直前に追加・更新したプラグインやテーマがあれば、まず候補に入れます。WordPress本体側の脆弱性だけでなく、拡張機能経由の侵入は実務上よく起こります。

WordPress.org から削除済み・更新停止のプラグインを点検する

長期間更新がないプラグインや、公式ディレクトリから削除済みのものはリスクが上がります。WordPress公式のHardeningガイドでも、プラグインは信頼性と更新状況を意識して選ぶべきとされています。

Nulled テーマ・プラグインを疑う

Nulled（本来有料の製品を不正配布したもの）は、内部に悪性コードが埋め込まれている典型例です。制作会社や前任者の導入物も含め、「無料でもらった有料テーマ」が残っていないか確認してください。

全プラグイン無効化で切り分ける

バックアップ取得後に、全プラグインを一時停止して症状が止まるか確認します。停止後に改善するなら、プラグインか、そのプラグインが残した設定・ファイルが原因候補です。

ただし、無効化で直ったとしても「感染源がそこにある」とは限りません。攻撃者が別ファイルから不正コードを注入しており、たまたまプラグイン停止で表面化しなくなっただけ、ということもあります。

データベース内の確認

ファイル側だけで異常が見つからない場合、データベース（サイトの設定や本文を保存する領域）も確認します。

phpMyAdmin に入れるか

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

wp_options の siteurl home

WordPress公式ドキュメントでは、WordPress Address と Site Address はサイトの所在を制御する重要項目です。データベースでは通常 wp_options テーブル内の siteurl と home に保存されています。ここが身に覚えのないURLに変わっていないか確認します。

確認対象 正常時の見方 異常時の見方
siteurl WordPress本体の正規URL 別ドメイン、見覚えのないサブディレクトリ
home 公開サイトの正規URL 外部サイトや不自然な転送先URL
active_plugins など関連オプション 導入済み構成と整合 覚えのないプラグイン名、長い難読化文字列

wp_users の不審な管理者

WordPress公式FAQでも、身に覚えのないユーザー作成は侵害の兆候です。wp_users と権限テーブルを見て、知らない管理者アカウントが追加されていないか確認します。

投稿本文や固定ページへの不審script

Google Search Centralが説明する hacked content（ハッキングされたコンテンツ）には、既存ページへのコード注入や不正ページ追加が含まれます。本文やカスタムHTMLに見慣れない <script>、iframe、外部ドメインへの自動転送コードが大量に入っていないか確認してください。

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

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

  • 不審ファイルやコードを除去しても、数時間から数日で再発する
  • バックアップが存在しない、または改ざん前の世代が残っていない
  • .htaccess を直してもすぐ元に戻る
  • Googleから「ハッキングされたコンテンツ」「マルウェア」などの警告を受けている
  • 不審な管理者ユーザーを削除しても再生成される

これは、見えている症状の背後に cron（定期実行処理）、mu-plugins、別PHPファイル、漏えい認証情報など、再感染の根本原因が残っている可能性が高い状態だからです。

この段階では、単純な削除作業ではなく「侵入経路の特定」「痕跡の横断調査」「安全な復旧ラインの判断」が必要になります。自社対応で止まりそうなら、早い段階で 障害復旧サービス に切り替えたほうが、結果として停止期間とブランド毀損を抑えやすくなります。

また、外部から見える範囲のリスクを急ぎで把握したい場合は、無料セキュリティ診断 で初期確認を進めるのも有効です。

復旧後にやるべきこと（恒久対応）

見た目が直っても、復旧は終わりではありません。WordPress公式FAQとHardeningガイドに沿って、侵入後の後処理まで行います。

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

対象は次のとおりです。

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

WordPress公式のPassword Best Practicesでも、強く長い一意のパスワードが推奨されています。

2. WordPress本体・テーマ・プラグインを最新化する

古いバージョンの放置は再侵入リスクを上げます。復旧後は、残すもの・削除するものを整理したうえで最新化してください。

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

WordPress公式FAQでは、wp-config.php の秘密鍵（AUTH_KEY など）を更新することで、現在ログイン中のすべてのユーザー（攻撃者を含む）が強制的にログアウトされると説明されています。盗まれた認証クッキーが無効化されるため、侵害後に必ず実施すべき手順です。

4. Search Console で再審査を依頼する

GoogleのSecurity Issues report に警告が出ていた場合は、修正後にレビュー申請が必要です。Googleは、何を除去し、どの脆弱性を塞いだかを説明して申請するよう案内しています。

5. ログを保全し、侵入経路を特定する

アクセスログ、エラーログ、サーバーログは削除せず保全します。「直ったから終わり」ではなく、「どこから入られたか」まで見ないと再発防止になりません。

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

リダイレクトハックは、復旧作業より「普段の運用不足」で被害が拡大しやすい障害です。再発防止は次の観点で設計します。

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

同一サーバー内だけのバックアップでは、改ざんや障害に巻き込まれることがあります。日次取得に加え、世代を分け、保存先も分散させてください。

2. 更新フローを定期業務にする

WordPress本体、テーマ、プラグインは「時間があるときに更新」ではなく、定例作業に落とし込みます。更新前バックアップ、検証、反映の順序を固定すると事故が減ります。

3. ログイン保護を強化する

WordPress公式のHardeningガイドやパスワード指針に沿って、次を検討します。

  • /wp-login.php へのIP制限
  • Basic認証（追加のID/パスワード認証）
  • 2要素認証

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

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

5. ファイル変更検知（FIM）を導入する

FIM（File Integrity Monitoring: ファイル改ざん検知）は、wp-config.php やテーマファイルの不審な更新を早期発見するのに有効です。少なくとも、重要ファイルの更新通知が飛ぶ状態は作っておきたいところです。

6. 継続監視を体制化する

社内で更新や監視を回し切れない場合は、復旧後の予防フェーズを 運用保守サービス のような継続支援に載せる方法もあります。押し売りではなく、属人化を減らす手段として考えると判断しやすくなります。

まとめ

WordPressの不正リダイレクトは、見た目の転送を止めるだけでは復旧完了とはいえません。

改ざんは「削除」で終わりではなく、「侵入経路の特定」と「再発防止」まで含めて初めて復旧です。

対応時は、次の順序を崩さないでください。

  1. まず症状を固定する
  2. .htaccess や wp-config.php、テーマ、mu-plugins、wp_options を優先確認する
  3. プラグイン・テーマ・データベースを順番に切り分ける
  4. 再発やGoogle警告があるなら早めに専門家へ切り替える

焦ると .htaccess だけを直してしまいがちですが、それでは根本原因を残しやすくなります。順序を守って切り分け、それでも不安が残る場合は、無理に抱え込まない判断が重要です。

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

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