サイト改ざんからのSEO順位復旧|8万件のインデックス汚染2ヶ月改善実例

「改ざんの駆除は終わりました。サイトも正常に動いています。でも、検索順位がまったく戻らないんです」
このご相談を、私たちは本当によくいただきます。
セキュリティ会社に頼んで不正ファイルを除去してもらった。 サイトの表示も問題ない。 なのにGoogle Search Consoleを開くと、数万件の「クロール済み-インデックス未登録」が残ったまま。 検索からの流入は減り続け、売上にも響いている――。 こういう相談です。
最初にはっきりさせておきたいのは、改ざん対応には性質のまったく違う2つの作業がある、ということです。
- システム面の復旧 — 不正ファイルを駆除して侵入経路をふさぐ。セキュリティ会社の領域で、もう一度ハッキングされない状態をつくる作業
- SEO順位の復旧 — 改ざん中にGoogleへ登録された大量の不正URLの評価を消し、落ちた検索順位を取り戻す。検索からの集客を戻す作業
このふたつは、目的も手法もまるで別物です。
多くの方が「改ざんさえ駆除すれば順位は元通りになる」と考えています。 けれど、駆除はあくまでスタートライン。Googleの評価を回復させる作業は、ここから別途始まります。
この記事では後者、つまり順位復旧のほうに焦点を当てます。 実際に86,600件という膨大なインデックス汚染と大幅な順位下落を抱えたWordPressサイトを、約2ヶ月でほぼ正常化させた事例をもとに、駆除後も順位が戻らない理由、そもそも戻せるサイトかどうかの見極め方、そして具体的な技術対策まで、実際のデータと一緒に書いていきます。
サイト改ざんで順位が落ちるとき、サイトの中で何が起きているのか
改ざん・ハッキングの被害に遭い、不正ファイルを駆除し終えたのに順位がいっこうに戻らない。 この現象には、ちゃんと理由があります。
改ざんで最も多いのは、運営者がまったく気づかないうちに偽ページを大量に自動生成されるタイプの被害です。 今回の事例では、約86,600件もの不正URLが裏で作られていました。
生成されるURLにはいくつかの典型があります。
?_gl=1*rgknbr*_ga*MzY3MjE1MDc…のように、やたらと長いパラメータがぶら下がったURLdetail.phpやshopdetailを含む、いかにもECサイトの商品ページに見せかけたURL
いずれも詐欺サイトや偽の商品ページへ訪問者を誘導するために作られたもので、ひとつの改ざんが短期間に数万から数十万のURLを量産していきます。 日本語スパムURL(いわゆる Japanese Keyword Hack)として、自社サイトには存在しないはずの日本語ページが検索結果に並ぶケースも、構造としては同じです。
こうして生成された不正URLをGoogleが巡回すると、Search Console上では「クロール済み-インデックス未登録」というステータスが大量に並びます。 これは、Googleのクローラーがページを見には来たものの、「検索結果に載せる価値はない」と判断して保留にした状態を指します。
そのページ単体が検索に出ないだけなら、まだ実害は限定的です。 問題は、低品質なURLがサイト全体に占める割合が大きくなると、Googleがドメインそのものを「質の低いページばかりのサイト」と見なし始める点にあります。
8万件の詐欺ページに対して本来の記事が1,000記事しかなければ、正常なコンテンツはわずか1%ほど。 本来評価されるべき記事が、大量のノイズの中に埋もれてしまうわけです。
ここから、本来上位に表示されていた正常なページの順位まで連動して落ちていきます。 検索流入が前月比で6〜8割減り、主要キーワードで10位以内だったページが圏外まで沈む。 これが、改ざんを起点にした典型的な順位下落です。
では、なぜ不正ファイルを駆除しても順位が戻らないのか。 理由はシンプルで、駆除はサーバー上のマルウェアを消す作業であって、Googleのデータベースに刻まれた不正URLの記録までは消えないからです。
駆除によって新しい不正ページが増えるのは止まります。 けれど、すでに登録された数万件のURLはそのまま残り、Googleは定期的に再クロールしては「このサイトはまだ低品質ページを大量に抱えている」と認識し続ける。 スパム判定は自動では外れません。
だからこそ、駆除のあとに「Googleに残った記録を能動的に消しにいく」作業が必要になります。

