WordPress保守のトラブル事例13選と対処法をプロが解説

「自分で不正ファイルを消したのに、また改ざんされた」
「保守をお願いしていた会社と連絡が取れなくなった」

サイト引越し屋さんには、このようなWordPress保守にまつわるご相談が毎月たくさん届きます。

トラブルの入り口は大きく2つ。ひとつは更新やセキュリティ対策を後回しにしていたケース、もうひとつは保守会社に任せていたものの、契約の中身や名義、対応範囲を把握していなかったケースです。

この記事では、2017年1月のサービス開始から累計3,500件以上のWordPress案件に対応してきたサイト引越し屋さんが、実際にご相談いただいた13の事例をもとに、何が起きて、どう対処したのかを解説します。お困りの症状に近い事例から読み進めてください。

WordPress保守のトラブルは「放置」と「任せきり」から起きる

13の事例を並べてみると、トラブルの原因は「保守をしていなかった」ことだけではありません。

保守会社と契約していても、サーバーやドメインの名義、更新の実施状況、バックアップの保管場所を発注側が知らないままだと、いざというときに身動きが取れなくなります。

まずは本記事で紹介する事例の全体像です。

分類	事例	ご相談時の症状	根本的な原因
保守を怠っていた	事例1	削除したはずの不正ファイルが再発	自己流の駆除、汚染されたバックアップ
	事例2	約20ドメインが同時に被害	1サーバーに多数のサイトを集約
	事例3	検索結果に不正なページが大量表示	使っていないサイト・テスト環境の放置
	事例4	PHPを上げると管理画面に入れない	数年分の更新の先送り
	事例5	プラグインのせいでPHPを更新できない	開発が止まったプラグインへの依存
	事例6	誰もWordPressの中身が分からない	担当者の退職と引き継ぎ不足
保守会社に依頼していた	事例7	管理会社と連絡が取れない	ドメイン・サーバーの管理を丸ごと委託
	事例8	解約するとサイトが消えると言われた	サイトが保守会社の環境に依存
	事例9	移転に業者の許可が必要	サーバー・ドメインが業者名義
	事例10	オリジナルテーマでPHPを上げられない	制作会社しか触れない独自仕様
	事例11	保守を断られた・打ち切られた	保守会社の対応範囲と自社環境のずれ
	事例12	本当に守られているか分からない	作業内容やレポートが見えない契約
	事例13	メールの移行だけ宙に浮いた	移転を請け負った業者の対応範囲外

＝＝＝

サイト引越し屋さんではWordPressの保守管理を代行しております。
詳しくは、下記のサービス詳細をご覧ください。

>>WordPress保守管理サービス詳細はこちら

保守を怠ってトラブルになった事例6選

ここからは、WordPressの更新やセキュリティ対策が後回しになっていたことでトラブルに発展した6つの事例を紹介します。改ざん被害の多くは、サーバー会社から「不正なファイルを検知したため制限をかけた」という通知が届いて初めて気づくケースでした。

また、改ざんがなくても、何年も更新していないサイトはPHPのサポート終了をきっかけに一気に動かなくなるリスクを抱えています。

事例1 自分で不正ファイルを消したのに再発し、バックアップも汚染されていた

現場で起きたこと

WordPressの公式サイトと、EC-CUBEのネットショップを同じサーバーで運営していた洋菓子店様からのご相談です。秋ごろに一部ファイルの不審な動きに気づき、サーバー会社と相談しながら怪しいファイルを手作業で削除して「一旦は除去できた」と判断されていました。

ところが約1か月後、サイトは表示されているのにお問い合わせの通知メールが送れなくなるという形で再発します。その後サーバー会社から正式に不正ファイル検知と制限実施の連絡が届き、ここで改ざんがはっきりしました。

サーバーの自動バックアップで最も古いデータも、すでに改ざん後の状態である可能性が高い状況でした。

原因は見えている不正ファイルだけを消したこと

改ざんされたサイトでは、表に出ている不正ファイルとは別に、再侵入用の「バックドア」が仕込まれていることが少なくありません。

目に見えるファイルだけを消しても裏口が残るため、しばらくすると同じ被害が繰り返されます。発覚が遅れるほど、正常な状態のバックアップも保存期間の外に押し出されてしまいます。

対処法

