WordPress の管理画面に更新通知がたくさん出ている。でも、ホームページは今も普通に表示されているし、更新して動かなくなったら困る。
そんなとき、更新ボタンを押すのをためらう方もいるでしょう。会社のホームページを引き継いだばかりで、最後にいつ更新したのかも分からなければ、なおさらですよね。
僕は、更新に不安があるときほど、まず現在の状態を整理することが大切だと考えています。そのまま待ち続けても、更新しやすくなるわけではないからです。
長く更新を止めていると、修正されていない問題だけでなく、更新を再開するときに確認する変更も積み上がることがあります。 ただし、何年放置したかだけで、被害の有無や必要な作業が決まるわけでもありません。
この記事では、何が積み上がるのかを整理しながら、長期間更新していないサイトで、どこから手をつければよいのかを考えてみたいと思います。
WordPress は、複数のソフトウェアを組み合わせて動く
最初に、WordPress がどのように動いているか、少しだけ触れておきます。
記事や設定、利用者の情報を管理するのが WordPress 本体です。そこへ、見た目を担うテーマや、フォームなどの機能を追加するプラグインを組み合わせて、ホームページを作っています。
その土台となるのが、サーバー側のソフトウェアです。PHP は WordPress などの処理を実行するためのプログラミング言語で、MySQL や MariaDB は記事・設定を保存するデータベースを管理します。ブラウザーからのアクセスを受け取り、ページなどを返す Web サーバーも関わっています。
名前がいくつも出てきましたが、ここで覚えておきたいのは、それぞれが別々に更新されていくということです。WordPress 本体の更新を止めていても、テーマやプラグインには新しいバージョンが提供され、サーバー側でも PHP などの更新が必要になることがあります。
この組み合わせでうまく動くかどうかが、あとで触れる「互換性」の話です。サーバー側の構成と推奨環境は、WordPress 公式のサーバー要件でも確認できます。
今、問題なく表示されているなら、そのままでもよいのか
WordPress 本体、テーマ、プラグインの更新には、機能の追加だけでなく、不具合やセキュリティ上の問題を修正するものがあります。WordPress 公式も、本体を最新に保つことや、プラグインを更新することを案内しています。
そう聞いても、「今は問題なく使えているのに」と思うかもしれません。ただ、ページが表示できるかどうかだけでは、分からないこともあります。攻撃に利用され得るソフトウェアの弱点を「脆弱性」と呼びますが、通常のページ閲覧だけでは、その有無は判断できません。
更新の重要性は、WordPress 公式の更新案内とプラグインの管理資料でも確認できます。
また、PHP の警告や、今後の利用が推奨されなくなった古い処理についての通知を、画面へ表示せず、ログ (処理中の出来事を記録したファイル) に残す設定もあります。
警告があるから、すぐにサイトが使えなくなるという意味ではありません。ただ、訪問者から見た表示だけでは、テーマやプラグインの処理に見直しが必要かどうかまでは分かりません。
WordPress 公式の問題調査に関する資料では、調査に使う機能と、記録・画面表示の設定が説明されています。内部の状態を調べる必要がある場合は、テスト環境などで担当者に確認してもらうとよいでしょう。
セキュリティについても同じように、画面を見ただけでは判断できません。利用中のバージョンに脆弱性があり、修正版が提供されている場合、更新を止めている間はその修正がサイトへ反映されないままになります。影響の内容や攻撃が成立する条件は、個々の脆弱性によって異なります。
古いから必ず攻撃される、という話ではありません。僕が避けたいと考えているのは、「表示できているから大丈夫」と判断して、必要な修正まで止めてしまうことです。
WordPress のセキュリティ方針では、公式にサポートされるのは最新バージョンのみとされています。古いバージョンにも重要な修正を届ける対応は行われますが、それを前提に、古い状態のまま使い続けてよいとは考えない方がよいです。
更新通知がない場合も確認が必要
更新通知は、提供されている更新を知るための入口です。通知がないことだけで、使っているテーマやプラグインが安全だと判断することはできません。
開発元が更新を提供しなくなった製品では、新しい修正が届かないことも考えられます。公式の製品ページや開発元の案内で、更新履歴、対応する WordPress のバージョン、サポート状況を確認したいところです。
なお、最終更新日が古いという理由だけで、サポート終了や脆弱性の存在を決めつけることも避けましょう。更新通知と、開発元が示す対応状況を合わせて見る必要があります。
更新を止めていた間の変更を、再開するときに確かめる
もうひとつ、今回の記事でお伝えしたいのが、更新を再開するときのことです。
先ほど、WordPress は複数のソフトウェアを組み合わせて動くと書きました。この組み合わせで想定どおり動くかどうかを「互換性」といいます。
WordPress 本体、テーマ、プラグインの更新を長く止めていると、現在使っているものと更新先との間に、多くの変更が含まれる場合があります。設定方法や機能が変わっていれば、その確認も必要になります。
WordPress 公式のプラグイン資料でも、本体の更新後にプラグインが更新されていない場合、互換性がない、または確認できていない可能性があると説明されています。個別製品の対応情報を確認し、実際のサイトで検証することが大切です。
普段から更新していれば、その都度の変更内容と動作を確かめられます。しばらく止めていた場合は、その間の変更をまとめて確認することになるかもしれません。
複数の変更が同時に入ると、問題が起きた際に、どの変更が影響したのかを絞りにくくなります。テーマやプラグインごとに更新先の対応条件を調べ、場合によっては PHP の変更や、一部の機能の置き換えも考えることになります。
更新を止めている間も、あとで確認することまでなくなるわけではありません。 更新通知が何件あるかだけでは、再開に必要な作業の量は分からないのです。
サーバー側の PHP も関係する
サーバー側の PHP は、WordPress 本体だけでなく、テーマやプラグインの処理にも使われます。
古い PHP のままでは、更新先のソフトウェアが求める条件を満たせない場合があります。一方、PHP だけを新しくしても、古いテーマやプラグインがその環境で動くとは限りません。
WordPress のサーバー要件には、推奨環境と、古い環境で動作する条件が区別されています。古い PHP などにはサポートが終了したものもあり、動作することと、継続利用に適した状態であることは同じではありません。
そのため、WordPress の更新と PHP の変更は、別々のボタン操作として考えるより、サイト全体の組み合わせとして検討した方がよいでしょう。変更する順序は、現在の構成と更新先の対応条件によって変わります。
ここまで読むと、古いサイトは作り直した方がよいのでは、と感じるかもしれません。でも、そこも状態を見てから判断したいところです。
更新と小さな修正で使い続けられるサイトもあれば、一部のプラグインの置き換えや、独自に追加されたプログラムの修正が必要なサイトもあります。現在の機能が今後も必要か、更新後も維持できるかを調べてみないと、全面的なリニューアルが必要かどうかは決められません。
選択肢の考え方は、古い WordPress サイトを段階的に改善する方法も参考にしてください。
更新を再開するときは、現状を確かめるところから
では、長く更新していなかったサイトは、どこから手をつければよいのでしょうか。
個人的には、まず「何が動いていて、問題が起きたら誰が戻せるのか」を整理することを優先したいと考えています。ここが分かれば、更新を試す場所や、確認する機能も決めやすくなるからです。
検討する流れは、次の5段階です。
- 現在の構成と、すでに起きている不具合を確認する
- バックアップを取り、保存先と復元方法を確認する
- テスト環境で更新後の動作を確かめる
- 確認結果をもとに、公開中の本番サイトでの更新を段階的に進める
- 更新後の機能を確認し、次回の管理につなげる
これは、すべてのサイトで同じ順序の更新ボタンを押す、という手順ではありません。更新する対象や PHP の変更順序は、構成を確認して決める必要があります。
1. 構成と現在の動作を記録する
まずは、WordPress 本体のバージョン、テーマとプラグインの名前・バージョン、PHP やデータベースのバージョン、サーバーの契約先を確認します。テーマやプラグインの更新履歴と対応状況も調べ、以前の制作者が独自に変更した箇所が分かれば、それも記録します。
このとき、今のサイトがどのように動いているかも残しておきたいところです。たとえば、もともと送信できなくなっていたフォームを更新後に見つけると、今回の更新が原因なのか分からなくなってしまいます。主要ページの表示やフォームの動作を、更新前にも一度確かめておきましょう。
不明な項目は、無理に推測せず「不明」として残して構いません。サーバー情報を確認するために、PHP の設定を変更する必要はありません。
2. バックアップを「戻せるか」まで確認する
バックアップは、問題が起きたときに元の状態へ戻すためのデータです。WordPress の復元には、画像やテーマなどのファイルと、記事・設定などを保存するデータベースの両方が必要です。
「サーバーに自動バックアップがあるはず」という場合も、次のところまで分かっているか見てみてください。
- いつ取得したバックアップか
- ファイルとデータベースが両方含まれているか
- 保存先はどこか、サイト側に問題が起きても取り出せるか
- 誰が復元できるか、必要な権限と手順を把握しているか
- 別の環境で復元し、サイトが動くことを確認できるか
バックアップ機能が有効であることと、必要なときに復元できることは別です。 保存先や復元方法が分からなければ、本番更新の前に確認しましょう。
WordPress 公式のバックアップ資料でも、ファイルとデータベースの両方を保存することや、異なる場所にバックアップを置くことが案内されています。
予約や注文などが蓄積されるサイトでは、復元によってバックアップ取得後のデータが失われる可能性があります。作業中の受付と、復元時の新しいデータの扱いも決める必要があります。
3. テスト環境で、普段の操作を試す
テスト環境 (ステージング環境) は、公開中のサイトとは別にコピーを作り、変更を試すための環境です。
長期間更新していないサイトなら、公開中のサイトでいきなり試す前に、この環境を用意することを検討したいです。まずコピーが元の状態で動くかを確かめ、そのあとで更新を試します。
ここで見たいのは、普段の仕事で使っている操作です。記事を編集できるか、フォームを送信できるか、予約や購入ができるか。ページが表示されたところで終わらず、実際に使う機能を動かしてみます。
WordPress 7.0 向けの公式テストチームの FAQでも、独自のコードや複雑な構成を持つサイトでの事前検証と、ステージングで普段の操作を試す方法が案内されています。
ただし、テスト環境で動けば、本番でも必ず問題が起きないという保証にはなりません。PHP やサーバー設定の違いがないかを確認し、本番でも更新後の確認を行います。
また、テストから顧客へメールを送ったり、実際の決済を行ったりしないよう、外部サービスとの接続を確認してから試してください。環境の作成や設定に自信がない場合は、この段階から相談してよいと思います。
4. 更新の順序と区切りを決める
本番では、テストで確認した組み合わせと手順をもとに進めます。複数の対象を一度に変更するより、確認できる単位で区切ると、問題が起きた際に原因を絞りやすくなります。
WordPress 公式は、複数のバージョンをまたぐ更新について詳細な更新資料を案内しています。そこでは直接更新が可能なことに触れつつ、段階的な更新の検討も示しています。
「段階的」とは、必ず過去の全バージョンを順番に入れるという意味ではありません。WordPress、テーマ、プラグイン、PHP の対応条件を調べ、必要な区切りを決めることです。
既知の脆弱性がある場合は、検証を理由に対応を無期限に延ばさず、影響と緊急性を確認して早めに相談してください。
5. 更新後の確認と、次回の担当を決める
管理画面に「更新しました」と表示されると、ひとまず安心するかもしれません。ただ、そこで作業を終えず、更新前に確かめたページや操作をもう一度見ておきましょう。
主要ページとスマートフォンでの表示に加えて、フォームは送信から管理者への通知、自動返信まで確認します。予約、購入、会員ログイン、サイト内検索など、使っている機能も試してください。担当者が管理画面に入り、記事を編集・保存できるかも確認しておきたいところです。
問題が見つかったら、実行した更新、発生時刻、表示されたエラーを記録し、無闇に変更を重ねず相談しましょう。
そして、次の更新を見る人まで決めておくとよいと思います。更新通知を誰が確認するのか、バックアップをどう確かめるのか、不具合が出たら誰へ連絡するのか。一度更新できたあとも、その流れを続けられるようにしておきたいですね。
構成と復元方法が把握でき、通常の更新を進める段階になったら、安全にアップデートするための確認手順を参考にしてください。継続的な確認項目は、WordPress の保守では毎月何を確認しているのかで整理しています。
分からないところがあれば、更新する前の段階から相談してよい
ここまでの内容を、すべて社内だけで進めなければいけないわけではありません。まずは、分かるところを整理するだけでもよいと思います。
管理画面を閲覧できる権限があれば、更新通知やテーマ・プラグインの一覧を記録できます。主要ページを見たり、契約資料やサーバーの案内からバックアップの保存先を調べたりすることも、最初の一歩になります。
管理画面では、次の場所が確認の入口になります。表示される項目は、WordPress のバージョンや権限によって異なります。
- 「ダッシュボード」→「更新」: 提供されている本体・テーマ・プラグインの更新を確認する
- 「ツール」→「サイトヘルス」: 「ステータス」で注意が必要な項目を、「情報」でテーマ・プラグインやサーバーの構成を確認する
サイトヘルスの公式資料では、構成情報や確認結果の見方が説明されています。問題の表示がなくても、独自の変更やすべての機能の動作まで保証されるわけではないので、実際の操作確認と組み合わせてください。
実際の更新まで自社で進めるには、構成と更新先の対応条件を把握し、復元やテスト、更新後の確認を担当できることが前提になります。長期間更新していない場合は、その前提が揃っているかを先に確かめてください。
特に、次のような状態であれば、更新ボタンを押す前に制作会社や保守担当者と話しておく方がよいでしょう。
- 最後の更新時期や現在の構成が分からない
- バックアップを取り出せない、復元できる人がいない
- 古いテーマやプラグインの対応状況が確認できない
- 独自の変更があり、更新の影響を調べられない
- PHP の変更も必要だが、対応する組み合わせが分からない
- 更新前からエラーがある、身に覚えのない変更が見つかっている
- 予約や購入を止められず、テストや復元時のデータの扱いを決められない
相談前には、サイトの URL、最後に更新したおおよその時期、更新画面のスクリーンショット、サーバーの契約先、バックアップの状況、現在の不具合、止めたくない機能を用意すると話を進めやすくなります。
WordPress とサーバーの管理画面へログインできるか、以前の制作会社と連絡が取れるか、過去の更新でトラブルがあったかも分かれば伝えてください。不明な項目は、そのままで構いません。
僕は、「何をお願いすればよいか分からない」という段階でも、相談してよいと考えています。現在の状態と戻す方法を一緒に整理してから、自社で進めるか、調査や修正を依頼するかを考えればよいからです。
更新を再開したあとも、定期的に変更内容と動作を確かめていけば、次回にまとめて確認する項目を減らしやすくなります。次の更新も進められる状態を維持することが、長く使い続けるためには大切だと思います。
オレインデザインへ相談する場合も、「何年も更新していないけれど、どこから確認すればよいか分からない」という状況をお問い合わせフォームからお知らせください。現在の状態をもとに、調査や更新の進め方についてご相談いただけます。
「更新しないといけないのは分かっているけれど、どう進めたらよいか分からない」。そんなときに、最初の一歩を考える参考になれば嬉しいです。
