レンタルサーバーでWordPressを安全に更新する方法｜宿主さん向け手順

ロリポップ、さくらのレンタルサーバ、エックスサーバーなどでWordPressを運営している場合、OSや物理サーバーの管理は通常サーバー会社が行います。しかし、WordPress本体、テーマ、プラグイン、記事、管理者アカウントまで自動的に守ってくれるとは限りません。

安全に更新するには、次の三つを一連の作業として行います。

戻せるバックアップを用意する → 一つだけ更新する → 公開画面と予約導線を確認する

この記事では、コマンドを使わず、レンタルサーバーとWordPressの管理画面を中心に進める方法を説明します。

この記事の対象となる環境

サーバー会社の会員・ユーザー専用ページがある
WordPressへは /wp-admin/ からログインする
PHP、データベース、バックアップをサーバー管理画面で設定する
OSやWebサーバーを自分でコマンド更新していない

VPSを自分で管理している場合は、この記事だけでは足りません。まずレンタルサーバーとVPSの違いを確認してください。

二つの管理画面を区別する

サーバー会社の管理画面

契約、ドメイン、SSL、PHP
データベース、ファイル管理
バックアップと復元
WAFなどのセキュリティ

WordPressの管理画面

WordPress本体、テーマ、プラグイン
記事、固定ページ、ユーザー

二つのパスワードを同じにせず、どちらの管理画面で2段階認証を設定できるか確認します。ログイン保護はWordPressログインのBASIC認証・2段階認証で解説しています。

最初に保守契約を確認する

制作会社や保守会社がいる場合は、次を確認します。

WordPress更新は誰の担当か
宿側で操作すると保守対象外にならないか
緊急時の連絡先と受付時間
バックアップと復元を誰が行うか
予約フォームや独自プログラムがあるか

更新通知が表示されても、それだけで宿主さんが作業担当だとは限りません。

更新する日時を決める

予約や問い合わせが増える夜間・休日、チェックイン対応中、キャンペーン直後、担当者が離席する直前は避けます。平日の日中など、更新後に1時間程度の確認時間を取れ、問題が起きたときにサーバー会社や制作者へ連絡できる時間帯を選びます。

更新対象をメモする

対象	現在	更新後	影響する機能	結果
WordPress本体			サイト全体
使用中テーマ			表示
予約プラグイン			在庫・決済
フォーム			問い合わせ
SEO・キャッシュ			検索・速度

更新の詳細を開き、対応するWordPressとPHPのバージョン、主な変更点を確認します。配布元が不明なテーマや長期間更新されていないプラグインは、無理に更新せず制作者へ相談します。

バックアップはファイルとデータベースの両方

WordPressは大きく二つに分かれます。

ファイル：テーマ、プラグイン、画像、設定ファイル
データベース：記事、設定、ユーザー、プラグインのデータ

片方だけでは元に戻らない場合があります。WordPress公式の更新手順も、更新前のバックアップを案内しています。

自動バックアップで確認すること

ファイルとデータベースの両方が対象か
最後に成功した日時
何日分残るか
自分で復元できるか、依頼が必要か
復元料金と所要時間
メールや外部予約システムも含むか

ロリポップのバックアップ復元マニュアルでは、Webサイトとデータベースが別の復元対象です。複数CMSで一つのデータベースを共有している場合、復元によってすべてがバックアップ時点へ上書きされる注意もあります。

「バックアップあり」という表示だけで進めず、更新直前の取得成功を確認します。可能なら本番サーバーとは別の場所にも保存します。

復元方法を更新前に読む

問題が起きてから復元画面を探すと、別サイトを戻す恐れがあります。

対象ドメイン
WordPressの設置フォルダ
データベース名
戻す日時
復元にかかる時間
復元中の予約受付方法

をメモします。復元すると、バックアップ後に入った記事、問い合わせ、予約情報が失われる場合があります。データベースを戻す前に差分を確認します。

更新前の表示を記録する

トップ、客室・料金、猫の紹介、アクセス、お知らせ、予約、問い合わせをパソコンとスマートフォンで開き、画面とURLを保存します。

次の動作も確認します。

予約ボタンを選ぶと、正しい施設・プランのページが開く
テスト用の情報で問い合わせを送信できる
宿側通知と自動返信を受信できる
管理画面へ再ログインできる
SSL警告や404がない

予約テストは本番在庫や決済に影響しない方法を予約サービスへ確認してください。

可能ならテスト環境で先に更新する