弊社で調査した結果、改ざん前の正常なバックアップが存在しないため元の状態にそのまま戻すことは技術的に成り立たないと判断しました。そこでお客様と相談のうえ、次の方針に切り替えています。

• 不正ファイルを除去し、プログラム一式をクリーンな状態で再構築する
• 既存のデータベースを接続し直し、記事や商品データを活かす
• 公式サイトとネットショップの分離について、リスクと費用を比較した選択肢を提示する

私たちはこれを「過去の状態へ戻す復元」ではなく「安全な状態へ再構築する復旧」と呼んでいます。

今回はEC-CUBEも公式配布が終了したバージョンだったため、配布中のバージョンへ移行し、それに合わせてPHPも7.4から8.1へ引き上げました。ご相談から作業完了までは、正式なご依頼後わずか数日でした。

被害に気づいたら、ファイルを削除する前に専門業者へ相談するのが近道です。

事例2 1つのサーバーに約20ドメイン、侵入が全サイトに広がった

現場で起きたこと

グループ会社やブランドごとのサイトを、1つのレンタルサーバー契約にまとめて運用していた企業様のケースです。

サーバー会社から不正アクセスと脆弱性の悪用を指摘され、緊急の制限がかかった状態でご相談いただきました。不正ファイルを消してもバックドアが再設置される状態が続き、バックアップにも感染が及んでいる可能性があるとの報告を受けていました。

サーバー全体を調査したところ、被害は想像以上に深刻でした。不正な管理者ユーザーが作成されたログが残っており、そこから侵害が進んだと見られます。サブドメインやLP用のディレクトリにもWebからアクセスできる不正ファイルが置かれていました。

原因は1サイトの侵害がサーバー内の全サイトに波及したこと

同じサーバー契約の中では、各サイトのファイルが同じ権限で動いていることが多く、1サイトが乗っ取られると隣のサイトにも手が届いてしまいます。サイト数が増えるほど、更新が止まった古いサイトが1つ混ざる確率も上がります。

対処法

最優先のコーポレートサイトだけを現行サーバーで直すことも技術的には可能でした。ただ、他のドメインや共通領域に残った不正ファイルから再感染する可能性が高いため、クリーンな別サーバーへ移したうえで復旧する方針をご提案しました。

1. 既存ユーザーの権限をいったんすべて無効化する
2. マルウェアスキャンを複数の方法で実施し、検知なしを確認する
3. WordPress本体・プラグイン・テーマを最新版にし、PHP 8.3での動作を確認する
4. セキュリティプラグインとサーバー側のWAFを有効にする
5. Webサイトだけを新サーバーへ切り替え、メールは旧サーバーに残して業務を止めない

復旧の目安は1サイトあたり2〜4日で、複数サイトは並行して進めました。再発防止として、今後は1サーバーに置くサイトを1〜5程度にとどめ、重要なサイトはサーバーを分けて運用することをおすすめしています。

事例3 使っていないサイトやテスト環境が放置され、不正ページが検索結果に並んだ

現場で起きたこと

外部からの攻撃でサイトが見られなくなり、サーバー会社の復元機能を試しても直らなかったという企業様からのご相談です。調査すると、本番サイトとは別に、サーバーの初期ドメイン領域に古いテストサイトが残っており、そこもハッキング被害を受けていました。

本番サイトの復旧は翌日に完了しましたが、Google検索では存在しない不正ページが大量にインデックスされていました。別の企業様のご相談でも、もう使っていないサイトや初期ドメインの領域に大量の不正ファイルが置かれていたことがあります。

原因は「誰も見ていないWordPress」が残っていたこと

リニューアル前の旧サイトや検証用のテストサイトは、更新もログイン監視もされないまま残りがちです。攻撃する側から見れば、管理されていないWordPressは格好の入り口になります。

対処法

使っていないサイトはお客様に確認したうえで削除し、本番サイトの復旧後に周辺の後始末を行いました。改ざん被害では、サイトを直しただけでは終わらない作業が残ることがあります。

復旧後に必要になりやすい作業	放置したときの影響
Search Consoleでの不正URLの削除申請	検索結果に不正ページが表示され続ける
Webサイトのブラックリスト解除申請	ブラウザやセキュリティソフトに警告が出る
独自ドメインメールの迷惑メール判定の解除	取引先にメールが届かなくなる
不要なサイト・テスト環境の削除	同じ経路から再び侵入される