「改ざんによる下落」か「ただのSEO変動」か、まず切り分ける
順位が落ちたとき、原因がSEO施策側にあるのか、それとも改ざんなのかを見極めることが復旧の出発点です。
通常のSEO変動なら、コンテンツや内部対策を見直せば改善の余地があります。 けれど改ざんが原因の場合、記事をいくら直しても順位は戻りません。 打ち手がまったく違うので、最初の切り分けを間違えると時間を大量に浪費します。
見分けるポイントを並べると、こうなります。
| 確認場所 | 通常のSEO変動 | 改ざんを疑うサイン |
|---|---|---|
| Search Console「セキュリティの問題」 | 通知なし | ハッキング・有害な挙動の通知が出ている |
site:自社ドメイン 検索 | 見覚えのあるURLだけ | 見覚えのない日本語ページや偽ECページが急増 |
| 検索パフォーマンスの流入キーワード | 事業に関連するキーワード | 無関係な商品名・海外スパムワードが急に増える |
| 検索結果のタイトル・説明文 | 自社が設定した内容 | 不自然な日本語や別事業の文言に書き換えられている |
| サーバー内のファイル | 変化なし | 見覚えのないファイルやディレクトリが増えている |
順位が落ちたからといって、すぐに「SEOが悪かった」と決めつけないことです。
まずSearch Consoleのセキュリティ警告と site: 検索を見る。 右側のサインに心当たりがあれば、それはSEOの問題ではなく改ざんの問題なので、駆除と順位復旧を前提にした対応へ切り替えてください。
順位を戻せるサイトか、最初に見極める
技術論に入る前に、そもそも戻せるサイトなのかを見ます。 掃除しても、Googleとの関係がどこまで壊れているかで難易度がまるで変わるからです。
私が最初に確認するのは次の3つ。
- ブラックリスト登録 — セーフ ブラウジングに載っていないか(Search Consoleの「セキュリティの問題」で確認)
- 手動による対策 — 人の目で課されたペナルティがないか(同じく「手動による対策」レポート)
- 正常な記事の生存 — 改ざんと無関係な本来の記事が、まだ圏外に飛んでいないか(
site:検索)
3つとも「なし」なら話は単純です。 順位を落としているのは大量の不正URLというノイズだけなので、それを消せば本来の評価が戻る。 今回のサイトもこの状態だったから、ドメイン移行ではなく掃除を選びました。
どれかに当たっていると一手間増えます。 ブラックリストや手動ペナルティは自動では解けず、駆除後に再審査リクエストを出してGoogleに「直した」と認めさせるまで順位は戻らない。 正常な記事まで圏外なら、ドメインの信頼そのものが削れているサインで、復旧は長引くと見ます。
【事例】86,600件のインデックス汚染と順位下落からの復旧記録
2024年10月初旬、Search Consoleのアラートで異常を検知しました。 中を確認して、想定以上の状況だとわかります。
インデックス未登録のURLが約86,600件、そのすべてが「クロール済み-インデックス未登録」。 検索流入は前月比で約65%減り、5位以内に入っていた主要キーワードのページは20位より下、つまり実質圏外まで落ちていました。
さらに、新しく投稿した記事も48時間経ってもインデックスされない。 新規ページがなかなか拾われないのは、ドメイン全体の信頼が下がっているときの典型的な症状です。
不正URLのパターンを分けると、?_gl=1*rgknbr*_ga*… 形式が約62,000件、detail.php?id=xxx 形式が約18,000件、shopdetail?item=xxx 形式が約6,600件。 どれも偽ECサイトやフィッシング詐欺への誘導ページでした。