ステージングとは、本番サイトを複製して更新を試す場所です。ロリポップのPHP設定マニュアルでも、本番のPHP変更前にステージングで表示と動作を確認する方法が案内されています。

テスト環境は検索結果に表示されないようにし、実在する宿泊者の情報や本番の決済を使いません。テストメールを宿泊者に送らず、テスト環境の内容で本番環境を無条件に上書きしないでください。

更新は一つずつ行う

すべて選択して一括更新すると、原因を特定しにくくなります。製品固有の指示がなければ、次の流れを基本にします。

バックアップ成功を確認
影響の小さいプラグインを一つ更新
管理画面と公開画面を確認
次のプラグインを更新
使用中テーマを更新して表示確認
WordPress本体を更新して全体確認
キャッシュを削除して再確認

予約、決済、会員、フォーム、翻訳、キャッシュ、セキュリティは影響が大きいため、個別に扱います。WordPress公式のプラグイン資料も更新前のバックアップを推奨しています。

更新後の確認表

公開画面

[ ] トップ、客室、料金、アクセスが表示される
[ ] 画像、メニュー、内部リンクが正常
[ ] パソコンとスマートフォンで崩れていない
[ ] SSL警告や404がない

予約・問い合わせ

[ ] 予約ボタンが正しい予約先へ進む
[ ] 空室検索画面が開く
[ ] 問い合わせを送信できる
[ ] 宿側通知と自動返信が届く
[ ] 地図、SNS、OTAリンクが開く

管理画面

[ ] 再ログインできる
[ ] 記事を下書き保存できる
[ ] 更新エラーが残っていない
[ ] サイトヘルスの重大問題が増えていない

更新中のまま止まった場合

更新処理が止まったように見えても、画面の再読み込みや別の更新操作を繰り返さないでください。

発生時刻を記録
別ブラウザで公開ページを確認
サーバー会社の障害情報を見る
エラー画面を保存
制作者またはサーバー会社へ連絡

WordPress公式資料には、メンテナンス表示が残った場合の .maintenance ファイル対応もあります。しかし、場所が分からない宿主さんは自分で削除せず、サポートへ依頼するほうが安全です。

問題が起きたら変更を重ねない

表示崩れを直そうとして、テーマ、PHP、別のプラグインを続けて変えると、原因を特定しにくくなります。更新した対象、更新前後のバージョン、操作時刻、問題のURL、使用した端末、表示されたメッセージ、キャッシュ削除後も再現するかを記録します。

直前の一変更だけを戻せるなら戻し、難しい場合は停止して相談します。

PHP変更は別の日に行う

PHPはWordPressを動かす土台です。PHP変更とWordPress更新を同時に行うと、原因を分けにくくなります。

ロリポップの公式マニュアルも、テーマとプラグインが変更先のPHPバージョンに対応しているか、事前に確認するよう案内しています。サーバーや契約時期によって、利用できるPHPバージョンと元に戻せる範囲が異なります。

現在のPHPを記録
WordPress、テーマ、プラグインを対応版へ更新
バックアップ取得
テスト環境でPHP変更
表示・予約・フォームを確認
本番PHPを変更
反映後に再確認

変更後に元のPHPバージョンへ戻せない場合もあるため、ボタンを押す前に公式マニュアルを読みます。

自動更新をどう考えるか

WordPress公式資料では、プラグイン・テーマごとに自動更新を設定でき、結果はメールで通知されます。

提供元が明確で予約・決済に直接影響せず、自動バックアップと監視があるものは自動更新を検討できます。予約、決済、使用中テーマ、ページビルダー、多言語、会員、キャッシュ、独自改修は、人が確認して更新するほうが安全です。

「全部自動」か「全部手動」ではなく、影響と復旧体制で分けます。

AIへ依頼するプロンプト

レンタルサーバー上の宿のWordPressを更新します。
私はITに詳しくありません。まだ本番変更はしないでください。

最初に読み取りだけで、次を確認する計画を作ってください。
- サーバー会社と契約プラン
- WordPress、PHP、使用中テーマ、プラグインの現在版
- 更新候補と影響する機能
- ファイルとデータベースのバックアップ方法
- 復元方法と、復元で失われる可能性があるデータ
- 予約、問い合わせ、メールのテスト方法

サーバー管理画面とWordPress管理画面を分けて説明してください。
パスワード、顧客情報、APIキーを表示・保存しないでください。
更新、PHP変更、復元は、私が承認するまで実行しないでください。

AIへ管理画面のパスワードをチャットで渡しません。宿主さんが画面を操作するか、安全な実行経路を用意します。