被害がどこまで広がっているのかを調査のうえ、適切に対処していくことが重要です。

事例4 何年も更新しておらず、PHPを上げると管理画面に入れなくなった

現場で起きたこと

何年も手をつけていなかったブログを再開しようとした方からのご相談です。WordPressは4.9系、PHPは7.4のまま。ダッシュボードから更新するとエラーになり、サーバーの管理画面でPHPを切り替えるとダッシュボードにアクセスできなくなっていました。

似たご相談は少なくありません。WordPress 5.6系のまま数年更新していなかった企業サイトや、PHPを最新にしたら表示が崩れたので慌てて7.4に戻したという個人の方もいらっしゃいました。

原因は古いテーマやプラグインが新しいPHPに対応していないこと

WordPress本体だけでなく、テーマやプラグインも当時のPHPを前提に書かれています。更新を何年も先送りすると、一度に上げなければならない差分が大きくなり、どこで動かなくなるのか予測しにくくなります。

今回のブログでは、使っているテーマがPHP 8.3に対応できるか不明で、テーマ変更も視野に入れる必要がありました。

対処法

このような状態のサイトで、本番環境をいきなり更新するのはおすすめしません。弊社ではバックアップとは別にテスト環境を用意し、最新の環境で動作を確かめてから本番へ反映しています。

検証の中で動かない部品が見つかった場合は、プログラムの調整、代替プラグインへの差し替え、該当プラグインだけのバージョン調整や停止など、サイトごとに対処を選びます。

さくらのレンタルサーバのようにPHPの設定がサーバー全体に効くサービスでは、対象サイト以外にも影響が出る点にも注意が必要です。

事例5 開発が止まったプラグインがPHPの更新を阻んでいた

現場で起きたこと

数年前に無料ブログからWordPressへ移行した際、URLを引き継ぐために導入したパーマリンク系のプラグインが何年も更新されておらず、そのせいでPHPを上げられないというご相談です。ブログは今も更新を続けていて、検索からのアクセスを失いたくないというご希望でした。

原因は移行時の「つなぎ」のプラグインがそのまま残ったこと

移行時に入れたプラグインは、役目を終えたあとも外すと表示が変わってしまうため、そのまま残されがちです。そのプラグインの開発が止まると、サイト全体が古い環境から抜け出せなくなります。

対処法

お客様のサーバー内にテスト環境を作り、次の2段階で進める方針をご提案しました。

• WordPressの設定変更などで、プラグインなしでも同じURL構造を保てないか検証する
• 難しい場合は代替プラグインを選定し、現在のURLと同じ構造を再現する

どうしてもURLが変わる箇所が出た場合は、301リダイレクトを設定して検索エンジンの評価を引き継ぎます。検証はすべてテスト環境で行うため、作業中も本番のブログは通常どおり更新していただけます。

事例6 構築担当者が退職し、誰もWordPressの中身を把握していない

現場で起きたこと

社内のエンジニアがWordPressで構築したものの、その方が退職し、構成を把握している人がいなくなったという企業様のご相談です。WordPressは4.9系のままで、ブログを書く社員からブロックエディタを使いたいという要望が出たことで、ようやく課題が表に出ました。

ほかにも「以前はWeb担当者がいたが今は不在で、何をすればいいか分からない」という企業様や、学生・講師向けのポータルサイトを運用する学校法人様から「古いプラグインを残したままメジャーアップデートすると何が起きるか分からない」というご相談もありました。

原因は保守の手順と情報が人に依存していたこと

ログイン情報、使っているプラグインの役割、カスタマイズした箇所が担当者の頭の中にしかないと、退職と同時にサイトはブラックボックスになります。社内にエンジニアがいても、WordPressの更新実績がなければ判断は難しいものです。

対処法

まず管理画面とサーバーの情報をお預かりし、WordPress・PHP・データベースのバージョン、テーマとプラグインの互換性を事前調査します。そのうえでテスト環境で更新を検証し、問題がなければ本番へ反映します。

更新が終わったあとの運用が担当者頼みに戻らないよう、月次でWordPress本体とプラグインを更新し、必要に応じてPHPやテーマも更新する保守契約に切り替える企業様も多くいらっしゃいます。