このとき、新規ドメインへの全面移行も一度は検討しました。 汚れたドメインを捨ててやり直す、という発想です。
ただ計算してみると、移行対象は約1,200記事、必要な301リダイレクトは約3,500URL、しかも積み上げてきた被リンクを失えばドメインの評価も下がります。 作業工数は最低でも3〜4ヶ月、コストは数百万円規模。 費用対効果がまったく見合いませんでした。
そこで方針を切り替え、現ドメインを維持したまま、技術対策でGoogleの評価を回復させることにしました。 先ほどの3つの目安――ブラックリスト未登録、手動による対策なし、本来の記事は圏外化していない――を確認できていたので、「掃除すれば戻せる」と判断したわけです。 結果から言えば、この判断は正解でした。
駆除のあとにやった、順位復旧のための技術対策
Googleの評価を回復させるには、性格の違う複数の対策を組み合わせる必要があります。 どれか一本だけだと効きが弱く、復旧に半年以上かかることもあります。 今回は次の3つを同時に走らせました。
robots.txt で、これ以上の無駄なクロールを止める
まず、今後Googleが不正URLを巡回しないよう、robots.txtで制御をかけます。

robots.txt(ロボッツテキスト)とは、Googleなどの検索エンジンやAIのクローラー(ロボット)に対し、ウェブサイト内のどのページやファイルへのアクセスを許可・禁止するかを指示するためのテキストファイルです。
robots.txt の概要とガイド | Google 検索セントラル | Documentation | Google for Developers
robots.txtの扱いには慎重さが要ります。 Google Search Centralでも、robots.txtの用途として、クローラーのリクエストでサーバーが過負荷になっている場合のクロール管理や、サイト内の重要でないページ・類似ページのクロールを防ぐこと、と案内されています。
今回はまさにこれに当てはまりました。 8万件超の不正URLにGoogleのクローラーが無駄なリソースを割いている状態で、これは明らかに「重要でない・類似したページ」ですし、大量のクロールがサーバーに負荷をかけている可能性もありました。
「robots.txtをむやみに使うべきではない」という意見はもっともで、平時なら私もそう言います。 ただ今回のように理由がはっきりしている場面では、状況を見極めたうえで臨機応変に使うべきだと考えています。
実装では、WordPress標準の保護設定に加えて、改ざんが生成した特定のURLパターンをブロックしました。
User-agent: *
Disallow: /*?_gl=
Disallow: /*/detail.php
Disallow: /*/shopdetail
Disallow: /*_ga*ワイルドカード(*)でパターンごとまとめて止めつつ、既存の正常なページに巻き添えが出ないよう、対象パターンは慎重に選んでいます。 更新後はSearch ConsoleのURL検査ツールですぐにGoogleへ通知し、robots.txtテスターで意図どおり動くかを確認しました。
これで新規クロールの無駄が減り、クロールバジェットを正常なページへ集中させられます。 それと同時に、Googleに対して「このサイトは問題を認識して手を打っている」というシグナルを送る意味もあります。
410 Gone で、既存の不正URLに「もう存在しない」と宣言する
robots.txtが未来のクロールを止める対策だとすれば、すでにGoogleが巡回済みのURLには別の手当てが要ります。 そこで、改ざんが生成したURLへのアクセスに対して 410 Gone のステータスコードを返す専用のWordPressプラグイン(sm-malware-cleanup)を開発して入れました。
ここでのポイントは、404ではなく410を選ぶことです。 両者はGoogleにとって意味がまったく違います。
| ステータスコード | Googleの解釈 | 主な用途 | 再クロールの扱い |
|---|---|---|---|
| 404 Not Found | 一時的に見つからない | ページが一時的に利用不可 | 将来また見に来る |
| 410 Gone | 完全に削除された | 永久に消したコンテンツ | インデックスから速やかに削除 |
404を返すと、Googleは「いずれ復活するかもしれない」と考えて、しばらく再クロールを続けます。 一方410は「このURLに二度とコンテンツは戻らない」という強い宣言です。 Googleは410を受け取ると、そのURLを優先的にインデックスから外す処理に回します。
だから不要なクロールが早く減り、その分だけ正常なページの再評価が前に進みます。 404のまま放置していたら、ここまで早くは戻らなかったはずです。
実装にあたっては、正常なページを巻き込まないようパターンマッチを厳密にし、プラグイン自体は軽量に保ってサイト速度に影響を与えないよう配慮しました。 どのURLに対して410を返したかはログに記録し、後から検証できるようにしてあります。
//独自開発した sm-malware-cleanup プラグインの例
// プラグインの核心的な処理(簡易版)
function handle_malware_urls() {
$request_uri = $_SERVER['REQUEST_URI'];
// マルウェアパターンの検出
if (strpos($request_uri, '?_gl=') !== false ||
strpos($request_uri, 'detail.php') !== false) {
status_header(410); // 410 Goneを返す
nocache_headers();
die('This content has been permanently removed.');
}
}
add_action('init', 'handle_malware_urls');
410プラグインを自作するなら、ここに注意
このプラグインの実装は、見た目より神経を使います。 本番で使うなら、最低でも次のあたりは考える必要があります。
- 誤検知を避けるための、正規表現による厳密なパターンマッチング
- データベース負荷を抑えるキャッシュの仕組み
- 管理画面からパターンを追加・編集できる導線
- 410を返したURLのログ記録と分析
- 既存プラグインとの競合チェック
- SQLインジェクションなどのセキュリティ対策
実装を誤ると、正常なページにまで410を返してしまい、サイト全体がインデックスから消えるという取り返しのつかない事故になります。 自信がなければ、ここは専門家に相談したほうがいい部分です。
Search Console から、直接URLの削除をリクエストする
3つ目は、Search Consoleの「削除」ツールからの直接申請です。 2024年10月10日に、*?_gl=* のようにURLパターンを指定し、削除理由を添えてリクエストを出しました。

ただし、この削除リクエストには性格上の限界があります。 処理に数日から数週間かかること、一度に申請できるパターンに上限があること、必ず承認されるわけではないこと、そして何より、これは一時的な対処であって恒久対策ではないこと。
Googleの削除ツールはあくまで「一時的に検索結果から隠す」性質のもので、robots.txtと410 Goneの実装があってはじめて、効果が持続します。 単独でやっても、しばらくすると戻ってきてしまうわけです。
実際の処理の進み方も書いておきます。 申請から1週間後はまだ審査中のまま。 2週間後に一部のパターンが承認されて削除処理が始まり、3週間後にはすべてのリクエストが処理完了しました。 即効性はないので、申請したら他の対策を進めながら待つ、という感覚です。
この3つは、それぞれ役割が違います。 robots.txtは「今後は来ないでください」、410 Goneは「もう何もありません」、削除リクエストは「直接Googleにお願いします」。
別々の角度から同じゴールへ向かわせることで、Googleに「このサイトは本気で問題に取り組んでいる」と受け取らせる。 3本を同時に回したことが、復旧の速さにつながりました。
どれくらいで戻るのか|実際のタイムライン
「駆除のあと、どのくらいで順位は戻りますか」。 これは本当によく聞かれます。
今回は対策開始から約2〜3ヶ月で大きな改善が出ました。 インデックス未登録件数の推移はこうです。

| 時期 | 未登録件数 | 主な変化 |
|---|---|---|
| 2024/10/10(対策開始) | 約86,600件 | robots.txt更新・410プラグイン実装・削除リクエスト申請 |
| 10月末(約3週間後) | 約78,000件(-10%) | わずかに減少。まだ大きな動きはない |
| 11月中旬(約5週間後) | 約52,000件(-40%) | 急に減り始める。Googleが対策を認識した兆し |
| 12月初旬(約7週間後) | 約18,000件(-79%) | 加速度的に改善。一部キーワードで順位回復の気配 |
| 12月中旬(約2ヶ月後) | 約1,000件(-98.9%) | ほぼ正常化。検索流入が回復傾向へ |
| 2025/1月(約3ヶ月後) | 約500件 | 主要キーワードで上位に復帰。流入が感染前の約90%まで戻る |
数字の動き方には、はっきりした波がありました。
最初のひと月は、正直に言えば不安な時期です。 Googleのクローラーが変更を認識するまでにはタイムラグがあって、減りは週に数百件程度。 「本当に効いているのか」と疑いたくなる期間で、ここで焦って余計なことをすると逆効果になりかねません。
ところがふた月目に入ると、ある日を境に減少が一気に加速します。 Googleの自動システムが「この問題は解消された」と学習し始めたサインで、週に数千から1万件単位で消えていく。
三ヶ月目以降は落ち着いて、残った未登録URLが少しずつ減りながら、正常なページの順位が着実に戻り、新規記事も24時間以内に拾われるようになりました。
Googleの公式ドキュメントにも、スパムポリシーを守っていることを自動システムが学習するには数ヶ月かかることがある、と書かれています。 今回は8.6万件という量だったので相応の時間はかかりましたが、それでも想定の範囲(約3ヶ月)に収まりました。
最後にひとつ、正直なところを書いておきます。 どのページをどの順位で出すかを最終的に決めるのはGoogleであって、私たちが特定の順位を保証できるものではありません。
私たちにできるのは、Googleが正しく再評価できる「きれいな状態」を技術的に作ること。 逆に言えば、不正URLという評価低下の根本原因を取り除かない限り、サイトが正しく評価し直されることもない。 順位復旧とは、Googleに正しく判断してもらうための土台づくりだと考えています。
なぜ戻せたのか
成功の要因を振り返ると、まず複数の対策を同時に走らせたことが大きい。 robots.txtで今後を止め、410で既存URLの削除を明示し、削除リクエストで直接後押しする。
どれか一本では「やってますアピール」として弱く、3本そろってはじめてGoogleに本気度が伝わります。
次に、404ではなく410を選んだこと。 「これらは意図的に消したURLで再クロールは不要」と明確に伝えられたことが、復旧スピードを大きく左右しました。 地味ですが、HTTPステータスコードの選択ひとつでここまで差が出ます。
そして、週に1回はSearch Consoleの「クロール済み-インデックス未登録」の件数を確認し続けたこと。 数字で進捗を追っていたからこそ、ふた月目の急減を「効いている証拠」と判断でき、不安な一ヶ月目にも余計な手を加えずに済みました。 モニタリングは派手さこそありませんが、復旧作業では欠かせない部分です。
戻した順位を維持するために、再発を防ぐ
順位を取り戻しても、侵入経路が残っていれば改ざんは再発し、また同じように順位が落ちます。 順位復旧と並行して、再発防止まで手を入れておくことが大事です。
やっておきたいのはこのあたり。
- WordPress本体・プラグイン・テーマを更新し続ける運用に変える。使っていない拡張機能は無効化で止めず、削除まで
- 管理画面・FTP・サーバー・DBの認証情報を棚卸しし、不要なアカウントや強すぎる権限を整理する
site:検索とSearch Consoleの「セキュリティの問題」を定期的に見る習慣をつける- ファイルとデータベースのバックアップを取り、いつの時点まで戻せるかを把握しておく
最後のバックアップには注意点があります。 改ざんが疑われたとき、原因を調べないまま古いバックアップを戻すと、改ざん済みの状態に巻き戻すだけ、という失敗もよくあります。
もうひとつ。 改ざんを「SEO担当だけの問題」にしないことです。
実際には検索評価だけでなく、ユーザーの信頼、ブランド、問い合わせ対応、社内の工数まで影響が広がります。 Web担当・制作会社・情報システム・必要なら経営層まで、異変が起きたときにすぐ連携できる体制を作っておくほうが、結局は早く止められます。
よくある質問(FAQ)
- サイト改ざんの駆除後、検索順位はいつ回復しますか?
-
改ざんの規模によりますが、適切な技術対策を打てば2〜3ヶ月程度で大きな改善が見られます。
Googleの自動システムが学習するまでに数ヶ月かかることがあるためで、本事例では対策開始から2ヶ月で98.9%の改善でした。 ただし最初のひと月はほとんど動かないことが多く、ここで焦らないことが大切です。
- 自分のサイトが順位を戻せるかどうか、判断する方法はありますか?
-
目安として、ドメインがブラックリストに登録されていないか、Search Consoleで「手動による対策」を受けていないか、本来の正常な記事が圏外になっていないか、の3点を見ます。
いずれにも該当しなければ、評価低下の原因は不正URLの大量生成に絞られている可能性が高く、掃除すれば元の順位に戻せる見込みが十分にあります。 逆にブラックリスト登録や手動による対策があると、解除申請という別ステップが必要になり、難易度と期間が上がります。
- 駆除は済んだのに、順位下落が止まりません。何が原因ですか?
-
不正ファイルを駆除しても、Googleのデータベースに残った数万件の不正URLがサイト評価を下げ続けているためです。 駆除(システム復旧)とは別に、robots.txt・410 Gone・URL削除リクエストによる順位復旧の作業が必要になります。
- 404ではなく410 Goneを使うべき理由は?
-
404は「一時的に見つからない」という意味で、Googleは将来また見に来る可能性があります。 410 Goneは「完全に削除した」という明確なシグナルなので、Googleはインデックスから速やかに外します。 改ざんで生成された不要URLには410が適切です。
- 新しいドメインに移行したほうが早くないですか?
-
小規模サイトなら選択肢のひとつです。 ただ大規模サイトでは、全コンテンツの移行、リダイレクト設定、被リンクの損失まで考えると現実的でないことが多い。 本事例(1,200記事・3,500リダイレクト・数百万円規模)でも現ドメイン維持を選び、復旧できました。
- 自分で対応できますか?業者に頼むべきですか?
-
技術的な知識があれば自力でも可能ですが、WordPressのファイル構造とPHP、robots.txtとHTTPステータスコードの正確な理解、Search Consoleの高度な運用、正規表現によるパターンマッチング、サーバーログの分析まで一通り必要です。
誤った実装は正常ページまで検索結果から消す事故につながりますし、改善しないままトライ&エラーを繰り返す間の機会損失(売上減)が、対策費用を上回ることもあります。 検索流入が売上に直結する企業サイトやECサイトでは、早めに専門家へ相談したほうが結果的に安く済む場面が多いです。
まとめ
サイト改ざんによる順位下落からの復旧で、押さえておきたいのはこの5点です。
- 改ざんの駆除は第一歩に過ぎず、落ちた順位を戻すにはシステム復旧とは別の技術対策が要る
- その前に、ブラックリスト登録・手動による対策・本来の記事の圏外化の3点を見れば、戻せる見込みかどうかは判断できる
- 具体策はrobots.txt・410 Gone・URL削除リクエストを同時に走らせること
- 復旧には2〜3ヶ月かかる。最初のひと月は動かないので、焦らずモニタリングを続ける
- 侵入経路をふさいで再発を防がない限り、せっかく戻した順位もまた落ちる
「改ざんを駆除すれば順位は戻る」という思い込みは、復旧を遠回りにします。 正しい対策を打ち、中長期で見守る。 それができれば、下落した検索順位は確実に回復へ向かいます。
作業代行・開発ならおまかせください
この記事で扱った作業について、構築から運用まで対応可能です。
参考情報
WordPressで構築されたサイトを対象とし、不正ファイルの駆除(セキュリティ会社の領域)が完了済みであることを前提とします。被害規模やインデックス汚染の件数、手動ペナルティの有無によって工数と費用が変動するため、まずはSearch Consoleの状況を拝見したうえで無料でお見積りいたします。
対応内容
- 改ざん被害状況の診断(改ざん起因の下落かSEO変動かの切り分け)
- Search Consoleのインデックス汚染URL調査・パターン分類
- 不正URLパターンを対象としたrobots.txtの設計と実装
- 410 Goneを返すWordPress専用プラグインの開発・導入
- Search Console「削除ツール」からのURLパターン削除申請
- ブラックリスト・手動による対策の有無チェックと再審査リクエスト対応
- 正常ページを巻き込まないパターンマッチの検証・テスト
- クロールバジェット最適化とインデックス回復のモニタリング
- 復旧経過レポートの作成(インデックス件数・流入推移の可視化)

