気づけば溜まっているWordPressの更新通知…。「更新しなきゃダメなのかな…」と思いつつ、崩れるのが怖かったり、そもそもどう更新するか分からず、放置しているケースが多いかなと思います。
この記事は、そんなちょっと面倒で怖いWordPressサイトの更新を安全に行うための手順をまとめたものです。
先に正直にお伝えすると、この記事は長いです…。更新ボタンを押すだけなら10秒だと思いますが、安全に更新するための準備と確認をすべて含めると、これだけの作業になるということですね。
更新を放置している期間が長いほどサイトが壊れるリスクは高まってくるので、今回の手順を参考に安全に更新していただければと思います。
はじめにお読みください
この記事の手順は、すべての環境で同じ結果になることを保証するものではありません。作業はご自身の責任でお願いします。この手順を参考にして生じた不具合や損失について、責任を負うことはできません。
少しでも不安がある場合は、無理に進めず、制作会社や保守を請け負っている業者に相談することをおすすめします。
なぜ更新が必要か？
更新が必要なのは、WordPressサイト上の問題点を修復して、セキュリティのリスクを減らすためです。
2025年の1年間にWordPressまわりで見つかった脆弱性は11,334件で、そのうち91%がプラグインでした（Patchstack「State of WordPress Security in 2026」）。入れているプラグインの数だけ、狙われる入口があるということですね。更新することで、少しでもリスクを減らしていきましょう。
脆弱性（ぜいじゃくせい）という言葉は、この先もよく出てきます。セキュリティ上の弱点のことだと思って読んでもらえたらと思います。
WordPressサイトの更新対象は大きく4つあります
プラグインの更新が特に大事ですが、他にもWordPress本体、テーマ、そしてPHPの更新も重要です。
| 名前 | 役割 |
|---|---|
| WordPress本体 | 記事を書いたり、ページを作ったりする土台そのもの |
| プラグイン | お問い合わせフォーム、予約、SEOなど、機能を足すもの |
| テーマ | サイトの見た目を決めているもの |
| PHP | WordPressそのものを動かしている、サーバー側のプログラム |
この4つの名前は、これから何度も出てきます。はじめの3つは管理画面のメニューにそのまま並んでいるので、ここで覚えてしまってください。
PHPだけは、WordPressの外側にあります。管理画面からは更新できず、レンタルサーバーの管理画面で切り替えます。
どれも、作った人が改良を続けています。不具合を直したり、新しい機能を足したり、見つかった脆弱性をふさいだり。その成果が「新しいバージョン」として出てきます。
更新とは、いま動いているファイルを、新しいバージョンに入れ替えることです。
新しいバージョンが出ると、管理画面のメニューに数字が出ます。
ダッシュボード → 更新 を開くと、何がいくつ待っているかを見られます。そこで「更新」ボタンを押すと、入れ替えが始まります。
WordPressの自動更新は止めるべき？設定の場所と、おすすめの設定
更新しなくても問題がないように見えてしまう
WordPressを更新していないサイトも、問題なく表示されます。遅くなるわけでも、警告が出るわけでもありません。お客様から何か言われることもありません。
だから「急ぎではない」と感じるかもしれませんが、知らない間に、サイトが攻撃にあっているかもしれないのが怖いところです…。
狙われるかどうかに、サイトの大きさは関係ありません
攻撃する側は、サイトの中身を見て選んでいません。WordPressで動いているサイトを機械的に探して、片っぱしから試しているだけです。規模も業種も関係ありません。
WordPressのセキュリティ対策をちゃんとやるなら考えておきたい6つのこと
公開サイトでいきなり更新するリスク
更新ボタンは、公開中のサイトでそのまま押せますが、とくに長年放置して、たまってしまった更新をまとめて行うときは、慎重に進めたほうが安全です。
更新は、取り消せない操作です
更新ボタンを押すと、新しいバージョンのファイルがダウンロードされて、古いファイルと入れ替わります。
この操作に「元に戻す」ボタンはありません。
新しいバージョンで不具合が出ても、管理画面からボタンひとつで戻すことはできません。サーバーに入っての作業が必要になってしまいます。
実際に起きること
更新で起きる不具合は、だいたいこのあたりに分かれます。
- 「このサイトで重大なエラーが発生しました。」と出る
- レイアウトが崩れる
- お問い合わせフォームが送信できない
- 管理画面に入れない
- 投稿が保存できない
長く放置していた場合は、画面にエラーが出て、サイトが表示されなくなることが多いかなと思います。
なので、公開しているサイトでいきなりエラーにならないように、事前に検証したうえで更新するという手順が安全ということですね。
検証用の環境を作って更新を試そう
いま公開しているサイトとそっくりな環境を手元に作って、そこで先に更新する。壊れたら、そこで直す。問題がないと分かってから、公開サイトに反映する。
少し面倒かもしれませんが、公開しているサイトに問題が起きて焦るよりは、安心して更新できるかと思います。
【事前準備】公開サイトの状態を更新前に記録する
手を動かす前に、今の状態を残します。
これは地味な作業ですが、あとで一番効きます。何かあった時に「元はどうだったか」が分からないと、戻すこともできません。
1. サイトヘルスの情報を保存する
WordPressには、サイトの状態をまとめて見られる機能が最初から入っています。
ツール → サイトヘルス → 情報 タブを開きます。
ここには、サイトが動いている条件がすべて書かれています。あとで検証用の環境を作る時に、この数字を見ながら揃えていきます。
画面の上に「サイト情報をクリップボードにコピー」というボタンがあります。これを押して、テキストファイルに貼り付けて保存しておきます。
特に大事なのは、このあたりです。
| 項目 | 場所 |
|---|---|
| WordPressのバージョン | WordPress |
| サーバー構造 | サーバー |
| Webサーバー | サーバー |
| PHPバージョン | サーバー |
| データベースのバージョン | データベース |
| 使用中のプラグイン | 使用中のプラグイン |
| 現在のテーマ | 現在のテーマ |
特にPHPのバージョンを確認してください
PHPのバージョンが 5 から始まる数字（5.6 など）だった場合は、ご自身で進めるのは、正直むずかしいと思います。
この手順は「公開サイトと同じ環境を手元に作って、そこで先に試す」という形ですが、PHP 5 の環境は作れません。はじめからバージョンの上がった環境で確認することになります。
ところが、その環境でサイトを動かすには、先にテーマやプラグインのコードを直す必要があります。「試してから直す」ではなく「直してから試す」になります。更新の手順というより、コードを書き換える作業が前提になりますので、最初から制作会社への相談をおすすめします。
2. プラグインとテーマのバージョンを控える
プラグイン画面を開いて、スクリーンショットを撮っておきます。
サイトヘルスの情報にもバージョンは載っていますが、画面で見たほうが分かりやすいです。更新後に「どれを上げたんだっけ」となった時、見返すことができるようになります。
3. 主要ページのキャプチャを撮る
更新後に「どこか変わっていないか」を見るための、比較のもとです。
最低限、このあたりを撮っておきます。
- トップページ
- 下層ページを2〜3枚（レイアウトの違うものを選ぶ）
- 一覧ページ（お知らせ、ブログなど）
- 記事の詳細ページ
- お問い合わせフォーム
パソコンサイズの画面とスマートフォンサイズの画面の両方で撮れると、なお安心です。
4. 公開サイトのバックアップを取る
現時点で公開されているサイトのバックアップを取得しておきましょう。いきなり公開サイトを更新することはないですが、作業する中で手順を間違えてエラーになってしまった場合などに、バックアップを取っておくと安心です。
この記事では WPvivid というバックアップのプラグインを使います。無料で、データベースとファイルをまとめて取得できます。
バックアップは自分のパソコンにダウンロードしておきましょう。検証用のサイトを作るときに使います。
WPvividでWordPressサイトのバックアップをクラウド（Google Drive）に自動保存しよう！
公開サイトと同じ検証用の環境を作る
検証用の環境とは、自分のパソコンの中に作るWordPressサイトです。自分しか閲覧しないサイトなので、自由に検証することができます。
※「ローカル環境」と呼ばれることもあります。調べものをする時は、こちらの言葉のほうが見つかりやすいです。
先ほど確認した公開されているサイトと条件を揃えて、手元で検証できるように作っていきましょう。
1. Local をインストールする
検証用の環境を作る方法はいくつかありますが、この記事では Local（ローカル）というソフトを使います。無料で、インストールするだけで使えます。
- Local → https://localwp.com/
ダウンロードしてインストールしたら、起動します。
2. 公開サイトに合わせて作る
Local を起動して、新しいサイトを作ります。進む画面は3つです。
1つめ。「Create a new site」を選んで Continue を押します。
2つめ。サイトの名前を決めます。あとで自分が分かればなんでもかまいません。
3つめ。ここが大事なところです。「Custom」に切り替えると、3つの項目を選べるようになります。
【事前準備】公開サイトの状態を更新前に記録するで保存したサイトヘルスの情報を、となりに開いておきます。左を見ながら、右に同じ値を入れていく形です。
| サイトヘルスのどこを見るか | Local のどこに入れるか | |
|---|---|---|
| 1 | サーバー → PHP バージョン | PHP version |
| 2 | サーバー → Web サーバー | Web server（nginx / Apache） |
| 3 | データベース → サーバーバージョン | Database |
3つめだけ、「サーバー」ではなく「データベース」の中にあります。少し下にスクロールしたところです。
3. 同じ数字がない時は
Local で選べるバージョンは限られています。公開サイトとぴったり同じ番号がないこともあります。
その場合は、近いものを選びます。いちばん合わせたいのはPHPです。Webサーバーは種類（nginx か Apache か）が合っていれば、細かい番号は違っても大きな問題にはなりません。データベースも同じです。
もしかしたら、PHP 7.1〜7.3が選択肢にないかもしれません。その場合は、ひとまず 7.4 を選んで構築できないか試してみてください。
なお、WordPress本体のバージョンは、ここでは気にしなくて大丈夫です。次に行う公開サイトのデータを復元する際に、公開サイトと同じバージョンに置き換わります。
公開サイトのデータを持ってくる
環境ができたら、公開サイトの中身を持ってきます。記事、画像、プラグイン、テーマ、設定。すべてです。
使うのは WPvivid。【事前準備】公開サイトの状態を更新前に記録するでバックアップに使ったのと同じプラグインです。新しく覚えることはありません。
1. 公開サイト側：バックアップを作って、ダウンロードする
- WPvivid Backup → バックアップ & 復元 を開きます
- 「データベース + ファイル (WordPress ファイル)」と「バックアップをローカルに保存する」を選びます
- 青い「バックアップ」ボタンを押します
※手順2の「ローカルに保存する」は、そのサーバーの中に置くという意味です。ソフトの Local とは関係ありません。
終わると、画面の下のバックアップ一覧に出てきます。「ダウンロード」から、自分のパソコンに保存します。
ファイルが複数に分かれていることがあります。全部ダウンロードしてください。1つでも欠けると復元できません。
2. 検証用の環境側：アップロードして、復元する
- Local で作ったWordPressにも WPvivid を入れます
- バックアップ & 復元 の下のほうにある「アップロード」タブを開きます
- 保存したファイルを、点線の枠の中にドラッグします。分かれている場合は全部です
- 「バックアップ」タブに戻ると一覧に出てくるので、「復元」を選びます
※復元すると、WordPress本体のバージョンも公開サイトと同じものに置き換わります。検証用の環境を作ったときのバージョンは残りません。
3. 読み込んだあとにやること
- 公開サイトと同じID・パスワードでログインします（データごと移ってきているため）
- 設定 → パーマリンク設定 を開いて、何も変えずに「変更を保存」を押します
- トップページと下層ページを開いて、表示を確認します
- 画像やリンクが公開サイトのURLのままになっていないか見ます
パーマリンクの保存は、おまじないのように見えますが意味があります。URLの変換ルールが作り直されて、下層ページが404にならなくなります。
公開サイトのURLが残っていた場合は、復元がうまく通っていない可能性があります。もう一度やり直すか、制作会社に見てもらってください。
どの順番で更新するか
更新するものは4つあります。プラグイン・テーマ・WordPress本体・PHPです。
しばらく更新していなかった場合は次のような順番で更新して、更新ごとに問題ないか確認しながら進められると良いかなと思います。
- プラグイン
- テーマ
- WordPress本体
- もう一度プラグイン
- PHP
- もう一度プラグイン
プラグインが3回出てくるのは、本体とPHPを上げたあとに、新しい更新が出てくるためです。
1. 本体とプラグイン、テーマを更新してからPHP
PHPは、5 → 7、7 → 8 と数字が変わると、コードの書き方が変わります。先に本体やプラグイン、テーマのほうを更新してからPHPを更新すると、新しいバージョンに沿った形に修正してくれているので、エラーの数も減るはずです。
PHPを7以下から8以上に上げると、何かしらのエラーが出る可能性はあります。とくに自作のコードや、開発が終わったプラグインで出やすいので、そういった場合は1つずつ修正するか、代替を探していくような形となります。
更新されていない自作のプラグインやテーマが問題になる可能性
よく使われているプラグインは、最新版にすれば新しいPHPで動きます。作っている人が直し続けているからです。
直してくれる人がいないのは、そのサイトのために作られたものです。制作会社が作ったオリジナルのテーマ、その会社専用に作られたプラグイン。こうしたものには更新通知が来ないので、何年前に書かれたままなのか、誰も気づきません。
2. 本体のあと、もう一度プラグインを見る
本体の更新が終わったら、更新画面をもう一度開いてください。本体が古いあいだは更新できなかったプラグインが、更新できるようになっていることがあります。
プラグインの新しいバージョンには「WordPress 7.1以上が必要」のような条件が付いていることがあります（2026年10月時点）。満たしていないあいだは、更新画面にそもそも出てきません。本体を上げたことで、はじめて出てきます。
3. PHPのあと、もう一度プラグインを見る
本体のときと同じことが、PHPでも起きます。プラグインの新しいバージョンには「PHP 8.3以上が必要」のような条件も付いていて、満たしていないと更新画面にこう出ます。
この更新は現在使用中の PHP のバージョンでは動作しません。
更新するボタンは押せません。裏を返すと、PHPを上げないかぎり、そのプラグインは永久に古いままということです。脆弱性が見つかっても、修正版を入れられません。
検証用のサイトでは、PHP 7.4 のままだと Contact Form 7（PHP 8.3 以上）と WP-PageNavi（PHP 8.2 以上）の2つが止められていました（2026年10月時点）。PHPを 8.3 に上げたところ、2つとも更新できるようになりました。
PHPを上げたあとも、もう一度、更新画面を開いてください。ここが最後の拾いどころです。
更新後に何をチェックするか
更新が終わったら、サイトに問題がないかを確認します。主に見るのは、エラーが出ていないか、画面が崩れていないか、フォームは機能しているか、管理画面に問題がないか、といったところです。
1. 画面の表示
いちばん分かりやすいところです。【事前準備】公開サイトの状態を更新前に記録するで撮ったキャプチャと見比べます。
- トップページ
- 下層ページ（レイアウトの違うものを数枚）
- 一覧ページとページ送り
- 記事の詳細ページ
- 404ページ
パソコンとスマートフォンの両方で見ます。スマートフォンだけ崩れる、ということがよくあります。
2. 入力まわり
ここが壊れていると、売上に直結します。
- お問い合わせフォームの送信（実際に送ってみる）
- 自動返信メールが届くか
- 管理者宛の通知メールが届くか
- サイト内検索
- 絞り込み、並び替え
フォームは「画面が出るか」ではなく、実際に送信して、メールが届くところまで確認します。画面は出るのにメールだけ飛ばない、という壊れ方があります。
3. 管理画面
訪問者には見えませんが、ここが壊れると運用が止まります。
- 投稿を開いて、編集して、保存できるか
- メディアに画像をアップロードできるか
- カスタム投稿、カスタムフィールドの入力欄が出ているか
投稿の保存は必ず確認してください。ブロックエディタで保存できない時は、REST APIという仕組みが止まっているサインです。セキュリティ系のプラグインやサーバーの設定が原因のことが多く、放っておくと記事が書けなくなります。
4. エラーの有無
画面上にエラーが出ていないかを見ます。PHPのエラーログの出し方は、問題が出たときの切り分けと修正で説明します。
問題が出たときの切り分けと修正
検証用の環境で壊れたら、それは良かったことと捉えてもらえたらと思います。公開サイトでいきなり更新していたら起きるはずだった問題を未然に防げるということですね。
1. エラーの中身を見る
サイトが落ちると、画面が真っ白になったり「このサイトで重大なエラーが発生しました。」と出たりします。
その場合は具体的なエラーが見たいので、エラーメッセージが出るように設定しましょう。（公開されているサイトで出ると問題ですが、検証用の環境なので問題ありません）
wp-config.php を開いて、以下の行を探します。
define( 'WP_DEBUG', false );false を true に変えて、保存します。
define( 'WP_DEBUG', true );これだけです。もう一度ページを開くと、エラーの中身がそのまま画面に出ます。
長い英語に見えますが、見るのは最後の行だけです。
themes/sample-theme/functions.php→ どのファイルかon line 76→ その何行目か
パスの途中が themes/ ならテーマ、plugins/ ならプラグインです。そのすぐ次がフォルダ名なので、どのテーマ・どのプラグインかまで分かります。
ここまで分かったら、エラーの箇所を直していきます。もし、修正が難しそうなら制作会社に相談すると良いかなと思います。
「Fatal error」と、それ以外
画面に出るものは、2種類あります。見分けは先頭の単語です。
| 先頭 | 意味 | どうするか |
|---|---|---|
Fatal error | そこで止まった。ページが表示されない | 直さないと先に進めない |
DeprecatedNoticeWarning | 古い書き方への注意。ページは表示されている | 慌てなくていい |
Fatal error の修正は必須です。エラーが出たさいは Fatal error に注目して、修正していってもらえたらと思います。
2. 更新が止まっているプラグインは削除か代替を検討
エラーが出ているプラグインが、もうメンテナンスされていない場合は、削除か代替を検討するといいかなと思います。
- 使っていない機能のプラグイン → 消す
- 代わりがあるプラグイン → 乗り換える
- 作者がもう更新していないプラグイン → これを機に外す
更新が止まっているプラグインは、いずれ必ず動かなくなります。壊れたタイミングは、見直すタイミングでもあります。
公開サイトに反映する
検証用のサイトで全て更新して、エラーがない状態を確認したら、公開サイトでも同様に更新していきましょう！
ただし、公開サイトには訪問者がいます。作業中にアクセスされると、おかしな画面を見せてしまいます。段取りを決めておきます。
1. 時間帯を選ぶ
アクセスが少ない時間に作業します。GA4などを見て、自分のサイトの谷の時間を調べておくといいです。
基本的には、営業時間外に対応すると、見ている方への影響も少なくなるかなと思います。
2. 直前にもう一度バックアップを取る
【事前準備】公開サイトの状態を更新前に記録するで取っていても、もう一度取ります。
そこから時間が経っていれば、その間に記事が増えたり、問い合わせが入ったりしています。戻した時に、その分が消えてしまうので、念のため取得しておきましょう。
3. 更新を実行する
検証用の環境で確認した組み合わせを、同じ順番で実行します。
まずは公開サイトが最新の状態になることが大事なので、「ついでにこれも」と足すことなく、検証した内容で更新していきましょう。
4. もう一度チェックする
更新後に何をチェックするかでやったチェックを、公開サイトでもう一周します。
- エラーがないこと
- サイトの表示
- フォームの送信
- 管理画面の動作
5. 戻す判断の基準
公開サイトで問題が出た時、その場で直そうとするか、戻すか。
戻す基準を、作業前に決めておきます。
- 30分で直らなければ戻す
- 訪問者に見える不具合なら、即戻す
- 管理画面だけの不具合なら、営業時間外に直す
その場で判断しようとすると焦るので、事前に決めておくと良いかなと思います。
おわりに
ここまで、WordPressを安全に更新するための手順を、順を追って見てきました。
サイトごとに状況は違うので、すべてをお伝えしきることは難しいのですが、大まかには以下のような流れになるかと思います。
- 今の状態を記録する
- 公開サイトと同じ検証用の環境を作る
- 公開サイトのデータを持ってくる
- 決まった順番で更新する
- 壊れていないか確認する
- 壊れていたら切り分けて直す
- 公開サイトに反映する
正直に書くと、これを毎月やるのは、なかなかの負担です。
慣れればあまり時間をかけずにできるかもしれませんが、はじめのうちは、環境を作るだけで半日以上かかることもあります。
それでも、更新することが大事なのは、セキュリティの被害にあってからでは遅いからですね。サイトを乗っ取られて修復が必要になった場合は、比較にならないほどの時間がかかります。またサイトを作り直すお金も発生します。被害を未然に防ぐ意味でも、更新は大事ということです。
ぜひ、この機会が、WordPressサイトを更新するきっかけになれば嬉しいなと思います。更新にあたってご不安なことや問題があった場合は、お気軽にご連絡いただけますと幸いです。
→ お問い合わせ