＝＝＝

WordPressのメンテナンス対応が面倒だと感じたらプロにお任せください！
>>WordPress保守管理サービス詳細はこちら

保守会社に依頼していたのにトラブルになった事例7選

ここからは、保守会社や制作会社に管理を任せていたにもかかわらず、トラブルに発展した7つの事例をご紹介します。

共通しているのは、技術的な不具合そのものより「誰の名義で、誰が何をしているのか」を発注側が把握していなかったことが、問題を大きくしていた点です。

保守会社を乗り換えるときや、契約を見直すときの参考にしてください。

事例7 管理会社と連絡が取れず、ドメインもサーバーも手が出せない

現場で起きたこと

ドメインとサイトの管理を任せていた会社が事務所を引き払い、連絡が取れなくなったという食品メーカー様からのご相談です。ドメイン登録サービスに問い合わせても、契約者は管理会社なので所有者である御社には対応できないと断られていました。

サーバーもすべて任せていたため、どのサーバー会社を使っているのかさえ分からず、ログイン情報も手元にありません。サイトの更新に使っていた管理画面のサービスも、数日後には閲覧できなくなりました。

原因はドメインとサーバーの契約を丸ごと委託していたこと

ドメインやサーバーを管理会社のアカウントで契約していると、会社がなくなった瞬間に正当な持ち主でも手続きができなくなります。日頃は問題がなくても、最悪のケースで初めて名義の重さが表に出ます。

対処法

弊社でドメインの登録者情報（Whois）を確認したところ、最も重要な登録者の欄が御社の情報になっていました。この場合、レジストラや上位の管理機関に事情を説明し、本来の管理者として移管を求められる可能性があります。

同時に、ドメインの回復が間に合わない場合に備えて、現行サイトが表示されているうちに同じテーマとコンテンツをもとにほぼ同じデザインで再構築する案もご提示しました。

サイトが閉鎖されてからでは参考にできる材料が残らないため、早めの判断が重要です。新しいサーバーは御社名義での契約をおすすめし、契約の事務手続きは弊社で代行しています。

事例8 保守を解約するとサイトが消えると言われた

現場で起きたこと

制作会社に作成と管理を依頼し、毎月1万5千円ほどの保守費用を払っていた方からのご相談です。

編集したい箇所はそれほど多くないため解約を考えたところ、「解約するとサイトは消滅する」と説明されたそうです。調べてみると、ドメインは制作会社が取得しており、メールアドレスも制作会社のサーバーで作られていました。

原因はサイトが保守会社の環境の上で動いていたこと

保守費用にサーバー代やドメイン代が含まれている場合、解約すると置き場所そのものがなくなります。「消える」と言われるのはそのためで、データを新しいサーバーへ移せばサイトは残せます。

対処法

ご本人の希望は「今まで通りサイトを使えること」でしたので、技術的なやり取りは弊社が間に入って進めました。

1. 現在の保守会社に、ドメイン・メール・サイトの管理状況を確認する
2. ドメインの移管に必要な認証コード（オースコード）を発行してもらう
3. サーバー移転とメールアドレスの移行を、業務が止まらない順番で進める

注意したいのは、解約すると現在の保守会社が行っている設定やサービスも外れる可能性がある点です。弊社では解約の前に、どんな対策が設定されているのかを確認していただくようお伝えしています。

事例9 サーバーもドメインも業者名義で、移管に許可が必要だった

現場で起きたこと

2018年に業者がWordPressで構築して以来、一度もアップデートしていないというご相談です。

管理画面には新しいバージョンが利用可能と表示されたまま。サーバーもドメインも業者の名義で登録されていて、移すには業者に認証コードを発行してもらう必要がありました。

今後はサーバー管理やDNS設定、メールアカウントを自分で扱える状態にしたいというご希望です。

知人に管理と支払いを任せていた方からは、レンタルサーバーは契約名義を第三者に譲渡できないため、新しく契約して移すしかないと言われたというご相談もありました。

原因は名義と実際の持ち主が一致していなかったこと

名義が他人のままだと、更新の判断も移転のタイミングも相手次第になります。サーバーの名義変更ができないサービスでは、引っ越しという形を取るしかありません。

対処法

新サーバーはお客様ご自身の名義で契約していただき、テスト環境で最新バージョンへ更新しながら移転する計画を立てました。同じサーバー会社の中で移す場合はドメインの登録し直しで数時間サイトが表示されない時間が生じるため、移転先は表示が止まらない組み合わせも含めてご提案しています。

事例10 制作会社のオリジナルテーマでPHPを上げられない

現場で起きたこと

以前業者に作ってもらったオリジナルテーマのため、PHPのバージョンアップができないというアウトドアショップ様のご相談です。今後を考えて市販のテーマに変更したいとのことでした。

別の企業様からは、制作会社しか触れない箇所が多く、移転のタイミングで自社でも編集できるようにしたいというご相談もいただいています。

原因は改修できる人が制作会社に限られていたこと

独自に作り込まれたテーマは、作った本人でないと手を入れにくいものです。制作会社との関係が薄れると、PHPのサポート終了に合わせた改修が誰にも頼めなくなります。

対処法

テーマ変更はリニューアルに近い作業になるため、すぐに結論を出さず2つの案を比較していただきました。

対応案	内容	向いているケース
現テーマを一部改修	PHPで動かない箇所を特定して直し、バージョンアップする	今のデザインに満足していて、費用を抑えたい
テーマを変更	市販テーマに載せ替え、不要なページも整理する	今後の更新を自社で行いたい、改修箇所が多い

どちらが適しているかはWordPress内部の構成次第です。ログイン情報をお預かりして中身を確認したうえで、費用と今後の運用の両面からご提案しています。

事例11 保守会社に「サーバーまでは対応できない」と断られた

現場で起きたこと

社内のサーバーでWordPressを運用していた製造業の企業様からのご相談です。

WordPressが全社のメール・DNS・プロキシと同じ筐体で動いており、脆弱性が突かれると全社インフラまで巻き込む「共倒れ」の状態でした。サイトヘルスでも、自動更新の失敗やデバッグログの露出など、致命的な問題を含む8項目が検出されていました。

制作会社に保守を打診したものの、サーバー運用まで含むと責任範囲が広く対応が難しいと断られていました。

また、技術系のNPO法人様からは、管理会社の都合で年度末に契約が打ち切られ、新しい保守先を探しているというご相談を受けたこともあります。

原因は保守会社の守備範囲と自社の環境が合っていなかったこと

保守会社によって、WordPressの更新だけを見る会社もあれば、サーバーやメールまで見る会社もあります。環境に対して守備範囲が狭いと、断られたり、必要な対策が抜け落ちたりします。

対処法

製造業の企業様には、単なるサーバー移転ではなく、社内インフラからWeb環境を切り離し、検証環境・バックアップ・監視・セキュリティ対策・緊急時の復旧までを含めた運用設計としてご提案しました。

移転先はWordPress専用のレンタルサーバーとし、移転前にテスト環境で現在のサイトを再現して検証します。移転後は24時間365日の死活監視と定期的な更新を保守契約で引き継いでいます。

一方、NPO法人様はサーバーをご自身の名義で契約されていたため、データを移す必要はなく、管理体制だけを引き継ぐ形で済みました。名義が自社にあるかどうかで、乗り換えの手間と費用は大きく変わります。

事例12 保守の中身が見えず、本当に守られているか分からない

現場で起きたこと

公益財団法人様から、現在の保守会社はセキュリティ対策や定期レポート、改善提案が十分ではないと感じているため、乗り換えを検討したいというご相談をいただきました。

まずは今の保守会社がどこまで対策しているのかを知りたいとのことで、弊社エンジニアが管理画面とFTPの範囲で簡易調査を行いました。

調査で分かったこと

結果は「何もしていない」わけではありませんでした。できている対策と、確認や改善が必要な点が混在していたのです。

項目	確認できた状態	評価
サーバー側のWAF	疑似的な攻撃文字列の多くを403で遮断	機能している
管理画面へのアクセス	IPアドレス制限とログインURLの変更を併用	機能している
バックアップ	毎週自動で取得、3世代を確認。保存先は同じサーバー内のみ	外部保管と復元テストの確認が必要
更新状況	WordPress本体と主要プラグインで11件の更新通知が残っている	定期更新の実施状況を確認する必要あり
サーバー環境	データベースが古いバージョンとしてサイトヘルスで警告	サーバー会社・管理会社への確認が必要
デバッグ設定	エラーを画面に表示する設定が有効	本番環境では無効化が望ましい

対処法

調査結果をそのままお伝えし、管理会社の監視体制やWAFのログ確認など、権限の外にあって判断できない項目も明記しました。

保守会社を評価するときは、印象ではなく「更新は月に何回、どの環境で検証しているか」「バックアップはどこに何世代あり、復元を試したことがあるか」を具体的に確認するのが確実です。

バックアップがあっても、別の場所に保管され、実際に戻せることが確かめられていなければ、事故のときに役に立ちません。私たちはこれを「復旧力」と呼び、保守を見直すときの重要な指標にしています。

事例13 移転を頼んだ業者にメールの移行はできないと言われた

現場で起きたこと

採用サイトの改修を進めようとしたところ、WordPressのバージョンが古く、さらにサーバーがPHP 8に対応していないことが分かった企業様のケースです。

サーバーの変更を決め、移転を別の業者に依頼しましたが、メールサーバーの移管は別見積もりとして保留に。Webサイトの移転が終わる直前になって改めて相談すると、その業者から難しいと返答され、メールの移行だけが宙に浮いてしまいました。

原因は依頼の範囲を最初に決めていなかったこと

サーバーを移すと、同じドメインで使っているメールも影響を受けます。サイトとメールを別々に考えていると、最後にメールだけが取り残され、業務に直結する部分が止まりかねません。

対処法

弊社ではメール移行のみをお引き受けし、2つのドメインで合計40件ほどのアカウントを整理するところから始めました。どのアカウントがどのドメインに属するか、メールソフトの接続方式はPOPかIMAPかを一覧で確認し、移転先サーバーの情報をお預かりしたうえで切り替えています。

接続方式による注意点はPOPとIMAPの違いやメールサーバー手順を解説したこちらの記事も参考にしてください。

＝＝＝

WordPressのセキュリティ対策が不安な場合はプロへ任せるのが安心です。
>>WordPress保守管理サービス詳細はこちら

事例から分かるWordPress保守の見直しチェックリスト

13の事例を振り返ると、トラブルの芽は事前の確認でかなり摘むことができます。自社だけで確認できることと、保守会社に聞くべきことに分けて整理しました。

自社で今すぐ確認したいこと

確認する項目	確認の仕方	見落としたときに起きること	関連事例
WordPress・PHPのバージョン	管理画面のダッシュボードとサイトヘルス	更新できない、管理画面に入れない	事例4・5
使っていないサイト・テスト環境	サーバー管理画面のドメイン一覧	放置したサイトから侵入される	事例3
1サーバーに置いているサイト数	サーバー管理画面のドメイン一覧	1サイトの被害が全サイトに広がる	事例2
サーバー・ドメインの名義	契約者情報、ドメインのWhois情報	連絡不通や解約時に手続きできない	事例7・8・9
ログイン情報の保管場所	社内の管理台帳	担当者の退職で誰も触れなくなる	事例6

保守会社に確認したいこと

保守会社と契約している場合は、次の4点を一度確認してみてください。答えが曖昧な場合は、契約内容を見直すタイミングかもしれません。

• 更新の頻度と、本番に反映する前にどこで検証しているか
• バックアップの保存先と世代数、復元テストの実施状況
• サーバーやメール、ドメインまで対応範囲に含まれているか
• 解約した場合、サイト・ドメイン・メールはどうなるか

まとめ

WordPress保守のトラブルは、更新を後回しにした「放置」と、保守会社に預けたまま中身を知らない「任せきり」の2つから起きていました。

改ざんされたサイトでは正常なバックアップが残っておらず、元の状態に戻せないことがあります。保守会社とのトラブルでは、サーバーやドメインの名義が自社にないことが、解決を難しくしていました。

まずはチェックリストで自社サイトの現状を確認してみてください。バージョンが古い、名義が分からない、保守会社の作業内容が見えないといった点が一つでもあれば、トラブルが起きる前に手を打つ価値があります。

サイト引越し屋さんでは、改ざんからの復旧、テスト環境での安全なバージョンアップ、保守会社からの乗り換えに伴うサーバー移転やドメイン移管まで一貫して対応しています。現在の保守会社が行っている対策の調査からでもお受けしていますので、まずはお気軽にご相談ください。